Unfortunately, a large portion of the CVs I see are pretty awful. Here’s some general advice that doesn’t apply specifically to FeedHenry – in fact, it should help in applying to any startup.

Your cover letter, to me at least, isn’t all that important. I’ll probably read two paragraphs worth, and I’m much more likely to read it if it’s in the body of the email rather than in a separate document. This may horrify your careers advisor, but end the email like you’d end any other  - skip the “Yours sincerely”!

Now for the important stuff – the CV. A PDF gets some bonus points – nobody likes having to open Microsoft Word, and there’s a chance some won’t have it installed at all. A typical CV gets about 30 seconds attention. That’s 20 seconds on the first page, a further 10 on the next. This first pass is crucial – if I’m still interested, I’ll then start to read in more detail.
Unless you’ve racked up a lot of industry experience, you shouldn’t have any more than two pages.

Not only is the content important, so is the order. I don’t always make it beyond the first page. Here’s a rough list of what I’m looking for, in order:

• Contact & personal details
  (Including a Github account – don’t have one? Get to work, this is the single greatest value you can add..)
• List your skills – those you know best go first. Feel free to categorise by proficiency, e.g. “Proficient in:”, “Knowledge of:”, or indeed category – e.g. “Programming languages”, “Frameworks”.
• List your personal projects. These are projects you’ve done in your spare time, not as part of professional work or college coursework. Haven’t got any? I’ve probably stopped reading.
• List your relevant industry experience. This doesn’t include that job as a Service Station Attendant 6 years ago where you learnt about responsibility. Don’t care.
• This post quickly reverted to bullets. Your CV should do the same. 

Following these steps won’t work for every company, but for any self-respecting startup, these steps should raise your chances of at least getting to the interview stage. Best of luck!

@cianclarke leads FeedHenry’s development of complex mobile apps build in web technologies. He assists with interview cycles when recruiting engineers to join the services team of the company. This is a cross-post which originally appeared on his personal blog

Traditional enterprise software is giving way to cloud-enabled enterprise apps—partly because enterprise app development and management can be done at a fraction of the cost of traditional enterprise software deployment.

Companies that create “mobile-first” strategies to leverage the new world of mobile apps need to develop, deploy, and manage their apps in a flexible and scalable way. And business units, anxious to develop and release apps that satisfy an end user need, can easily build an app completely independent of IT, pulling authority away from IT to control how business data is being consumed.

The shifting role of IT in this new, ultra-mobile, app-driven world is evident: rather than being the gatekeeper to data, IT is becoming a business enabler. IT plays a critical role in giving organizations the flexibility to create compelling and transformative apps—and also control the movement of business data, a core focus for IT.

Enter FeedHenry. Our cloud-based mobile application development platform enables IT to regain control over mobile app initiatives so that access to critical business data is always secure. FeedHenry’s cloud-based platform allows developer to build the client-side code that goes on the device and, from the same platform, allow IT to build the cloud or server-side code that connects that app to the business data. With FeedHenry, businesses are empowered to create great apps while IT still gets to control all data security touch points—all from one central mobile application platform.

It’s clear that new mobile technologies have led to faster, more affordable, easier mobile app development. Gone are the large-scale enterprise software deployments. Gone is the traditional IT dictatorship. It’s time to embrace next generation software and the IT enablers that make it happen.

That important part of our Mobile Application Platform is called mobile Backend-as-a-Service or mBaaS where, with our open architecture and a variety of APIs, we make it possible to have rapid integration, secure connections and management of the apps and endpoints.

Our open architecture based on Node.js, in the cloud-based mBaaS, allows the platform to easily integrate to third party web services. Developers can choose and quickly integrate the best software available to complement the functionality of their mobile app. SendGrid, for example is a cloud-based service that provides comprehensive email infrastructure capabilities to enable developers to add email delivery functionality to their mobile apps without the need to build and maintain an email infrastructure.

SendGrid is a cloud-based SMTP email provider that allows email capabilities without having to maintain email infrastructure (software and hardware). SendGrid relieves development teams of the cost and complexity of managing and monitoring their applications’ underlying transactional email management infrastructures, freeing them to build great applications without worrying about email delivery rates, spam folders, ISP blacklists or scaling to meet high user volume.

