Vesess : Web Design, Application Development, UI Design, Usability and Consultancy Services from Colombo, Sri Lanka.

Today we are proud to announce the launch of our maiden product CurdBee. While regulars will know what it is, new readers will be pleased to find out that it’s a simple and efficient tool to bill your clients and get paid online.

During the early days at Vesess, we had just a hand full of clients and it was only I who really worried about sending invoices and collecting the money before our bank account dried up. Being a start-up, we couldn’t afford to spend much for a great accounting application such as QuickBooks, even though it was not that expensive in the big scheme of things. As far as I can remember, this was around the time 37Signals shifted gears and went from web design to web apps, with some cool yet simple ideas.

In any case, in the early days of Vesess, I had a spreadsheet along with a .doc file with our sweet logo on top, and it was this which I used to send invoices (and rather good looking ones, if I may say so myself) to our clients. The process was simple - copy and paste the client details from the spreadsheet, type in the amount, and use one of the free PDF converters to finish the job.

One of the actual invoices we sent in August 2004. Still looks nice and simple, doesn’t it?

Some of our clients thought we are using cool software and a couple of them actually inquired. Then again, a few discovered the truth when they noticed some stupid mistakes only a human can make, such as the total being different to the cumulative value of the items.

As we grew, the number of clients we handled started to increase, and more invoicing was required as some projects now involved monthly payments, others quarterly billing, and so on and so forth. This prompted us to consider developing a system to make life easy and save the unnecessary time we spent on manual billing.

So, one evening, I started to sketch a simple application which could allow us to send invoices directly via email. Thanks to Laknath who joined Vesess during that time as an intern, we solved the issue in couple of days with just a few lines of PHP.

The first iteration of our billing app. From adding a client to modifying an existing item, everything is handled on the same screen using AJAX.

Towards the latter part of 2007, we thought it’d be a good idea to work on a few products aimed at Small Businesses (SMEs) globally and perhaps let our developers start on some pet projects as well. With these ideas in mind we ran a survey to capture some of the problems faced by SMEs and find ways to overcome them using simple web apps. The number of respondents was quite satisfactory and to our surprise, we found that a good majority were interested in web apps which would help them in their accounting, billing and cash collection activities.

As our resident Ruby on Rails addict, Lakshan was well suited to re-engineer our simple in-house billing application using the new web application framework. Although we haven’t done anything particularly new or revolutionary with this application, we know that there are enough people out there, looking for a simple, hassle-free solution that will make their lives easier. CurdBee is for them.

The awesome invoices that The Bee creates. Start sending professional invoices today.

From the Boiler Room
So the application is released, you’ve signed up for an account, and are happily sending invoices to all and sundry. Knowing our readership, however, many of you are going to want to know more about how The Bee came to be. Yes, we do read your minds, dear readers. It is thus with great pleasure that we present a short interview with Lakshan, the CurdBee lead developer and hacker extraordinaire, who will tell you more about just how this baby came together. Go on, have a read - you know the inner geek in you will thank you for it.

Lakshan Perera was the lead behind CurdBee, and was responsible for putting the application together from scratch. A student at the University of Moratuwa, Lakshan has been with Vesess for a while now, and in essence embodies the spirit of Vesess - small teams, big ideas, and people with a passion for what they do, all merged together by rapid Vesessination. Here, Mahangu sits with him for a small chat about everything CurdBee.

Tell us a little bit about how you planned for this project, and why you chose RoR as your development platform
CurdBee was actually the brainchild of Lankitha. At first, it was designed to be a solid billing solution for Vesess, but later we realised this solution may have a general appeal as there are many small businesses and freelancers like us. We didn’t wasted time on writing specs and went ahead with rapid prototyping.

There was no better framework for rapid web development than RoR, so the choice was obvious. RoR’s has a rich plugin set which covered all the requirements of the CurdBee so that gave more confidence on the framework.

What challenges and obstacles did you face when designing an application for the web?
The main challenge was deciding on what features and capabilities the app should have. We wanted the app to be minimal yet effective. We always tried to look at it from the perspective of the end-user - how clear is the process to him, how could he perform the task at hand easily, and what information he’d want to see and which info he’d rather have in the background. This was not simple as it seems and it’s definitely a continuous process, and is not over just because the application goes public.

