FireBase is a cloud database service, that allows developers to "power real time collaborative applications". What does this mean for you? It means that with FireBase you can easily build applications that allow users to interact via your website. FireBase provides your front-end with persistent and shared real-time data out of the box, letting you focus on your application itself. Developing applications with FireBase can be refreshingly easy, as I will try do demonstrate in this article. I will show this in combination with the AngularJS MVC framework, on an existing Plone CMS back-end.

The job of FireBase is to bind a data structure that resides in the client (in our case, JavaScript browser data), to a database server in the cloud. Data across the applications is kept in sync within the FireBase cloud so that users have access to real time data. In this sense FireBase fulfills two goals, both equally needed for interactive applications:

• Persistence. Data is stored in the database, and the same data is shared between all clients that use it.

• Notifications. Clients can use the cloud data to communicate with each other, making queue management and "push notifications" easy to implement without additional tools. If a single client makes a change in the data, the changes arrive to all clients that share the data simultaneously.

FireBase also enables managing your authentication in a flexible way. Both external agents (Facebook, Twitter, Github, etc.) and custom authentication is supported. I hope to reveal more about my experiences about authentication in a following blog post.

In fact, FireBase in many respects appears to be similar to the ZODB: a native object database for Python, well known for Zope and Plone developers. Just like the ZODB, FireBase also stores a tree structure of data. Its role is to synchronize this data to a native data structure of the used programming language. It also supports authentication, and just like the ZMI for the ZODB, the database content can be managed through the web. Keen readers from the Zope and Plone communities may also remember the announcement of porting the ZODB to JavaScript, an April fool joke made by David Glick and Matthew Wilkes. When we look around today we realize that the joke could have been serious.

FireBase is a commercial service, while offered completely free in its current beta release period. It is beyond the scope of this article to benchmark FireBase or compare it with alternate solutions for the same tasks: I merely focus on its ease of use and features, from a developer point of view.

Glue it to the rest of the app

FireBase offers bindings for JavaScript, Objective-C and it has a REST API as well. Bindings are available for several programming languages incuding Python. In JavaScript, FireBase can work together with other frameworks. To use FireBase in combination of an MVC framework is especially tempting: FireBase compliments the MVC's client side data synchronization capabilities and together they offer data coupling through the entire stack from database to front-end.

For the choice of MVC, we used AngularJS in these examples. Angular plays nicely with Plone, as it can work easily with Plone's built in templating system. Besides Angular, Greenfinity also supports development in other popular MVC frameworks (such as EmberJS and Obviel), and FireBase can work with these frameworks equally well.

Why Plone? The application is "just HTML". Plone does not need to know about our data, and the Firebase traffic does not enter our server. This means that this would work equally easy with any Python based web server (such as for example Pyramid), or we could even just rely on static files. The demo examples with Plone mean to demonstrate a successful integration strategy for creating a hybrid responsive application from the combination of a complex and opinionated, traditional web back-end such as Plone, and a JavaScript MVC like AngularJS.

Check out the applications

FireBase allows you to develop simple applications in a short amount of time. It can be integrated with existing code, giving you a way to build out your client site infrastructure to support the application you choose to build, instead of focusing on implementing storage and networking.

There are two applications we built in FireBase in the time span of one afternoon. They are fully functional with a minimal amount of effort. Please keep in mind that we have not tested these examples for scalaibility or performance with high volume of users. The goal here is to show you how easy the applications can be built.

The demos are hardly more than the original demo examples that accompany the FireBase API for AngularJS. We are talking about one-one page of JavaScript code each. You can visit the source code for more details.

You can install the python package in any Plone site. After installation via buildout and the Plone Quickinstaller, the package provides you a Poll portlet and a Chat portlet. You can add these portlets to your site. To set up the portlets, you need to enter Manage Portlets as an administrator, and set up your FireBase url and secret, which you can copy from the FireBase admin interface (Forge) after creating your database.