At FeedHenry, we constantly receive inquiries about email functionality for iOS and Android apps, and it is quite a task to develop the functionality from scratch, not to mention the infrastructure behind sending and receiving emails.  In many cases, developers settle with just adding a link to access text messaging or letting users leave the app to send or check emails on Gmail, Yahoo! Mail and others. Calling SendGrid APIs is easy, just change your email configuration to point to SendGrid servers and with your SendGrid account credentials you are ready to test and deliver a mobile app with email features.

FeedHenry’s cloud-based mBaaS integrated with SendGrid enriches the possibilities for good, secure lightweight apps and superior email deliverability.

Sign up now for SendGrid on FeedHenry: http://www.feedhenry.com/partner/sendgrid/

FeedHenry embraces the two single biggest world trends in Information Technology today;  mobile apps and the cloud     

There’s no secret that we live in the mobile era, all over the world smartphone market penetration keeps growing and in some countries tablets are selling more than desktop computers and laptops.  Everything in the mobile industry is evolving, more than 100 mobile operators around the world are now offering 4G speeds, WiFi hotspots are everywhere and it is almost impossible to be at an airport, in a restaurant or any workplace without noticing smartphones and tablets in use.

Technology has made mobile devices smaller more powerful and with a variety of features, and users are consuming all those technology improvements through mobile apps. Yes, there are millions of apps now from gaming and social media to shopping and banking, and this explosion of data being consumed through mobile devices has had an impact on business. Not only from the commercial point of view, with companies offering products and services through their apps but also it has forced enterprises to look at the benefits of apps designed for employees to improve productivity and reduce costs. In many businesses this is now as important as is reaching customers via mobile devices.

In parallel to this new mobile reality, companies around the world have been embracing cloud computing and the adoption of cloud based applications continues to grow.  Rackspace as market leader in Infrastructure-as-a-Service has seen significant growth in the adoption of cloud computing thanks to the many benefits that cloud offers businesses – from having a pool of resources available on virtual servers and the cost savings these represent to the fact that the infrastructure is hosted and maintained without capital expenditures.

All of this brings us back to embracing the two single biggest world trends in Information Technology; mobile and cloud, especially for enterprise mobile apps.

Enterprises that are looking to provide mobile access to their employees and/or partners (B2E and B2B) require access to systems already in the cloud – access to a number of backend systems such as CRMs, ERPs and other internal systems. This of course is slightly different when we talk about consumer apps (B2C), where the mobile app may require information to and from a small number of backend systems, for example a product catalog database or a payment system.

Regardless of the goal to have B2E, B2B or B2C enterprise mobile apps, there are challenges with making critical business information available to mobile users.

Enterprise mobile app challenges:

Integration

• Multiple backend systems
• Legacy systems
• Cloud services

Security

• VPNs
• LDAP
• Encryptions

Scalability

• Going from a few users to thousands even millions for consumer apps
• Integrating with more systems
• Integrating with data warehouses
• More app features

 Multi-platform Devices

• iOS, iPhones and iPads  versions
• Android phones and tablets
• Blackberries
• Windows phones

Frequent updates

• On backend systems
• On app user interface
• Push notifications
• App content changes
• Online – Offline synchronization

 Monitoring and Analytics

• APIs monitoring (endpoints)
• Users downloads and access
• Resources performance

FeedHenry’s mobile application platform is an ideal solution to develop, integrate, deploy and manage enterprise apps, and offers organizations the ability to rapidly create complex enterprise apps that integrate with multiple backend systems and cloud services that covers all the challenges previously mentioned. Development teams must overcome all these challenges and deliver critical functionality quickly for multiple platforms and most importantly they have to connect in a secure way with all backend, third party and legacy systems.

FeedHenry’s Mobile Application Platform on Rackspace infrastructure provides a development and hosting platform that extends Rackspace to the mobile app space. Rackspace, the market leader in Infrastructure-as-a-Service, provides a secure and scalable infrastructure environment with industry leading technical support. Their service is built upon an open standards approach that makes it a perfect match to host FeedHenry’s platform on Public Managed clouds, Private clouds or Hybrid clouds

