We've just moved into a new office near Kings Cross station, towards Exmouth Market. If you're in the area, pop in for a chat. 

View Larger Map

Permalink | Leave a comment  »

Most of us know that documentation is a fundamental part of any software project, but we've also learned through experience that producing too much documentation of the wrong kind can be a waste of time. The aim of rapid development is to minimize waste and achieve lean, elegant processes as well as software.  The key to effective documentation is knowing how to record organizational memory without limiting the creative process during development or imposing excessive cost on the organization.

This article will explore several types of documentation and their relative effectiveness for application development throughout the project life cycle: pre-development, during development, and post-development. 

Permalink | Leave a comment  »

When contacted by potential clients, we are often presented with diverse  information including  links to competitors' sites, prototypes, feature lists, or wireframes, while other clients may come to us with just an idea.  However, presenting details of your vision clearly in writing will lead to a better web application. This will also enable professionals to more accurately estimate  the time and costs necessary to implement your ideas.

So how can you best identify the features and functionality you need when looking to build a new web application? Let's consider the three main formats for doing this: Wireframes, Feature Lists and User Stories.

Wireframes
A wireframe is a visual representation of your ideas which can act as a design brief.  Wireframes are simple guides that lay out the structure of a single web page or an entire.

There is software available that allows you to draw wireframes. Though wireframe software is user-friendly, allowing users to  make changes with ease, it tends to encourage  a lot of detail. Simple pen and paper drawings typically provide more highlevel wireframes and thus do not inhibit the thought process.  Some good examples of pen and paper as well as digital wireframes can be found on the Wireframe Showcase. 

If at all possible, get your designer involved in wireframing, as the professional eye of a web designer will help you produce a more realistic and usable layout, allowing the developer to realise your concepts most accurately and efficiently.

Pros:

• Wireframes help the designer visualise the concept and develop an accurate idea of what needs to be designed.
• Wireframes show the developer which features are on each page.
• As many clients find it easier to convey ideas visually rather than verbally, you may be less likely to omit features with wireframes.

Cons:

• If you complete the wireframe independently without teaming up with the designer, he or she may treat the wireframe as the final design rather than preliminary and may hesitate to suggest major changes (or you may be reluctant to embrace such changes), and thus be limiting designer’s expertise and creativity.
• Drawing up a wireframe can be time-consuming; without the aid of a designer you may spend unnecessary  time creating a visual map which is likely to be altered by the professional later on.
• Wireframes typically don't capture the full range of requirements and edge cases that occur in the background. Therefore the  developers may not be aware of all your needs.

The disadvantages of this method may outweigh the advantages if you choose to work without the help of a designer.

Functionality/Feature List
This method is a text-only list of the functional requirements  for each feature of your application. Some clients find that this is the easiest way to organise their ideas. When using a feature list, it's important to remember that you don't  need to worry about the technical aspects - it's the developer's job to determine how to implement your ideas most effectively. Your task is to effectively communicate to the developer the results you wish to see.

Pros:

• A well-considered feature list gives the developer and designer a good understanding of your requirements.
• A textual presentation of your ideas is more likely to cover non-visible features.

Cons:

• The most obvious disadvantage is that the feature list lacks the visual representation of the wireframe method, which may limit your ability to convey your complete vision of the application.
• Communicating your ideas textually rather than visually may increase the risk of miscommunication. Some requirements and features could be described vaguely or unclearly, which may lead the developer to interpret your vision of how the features will perform differently than you intended.

The feature list is certainly a useful tool which is best suited for high-level planning, as it lacks detail.

User Stories
User stories originated from Agile development methodologies, and in particular Scrum. The user stories method is also text-based, but differs from the  feature list approach in that it focuses on users rather than features. Rather than detailing the items the application should feature, this method identifies who the users are and  considers the various roles and  requirements each user may have. Ideally real users of the application should be involved in the user story gathering exercise. For example, the creator might evaluate the needs of the users on a job site, including administrators, job applicants, their potential employers, and employment agencies.

The format for the user story is simple, for example:

AS a jobseeker
I WOULD LIKE TO search for jobs
SO THAT I CAN find the jobs I want to apply for.