Different users has different needs and see things differently. Building an app which could cater to all levels of users is the main challenge, and that’s the goal I’m still striving for.

What is your coding setup like? What tools do you use, and what times of the day do you do most of your work?
I normally prefer lightweight tools over IDEs to get things done. Actually IDEs aren’t resoucre hungry and controls your coding process too much. I love the flexibility of just a text editor (gedit) and terminal. This style of development is greatly supported by RoR itself (actually they recommend it - following the pragmatic programmer’s concept). Apart from that I had Firefox opened throughout the development period for previewing the app, but that’s obvious.

For source code management we went with Git - it really proved how productive it could be. While I work with the backend, Amila was working on the front-end design. Both concentrated only on their local versions and and once we were happy with a revision we could push it to the repository. The rest was taken care of by Git, which simply merged the changes without any conflicts. Also, using Capistrano with the git repository made releasing these updates to the live site a breeze.

Regarding working hours, I tend to prefer short stints than late night hackerthons. Mostly, my work task oriented. I decide in the beginning at the day which tasks I’m going to complete today and try to finish them by the end. I concentrated on one task at a time, so it never exhausted me and allowed me to stay focused throughout.

When looking at the development process for CurdBee, where did the other Vesess team members come in?
Well, Vesess is a small team and each member leads a separate project. When one project is ready to come out of its cocoon, the whole team gathers around and ensures the safe delivery of it. Actually if not for Lankitha’s brainstorming, Amila’s sweet templates, and Mahangu’s enganging copy, CurdBee would not have been the app you see today.

Any parting advice for young coders looking to write their first web app?
A web app is not a Christmas tree, so don’t try and decorate it with all the little snippets and libraries you know. Try to keep things simple and always stay focused on what you’re building. Don’t try to overdo the app to show your coding supremacy.

Also, don’t reinvent the wheel. Reuse code wherever possible. If you can find a plugin to simplify a certain process, use it.

Look for design patterns and try to follow them, but don’t cargo cult - that means don’t just copy and paste other people’s code without understanding it. Code found on Dzone, Pastie or on developer blogs is not always correct. Always be aware what you are doing so you know where to look if something goes wrong. I actually made most of these mistakes, so I’m talking from experience.

A Happy Ending
Well, that’s the story of The Bee. Please visit our forums or drop us a line, and let us know what you think. A big thank you to every one who took part in the beta programme, and we hope you enjoy the app!

A couple of weekends ago, the Vesess team took a much needed breather, and headed out for a weekend away from work, email and reddit. As a team with a lot of virtual members, the time we get to spend together in meatspace is limited. Although we’re used to always being in touch via email and IM, the weekend at Sigiriya was a chance for us to really engage each other IRL, and find out what makes each of us tick. From Python, to GNOME, Rails, and beyond, a lot of what we talked about was based on what we do.

Sigiriya, the ancient royal fortress that our coders use as inspiration when designing our data security policies.

Boring? Not in the least. What’s different about talking shop with a geek in his or her spare time is that the issues and projects that surface will most often be personal ones. From quick hacks used for everyday productivity, to complex applications written for class, I learnt a lot about each of our interests on this trip. It didn’t have to be just tech either. From general business sense, to global warming, rising oil prices, and the recent food shortages, I listened a lot, and learnt a lot.

As a recent graduate, I’d call myself lucky to be at a place like Vesess. While most people my age are filling out twenty page forms, and sitting in on meetings that last for hours and never seem to go anywhere, I get to push my ideas, voice my opinions, and interact with some genuinely talented people. In $BIGFIRM, I would be a PR junkie, a drone who spewed out manufactured, corporate prose. Over here at Vesess, I get to set the textual style and tone for each project. I get to design the flow of information, and map out where it goes, and how it is consumed.

Then, I think of our hackers. In a large company, they would be junior programmers, churning out line after line of code according to a specification they don’t even get to see in its entirety. Here at Vesess, they conceputalise, design and put together entire applications.

Lies, you say? Nay.