FeedHenry Mobile Application Platform Overview

FeedHenry’s Mobile Application Platform offers an open and flexible environment with the following features:

App Development & Testing Studio

Allow developers to quickly and easily develop HTML5 and Hybrid apps that can be deployed to multiple devices or create native iOS and Android apps. Developers can design templates and toolkits to speed up build time and use many of the available client side and server side APIs.

Mobile Backend-as-a-Service

Enables full access to cloud services such as storage, security, caching, server-side business logic, and data sync. Backend integration is made easier and more efficient with standards-based server-side code on FeedHenry’s cloud based platform. No more mobile devices connecting directly to Enterprise backend systems posing risks to sensitive business data or re-building apps every time there is a change in the backend system.

Mobile App Management

Provides the enterprise with the tools needed to manage all mobile enterprise apps in one place, for example, allows administrators to distribute apps via a private app store, manage users access by corporate Active Directory and/or LDAP access and allows external users access via OAuth access such as Google, Twitter, Linkedin and Yahoo. Other important feature includes remote data wipe to remove data in case of mobile device lost or employment termination.

Analytics

Reporting and Analytics provides key insights in two areas: a) cloud app statistics about consumed resources, CPU utilized, endpoints performances and other cloud infrastructure performance of the different mobile apps and b) reporting on app usage such as number of downloads, app traffic, per platform, per location, etc.

Cloud Deployment

Server-side code can be deployed to different RackSpace cloud environments, offering organizations the flexibility to deploy apps in their chosen cloud infrastructure (Public, Private, Hybrid) or choice of PaaS environment. If the Enterprise already uses a Platform-as-a-Service with Rackspace infrastructure, FeedHenry’s platform provides the ability to deploy the server-side code and associated cache to any Cloud Foundry based PaaS (whether on-premise or elsewhere), opening up an emerging ecosystem of PaaS partners such as AppFog, ActiveState’s Stackato, Tier3’s IronFoundry and VMware.

Security

Supports both on device and backend encryption, user authentication and authorization at device, app and cloud level.  FeedHenry’s platform allows you to open end-points securely to FeedHenry server-side requests with 128 or 256 bit encryption using AES or RSA algorithms as well as auditing capabilities.

Scalable Architecture

As the app features, number of integrations and user base grows FeedHenry’s platform is designed with the flexibility to scale up cloud resources without re-engineering the app or cloud integrations.  Our platform is based on node.js technology that uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

App Build Farm

Deploy app-store ready apps using your own developer credential but without the need to maintain native development environment, for example, you can create iOS apps without a Mac because the FeedHenry platform has multiple build farms on the cloud for the different platforms (iOS, Android, Blackberry, etc.) and takes care of all the wrapping, creating the binaries that are then ready for each mobile device and version.

In summary enterprises can benefit from a mobile app platform that offers maximum flexibility and scalability, ease of integration with backend systems, rapid deployment, light-weight apps due useful functions on the server-side code and the ability to choose from a variety of cloud configurations for cost effective storage and security.

Request a demo through our Sales team at  sales@feedhenry.com  or  go to www.feedhenry.com for more information.

A well-executed mobile app strategy results in improved employee efficiency, reduction in costs and the potential to increase customer engagement and revenue generation.  However, it’s not as simple as it seems. Enterprises face serious challenges, not only in keeping up with the demands to develop new and more complex apps but also in ensuring the security, scaling and management of those apps. Enterprises have turned to Mobile Application Platforms (MAP) as an end to end  solution for the development, deployment, integration and management of these apps.

However to create truly effective apps, organizations need solutions that tie in to their cloud strategy, driving the need for a mobile app platform (MAP) that can deploy server-side code wherever the enterprise needs it, whether that’s a public or private cloud. A successful MAP needs to offer maximum flexibility and ease of deployment to different cloud and PaaS environments.  Then enterprise app developers can create, deploy and manage their apps on a secure and scalable platform without having to worry about cloud configuration, scaling, or lifetime management.

Why do Enterprises favor a Mobile Application Platform approach?

