Presupuestando: User stories

Presupuestando (budgeting in Spanish) is the name of my little project. It's aim be a site in which a user can request a budget (for example, reparations in the customer house, car or maybe travels), and the companies can interact presenting its budgets to the user.

At the beginning of the project i have compelled (from my mind) the following user stories:

Customer stories

• A customer request for a budget in its own words
• There is only a filter of budget type (Travelling, Housekeeping...) 
• The user can add a new type but the Prespuestando admin have to approve it (and find vendors to do it), so in this case the interactions finish at this point.
• The customer can be an existing customer or a new one, but the form would be the same for the two types
• The customer can fill an expected range of money for the budget or not
• The customer's location is detected and shown in the form. The user can edit this location (or drop it), the customer also can restrict the budget request to vendors in a specified perimeter from this point.
• The customer is notified when a vendor applies for a budget,  at this moment can request a change in the budget, approve the budget or discard it.

Vendor stories

• A vendor is notified when a customer request for a budget in one of his areas of interest 
• A vendor is registered and assigned to one or more budget types, one of the vendor's data will be its location
• The registration of a vendor is approved by the site admin.
• A budget is described in general and in lines, in a flexible and UX based interface (this story will be detailed prior its development)
• A vendor can request intervention details to the customer
• Vendor can save a budget in database
• Vendor can send a budget to the customer or discard it
• Vendor can change a applied budget if customer request it.

Admin stories 

• An admin fills the types of budgets
• And admin approves the registration of a vendor

Additional notes:

• At this moment is not determined the channel selected to the communication vendor-customer. The easy solution would be the email, but a twitter solution will be studied
• The admin stories has a very low priority to the web application. The admin can introduce the types by hand in database and vendor approves can be automatically approves (and disabled via Database if case of problems)

Backend for my project, choosing a NoSQL database

One of the goals of this projects is to have the possibility to work with a NoSQL approach. There are a lot of NoSQL documentation in the Internet, so I only gonna do a brief comments about its philosofity and principes:

• It's not a clear definition about the features of a NoSQL database, there are a lot of tools with differents approaches (document or object oriented, big hashes, ACID and no ACID), 
• A NoSQL database can provide you a huge scalability and high performance. Twitter, Google, Facebook does need this, and your application. Well, about performance, why not?.
• Typically object-oriented applications are builded around the SQL databases, letting the business logic reside in the database and working as simple CRUD interfaces. This is not necessary bad, SQL has its optimizations, performance, specialized teams,... but NoSQL gives you more options to have in mind.

After a short investigation, and following recomendations, I decide to use MongoDB as my first approach to NoSQL databases. My first option was Cassandra, with has a lot of hype around because is used by Twitter and Facebook. Its main features are a descentralized approach, Cassandra is never designed to run as single node but in a bunch of them, and is not ACID compliant.

In the other hand, MongoDB is ACID compliant and is an document oriented database, you can use JSON to manipulate data, is scalable depending on your needs but valid in a single node. It also seems well documented and supported.

A would like to combine with some sort of business DSL (in my next post i'm gonna talk about business oriented development and DSLs) and test two things.

The first one, If my front-end is build in GWT, my business logic in the DSL and  I don't want to use traditional CRUD generation, does I really need Grails building plugins or It's better that i develop another command system around my DSL?

The second is as follows, in many projects there are a considerable amount of repetitive code to access to certain tables (master tables), to display combos, completers, sometimes i18n... Most of this times, this data has no associated business logic, only data retrieval from Database.

Well, if MongoDB can be queried using JSON, and my GWT Front-End understands JSON, is it viable access this tables directly from the front-end? Can this method be productive dropping the repetitive backend code? Would I be acting against layer encapsulation?

I'll let you know my conclusions, give me some time!

Front-end stack for the new project: GWT

I'm going to start the project talking about the technologies I want to use. Obviously this technological election isn't the result of a reasoned study to fix the architecture to both client and functional environment. There are no client, there are no functional study, (neither name for the project!).


Today I'm gonna talk about Front End Stack. I would like to implement the UX of the project using Google Web Toolkit, GWT, and GWT are going to comunicate the server side via REST calls to a Grais Backend.


The main difference of this election is that I already know GWT. I worked in a pretty serious GWT project for 9 months, also I'm the responsible of GWT workshops in my company, and, the most important part, I do like GWT!

One reason is that I think I'm the perfect user profile of this technology, I have a knowledge of front end techonologies such a HTML, JavaScript, CSS, but I'm far from be a good front-end programmer. I am not confortable writing jQuery (although I feel is a great technology), and with these capabilities, GWT fixed pretty well as Java tool to build Rich Client Interfaces.

As GWT is a Java tool based on a Java->HTML/Javascript compiler it main benefits are that you write the code in Java, with a strong typing, easy unit testing (i'm talking about UNIT testing), quite productive APIs (from Google, vendors and J2SE) optimization process, and component oriented programming model.

I also think GWT can be a perfect tool to embrace HTML5, using its Java-Component based encapsulation, you can easilly migrate the implementation of a component to a HTML5 one, or add new advanced components to your toolset.

But probably my favorite feature of GWT is not a feature. GWT is a tool, it's not a framework. There are a lot of frameworks in Java. Struts2, Wicket, Spring MVC, JSF,.. but you can view GWT as a tool to translate Java into Javascript. And from this tool you can build your infraestructure (your framework if you want), and this infraestructure can be quite productive.

In my nine months project with GWT, we only reach the surface of this capability using code generations tools and I have the feeling that there are not a lot people talking about building GWT tools. I would like to do some research on this field.

Another feature I wanna test is the REST integration. In our project we use GWT RPC API, with an excellent result. This API seems a bit unfashioned, its name reminds you college times, it's simillar to RMI (at least without RMIException), but it's very productive. With this API you can have tested and compiled calls, it's very simple to integrate the calls with Spring IoC container, and the problems with proxied objets can be avoided. I recommend this sollution:



But this calls are no REST-complain. In other environments you may require to do this REST calls, for example, in my project. I want to use Grails as rapid web development framework, because i also want to test it (I worked with Groovy to do some scripts a time ago), also the dynamic capabilities of the language to build something not far from business oriented language (but this is another post), and is tool and command oriented development style as a via to implement my own code-generation tools.

To do this the best option seems to be GWT Overlay types, and combine it with Model View Presenter (MVP) pattern. This pattern is also a pending task for me, In our project we use a quite rudimentary MVC that got us trouble when the project growed.


To finish the post, a great presentation on GWT, Grails, REST and MVP from Matt Raible.

Building SOFEA Applications with GWT and Grails

View more presentations from Matt Raible.

New project, old blog

Fortunately Google guys have a lot of disk space and my old blog hasn't been dropped yet!

I started this blog two years ago without a clear purpose to share some general thoughts, tricks, and to try to improve my writing level in English (typical Spanish!) and as many blogs, the blog was abandoned.

Today, I reopen the blog to write about a new personal project. What project? I'm not sure at this moment, but is for sure that the project exists.



The blog's name source, via Microsiervos

For the last years I've been having the pleasure to work in interesting projects, with state of art technologies, sometimes with the responsibility of evaluate and choose them as Software Architect. In my free time I have read several books, blogs, articles, workshops, worked in small conferences and thinks like that, important stuff but no "real" development work.

Nowadays the situation is different, I'm working in a static phase of an old project, most of the time in maintenance tasks and, although I think you can learn and become a better professional in all situations, I have the feeling that I must start something and evaluate new technologies and paradigms.

So this is the motivation of the new era of the blog, share the steps and thoughts of the new project, wish me luck!