Thursday, September 19, 2013

Book Give-away: Hold a chance to win free copy of the book "Vaadin 7 UI Design By Example", just by commenting!

And the winners are:
  • Iskael Diaz Marquez
  • Camilo Gonzalez
Packt Publishing has two copies of Vaadin 7 UI Design By Example to be given away to two lucky winners.

How you can win:
To win your copy of this book, all you need to do is come up with a comment below highlighting the reason why you would like to win this book.

Please note: Winners residing only in the USA and Europe would get a chance to win print copies. Others would be provided with eBook copies only.

Duration of the contest & selection of winners:
The contest is valid up until October 5th 7th 12th, and is open to everyone. Winners will be selected on the basis of their comment posted. 
About the book:

This is what Packt Publishing says about the book:Vaadin 7 UI Design By Example written by Alejandro Duarte, is an engaging guide that teaches the user how to develop web applications in minutes. This book shows the user how to use Eclipse, Netbeans, and Maven to create Vaadin projects. It then demonstrates how to use labels, text fields, buttons, and other input components. The book also explains Vaadin theory to prepare the user for the rest of the trip that will enhance their knowledge of Vaadin UI components and customization techniques.

Join the contest! Leave your comment!
English, Spanish, Italian, Russian, any language accepted!
Please note that comments are moderated and your comment will not appear immediately.

Tuesday, May 21, 2013

Lightning fast commenting (in and out)

I have used this two or three times in my life but it's one of those simple (and useful?) hard to forget tricks. It could be useful during tough debuging times.
If you have several lines of code and you want to comment them out, you can use standard multi-line comments (this is for C++, Java, and others):
    Component contentArea = getContentArea();
    layout.setExpandRatio(contentArea, 1);
But you can also comment out the first and last lines using single-line comments:
    Component contentArea = getContentArea();
    layout.setExpandRatio(contentArea, 1);
Now you can comment in and out your code just by removing or typing the first "/":

CAUTION: Avoid usage in programmers with chronic lava flow disease, including junior and senior developers.

Monday, April 29, 2013

Empty lines and semantics in source code

I remember a couple of years ago, while working with some developers, one of them seemed to be irritated by seeing empty lines in source code. I think he was missing an important dimension of software: Readability. Grab a book nearest to you. Go ahead and do it. Grab any book close to you. Open it on any page. Are there any blank spaces between lines? If you didn't take a book for kids, empty lines will emerge like crack in the 80's making paragraphs easier on the eyes (instead of making them red). Speaking of the devil…

I feel better now*. Just as empty lines break ideas up in text books, empty lines in source code offer a new dimension for structuring code. It’s like something that the developer wants to say about the code. Almost like nonverbal communication. I’m exaggerating, but really, use empty lines to separate related lines of code when "extract method" gets to the limit.

Perfectly refactored code will have only one line per method, which is absolutely a boost in detail complexity. Don’t forget detail complexity! Sometimes we are so concerned with minimizing dynamic complexity that we end up adding tons of detail complexity. 100 methods are harder to read than 20 methods 5 times bigger if you properly place empty lines.

By the way, keep an eye on semantics, use the most suitable words for identifiers, and avoid Hungarian notation. If you need a variable to store the amount of attempts some action is performed, call it attemptsCount (or something similar with two words), don’t use things such as ac, or just count (count of what?). Saving some milliseconds on each key stroke is not as good as saving two or three days of development time plus two or three days of debugging time. Let’s do the math just for fun. When I type attempsCount it takes me like 2 or 3 times more than count. Let’s say 5 times more. If we have to type attemptsCount 1000 times and each time takes 2 seconds, we have a total of 2000s (or 33 minutes). If we have to type count 1000 times and each time takes 0.4s (2s / 5) it will take a total of 400s (or 7 minutes). Total gain using count: 26 minutes. Let’s say half an hour. Now, depending on the context, this could be absolutely nothing or way too much. Are you counting just one thing in your application? if so, count is OK, but I bet that if you are typing count 1000 times, you are counting more than one single thing. So, attemptsCount seems to be more appropriate for real life applications. Just let the code speak by itself.

And remember, it’s not only about complexity and semantics, which in turn determine maintainability. It’s also about writing code that is nice to read and good to programmers’ eyes, if you are not like the aforementioned co-worker, of course.

* Because of the blank line, don't get me wrong! I like to keep my neurons intact... well, except for some beers every now and then. By the way, brain cells do regenerate and reproduce, even after maturity. Thanks biologists. Love you Viviana.


Friday, February 22, 2013

Enterprise App now available with Maven

