As a foundation, I usually use Python DB API (namely, psycopg2 module). The API itself is rather low-level and is crying for improvement. What can be done?

Initially, let’s just make an ordinary decorator for opening and closing a transaction:

@transactional(db)
def do_database_stuff():
    return db.fetchall('select * from employee')

here db represents a small helper class, which monitors the opening and closing of cursors, and also contains connection management code.

Our decorator is not quite cool. On the one hand, it does everything correctly and properly closes the transaction with any outcome; on the other hand, we need to write a separate function for every transaction. This is somewhat messy.

Lets try to write it down as a lambda expression:

transactional(db)(lambda:db.fetchall('select * from employee'))()

Certainly not the cleanest line of code in the Python world. Incidentally, it is easy to make mistakes and miss the last pair of brackets.

To make us all happy, Python 2.5 offers a special new syntax for executable blocks, allowing better flow control of block entrance/exit. Such blocks are very common in the management of system resources: files, sockets, semaphores, etc.

This is how it will look like:

from __future__ import with_statement
 
with db.transaction() as tx:
    def employees = db.fetchall('select * from employee')

This is just one of the possible options. We have named object, tx, specified in the with-expression, representing our transaction. We can later place some useful methods into tx.

How with-expression interacts with an associated object (in our case tx)? There are two agreements:

1. obj.__enter__() is always invoked before entering with-block.
2. Any way out of with-block always causes a special method obj.__exit__(type, value, traceback) method to be invoked, where all three parameters will be filled only when an error occurs (typically for Python, they represent type of exception, the exception object and the call stack, respectively).

In our case, everything is quite simple:

• We make an __enter__ method to open the transaction and perform any connection management logic.
• Our __exit__ callback will be closing the transaction. The simplest implementation would be to always execute always commit on succuss, and if the with-block threw an exception, always try to do rollback . In real life, of course, this is not enough – you have to keep track of what kind of exception were thrown.

Python also makes sure that the call to return inside with-block will just as well be “filtered” by __exit__ callback.

What are the disadvantages of managing transactions via with-blocks? First of all, with-statement is not a function in terms of Python. For example, we can not repeat the execution of the block in the __exit__ callback (in case of decorators this can easily be achieved, allowing to program any retry logic).

The plugin home page.

Please try it out!

When we started to experiment with Balsamiq I could not have imagined how much this program would affect our development process and how many radical changes it would bring.

We develop business applications and developing online banking, online advertising and CRM are a very significant proportion of our work. We have developed some publicly available applications that include a large non client facing administration component. For example, we’ve built an E-commerce system, where about 15 screens are publicly available, while the in house admin component includes about 40 different screens, and continues to grow.

It’s also important that we don’t have our own graphics designers and UX designers on the team. Why? It’s probably a subject that warrants a separate post.

Before Balsamiq Mockups we would develop functional requirements and then make “the requirements for the designer”. These requirements we would then pass to a graphics designer with UX designer skills or an UX designer with graphics designer skills and then pass them onto the other. As they are all external contractors, they have their own schedules and priorities which may not always fit with that of the project. They can only afford to allocate a specific amount of time to the project and in this time need to draw all the screens.

We need to continually communicate with the designer, discuss screen drafts, and try to pass on our knowledge and understanding of the business to them. Trust me, it’s quite involved process. If everything goes smoothly and our designer grasps the idea and successfully implements the design then in a month or so we would get the screens and move forward.

What is important here? In fact, the work of designer comprises two major parts:

1.    Analytical part – to decide what functionality needs to go into/onto each screen; and

2.    UX part – to pick and place interface elements on the screen, and do it in an optimal manner

The problem is that for a UX designer the analytical part requires a deep understanding of the complex business models which is time consuming and duplicates the work that we did at the beginning of the project in order to write the project requirements. Designers often have little interest in doing the analysis.

After we mastered Balsamiq, we plucked up the courage so instead of writing requirements for UX designers we started to draw interfaces ourselves. Although there is complex logic in Web systems such as AI, workflows, maths and graphics they are essentially flat. Between 50-80% of functionality of a typical Web app is shuffling data between front-end and DB.

It’s our project manager or analyst who understands the client’s business and requirements and communicates with customer and they draw the screens. This means that we can put the screens together pretty quickly. The output is a set of wireframes instead of a long specification document, which is then passed to the UX designers. This simplifies the process and makes it more efficient.

Now the mission of UX designers is to make highly-usable user friendly screens from our purely functional drawings preserving their functional integrity. After a few completed projects using Balsamiq the quality of our “pre-screens” have improved so much that in some cases we have done the UX part as well. After all it’s not rocket science.

As a consequence we get some interesting results. There is no need to write cumbersome requirements; most of them can now be expressed graphically using wireframes.

There is one more important benefit in that we now get the opportunity to embed UX design into our Agile-process. Our development speed has increased significantly, the stage of project ”acceleration” is considerably shortened.

Also communication with our customers has improved. Instead of discussing long texts we can talk graphical screens, which facilitates understanding between us and our client, which is one of the key elements in the success of any project.

It’s quite possible that there are better prototyping programs than Balsamiq Mockups. We selected it based on reviews and ratings. We tested it, liked it and bought it.  Balsamiq Mockups meets our requirements and does exactly what we need.  And it’s not that common in software industry.