To start quickly, you can use the live demo and save yourself from the burden of installation.

Poll Application

Polling features are pretty popular on websites, especially when they show real time results. Firebase allows us to build a poll in a Plone portlet and track those results.

Clicking on a bubble in the poll increases the number of votes. Votes are tracked directly after the text in the bubble. Bubbles automatically sort and display based on the number of votes. As votes are changed, the user can see the bubbles resort themselves instantly.

This poll is unique in that it allows the users to edit the poll at any time. Users may add a new item, remove an existing item, or click on an existing item to edit it. AngularJS makes the implementation of the editing functionality remarkably simple to achieve. In a real application, the permission to edit the choices should be limited to some authentication role of Plone. For the sake of the demo we allowed all people to play nicely together and test the application without any necessary permission.

This application...

• is responsive: when a user votes on an item, all the clients will immediately update their counters and reorder their bubbles.
• uses shared data: the data is not stored in the Plone back-end, but just in the FireBase cloud. Because of this, the portlet controlling the same data can be installed on several websites simultaneously.

Live Chat Application

Live chat applications are becoming an increasingly popular way to offer customer service on a website.

The chat application in the demo site allows you to edit your nickname (or use an Anonymous nickname). When you return to the site, the chat application will remember any nickname you previously used. If you are logged in as a Plone site user, it will default your nickname to your Plone user name. Users can chat across locations with other users via the chat window embedded in the website. No chat clients to download!

This application...

• is responsive: when a user sends a message, all the clients will immediately display this message.
• uses shared data: the data is not stored in the Plone back-end, but in the FireBase cloud. Because of this, the portlet that gives access to the same chat room, can be installed on several websites simultaneously.

How it works

In our next post, I will tell you how this works. I will also tell more about my experiences about custom authentication, managing your data and administering your database through-the-web. I will also show how to access the same data from Python.

Are you interested to hire Greenfinity to add simple, but impressive interactive features to your existing website? If so, let us know: we offer one hour of free consultation to discuss your ideas, if you are one of the first 5 clients contacting us after we publish this article. Remember: great features need not be neither complex, nor expensive! Contact us for more.

Pyramid is an elegant and popular web development framework that is based on the Python programming language.

The three (no, six) tenets of Pyramid are Simplicity, Minimalism, Documentation, Speed, Reliability, Openness.

This year Greenfinity attempted the impossible, by creating the 7th element: Cookies. We made almond shortbread cookies, featuring the Pyramid logo. We sent them to the PyCon 2013 conference, as a sweet surprise to the participants of the greatest Python event of the year.

Did you get a look at these limited edition Pyramid cookies at PyCon? We hope you enjoyed them.

And now for something completely different...

In a typical Python web development project, you need JavaScript as well on top of Python. Here, I will show a method to satisfy your JavaScript installation and processing needs - straight from zc.buildout, the well known tool for the installation of advanced Python projects.

TL;DR

In this article, I will focus on how to do installation of server side JavaScript from bin/buildout. In upcoming posts, I will show what you can actually use server side JavaScript for, and also, how you can process client-side (browser) JavaScript for your web application.

Additional dependencies

First, we need some dependencies that buildout cannot handle itself. You need to install NodeJS and npm, the Node Package Manager. On MacOSX, this can be done in the following way, if you use MacPorts:

$ sudo port install nodejs
$ sudo port install npm

On Ubuntu, you would do the following instead:

$ sudo add-apt-repository ppa:chris-lea/node.js
$ sudo aptitude install nodejs npm

Check out the instructions for installing Node on your favorite OS here.

The good news is that while this is an extra dependency, it's the only dependency you will need. With this you can use the tools and follow the practices of the JavaScript developer community, without the need to use applications ported to Python, Java, or PHP, reinventing the wheel.

See it in action