In fact, one such application is currently in private beta. Something which Lakshan, our resident RoR guru, wrote from the ground up, CurdBee is a great example of a pet project going prime time. While all the initial planning and hacking took place in his head, the entire team eventually pitched in to make it ready for the world at large.

CurdBee, a result of rapid Vesessination.

This, in essence, is what we call Vesessination - a single idea brought to fruition by everyone, working together. At Vesess, that’s essentially what’s we’re about. Small teams, big ideas, and a lot of experimentation. Well, that’s all for now, folks. Tune in next week for some quality time with Lakshan’s new baby.

As geeks, we’ve been using P2P software for years. Starting with Napster in 1999, and the plethora of different filesharing networks that followed, right up to torrents, which we all use and love today, we’ve seen the technology being used for a number of worthwhile causes. Thus, when Sean came to us with his plan to put it to use in the real world, we jumped at the chance.

Today, after a lot of thought and hacking, we’re proud to announce the launch of p2prescue.org, the web hub of what Sean describes as a U.S.-based, not-for-profit organization working to raise awareness about and deliver support to Sri Lanka. At a time where NGOs and aid organisations are a dime a dozen in Sri Lanka, it was an experience to work with a group of people who were approaching our nation’s problems from a different angle. People have needs, and indeed, people have always had needs, and always will. What makes an aid effort stand out from the rest, however, is how they choose to approach these needs.

Focused on enabling sustainable development through training people, and creating jobs, Sean dubs the organisation’s approach P2P, or People to People. In a world where organisations are becoming increasingly bureaucratic, it is good to see one that is choosing to interact at the grassroots level. It is a good reminder to everyone that aid is not just about money.

The P2P Rescue Shop, powered by WP e-Commerce

From a technical point-of-view, the Shop portion of the site is an important one. Using the free plugin WP e-Commerce, we setup a virtual shopping cart via which visitors can choose to purchase the items that Sean’s various P2P projects have created. At the moment, the Tsunami Birdhouses seem to be hot, and rightly so - made entirely from items salvaged during the December 2004 Tsunami, these creations are a real life example of using what you have, one of P2P Rescue’s main dictums.

Socially, the Voices section is certainly the website’s most striking feature. Taking the form of a weblog, this section is where the people behind P2P Rescue have their say. From status updates from Sean himself, to stories of how the bird houses were made, this is the face of P2P Rescue, and is certainly what our readers will find most interesting. If you’ve never been to Sri Lanka, and are curious about what it’s like, the Voices section is a great place to wet your interest.

All in all, we learnt a lot from P2P Rescue. As a web organisation ourselves, its novel approach to communication in the real world made us challenge many of our own ideas and preconceptions, and helped us realise that no matter where you are, the only constructive way forward is indeed People to People. In any case, that’s enough from our end. Let’s hear what Sean Kelly has to say about the project.

Left-to-right: Sean Kelly, Her Highness Alexandra Princess of Denmark, and Michael Parayno.

Vesess: In a region where many countries were affected by the December 2004 Tsunami, why did you choose Sri Lanka in particular as a base of operations?

Sean: My thinking on this wasn’t clear in the beginning. I knew I wanted to employ and train people to create items from salvaged tsunami items to help raise money. But such wreckage was, of course, available anywhere and everywhere. I originally considered Banda Aceh because of how severely destroyed it appeared in aerial video/photos. It seemed soon enough, however, that Aceh was already getting incredible attention.

Before I was too far in with my planning I heard from a former colleague, Francesca Koe, who was just beginning to work with an international team on a reef-restoration, memorial, and scuba project in Sri Lanka. After a few discussions, I decided I would join her and others in Sri Lanka to see if I could assist with raising awareness around their work. That was mainly the deciding factor.

Even before my first trip to Sri Lanka, however, I felt the plans were ideal. I knew very little about the country and figured few others in America did, either. I thought my experience as a writer would be put to good use not just in describing existing funds, but in showing the world the wonderful sides of a country I myself was just coming into contact with.

Vesess: What are the advantages of peer-to-peer, or as you put it, People-to-People communication and interaction, when compared with more traditional aid and rescue deployments?