As enterprise mobility has matured, organizations are creating a growing number of apps that require integration with cloud, legacy and third party systems. Most importantly these disparate systems must be presented as a unified experience for the end user. Once the apps are shipped the organisation must then deal with  with app management, security and scaling over the lifetime of the app deployment. Mobile apps have now been elevated from being a tactical marketing tool to being a strategic business initiative that needs to align with the overall business strategy.

FeedHenry addresses the need for a well integrated mobile and cloud strategy with their Mobile Application Platform. The FeedHenry platform supports an end to end lifecycle model that includes:

• app design and development
• Secure connectivity via HTTPS and/or PKI infrastructure
• Integration with back end systems via our proxy layer and Node.js business logic
• Analytics insight on both client and server

The platform is built on an Open Source stack that includes Phonegap, CloudFoundry, Mongo, Redis and MySQL. For client side development we support  HTML5, Native SDKs and hybrid app development for all major mobile devices and form factors.

Most importantly we believe in a philosophy of “any cloud”. So we can host FeedHenry anywhere you can supply a suite of Linux instances, whether private, public or hybrid.

In FeedHenry you actually can have it your way

FeedHenry Mobile Application Platform Architecture

The hosted Mobile App Development and Testing environment allows enterprises develop HTML5 and hybrid apps that can be deployed to multiple devices (iOS, Android, Blackberry, and Windows Phone) and mobile web in a “build once, run everywhere” fashion. But  we don’t have HTML5 religion, Developers are  can use our native SDKs to build apps “the hard way” .

For Enterprises we offer a Mobile Application Management suite that allows them to distribute apps via a private app store, control access via logins control by corporate Active Directory and/or LDAP access and finally allows external users access via OAuth access such as that used by Google, Twitter, Linkedin and Yahoo. Once a user leaves the organisation we can wipe the data remotely for specific FeedHenry apps without interfering with the rest of the end-users data.

The platform’s Mobile Application Cloud meets the critical needs of enterprise mobility. The mobile Backend-as-a-Service (mBaaS) enables full access to cloud services such as storage, security, caching, server-side business logic, and data syncing. Rather than the app on-device connecting directly to backend systems and posing risks to sensitive business data, it does so via the cloud.

The Mobile Proxy Layer provides a hosted JavaScript Node.js layer with local caching.  At its simplest this secures internal enterprise end-points, via a mobile proxy layer, avoiding the enterprise end-points being open to the Internet, and improves performance, by caching the results.  However, the server-side can be much more complex if required, for example, transformation of XML into JSON, or other server-side business logic.

A key feature of the FeedHenry platform is the ability to deploy this server-side JavaScript and its associated cache to any Cloud Foundry (CF) PaaS (whether on-premise or elsewhere), opening up an emerging ecosystem of CF PaaS partners such as HP Cloud’s Application PaaS, AppFog, ActiveState’s Stackato, Tier3’s IronFoundry, DELL’s Fast PaaS and VMware, the creator of CF.

This means that any public or private IaaS provider can be used, including VMware’s vSphere, HP Cloud Services, Telefónica Instant Servers, Joyent Cloud, Rackspace Cloud Servers and Apache AWS.  Anywhere you can deploy a set of Cloud Foundry Virtual Machines (VMs) can become the staging target for your server-side code, managed by FeedHenry.

Currently, FeedHenry enables enterprise developers to deploy their server-side code to both public and private cloud and PaaS environments with a single click. The platform is also offered as a cloud service on HP Cloud at https://hpcs.feedhenry.com/ and on public Cloud Foundry at https://mobilecf.feedhenry.com/.

FHC

The first tool of choice is our Command Line Interface (CLI). FHC allows you to list, create, build and deploy applications in FeedHenry from the command line. Why is this a power user feature? Most power users prefer to be able to perform tasks through a few keystrokes on a command line, rather than through a visual UI. Here are a few popular use cases for FHC:

• A SCM system that doesn’t support post receive hooks to automatically pull code after a checkin?

  fhc git pull someAppID

• Find yourself frequently creating a series of iPhone and Android builds for distribution Over The Air (OTA)? Build a shell script that kicks these builds off through FHC, come back once done
• Want to search through log output of an app in a live environment?

  fhc logs someAppID | grep -i 'ERROR: '