AS a site admin
I WOULD LIKE TO be able to take payment for job posting
SO THAT I CAN make money.

It's useful to include detail, but group your ideas according to the user perspective  and level of importance - annotate them with  MUST (have), SHOULD (have), COULD (have), WOULD (like to have). Writing your stories on index cards will help you easily prioritize your ideas.

To keep this early stage simple and focused, you may want to create your user story in a workshop environment with developers, designers, and different users present (if available).

Pros:

• This method is a particularly thorough way of planning. The user story allows everyone to see the application from different perspectives, which encourages fuller consideration of the users' needs.
• User stories allow the designers creative freedom while allowing the developers freedom to apply professional judgement in identifying the most effective solution.
• The user story provides a complete picture, allowing the team to more accurately estimate both the time and cost to implement the application.

Cons:

• The user story is likely to take more time to draw up than the feature list (though perhaps not as much time as detailed wireframing would take).
• Gaining the perspectives of real (not hypothetical) users may be difficult.
• You run the risk of providing too little detail if you try to write user stories without the guidance of a developer.

User Stories can be invaluable planning tools that help developers and designers deliver useful features to users.

Conclusion
To summarize, a Feature List can be produced quickly and provides a good starting point to get a ballpark figure of time and costs involved. However, before starting the project it is strongly advisable to do a User Stories gathering exercise, followed by Wireframes prepared with a web designer.

If you are UK based, please click here and fill in the form to receive pre-printed user story cards.

Permalink | Leave a comment  »

Though the number of Ruby on Rails developers is rising, many may lack the level of experience that we require. Therefore, it is necessary to implement a strong hiring practice to identify the best candidate for a role, and ensure that new recruits are not simply apprentices but experienced developers who can contribute significantly from day one.

We have always taken inspiration from 37signal's working practices and recently came across Google's hiring strategy that seems to advocate what we happen to be practicing already. So in this blog I would like to give a bit of background information on hiring methods established by Google and 37signals, and then show how our recruitment process and strategies compare.

Google’s Hiring Philosopy
Google’s Lake Wobegon Strategy advocates hiring above the mean, arguing with proven results that sustained company success is most achievable when you only hire those who are better than the mean average of your entire team. So, by hiring a better person with every new employee you are more likely to see increased company success.

37signals’ Hiring Philosophy
Jason Fried and David Heinemeier Hansson (founders of 37signals) in their latest book Rework, discuss some of the principles of successful hiring, including:

Don't limit your search to a specific geographic location as this restricts your pool of potential candidates to a specific area. This is particularly relevant to our field, where experienced Ruby on Rails developers can seem few and far between if you are only advertising locally. By expanding your search internationally you are increasing your chances of finding the best person for the job. With the advances in technology, building an international distributed team is not only possible, but for 37signals finds it beneficial.

Test-drive your candidates in a real working environment. The candidate needs to be somebody who is compatible with existing employees on a personal level. Certain qualities cannot be assessed by reviewing the candidate’s resume and carrying out an interview, and require an on-the-job trial.

Bit Zesty’s Hiring Practices
Google’s Lake Wobegon strategy is sound in its analytic nature, but the reality of applying a check-list approach can be a little difficult in practice. Though our hiring method is comparable to Google’s, it is one that has evolved naturally with influence from 37signals and is a more personal and workable form of assessment.

The crux of the matter is that we will hire someone better than ourselves. By adhering to this simple principle we not only spend less time instructing the new recruit, but we can put more trust in their initiative, which leads to a freer exchange of ideas and encourages innovation. Also, we don’t just recruit very experienced Ruby on Rails developers, we make sure that they bring other technical skills that the team does not have yet - ensuring that our skill base keeps expanding. This way, everyone keeps improving and learning.

We feel strongly about attracting a worldwide pool of potential candidates, so that we are not limited by location. We hire based on candidates skills rather than where they are based. This of course presents some challenges not only in day to day management but also in recruiting. The candidates go through a rigorous selection process, which includes pair-programming using screen-sharing, where we can see the approach the developer takes, the tools they use and their knowledge. We also interview them over Skype in order to establish their motivation and whether they will be able to work at a distance and become a good fit for our team.