Sean: If you are aware of network technology structures, the client/server approach involves (for example) one server passing data between multiple clients. The server has most of the power. This, to me, seems a great deal like how major aid organizations operate with regard to donors. The organization (server) holds most of the power and ultimately decides where the money goes. The donors feed the server their money but have limited decision-making powers.

The P2P model doesn’t differentiate between clients and servers. Everything is equal and the true power of a P2P system is how each “peer” works with the next. The idea struck me as a major change of approach in the business of giving aid or adopting “social change.”

In my view, the aid organization, volunteers, donors, and even the beneficiaries of aid are all equal and impact the system. In this view, the organization is extremely receptive to outside action. It is dependent upon it too. If this “network of equals” fails to act, the system collapses entirely.

This has proven to me an innovative way to view aid–at times it was Sri Lanka that contributed most to the system by way of hard work and creativity. At other times, people in Sri Lanka flagged and suddenly people in America re-focused. The P2P model allows for waves of inspiration as they come naturally in the process.

Vesess: As a technology company, it was interesting for us to see p2p being used in the offline sphere. How and why did it work in real life?

Sean: It is still a work in progress, of course. I think there is tremendous potential to the idea as a model for empowering people. But it is an ideology that is threatened by two major influences: the situation of the world as a whole and the willingness of all involved to strive for equality.

With regard to the latter I have discovered that major aid agencies often don’t adequately seek input from the people they are helping or their donors. They often give as an authority. A power over donors or beneficiaries. Donors, too, don’t seem all that interested in equality. They donate based on a level of guilt that is satisfied purely on handing over some money and then forgetting about what happens to it, rather than following it to its end. And the receivers of aid are often just that. They receive without being motivated to put something back into the system, to create their own equality.

And of course, the overall state of world health is a hugely mitigating factor. Striving for equality and social change requires effort and concentration, and the world is enduring am incredible level of suffering at this time in history. Just think of Hurricane Katrina, Darfur, Zimbabwe, the price of food, a looming worldwide recession, various sad and unfortunate wars and human rights abuses.

For the P2P model of social change to work, it needs all communities in all areas to strive for some semblance of equality.

Vesess: In your opinion, is it possible for a social system, online, or offline, to sustain itself without a distinct hierarchy of control? In other words, is p2p communication sustainable as a political system?

I think if you follow the ideology far enough down the line it is conceivable. I believe it works, bit by bit, on a small scale. But for it to be effective on a global scale would require a major change to human nature. Do we, as humans, really want to strive or equality? The increasingly large gap between haves and have-nots, the billionaires and those living off a small bag of rice, suggests we don’t. I should add that by equality I am not suggesting socialism or communism or some other political model. I’m not suggesting fascism either. Socially and politically people need guidance. There will always be gaps separating people by strengths and weaknesses. But in the world of social change, I think striving for greater equality and being open to learning both from those people who have more AND less than you has tremendous value.

In that sense, I consider myself directly in the middle. I am learning from myself and other people who, like me, are just trying to do their best. Yet I am open to learning, and have learned, incredible lessons from the donor who would hand me his/her hard earned money and the impoverished Sri Lankan who shared his King Coconut.

Vesess: What advice would you have for anyone looking to setup a similar initiative?

Sean: You said your readers are pretty tech savvy, so let’s stick with the technology world for a moment. There are thousands of small aid organizations, each often repeating the work of the next. That’s like thousands of P2P networks. There’s one clear answer to how they can be more efficient–through APIs. Developing standard ways of connecting them all together would certainly go a long way toward creating greater efficiencies between organizations. Connecting P2P Rescue to, say, a pertinent segment of Unicef efforts, a small team in Sri Lanka, a network working on parallel efforts in the Philippines, and so on, could see enormous rewards on all fronts. Shared assets and contacts. Faster mobilization. Those are some obvious examples.

The reality, however, is in my experience attempting to work with major aid organizations in and out of Sri Lanka, I continued to bump into closed (proprietary?) systems. Yes, I HAD located and met with and assessed sites needing a total of 309 homes along the southwest coast. I offered my full support and resources to cooperate in rebuilding programs. But I was turned away for a variety of reasons–political, religious, bureaucratic.