• Need to quickly apply a hotfix?

  git push origin release
  fhc git pull someAppID
  fhc stage someAppID --live

Aliases

To make the use of FHC more useful, we make use of aliases. The ID assigned to an app is really long – and while we can copy and paste, it’s nice to be able to alias it to something else. Setting up an alias is simple:

fhc alias myapp=sX7ITIjMxxLiZllZi0rRWHrM

Now, we can run commands like

fhc logs myapp

Working Locally

Another very useful power user feature of FHC is fhc local. Local allows developers to work on their app offline. To get set up for working locally, we first need to install dependencies, as you would with any Node.js application. To do this:

cd cloud
npm install -d
cd ..

Now, we’re good to go. We simply run

fhc local

and open http://127.0.0.1:8888 (localhost) in our web browser. What this does in the background is runs the main.js cloud code from your cloud directory locally as a Node.js process, and also runs a webserver serving up the files in client/default/index.html.

There’s many options available too, such as watching the local file system for changes, proxying requests through to the FeedHenry live environment rather than running the app locally and applying packages. To see all the options available, run

fhc local --help

Using Over The Air (OTA)

OTA makes installing builds on device much quicker. This feature is available for all Android developers, but only those in possession of an iOS Enterprise Development account ($299/yr rather than $99/yr) can sign apps Over The Air. To do this, you need to use a Distribution Certificate & Private Key, along with an In-House provisioning profile. Once these resources are uploaded to your account, you can use fhc ota to generate OTA builds, and builds in the studio will also show an OTA install URl.

Using Git

In a team-based environment, using some form of SCM is vital to the success of the project. We use git.

Usually, we’ll have sprint branches, where the user stories for that sprint are checked in. All developers work off this sprint. Developers will develop and test code locally using fhc local (described above), and once done commit it to the repository.
To make sure we don’t need to git pull our app every time, we use a post receive hook – this tells FeedHenry to grab the latest code on every commit.

Releases are done off either master or, more than likely, a release branch. The reason for using a release branch rather than master is it’s too easy to accidentally check into master.
We have a corresponding FeedHenry studio app for ‘dev’ and ‘release’ – one of which points to the latest sprint branch, the other the release branch. When we’re ready to ship new code, the sprint branch gets merged into release. We then stage the cloud code, and generate builds, both from the live project in FeedHenry.

A new breed of Mobile Application Development Platforms enables companies to develop, test and deploy apps that are less tied-in to specific mobile operating systems. Often referred to as cross-platform or hybrid app development, these platforms allow apps to be built once, in a standard language, and then run on a range of devices. This cuts development time and costs while maintaining all the on-device functionality of an app created using a single, native development language.

But there’s more to the challenge of BYOD than compatibility issues.

For businesses there’s the additional problem of security. If people are using business apps on their own smartphones or tablets, what happens if a device gets lost or stolen? What happens if they leave the company? How can an organisation ensure that sensitive internal data is protected? How is it separated from personal data? And how can they be sure that the app integrates securely with internal business systems?

The answer lies in the cloud. Users can have a “thin client” – a lightweight app on their smartphone or tablet that pulls and ring-fences all of the complex functions and information they need from the secure cloud.

Using a cloud-based Mobile Application Platform to develop an app, there’s no need to store sensitive data on the device itself, so there’s much less risk if the device is lost or stolen. The cloud stores the data and delivers it to the device. Basically – it does all of the leg work.

Business apps often require higher degrees of integration with IT systems and third-party services than consumer and gaming apps. Traditional business applications (such as CRM, ERP and Supply Chain Management) are now being mobilised and take advantage of device features such as geolocation and cameras, as well as services like social media and payments processing. Developing an app that securely integrates with these systems requires a server-side infrastructure. The cloud is the perfect model to support this and handles all of the integration, storage, security, and data push and synchronisation.

Gone are the days of the large-scale, capital-intensive applications projects. Innovation in cloud technologies and the advent of mobile apps now give businesses immense opportunities to implement high-value – yet low-cost – mobile apps, often on a monthly software-as-a-service type model.