While the selection process can help us to identify the best people in terms of technical skill, the successful candidate will have to be a natural fit for the company with regard to interaction with other team members and our work methods. The best way to assess this is through the on-the-job trial. We typically agree on a trial period of one month, which enables us to confidently judge if the candidate will be suitable as well as giving them a chance to see if they like working with us. It may well be that the candidate, although very skilled, may find our practice of distributed pair programming too intense.

In conclusion, while technical skills and experience are important, we also consider attributes such as dedication, attitude and the ability to perform well in a real working situation and as part of a successful, distributed team. And so far the issue of distance, although presenting challenges, has proven to bring far more advantages than drawbacks.

Permalink | Leave a comment  »

In Rails 3 the way you set your default cookie domain to allow your session to be shared across subdomains has changed. In Rails 2.3.5 you would add the following to your application.rb :

config.action_dispatch.session = {:domain =>".mydomain.com"}

In Rails 3 there is now a session_store.rb initialiser, in there you can configure your default domain like so:

Rails.application.config.session_store :cookie_store,                                   :key => '_app_session',                                   :domain => '.mydomain.com'

Permalink | Leave a comment  »

I gave a short talk at the MiniBar Finance Innovation conference last week.

MiniBar is a monthly tech and business conference which invites innovators and entrepreneurs to get together and share their ideas. This month, the event was sponsored by PayPal X and the six guest speakers each gave a 5-minute talk about innovation in payment systems. I used my slot to explain how we utilized the PayPal Adaptive Payments API when developing a group-buying application for our client, Likebees.

Likebees operates by offering users the chance to buy vouchers for substantial discounts for local services, such as restaurants or hairdressers. The catch is that the discount only becomes activated if enough people buy it, and this is where the pre-approval API becomes necessary. Instead of allowing each transaction go through so that they then have to be cancelled manually if the target number of buyers is not met, the API ensures that buyers are only charged when the deal reaches its 'tipping point'.

Anthony Hicks from PayPal cornered me for a quick interview afterwards:

Yannick, our client and Likebees co-founder also got caught on camera and explained the business side of Likebees in more detail:

Permalink | Leave a comment  »

Permalink | Leave a comment  »

While building our company dashboard, which was mentioned in our previous blog post on SVG with Raphael, I came across a problem with the project management tool we use, Pivotal Tracker. 

The Pivotal Tracker API is only in XML, which means you can't do cross-domain requests and access the API via javascript. This meant that, if I wanted to extract data about the status of our user stories, I would have to do it on the server side. As everything so far had been done with javascript on the client side, I was reluctant to start making things more complicated.

I contacted Pivotal, who said they might think about adding JSON at some point, but I didn't want to wait for them to sort it out. Instead, I built a quick API proxy that allows you to make a request to a XML API and get back JSON. So, now, I can do this in my javascript:

https://gist.github.com/379214.js?file=gistfile1

It will proxy the GET request to the API and convert the XML response into JSON, via http://xml2json.heroku.com (supports JSONP). I've put the code on GitHub http://github.com/bitzesty/xml2jsonp in case anyone else needs to do the same thing.

Permalink | Leave a comment  »

We have developed several SaaS (Software as a Service) applications for clients in the past and are currently working on our own SaaS project, so it feels like a good time to go into more detail about this burgeoning area of web development.

What is SaaS?
SaaS is where a service provider gives users access to software - such as Google Docs or Basecamp - through their browser. The user does not need to worry about the process of installing software and  the provider supplies an easy-to-use interface as well as hosting.

The service can be as simple as file storage, such as is provided by Flickr or Dropbox, or providers can offer software for entire e-commerce sites (e.g. Shopify) and CRMs (e.g. Highrise). These SaaS applications tend to be made available for a monthly fee, so that the provider generates income through subscriptions. Alternately, some SaaS providers take a mark-up from the sales.

Pros and Cons of SaaS
As an SaaS end user, the advantages are obvious: you gain access to a high level of functionality; you enjoy the support services of the provider; you can access it from any operating system, as it can be reached by any browser; and you don't have to deal with upgrading the software, as this will happen automatically.

