A few weeks back now, we started the development of our new web application BeeLit.

Of course we had to make several important choices for our IT architecture.

We started by choosing a light, flexible and really fast back-end as mentioned in our post: Why Erlang ?

For the front-end, we wanted the browser to be the center for rendering and aggregating services. (Read our post about True Aggregation, the Browser as a Platform).

To achieve this goal, we had to decide for:

1. a JavaScript library to ease the cross-browser issues and advanced DOM functionality
2. a communication language between the browser and the back-end: JSON ? XML ?
3. a template engine to render the back-end services in HTML

We chose jQuery as our JS library (the reasons of this choice will be detailed in a future post).

We decided to go for JSON as the preferred communication language between the browser and Erlang.

The main reason being:

JSON is JavaScript, and JavaScript is THE language of the browser that runs the client logic.

When an AJAX kind of call returns a JSON, your JavaScript code understands it natively.

When an XML is returned, in some ways, you have to convert it fully or partially to JavaScript variables. Then the data becomes useful in your browser. This remains true even if you use XSLT for the rendering.

Don’t get me wrong. It doesn’t mean that we are closing the door on XML and that we won’t aggregate XML services from other API’s in our solutions. It took almost 10 years for the IT Industry to replace ASCII files with XML. And nowadays, you can find plenty of API’s working with XML. So XML is here to stay.

But receiving JSON data in a browser simplifies the developer’s life dramatically.
(Read the rest of the article…)

3000 is the number of unique visitors, in two days, who read our last post: Why Erlang ?

In comparison, our last busiest day was 82 unique visitors.

So, just a bit of self-hugging, thank you Hughes for the great post !

I guess, it is some of those startup momentum’s that give you the will and motivation to do better.

And guess what ? We have better incoming !

More precisely, this week will be an important step for us, so…

Stay Tuned.

We also made a few changes to this blog and added two new features:

1. Now you can directly share our posts in your favorite social bookmarking application, clicking on the Share button at the bottom of each post.
2. You can now ask for email updates when you let a comment in a post, just to know if someone has answered you or if the discussion simply keeps going on.
3. Minor design changes.

Why we chose Erlang over Python, Ruby, PHP family for our back-end.

The short answer :

Because it’s a completely different approach from the OO programming languages (even from the pure functional ones like Lisp or Haskell), it’s concurrent, stateless, has been battle tested in real large-scale industrial products, has an active web app centric community and finally, because it fits perfectly with our view of a light back-end delivery service engine.

Quick links featured in this post :

• Erlang - Software for a concurrent world, Joe Armstrong

• Introduction to Erlang, Bob Ippolito (SimpleJson, Mochiweb)

• Mochiweb, the web application server we chose

• The Erlang Community

• Yariv Sadan’s blog, creator of Erlyweb, an Erlang web application framework

• Yaws, a web server written in Erlang

• Server Apache vs. Yaws, a graphical benchmark

• Programming Erlang, the book from Joe Armstrong

When we were looking for our main back-end language back in April, Google had just launched a micro-bomb named GAE, the Google App Engine.  We know all about Google’s killer web apps,  services and brains reservoir, and so it was difficult not to have a closer look at the potential of their brand new SDK.  In brief, GAE is the Google answer to the Amazon S3 in the cloud computing arena. It simply enables you to benefit the same scalable systems than those that power Google applications.

We decided that the server part of our web app should remain light, flexible and be able to deliver chunks of JSON as fast as possible.  The client (browser) would be in charge, among other things, of processing the data and building the final XHTML.

At that time, I was comfortable with Ruby and was following the progresses of the Merb framework project.  But after all, why not change and learn something new ? I love trying out new things, so why not Python, keeping in mind that we could benefit from GAE in the future?  Don’t misunderstand me, I’m still following the development of Merb with a lot of interest :).

So, I started to look at WebPy, Pylons and was getting excited to enter this new community. Coming from Ruby, learning Python, and making a small working prototype using WebPy (soon to be transferred to the GAE SDK) was quite easy.  The goal isn’t to enter in a deep comparison of those two languages, I’m not mastering Python enough anyway. It wasn’t to start a flame war either,  it should have been just the opposite (Ruby2Python or even Python2PHP, …). ALL languages have their pros and cons and those might even change depending on the context.
(Read the rest of the article…)

When you build a system based on people, at a certain time, you need to fill your system with data for mass testing.

If you need hundreds (or thousands) of people, finding names can be a painfull moment to go through.

Here is a spreadsheet that generates as much names as you want.

It comes with 1000 random names (English) and each time you change something in the list, it refreshes itself with new names.

With your favorite spreadsheet editor, you can then generate, for instance, a JSON dataset, emails,… simply by using basic formulas.

An important part in the creation process of a new SaaS offer is of course about technology choices.

You need to choose a language for your back-end, for the front-end, you need a DataBase, you might want to develop everything on an existing platform, …

In some extent, you may even want your technological choices to mirror a certain corporate philosophy.

In the coming weeks, Mic and Hughes will share with you some technical posts about our findings, thoughts and decisions.

We don’t have the pretense of coming out with an absolute winner for each choice that we make. In fact, we think there is no such thing. Each technology has its pros and cons and even those might change depending on the context.

When we started looking at technology to use for our BeeLit solution, we had the following issues in mind:

• Security: Definitively one of our main concerns

• Scalability & Performance: We wanted to solve performance and scalability issues on the software level and not only with hardware. (The Multicore Crisis on SmoothSpan)

• Use of OpenSource Technologies: To ensure lower costs to our future customers and also to give us some flexibility ( OpenSource in SaaS Industry by Gartner)

• Platform approach: to transform your web browser into a real application platform

• Mashup Approach: to make our solution a user-centric solution and also to give us a real framework to stay competitive among other SaaS offers