Apps can deliver great value to business – whether they are customer-facing or employee apps. Barriers such as security, integration and upgrading can be overcome with smart use of the cloud. We can look forward to a world where apps and mobile devices become the standard business tool and the cloud is the power behind them.

But how does a business go about kick-starting or pushing forward their mobile app strategies? One way to approach it is to look to an initiative such as O2 made-to-measure apps”. Through partnerships with leading service providers, we bring together all the skills and resources needed for your business to leverage the power of mobile apps.

To find out more about BYOD, mobile apps and Made-to-Measure apps from O2, see more here

Find out more about FeedHenry’s Mobile Application Platform

We deploy lots of cloud infrastructure at FeedHenry in both public and private cloud environments. What gets confusing is when our customers use their private cloud to provide a public cloud service. When this happens my head hurts a little, so I thought I would put down some thoughts on this space to clear the ideas in my own head and hopefully help our customers and partners to get a grip of this whole public/private cloud conundrum.
First of all let’s stop using the term cloud as this confuses people with the fluffy white things that float above us. Let’s use the term cloud service in its place. A cloud service is something that provides utility to its users.

Here is a simple definition of a cloud service:

A public cloud service is any utility service that is accessible via a public network address.

We ignore protocol (HTTP, HTTPS, DNS, TCP/IP etc.) and naming conventions. This definition encompasses “cloud” services that predate the term cloud, specifically Time services, DNS, Internet routing services, FTP servers, Network News, WAIS, gopher, archie and a host of other “cloud” services that existed before the creation of the world wide web and the HTTP protocol.

This gives us a simple corollary definition for a private cloud service:

A private cloud service is any utility service that is only accessible using only a private network address.

Note that this private network may well be tunnelling over a public network using a VPN. However, most people feel uncomfortable with this definition. It seems to lack substance in some way. So lets put some meat on the bone.

Cloud Services fall into two camps: those with decentralized  administrative control (e.g. DNS, bit-torrent, Napster, NTP) and those with centralized administrative control (e.g. Facebook, Amazon AWS, Google).  It turns out decentralized administrative control also makes it easy to distribute the workload of those services so that many separate administrative domains contribute to the overall provision of service.

However, decentralized administrative control and Enterprise data management go together like ice-cream and ashes.

Enterprises need to know the who, what, when, where and how much of data. Who has access to what data, when and from where? How much data do they have access to? How much does it cost?

Decentralised data leaks. Decentralised data accumulates. Decentralised data rots.

Historically Enterprises used the “watch that basket” approach. Which is to say they put all their eggs in one basket (their own data centre) and kept a close eye on it via administrative controls, an IT department, Firewalls and VPNs.

Unfortunately, IT departments have two key drivers; cost management and SLA management.  Cost management is usually translated into “lets keep our costs flat/predictable for the budget period in question” and SLA management is translated into “lets provision for the maximum expected spike in the budget period in question”.

Business Units on the other hand are driven by innovation and change and want new IT systems to help drive that change.  So there is a dynamic tension been centralized service provision by the IT department vs innovation at the edges by the most aggressive business units. This typically leads to new technologies bleeding into the organization regardless of technology directives set by the over-arching organization. To wit the famous clarion call “We are an Oracle|Microsoft|IBM|HP|SAP house” while Macs, Linux, MySQL, Apache, PHP and others are being smuggled in the back door.

Well the latest innovation being smuggled in the back door is cloud computing. It turns out that convenience trumps security so sales directors have been injecting SalesForce.com into their organizations for over ten years now. Workday is targeting the whole tamale with a complete “in the cloud” HRM system. IaaS systems like AWS and RackSpace and PaaS systems like Google App Engine, Force.com and Azure offer unlimited storage and compute power at sub-dollar prices per hour.

The price is right for public clouds but the access controls and cost management freak out Enterprises. Particularly in the face of legal minefields like the Patriot Act.

Private Clouds offer the best of both worlds with the ability to leverage the scalable nature of clouds with the absolute control enabled by owning the physical hardware. The key properties of private clouds that make them attractive to Enterprises are:

• You can cut the hard-line
• You can physically take it with you
• You can audit all access

With the best will in world you just can’t tell how many copies of your data exist within AWS or RackSpace or Azure and what happens to them and when after a delete operation has been processed. This is what drives CIO’s crazy about public clouds. The cost savings are wonderful and the absence of a mammoth capex bill is a joy, but the “who, what, when, where and how much” is a black hole that is difficult to audit in meaningful way.

I’ve talked about public cloud problems before (and before anyone gets the wrong idea I’m a huge fan of AWS) but to recap there are four areas that public clouds can get you into trouble around:

• The Data Problem : What goes up must come down. Once you have over 1TB of data in the cloud getting it back all at once and deleting it so its definitely gone is a huge issue.
• The Britney Spears Problem : If you are a recognizable personality storing your stuff in the cloud them the likelihood is that you unsecured data is at risk from operations personnel on the inside.
• The Programmer Problem: Per transaction pricing is great until some programmer writes a program that generates a million transactions an hour. Programmers have to understand the implications of pay as you go.
• The Doctor Problem : HIPAA in the US and a range of other legal devices in Europe impose stringent data protection requirements on individuals and organizations that store medical data. The privacy problems associated with UK Summary Care Record scheme have been well documented. At the heart of the problem is the need for a large pool of people to have shared access to high confidential data.
• The End User Problem: End users consistently fail to realize that in a cloud environment their poor security practices can compromise other people’s data rights. Poor passwords, duplicate passwords and shared passwords are only the tip of the iceberg.
• The Failure Problem: Clouds go down. Your cloud is going to fail or you are going to fail to use the cloud correctly. For the end-user the end result is the same, interruptions in service and/or loss of data. Microsoft, Amazon, Google and Rackspace have all had major cloud outages in the past 12 months and will continue to do so.

Private Clouds are not a panacea in all these situations but its a big step in the right direction and that gives CIO’s a few more minutes sleep at night.

Iteration velocity is not a constant

When building a product, eventually the team will reach a plateau where iteration velocity can be accurately measured. It becomes easy to define just how much can be delivered in N number of weeks, before it’s time to sit back, review, and plan the next set of deliverables.

In a services based environment, this isn’t always the case. Iteration velocity varies from project to project, and depends on the duration, scale, and level of developer experience. Velocity can vary massively, from wildly productive to utterly blocked by an API that hasn’t become available. The team, and the agile process, needs to be able to adapt to this consideration.

Team size varies

Agile product development usually centers around a core team of developers, who may be working on separate features. In a services team, we’re still one team – but project assignment can change from week to week, depending on project workload. Ideally, a developer is assigned to one project throughout its course – but in the event of blockers the team needs to be pretty flexible.

Scrum

When it comes to scrum, the rules stay pretty much the same. It might seem that when different team members are working on different customer projects, what benefit could a group standup possibly bring – but in reality, we’re often solving similar problems in a slightly different shape or form. Scrum is hugely beneficial, just the same as it would be in a services environment.
The logistics don’t differ either – updates are sub-30 seconds, scrum master is rotated & is responsible for keeping on top of any blockers.

The traditional rules still apply

1) Unit Tests

Unit tests are still an essential part of the development cycle of a services team. In particular, unit testing the cloud side integrations of a project can be a huge lifesaver. In the event something goes wrong, the unit tests can often help quickly pinpoint the exact source of a problem. You can read more about how we unit test cloud applications here.

One of the things we’ve recently worked hard on improving is how we unit test client side JavaScript logic – the part of the app that sits on device. In particular, we’ve focused on testing any complicated pieces of business logic that exist on the client. The principles are similar to those of cloud unit tests – given a certain input X, we expect output Y  succeed and return these properties.

3) Pulling it all together: Continuous Integration

In a services environment, the list of projects to be added to the Continuous Integration box is ever growing. A project is developed for a period of N weeks, then released & the codebase is static until some future phase of the project. This can be quite different to a product based team, and it means the setup cost of adding an app to a Continuous Integration server has to be incredibly low for the developer. To ensure this, our CI setup process simply involves the developer creating a simple shell script which can test various parts of the application. A typical build.sh script might look like this:

Our continuous integration server (Jenkins) then runs this shell script, which sets the current execution environment of Node to the cloud directory (to ensure relative paths work as expected).
Once it’s ready to run the node code, it pulls together 1) and 2) above – running the unit tests, and JSHint.

In the event the tests fail, a lead developer (or the whole team) get emailed a report and the build is marked unstable.

If you’re actively practicing agile in a services environment, we’d love to hear how you’ve managed this in your team! Any comments or suggestions, please reach out in the comments.

Cian leads FeedHenry’s development of complex mobile apps built in web technologies. He is the author of numerous Node.js modules, and is an active open source contributor. Find him on twitter @cianclarke, or github

The FeedHenry App Studio in its old form was built primarily on jQuery, jQuery-UI and numerous jQuery plugins. The main plugins used were Accordion, Tabs, Button, Dialog, jWizard, jqGrid and UI-Layout. On top of this, there was a tonne of custom CSS classes, id’s and styles. It was (and still is) a big project with a lot of files. Despite this, it did what it was required to do i.e. Provide a frontend to the FeedHenry Cloud platform.

Why change? It works!

Yes, it did work, but had some problems. It had problems from both the User’s (your) and Developer’s (our) point of view. The UI was dated looking and needed some love. We made a choice a few years back to create the studio as a single page application (jQuery UI-Layout). As it evolved, this choice proved troublesome as we added new elements like metrics and reporting. In fact, any new features that were added had to fit strict size constraints. It was a pain, but we did it nonetheless.

jQuery UI was great at the time, but didn’t do enough for the general look and feel of the Studio. We still ended up adding custom classes and styles for a lot of things. This led to confusion between class conventions and patterns, and ultimately led to multiple classes all doing similar things. The level of selector reuse was bad.

The javascript was a similar story. There was no strict pattern followed throughout the Studio code. Instead, there were small pockets of patterns as various features were added over the years. Some patterns matched, but in general the code was badly structured. We used John Resig’s javascript inheritance ‘Class.extend’ http://ejohn.org/blog/simple-javascript-inheritance in some parts, and functions with public & private members in other parts (similar to how Douglas Crockford describes private members http://javascript.crockford.com/private.html). There were some nice sub-patterns in the code, particularly around the auto creation & binding of the tabs (‘north’ layout), each with an accordion (in the ‘west’ layout) that controlled the main content shown in the ‘center’ layout. As it was a single page application, the footer sat in the ‘south’ layout.

From a User’s point of view, the UI needed to be overhauled to give a nicer experience. From our point of view, the code needed restructuring and simplifying to make maintenance easier and more fun. A good knock-on-effect of this, as we discovered, would be speed improvements, particularly the initial load time of the Studio and the time it takes to switch tabs.

Out with the old…

We used Bootstrap http://twitter.github.com/bootstrap/ before for the Docs site http://docs.feedhenry.com and landing pages on https://hpcs.feedhenry.com and https://mobilecf.feedhenry.com. It worked well and provided a nice UI layout out of the box. It was a good fit for what we wanted to do with the Studio UI. So while we replaced the old jQuery UI components with the shiny new Bootstrap equivalent, we also untangled and rewired as much of the coding mess as possible. We made a big leap towards an MVC pattern everywhere.

For those who are interested in what we replaced the jQuery UI/plugin components with, here’s a table:

Also, some other Bootstrap components we used in place of our old custom code/styles:

• Breadcrumbs (custom styles before)
• Forms (custom form & input styles before)
• Font-Awesome icons in nav list (no icons before in accordions)
• Transitions (no transition before, anywhere)

Where did the magic go?

Wizards haven’t changed at this time. There’s still one old plugin in use because the migration for it is a big task on its own. The jQuery jWizard plugin is heavily integrated into the UI. The plugin was also modified to allow showing and hiding buttons at different steps in the wizard. Before we make a decision on this, we need to ask ourselves if wizards are the most appropriate solution. Should we even use a modal dialog for them (we don’t in some places already)? Should all the wizard steps be presented on a single screen (currently only do this for ‘Generate App’)? Watch this space…