We can use the example buildout of Substance D for demonstration. Substance D is an application development environment built using the Pyramid web framework. Substance D is used only for demonstration here, the same method works equally well for any Python, buildout based web application. That said, you can skip trying this buildout if you want, and add a similar configuration to your own project right away.

Let's check out the sources. Sdidev is the buildout for developing on Substance D. It is meant to be used in development only and the buildout is not needed in production. Note that for this demo, the ree-grunt-sprinting branch of the sdidev buildout has to be used.

$ git clone git@github.com:Pylons/sdidev.git
$ cd sdidev
$ git checkout ree-grunt-sprinting

Do a virtualenv:

$ virtualenv -p python2.7 .

And make a buildout:

$ bin/python2.7 bootstrap.py
$ bin/buildout

At the end of the buildout's log you will see some interesting things happening on the console. After building out our Python, zc.buildout starts showing colorful signs of progress with building out our - surprise! - JavaScript.

Installing node_modules.
npm http GET https://registry.npmjs.org/grunt-cli
npm http GET https://registry.npmjs.org/grunt
npm http GET https://registry.npmjs.org/yo
npm http GET https://registry.npmjs.org/bower

--- SNIP ---

NodeJS server side modules updated.

... Fun isn't it? But wait, we have not finished yet; it goes on:

Installing bower_modules.
bower copying /private/tmp/gruntdemo/sdidev/src/slickgrid
bower fetching slickgrid
bower cloning git://github.com/twitter/bootstrap.git
bower cached git://github.com/twitter/bootstrap.git
bower fetching bootstrap
bower cloning git://github.com/components/jquery.git
bower cached git://github.com/components/jquery.git
bower fetching jquery
bower checking out jquery#1.9.1

--- SNIP ---

Bower client-side modules updated.

What just happened?

Let me explain.

In our project's buildout.cfg, we are extending yeoman.cfg. Yeoman is Twitter's bundle to support processing and installation tasks for web development. It contains three tools: Grunt, Bower, and Yo. I will talk about what these do in an upcoming article. Grunt can also be installed independently from Twitter's Yeoman.

The yeoman.cfg is a buildout extension config that I created to cover all buildout tasks we deal with. You can take yeoman.cfg with you, and use it from your own buildout without the need to change it in any way. The only thing you add to your buildout.cfg is:

[buildout]
extends = yeoman.cfg

The yeoman.cfg file contains the rules for building JavaScript. It contains a few parts each doing a different installation step.

[buildout]
parts = 
    node_modules
    bower_modules
    grunt_script
    bower_script
    yo_script

The first part does the installation of selected Node modules via npm and will be run each time you update the buildout.

[node_modules]
recipe = collective.recipe.cmd
on_install = true
on_update = true
cmds = NODE_PATH="" npm install .; echo "\nNodeJS server side modules updated.\n"

npm is the standard tool to install server side (Node) JavaScript. "npm install ." will install the package at the current local directory, with all its dependencies. To make it work, we need to turn our buildout into a virtual Node package, thus enabling to specify its dependencies in a package.json file. Note that this file is a data configuration in JSON format, which means that generic JavaScript is not allowed in it.

{
   "name": "sdidev-resources",
   "version": "0.1.0",
   "devDependencies": {
     "grunt": ">=0.4"
   }
}

You can try to issue

NODE_PATH="" npm install .

from the console, if you are in the buildout root, to see how this installation works. The same will be executed from bin/buildout, via the node_modules buildout rule.

A more complete package.json version will also install some other tools you will find useful. By adding your own package dependencies to it you can satisfy virtually all your needs. I will talk more about the usage of these tools in the upcoming parts of this post.

{
   "name": "sdidev-resources",
   "version": "0.1.0",
   "devDependencies": {
     "yo": "*",
     "grunt-cli": "*",
     "bower": "*",
     "grunt": ">=0.4",
     "grunt-contrib-jshint": "*",
     "grunt-contrib-uglify": "*",
     "grunt-contrib-concat": "*",
     "grunt-contrib-less": "*",
     "grunt-contrib-watch": "*"
   }
}