• SOA Approach: to smoothen aggregation of information as well as functionalities

• Community: Often more important than the technology itself, the community around is key

• Fun: Yes indeed: Technology can be fun!

We might even have a little surprise in store when it comes to the technology we use for the front-end…

Stay tuned.

For years, every time I would use Regex, Regexp, Regular Expressions (you name it), I would find myself crawling through the enormous library available on RegExLib.com, hoping to find that someone had posted the exact expression I needed.

Then I decided to invest some time in demystifying the beast. I read dozens of websites.

Here’s a series of links that helped me get started:

• Plenty of sites offer tutorials, but this was the first website to show me the light. Granted, the web design is particular. But the content is gold.
• JavaScriptKit presents a simple and clear JavaScript use of regular expressions.
• While learning, I did some testing with the Firebug console, but quickly needed a real testing tool. Lots of free online tester tools are available, you can find them by googling: regexp testing online. The one I prefer and currently use is from gskinner.com. I use the Adobe AIR based desktop version (it was my first AIR app download and I was pretty impressed by the smooth and neat installation).
• Once you are in the comfort zone, Regex cheat sheet is there to remind you the basics

Just a couple of hours of efforts were enough to get started and… a couple of days more of practice to get comfortable.

I hope this will help you. Don’t hesitate to add your own findings in the comments below.

It is my great pleasure to announce that this post has been published at the same time on the blog Diversity.

Ben Kepes, founding director of Diversity, has been very inspiring to us even before becoming a reader of our blog and I thank him for his trust.

Enjoy the reading !

__________________________

Every morning when I stop reading the last big news from about 30 blogs in Netvibes and switch to my countless SaaS Business Apps such as Gmail, Basecamp, Highrise, Remember The Milk, Google Docs, … I wonder why aggregation of information like news was present so fast in my day to day life and why Business Apps, when it comes to integration, are still in the stone age.

If I had to define the perfect Business Application, it would certainly be user-centric:

1. I would have a single interface where I could find all my information and processes;
2. The interface would be flexible. It would allow me to rearrange it the way I want: fitting my working habits and my organization of information;
3. And finally, it would only include the features I need and for which I would eventually pay.

Even with such powers in my hands, I would still expect quite a lot from the software provider: security, maintenance, performance, scalability and innovation.

There are obvious barriers to reach that point.

First, I doubt we will ever have some kind of a single universal DB with information about persons, friends, contacts, habits, projects, … They will probably continue to multiply and spread as new web solutions will appear.

Secondly, I doubt a single provider will ever meet all my needs. Moreover, I believe innovation comes from diversity.

So, looking at how SaaS providers are responding to this demand, we can find:

1) The me-only providers. They often provide a wonderful tool for a specific domain but are not integrated with others.

2) The API players. They believe in information aggregation and easily pass the barrier of the constantly multiplying and spreading sources of information.

Centralized and external data is combined not only to avoid redundancy for the users, but also to provide better and more complete results.

Good examples:

• Sinclair Schuller on the benefit of merging local data acquisition with SaaS.
• Ben Kepes with a post on FreeAgentCentral.

API followers would usually also provide API for their own data.

3) The SaaS Platforms. This new feature in the SaaS industry is more than probably going to be the battlefield in the in the coming months and years (McKinsey: Emerging platforms war in enterprise software).

Taking the same naming convention than McKinsey, Development Platforms and Application-led Platforms are good candidates to help the user pass the second barrier.

Providing a single interface for the users and elaborated systems for developers, this might be the solution we are looking at.

It is definitively one step further in the direction of a user-centric approach. Still, there are in my opinion certain downsides you need to consider:

First, the lock-in it creates for developers. When you choose a platform, you basically choose for a complete environment from A to Z at the disadvantage of complete freedom in innovation and technical choices.

Secondly, the real possibilities for the end users are still quite limited in terms of interface customization and flexibility.

4) True Aggregation in SaaS or the Browser as a Platform.  The idea is to be able to empower the end-users and at the same time to leverage providers’ efforts and innovation without creating any lock-in.

While running their business applications through a web browser, the users can customize their screens adding or removing services offered by various providers.

Using the buzz semantic, these users are in fact running SaaS applications through a Mashup interface based on SOA architecture.

I recommend the excellent post about Enterprise Mashups written by Brian ‘Bex’ Huff.

Mashups are usually packaged by developers or Mashup specialists. But, just like Netvibes did for the RSS feeds, you could let them be created by users.

The real challenge for the software providers will then be to rethink applications in smaller blocks that could work independently AND in collaboration with other unknown services.

So we are finally seeing a move into federation in SaaS Business Applications. Aggregation of information and aggregation of features should be on the mind of everybody who plans to start a new SaaS venture.

While all-in-one heavyweight platforms such as those offered by Salesforce provide a certain comfort, I strongly believe that innovation is about freedom of choices and diversity; and it’s something that can only be achieved by embracing that diversity and not by creating lock-ins.

Last but not least, there is a last barrier that might be bigger than the two others mentioned above: the will of providers to work together and share the love!

Share the love.

Our first solution, BeeLit, has a new website !

BeeLit is an online solution helping freelancers, SMEs/SMBs or small teams of bigger companies with administrative tasks such as Time Tracking, Expense Management and Customer Invoicing.

To visit the website just type the following URL in your favorite browser : http://beelit.com.

Or simply push the big button hereunder:

Today the website is quite basic and gives an overview of the main functionalities included in BeeLit.

In the coming weeks, the content of the website will grow with more information such as detailed descriptions of the functionalities, more screenshots, videos, …

Be sure to stay updated by subscribing to this blog or subscribing to the new BeeLit Newsletter.

Have a great week!