You are also spared the up-front expense of buying software. This is particularly appealing for small businesses, where the monthly fee may be preferable to a large up-front payment.

SaaS in general is a good bet for start-ups and SMEs, as it offers them the chance to use software more advanced than they would usually be able to afford, without it taking up a lot of expensive server space. Indeed, with the global recession fresh in everyone's minds and IT capital budgets still very tight, large organizations are also beginning to use SaaS and to take advantage of the subscription based model.

However, using SaaS does mean that you are dependent on the provider, which in turn means that you are vulnerable if your provider suffers from a system failure or a security breach, or even physical damage.

This comes down to the trust which has to exist between the user and provider, but you can reduce the risk of losing all your data by taking basic precautions against unauthorised access and making regular back-ups.

Is SaaS for you?
The internet service provider Easynet Connect claims that more than half of small and medium enterprises will start to use The Cloud in their businesses in 2010. This shows that businesses are becoming more trusting and open to the opportunities that the internet has to offer. This in return is translating into an increasing uptake of SaaS by UK businesses, as reported by Information Age.

Whether you will be one of early adopters of SaaS depends on the size and nature of your business: if it is new and small, you will probably appreciate the monthly fee as opposed to a large up-front payment, while if you need to access your work from many different places the flexibility of using SaaS will suit you very well.

On the other hand, if your company is large and has a substantial IT budget and in-house resources, you may prefer the autonomy of actually owning everything.

If you feel that using SaaS could benefit your business, there is no reason why you shouldn't try it out. The risks can be kept to a minimum with the right precautions and you don't even have to run your entire business with SaaS. SaaS can be adopted to great effect just in a few areas of your business, so you should definitely investigate all the possibilities before committing to buying expensive enterprise software, especially for the non-critical areas of your business.

Bit Zesty - SaaS software development with Ruby on Rails

Permalink | Leave a comment  »

I gave a talk at NoSQL EU on a few of the different types of NoSQL solutions we've used in the past, explaining why we'd chosen each one and how they had worked for us. It was a bit tough to do whilst with a cold, so apologies if I sounded nasally/tired.

I've uploaded the slides to SlideShare for those who couldn't make it to the talk. At the moment, it is limited to the NoSQL solutions we have used on our projects, with case studies and a comparison of the benefits and drawbacks, but hopefully I'll be able to work on it more so that it incorporates some of the other 'bigger' NoSQL players, such as Riak and Cassandra.

Notes from the field: Different NoSQL tools in Production

Permalink | Leave a comment  »

Last week I gave a talk at Google OSJam on Raphaël (a javascript SVG library), the library that makes it easy to draw and animate vector graphics on a browser.

SVG is one of the many methods of drawing images on the web. Some of the other technologies include Flash, Canvas and now WebGL.

The reason we used Raphael in some of our projects is that we needed to bind events to the shapes we drew. For example, we had to create an interactive gantt chart that displayed a form via Ajax when you clicked on a task. This functionality in Raphael is made possible by the fact that SVG paths are DOM elements, although it does mean you don't get the performance of pixel manipulation as you would with canvas. Raphael also renders VML when on IE, so in theory your graphics should be cross-browser compatible.

I gave a demo of an animated clock that I'd made a few hours beforehand with Raphael and the jquery.jclock library. The clock will eventually be apart of a Panic inspired dashboard we are building to increase visibility across all of our projects.

The clock itself is quite simple: I modified the jclock library to trigger a 'tick' event, which we later used to animate the SVG clock for the hand rotation. Since the talk, I have also developed an alternate style for the clock, but the original code and examples can be found here (the library is creatively called jquery.svgclock.js):

http://github.com/bitzesty/hud

Brought to you by Bit Zesty - a 'crack' team of Ruby on Rails web developers

Permalink | Leave a comment  »

Permalink | Leave a comment  »

We hosted another event at THECUBE last week, this time on the more general subject of how websites are built.

The workshop was structured around the main issues involved in the website-building process, with particular emphasis on budgetary considerations and the cheaper alternatives to fully custom-built websites. Around 20 people turned up, mostly from the target audience of start-ups and prospective website owners, although a few people attended purely for the section on SEO.