How it works

The Node Package Manager provides two ways for installation: global or local. Global installation is done with the -g parameter. Global installation is often discouraged, partly because it usually requires admin privileges. In the solution I present here, we use no global installation, instead, a local installation is utilized. This has a few advantages for us.

• The installation will be local to the buildout, and isolated from the other buildouts, allowing each buildout to have its own private working set of installed packages and versions.
• The NODE_PATH="" setting in the node_modules buildout rule will cause your globally installed Node packages to be ignored as well, and the usage of your local installation will be enforced. NODE_PATH has a similar role in Node as PYTHONPATH in Python.

This will cause all packages installed locally into the node_modules directory in the buildout root. You can delete node_modules and re-run bin/buildout to regenerate its contents - in the same way as it would happen if you deleted the Python eggs directory.

The only thing left to do is running executable applications. The following buildout rule takes care of that in case of grunt:

[grunt_script]
recipe = collective.recipe.template
input = inline:
    #! /bin/sh
    export NODE_PATH=${buildout:directory}/node_modules
    ${buildout:directory}/node_modules/.bin/grunt $@
output = ${buildout:bin-directory}/grunt
mode = 755

This will create a bin/grunt executable script, which will execute "./node_modules/.bin/grunt", the executable that npm has installed. This means that the JavaScript tools will be runnable from bin/* in the same way as all other buildout scripts.

$ bin/grunt --help

Want to use even shorter commands? Make use of virtualenv, if you prefer so. In this case you will not even need to put the bin/ in front of the script names. For example:

$ source bin/activate
$ python2.7 bootstrap.py
$ buildout
$ grunt --help

Summary

In this post I showed how JavaScript NodeJS installation can be integrated to zc.buildout for a Python web application, and how this integration works. Next I will show how to use your newly installed tools for your web development project.

Sublime Text is a sophisticated text editor for code, markup and prose.

I have been a long time Vim user, and always resisted the temptation to jump on the IDE bandwagon. Admittedly, I am a dinosaur, but it is not because of this, that I had stayed faithful to Vim just until recently. Vim has always done things the way I needed, and every time I tested a potential new editor, I realized that something was missing that I used to depend on in Vim.

So... last Christmas I started to think about what I would like to get from myself as a present, and I thought that a new editor would be nice. I started to test Sublime Text 2, and, surprise: I found it a very satisfactory experience.

I have a few editor features that I consider as basic. Naturally, I have my own point of view: since I am doing web application development with Python and JavaScript, some things such as tab settings or linting can be more important for me than for programmers in other languages, while for the same reason I don't care much about features related to, say, compiling.

So let's see my first experiences with Sublime! I installed it, and started to add and configure all the plugins I need for my workflow.

Syntax coloring, correct tabbing with 4 soft spaces

I consider correct tabbing to be basic, which means that if an editor does not have this, I would exclude it without looking for anything more. Fortunately, most good editors do this correctly, including the ability to understand the syntax of the given programming language, as it affects auto-indentation.

Live, "as you type" syntax checking. linting.

I have this feature in Vim, because it is really important to see live errors and warnings as you type, especially in JavaScript, where an excess comma can simply break all your code. I make this a basic requirement in my search. And, this works well in Sublime.

Actually, it works better for me in Sublime then on Vim. I succeeded to set this up in Vim, but since I did not follow best practices for installation and do updates rigorously, I ended up with something that was working, but never exactly matched any of my team members version. Sublime solves this problem with its package installation system.

Editable configuration files

This is a great one. The configuration files are editable in JSON format and they are updated in sync with the changes you make through interacting with the editor UI. For example, if you zoom in and out, and if the preferences are open, you can see the text of the configuration file updated live.

Supports Vim keystrokes

It knows Vim keystrokes! All you have to do is enable the Vintage module in the configuration. No more excuses for Vim users! You cannot say "...but ...but I could do this much easier in Vim."

Git support

Git support works through plugins, and it works well. Although, I would love to see a more powerful way of presenting diffs, similarly to VimDiff where you can see the two versions side by side.

Multiple cursors and selection

This is simply awesome. It is easier to show it than to explain it:

Code Intel

Sublime knows where your modules are at, and you can click on a symbol any time to look up its definition. This is done by the SublimeCodeIntel plugin. For python code in a buildout, this means that Sublime will know all your package locations, be it a core Python library module, or a locally installed package under "src" or "eggs". For buildout, I use the following section to generate the information that Sublime needs:

[codeintel]
recipe = corneti.recipes.codeintel
eggs = ${instance:eggs}

Debugging Python

Python applications are debugged with pdb from a console. When I am at a breakpoint, and do a listing of the code, or step up and down the trace stack, Sublime will open the source and place the cursor. Very useful. The only thing I did to install the PdbSublimeTextSupport python package, and save the following as a .pdbrc file:

from PdbSublimeTextSupport import preloop, precmd
pdb.Pdb.preloop = preloop
pdb.Pdb.precmd = precmd

Autosave! Autosave!

I leave this feature until the end. I know that it is also possible in Vim, but for some reason I have never used it. Sublime makes autosave very tempting. When you click away from the file you are editing, it will be saved. I was worried a bit that autosave can lead to accidental loss of code. But then I convinced myself, that the ability to undo, coupled with the fact that I version manage my code anyway, compensates the risk. The result? I type in my code, then I click the Reload button on my browser... and, I can see the updated version immediately! I don't really have to say how much this increases my work productivity.

Problems?

Not many, really. I find a few places where I would like to see improved support. For example, easier management of color schemes would be great. But altogether, Sublime Text 2 provides me with a great development experience.

Getting help

There is plenty of documentation on the web that explains how to configure Sublime and its plugins. I found the blog post of Mikko Ohtamaa especially useful.

Price

Finally, a word about pricing. Sublime is not free software. A single user license for Sublime Text 2 costs $70. But Sublime can be downloaded and trialed for free. Unlike other software, that lock themselves down at the end of the trial period, and perhaps at the worst and most unexpected moment, Sublime will instead periodically pop up a discreet message to you, but you will be able to continue to use the software. I immediately rewarded this user friendly behavior by buying Sublime's license.

Verdict

Sublime Text 2 is a programmer editor that is stable, and provides most needed editor features on a high level. At the same time, it remains easily hackable, thus connecting the useful with the pleasant. It is worth to give it a try. And, if you are a Vim user, you will find the switch to Sublime extra comfortable.

In this video presentation (targeted towards JavaScript Web Developers), I show how I use JavaScript unit testing in my everyday work.

I want to demonstrate that unit testing of JavaScript code is not only important for Continuous Integration - it also becomes part of the daily working routine of a software developer. If we practice unit testing it will help us to produce better quality JavaScript code.

And it's more fun, too. It makes it possible to do test driven development of web client JavaScript code.

During the screencast, I show how I use the BusterJS test runner to run the QUnit tests of the KARL application. Note that in its current unfinished state, buster-qunit requires a manual preparation of your existing QUnit tests, and once this is done, the tests will be able to run both as native QUnit, and as emulated BusterJS tests.

Interesting links:

BusterJS: http://busterjs.org

BusterJS is a JavaScript testing toolkit that allows unit testing of both in-browser and Node.js JavaScript.

buster-qunit: https://github.com/reebalazs/buster-qunit

The buster-qunit is an unreleased extension to buster.js. Even in its current unfinished state, I find it very useful, because it allows me to run the existing QUnit tests from the KARL project, with the more modern test runner of BusterJS.

KARL: http://karlproject.org

QUnit: http://qunitjs.org

buster-webui: https://github.com/reebalazs/buster-webui

Jenkins: http://jenkins-ci.org