Thanks to your comments and the requests made on our discussion group we have been able to bring PURE to its next step.

This release contains a few corrections but also a lot of new features:

• Auto-rendering: a new PURE method takes your HTML and your JSON data and merges them automatically. The class attribute is used to map the HTML and the data. (Read more about autoRender and its jQuery version on our Wiki).

• Recursive Template Call

• Functions as directive are called by reference and not serialized

• Attach events to your HTML (Read more)

• Change the id of the template root node (as any other attribute)

• Better string value handling

• Use of named properties in iteration “obj.prop” as well as “obj['name']“

We also made some changes to the PURE environment:

• The Home page and the Getting Started page have been re-done, including more examples

• The source code moved from Google Code to GitHub

• You can find now a technical documentation on the GitHub Wiki

• You can report bugs on Lighthouse

• There is a dedicated jQuery Plugin project

• You can discuss about PURE in French on our French discussion group

We are also actively looking for help in order to port PURE to other JS libraries such as DomAssistant, Dojo, Mootools, Prototype, YUI, …

If you are ready to get your hands dirty, just pass by the discussion group and leave us a message.

Stay tuned

As you may know, Belgium has some oddities.

One of them is a poor phone law that makes consumers pay the full price for a phone, probably one of the highest in the world. This doesn’t bring any cheaper usage cost than our neighbours either.

So it came as a kind of consolation when I saw PURE running smoothly on my brand new iPhone 3G.

Ok, it’s an easy shot as Safari is running there. But that’s good news for web applications using PURE.

Even if we’ll have to build specific screens for the smaller devices, we’ll be able to use the same technology, back-end services and share some templates between the desktop and the smart phone versions.

Moreover, the rendering speed was really good. We will show some benchmarks soon.

I can’t wait on what Google/HTC will ship in a couple of months.

As a quick recap, I’m building a lightweight server side custom framework which focuses mainly on handling JSON service requests.  This, combined with Mnesia, is our MC stack (Model - Controller).  The client browser will be fully in charge of the ‘V’iew layer of the app.

(See our post Why Erlang ? for more information).

A stable version of the core has been finished a week ago.  In brief, a request hits the server, Nginx proxies it to Mochiweb which starts a new process. 

At this point the framework converts the posted data (JSON) to a native Erlang structure. We check if the request contains one or more services and, based on their name (=:= module), we spawn processes accordingly.

As you may have noticed, in order to save some http requests and to use the full power of our server, the client can ask for an array of services.

i.e. : Let’s imagine you are building a screen which is divided into multiple small independent functional parts : your preferences, your status, your personal info, whatever …, you have the choice to wrap all those service calls into one JSON and the framework will happily process those in parallel … fine isn’t?

At this stage of development, and provided that the DB is not fully populated, if I make a comparison with other developments I’ve done using other languages/architectures, my global feeling is : SPEED.

Whenever I find myself in the situation of using a ‘map’ function and depending on the computation weight on each element, I’m parallelizing the operation (pmap).

Coupled with PURE for the rendering at the client side, we aim to end up with a highly responsive application.

The job now is to continue on that track and make the whole thing even more flexible.

One of my concern when choosing Erlang was the lack of libraries compared to other languages such as Ruby. However, I found relatively easy to develop, from scratch, a mail module responsible to dynamically build messages to be send to one or more addresses (via Postfix) and a ‘captcha’ system.

Soon, I will say a little bit more about those two points and will also describe how to quickly set up an Ubuntu server running Erlang and friends.

Stay tuned

We built PURE with the idea of having the rendering of the HTML on the client.

The idea behind it is to decentralize the power needed to run the application to the clients and also to lower the bandwidth needed (by sending just small pieces of JSON).

If this is good in our context (creation of a business application), some people might have good reasons to render the HTML on the server side.

For example, if you need to have the content of your application or website indexed by Google (for SEO).

We have planned to bring the logic of PURE to our Erlang back-end for our own needs (like sending tables to Excel for example) and there is nothing that should stop anybody from doing the same with any other back-end language.

But there is also the possibility to run the JavaScript on the server side.

While we have received comments about Spidermonkey or Rhino, we have never performed tests until now.

We have however received a message from Davey Waterson, JavaScript Architect from Aptana, telling us that:

PURE works unchanged out of the box with Jaxer running as serverside JS

Have a look at his example. You can also check out the Aptana website for more information about Jaxer

Davey will soon publish new examples of integration between PURE and Jaxer on the Aptana Forum

We’ll keep you updated.

On a more personal note, PURE has been entirely built on Aptana Studio and it was a great surprise to read that the same company was paying attention to our project.

Stay tuned

The launch of PURE (our JavaScript rendering engine), this week has been an exciting moment for the BeeBole team.

While the number of visits to our post introducing the solution reached 5145 hits the first day, our dedicated website for PURE started to gain attention.

More than 7000 of you came to discover the tool during the first week and some of you already started using the solution, like Jimmy from the blog Just Talk About Web.

The first wave of feedback that we got from various places (Reddit or our Google Group) has been really helpful and led us to release a new version of PURE (v1.3). Find the release note here.

Many thanks for your support.

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.