Finally! I've managed to write a Maven POM for Enterprise App. Just add this into your pom.xml file:


You might need to add the official Maven repository for Vaadin addons as well:


Better late than never ;)


Thursday, February 21, 2013

A strategy to manage large SQL tables

Some months ago, I got involved in a project where I needed to generate quite big reports (more than 1 million rows) extracted mainly from an SQL table growing at a very fast pace. This table played a central role in the everyday usage of the system.

In order to avoid losing performance, we scheduled a database backup and a process to empty that large troublesome table every 3 months. But the problem with the reports remained the same. At some point we ended up with a table with more than 3 million rows and sometimes we had to generate reports with more than 1 million rows. Even if the report was small, querying this table was taking way too much time (some times more than 10 minutes).

Here is what we did. First we decided to design kind of an ETL process using only SQL (somebody will argue that this is not ETL, but I think it is). How? We developed a module to execute SQL scripts defined at run-time every day at 3:00 am.

These scripts were basically "insert into table" statements. They took data from some tables and inserted the result into another table. Data in the destination table was more suitable for reporting, so we gained some time when generating the reports by moving processing (expensive joins mostly) from working hours to 3:00 am, when nobody, even the CEO, was using the system. Reports were way faster (around 20 seconds for the biggest one).

A couple of months after going to production with this scheme, we faced another problem. The destination table, which was supposed to be more suitable for reporting, started to be a problem as well. As you may guess, it was too big. We were facing our initial situation again. The solution: Split that large data set into smaller ones. How? Every row in that table had a time stamp. So we divided the data into semesters by making one table per semester. The script executor module was modified to put the data into the correct table according to current date. The reporting application was also updated to allow users to select the semester (so the app was able to query the correct table).

Report are pretty fast at the time of writing this. In any case, this solution gave us some time to think about implementing a Big Data solution, NoSQL maybe... Wait! This is already kind of a Big Data solution :)


Friday, January 18, 2013

Pagination: An old web 1.0 solution

A few days ago, an Enterprise App user asked me if lazy loading is better (particularly in a buisiness application) than pagination. My answer: Totally! Pagination is an old, so called, web 1.0 solution. At that time, no AJAX was possible at all.

It's not very usable to have a lot of 1, 2, 3, 4, 5, 6, ..., 100 links. Lazy loading รก la Vaadin is not only easier to use but to understand for the end user. If a user sees a scroll bar, they will understand that scrolling that thing will cause the rows to, well... scroll. No need for further explanations about it (is there any explanation to make?). Chances are that pagination will cause some novice users to get lost, at least the first time they use the software.

Sometimes scrolling through the entire data set is certainly necessary and pagination could make that task a pain in the neck. I think pagination is OK if we have, let's say, seven pages at most (tanks Miller). If the number of pages is uncertain at design or development time, I would definitely try a different approach. Nevertheless, if the target client devices allow it, I will go with lazy loading.

I don't know why the heck I used pagination for such a long time. I think I just got used to use pagination in every table with data I created. DisplayTag could be guilty, but even DisplayTag can be configured to use a new appealing and delectable lazy loading mechanism.

Some of you might argue "Google uses pagination". I must admit there are situations where pagination makes a lot of sense. I can't imagine an almost infinite page with all the results of a Google search. Also, I feel very comfortable reading online books in a paginated user interface. But a lot of debate is happening out there. Even Google itself prefers view-all search results.

Another, specially but not exclusively, great thing about lazy loading when used in tables, is that it is a good way to get your web applications to appear more modern, more web 2.0. Just note how Facebook, Twitter and other heavyweights use lazy loading to show their data. Go ahead, modernize your web apps by using some lazy loading.

Tuesday, January 15, 2013

Hello GitHub

I have been a ProjectLocker and Assembla user for years. They both offer excellent tools for software projects management. However, now I'm moving to GitHub, 'cause you know, I'm becoming kind of an open-source activist (don't take that too serious, it doesn't mean that I'm pretending to be the next Stallman or anything). GitHub seems to be better suited for social open source projects.

I have written my share of code, so it's time to give something back to the World (also, I'm publishing all that code to raise my developer career but it doesn't sound like the thoughts of an open-source activist). Check it out, tons of code for you: QBasic, C, C++, PHP, and Java (mostly Java), and some projects using well known Java technologies such as Spring Framework, Hibernate, JPA/TopLink, Struts 2, SiteMesh, DisplayTag, Vaadin, and Enterprise App).

Enterprise App users! now you can follow the add-on development here. I will migrate all issues and tasks to GitHub to handle everything from one place. You can fork and send patches (through pull requests) if you want to.