We kicked things off with a whistle-stop tour of the technical choices available at the beginning of the process, including platform choices, front-end and back-end language options, and an overview of client-server architecture. After the lunch break, we moved on to design issues and the importance of usability, before discussing SEO and what to look for when hiring developers.

Everyone chipped in with questions about their own websites throughout the day, and the group exercises on identifying keywords and planning website features allowed people to get more specific advice on their projects. Judging by the people I talked to during the breaks, everyone took away something useful from the workshop, whether it was a deeper understanding of the website-building process or ideas about how to improve their websites.

The positive feedback means that we are definitely thinking of holding more workshops in the future, so keep an eye out for updates on our website.

Bit Zesty - Ruby on Rails web application development

Permalink | Leave a comment  »

Last week, we hosted a lunchtime q&a session on SEO (Search Engine Optimization) at THECUBE. SEO is a process which online businesses can use to maximise their site's visibility on search engines, and our co-workers had plenty of tips and experiences to share about it. I have summarized the main points that emerged from the session, which will hopefully give you an idea of how the process works. 

1. Identify the right keywords for your business.
   Search engines index sites by the text they contain, so it it is important that you should identify the key terms which define your business, as well as the words which will be entered into search engines by potential customers. Once identified, these words can be used to great effect, repeated throughout the site often and prominently (see point 2) enough for the search engines to register them. In order to compete with larger, more established companies on the keyword front, it is better to decide on a more specific set of keywords and target these on your site, rather than waging a hopeless battle for general terms. You can use Google's Keyword Tool to identify relevant keywords that have many searches but comparatively little competition.
2. Place keywords in the titles on your website wherever possible.
   Search engines prioritise the text in the title tags and in your headings and sub-headings, which are labelled as <h1>,<h2>, <h3>... in HTML, so you should make sure that you choose these words wisely and use keywords where appropriate. The words in the main body of the text are also taken into consideration, but less so than the headings. However, search engines can detect when websites repeat keywords endlessly out of context, so don't overdo it.
3. Try to get other sites to link to your own.
   Another factor the search engines take into account and consider important is the number of times other sites link back to your site. The more prestigious the site providing the link, the more credit your site gets from the search engine. For example, a link from a well-established site such as bbc.co.uk will count for more than one from a lesser-known, newer site. The links only work in your favour if your keywords are included fully in the link, so make sure that you always include keywords in the link when linking to other pages on your own site and try to ask others who link to you to use those keywords as well - being the destination of a 'Click Here' or 'Read more' link will not help you at all. For example, instead of saying The Cube, it would be more useful if the link included The Cube - Co-working Space in London - not only is this more helpful for the reader, but it also improves the SEO.
4. Maintain a steady flow of fresh content on your homepage.
   Search engines value fresh and original content, so it is in your interests to keep your website regularly updated. This can be done quite easily, for example, by posting a blog on your homepage.
5. Choose the right technology.
   Finally, search engines weight sites on the speed at which the pages load up. If your homepage is full of Flash and Javascript, it will take longer to load and count against you in the rankings, so it is generally better to use HTML (and keep Javascript to a minimum) where SEO is a consideration. On a further note, search engines find it harder to reach the text in a Flash format, so it is again advisable to work in HTML and only use Flash on a limited basis. 

By bearing these points in mind when working on your site, you will be making the most of search engines' potential to help you attract new custom and increase your company's profile.

We have created a short course on SEO for anyone who wants to learn more.

Bit Zesty Ltd is a web application development company.

Permalink | Leave a comment  »

I am quite excited about the rising popularity of document stores, we have been using MongoDB and CouchDB for some time now, both for internal and client projects. Both databases are similar (although built on different technologies) as they are schema-free, scalable, document-oriented.

The concept of a document database isn't new. It was pioneered by MUMPS in the 1970s for health-care and financial applications and by IBM in 1989 with the Lotus Notes Database. It's interesting to see the main concepts behind these legacy databases evolve and reemerge in new open-source projects.