Perhaps some of the reasons were legitimate. But tell that to the family of six living under a corrugated tin roof with no bathroom facilities. The very idea behind P2P Rescue is essentially, if you have resources to spare to a place where resources are needed, you are part of the network. You don’t need to be Christian, for example. You just need to be willing to get your hands dirty for the benefit of another.

Thank you Sean, and P2P Rescue, for everything you taught us during this project. We’re sure you guys are going to do great things in Sri Lanka, and South Asia. Good luck!

So you want to write a web app? Vesess welcomes you and a million others to this primer on developing your first web based application. By the end of this post you should have a better idea of how to approach web development in the post-basecamp era. Let’s start with the basics.

Good web apps are a combination of intuitive interfaces + solid code

The quality of web application’s code lies within the simplicity, flexibility and understandability of it. Thus, agile development has quickly become the way of the web dev. At Vesess, our web team is no different. We do web apps with 1 designer + 1 developer. So, having said that, it’s time for us to share a little of how we approach this task. We’ll begin by dwelling on some fairly abstract concepts.

Use a Framework

It’s always better to use an existing web application framework rather than starting everything from the scratch. Frameworks provide you with a solid base to focus on the problem you want to solve. In the long run, that’s a lot better than having to worry about infrastructural issues. These frameworks are written in different languages and follows several conventions. Our recommendation is to work with a framework that is written following the MVC (Model, View, Controller) architecture, as this is the most productive kind to work with.

When choosing a framework it’s good to consider these factors:

1. Your developer’s proficiency with the language involved.
2. The suitability of the framework to the problem domain (for example, frameworks such as MODx or Silverstripe best used in the development of content rich sites).
3. Your deployment environment and budget.

Use a Source Code Management System (SCM)

We recommend that you use a SCM such as Subversion to manage your application code from the beginning. Got only one developer on the project? We still think it’s worthwhile. SCM systems are a great insurance for developers since they have the comfort of a code rollback at all times, and can even sync their projects easily between multiple PCs.

Further having a code repository makes your life easy when it comes to application deployment. You could simply use a tool such as Capistrano with your repository to deploy your application on a remote server.

Choose a Good Editor

A web application project may contain code written in different languages, with snippets stored in different file formats and in different directory structures. Thus, it is essential that you use a editor or IDE which supports all of these conventions. Of course, syntax highlighting and smart indention will help you write clear, precise code, and in the long run will make hunting bugs that much easier. Many modern IDEs also have smart pop-up menus that can complete code for you. Although veteran coders often shun such features, they can save you a lot of time and keystrokes when typing in repetitive strings.

If you are on mac you could get your hands on TextMate or Coda. Linux users on the other hand might like to try this lightweight editor called Scribes, especially if you feel Vim and Emacs are too much for you. If you are willing to use a web based IDE, Aptana is a great one.

Use AJAX and JavaScript wisely

Lot of web applications get bloated with unnecessary AJAX and JavaScript effects. Don’t let the application’s usability drop because of the overuse of these. Always make your JavaScript unobtrusive and have fall through methods for your AJAX calls. Make the habit of using the Firebug plugin for testing and tweaking your JavaScript.

Test your Code

Most of the major web application frameworks come with an integrated testing environment, and we recommended that you use them to do unit and functional tests on your application. Best practice would be to create the test cases alongside the development classes and test as you go along. Time spent on this will prevent you from falling into blind errors mid way in to development. Another good approach would be to use a test tool such as Selenium to troubleshoot browser compatibility and perform system functional testing.

Use a Bug Tracker

Although you will not need a fully fledged tracking system such as Bugzilla or Trac, maintaining a task list for bugs in your Project Management portal would be a wise thing to do. Keep all the bugs recorded there, as this might save you the trouble of fixing the same bug twice, and so on. Lighthouse seems to be a nice hosted bug tracker for web application projects.

Abstract and extend your Code

In the long run you may want to release an API for your application or you might want it to be compatible with mobile devices. Making your code abstract will give you the option of reusing and porting it. Always have a meaningful naming convention (usually, frameworks such as Rails force you to do this) for classes and models, as this will save you (and perhaps others) a lot of confusions later on. Also try to incorporate things like Microformats in to your application, since this will enable you to structure the output in a logical manner and make it easy to consume.