Permalink | Leave a comment  »

Increasingly, clients wanting an application built on a tight budget are drawing up extravagant feature lists which are incompatible with the amount they are prepared to pay. This tension between the client's budget and needs can lead to dissatisfaction with the end product or conflict with the development team. However, it doesn't always have to end in deadlock.

One way to overcome the issue is by building and releasing the application in stages. This method suits clients with a limited cash flow and has the additional advantage of allowing you to get user feedback quickly. This information can then be used to help you decide which features you need to build next.

Yet sometimes there's simply no need to shell out for a fully bespoke system, particularly when there are viable off-the-shelf solutions available at a fraction of the cost. But what do you do if an off-the-shelf system doesn't quite fit your needs and a fully bespoke one is out of budget? I see three options:

Open Source
Customizing an existing open source application (if one is available) will cost considerably less than a bespoke system, as you only need to pay for the new features.

API Extensions / Plug-ins / Widgets
It is possible to build bespoke applications which use third party APIs, a good compromise which not only saves on development time but also provides the client with a more feature-complete solution. For example, MailChimp can be added for email marketing, Intense Debate or Disqus for commenting, and Get Satisfaction or Zendesk for support and help-desk functionality.

Application Platforms
If you use an existing paid application platform, it may sometimes be possible to extend it with existing plug-ins or develop your own one to suit your needs. For example, Shopify allows users to customize their e-commerce sites with a range of additional apps, as well as giving option for developers to build custom features.

People beginning online business ventures rarely have money to spare, so there is no point in pushing the boat out on bespoke applications when the same results can be achieved for much less. The existence of open source applications, plug-ins and API extensions on the internet is a gift to clients on a tight budget, and it should be exploited accordingly.

Bit Zesty - Ruby on Rails app development London

Permalink | Leave a comment  »

Scrum clearly provides many benefits for the developers, but what are its advantages for the client and other stakeholders? This is a question I faced recently in a client meeting, and to answer it I first need to define Scrum itself. In layman terms, it is a project management technique that is used with agile development projects. It aims to make projects more effective by defining the roles of team members and by providing a specific way of organising the workload over a series of short development cycles (sprints).

Benefits for the client:

Scrum's main advantage is the way it facilitates changing customer requirements. It does this by providing a flexible framework wherein new features can be added and re-prioritizations can take place without negatively affecting the project flow and team's morale.

Secondly, the system of sprints encourages regular feedback, as each sprint is followed by a review. These reviews provide opportunities for the entire team to reflect on the previous sprint and discuss improvements for the next.

Thirdly, by defining roles for team members it promotes collaboration as well as clear and open lines of communication between the developers, the client and other stakeholders.

Finally, Scrum provides a framework for work estimation, where features are estimated in units of points: each point represents a relative amount of effort required. This technique is flexible enough to allow for changes in requirements as well as changes in the development team's velocity.

However, Scrum is not suitable for all projects and has certain limitations:

It does not work with traditional software development methodologies such as Waterfall.

It cannot be fully adopted if a team is too small or too big - an ideal team would consist of 4 to 6 developers.

It cannot work effectively unless it has have full management/client support.

It requires a Scrum Master who understands the Scrum practices and is able to apply them.

Bit Zesty uses scrum and agile for Ruby on Rails application development

Permalink | Leave a comment  »

Summary
No migrations (yes!), storing arrays and hashes as attribute keys (sweet), and inplace updates (ftw). We're not going to use MongoDB to build transactional systems any time soon, but for the majority of web applications it's a perfect fit.

Bit Zesty - Ruby on Rails Development (and MongoDB) UK

Permalink | Leave a comment  »

So I wrote a wrapper around strongbox that I am releasing called Safe - a Rails engine for storing encrypted data. Safe handles the generating of the public and private keys and uses strongbox to encrypt and decrypt the data. It's still in early stages, and it doesn't support all of the options that strongbox does, but it is on the TODO list.

So let me know if you find it useful and don't forget to symlink the keys directory in your deployment scripts!

Bit Zesty - Ruby on Rails developers in London.
 

Permalink | Leave a comment  »

Permalink | Leave a comment  »