Tuesday, March 27, 2018

New book about Vaadin Framework 8 coming out

As some of you may already know, I started writing a book about Vaadin 8 for Packt Publishing almost a year ago. After inevitable hindrances and changes in the scope and schedule, the book is almost ready now!

The book is addressed to Java web developers with basic knowledge of the Vaadin Framework 8. If you have followed the tutorial at https://vaadin.com/docs/v8/framework/tutorial.html and have played around with the framework, this book is for you. Of course, more experienced developers can also find interesting ideas in this book.

The book covers topics related to software design such as code organization, modularization, and API design. It also serves as a practical guide to common features in business applications, ranging from authentication and authorization to reporting and CRUD user interfaces.

Here's the outline (chapters) of the book:

  1. Creating new Vaadin projects
  2. Modularization and main screens
  3. Implementing server-side components with internationalization
  4. Implementing authentication and authorization
  5. Connecting to SQL databases
  6. Implementing CRUD user interfaces
  7. Adding reporting capabilities
  8. Lazy loading

​I'll announce on Twitter and here once the book gets published. Stay tuned!
Share:

Friday, December 2, 2016

Enterprise-app for Vaadin

Some years ago I published the Enterprise-app add-on for Vaadin. The most awarded feature was the CrudComponent class that allowed you could add a CRUD-like interface to any Hibernate entity by writing one line of code. Enterprise-app was (and still is) available for Vaadin 6. I partially migrated it to Vaadin 7, but never really completed the task.

I'm not longer supporting the Enterprise-app add-on, but working in a set of new Vaadin add-ons to replace parts of its functionality. So far I have implemented the Crud UI add-on, with a less magical but much more flexible CrudComponent. A key difference with the old one is that it doesn't perform the actual CRUD operations, instead, it delegates the operations to a CrudListener with 4 methods that you have to implement (or alternatively, use 4 separte interfaces and lambda expressions or method references). This allows you to use any persistence technology you want.

Suppose you have a JavaBean like the following:

public class User {
    private Long id;
    private String name;
    private Date birthDate;
    private String email;
    private String password;
    
    ... getters & setters ...
}

And a "backend" service class like the following:

public class Backend {
    Collection<User> findAll() { ... }
    User add(User user) { ... }
    User update(User user) { ... }
    void delete(User user) { ... }
}

Then, with the Crud UI add-on, you can create a CRUD web interface with the following code:

GridBasedCrudComponent<User> crud = new GridBasedCrudComponent<>(User.class);
crud.setFindAllOperation(() -> backend.findAll());
crud.setAddOperation(backend::add);
crud.setUpdateOperation(backend::update);
crud.setDeleteOperation(backend::delete);

There are several configuration options. See the examples on the add-on's page. The following is an example of a CrudComponent with modified configuration settings for Grid's columns, field captions, layout, and validations:

If you were a user of Enterprise-app, take a look at the new Crud UI add-on and let me know any issues you find or features you would like to have.

Happy coding!
Share:

Wednesday, June 8, 2016

Vaadin Video Tutorials

Finally! After endless hours of rehearsal, screen recording, audio recording, film recording, audio-image synchronisation, editing work, and do it all over again, we have published the first 6 videos of the Vaadin Tutorial series. But don't get me wrong, working on these videos was a lot of fun and I'm looking forward to publish more video content.

Share:

Thursday, April 21, 2016

Copy & Paste Based Development

This is about Mr., W. J. a nice and friendly developer working for an IT company in a cosmopolitan city. He was in charge of five other developers. I was one of them.

It was probably my second day in the company, and he assigned a programming task to me. I was working on it, trying to figure out what the heck was that software I was going to help maintaining for the next months all about. Then, Mr. W. J. wanted to borrow my brain for a second. I wasn't using it, so I lent it. "Do you think this is a good implementation?" Mr. W. J. puzzled asked while looking at the screen, then to my face, back to the screen, then to the infinite. "Ummm... I'd say..." I managed to merely bubble when he interrupted. "I think I can also do this..." he said and immediately started to select a whole class with a hundred lines of code or more. He copied the code. He pasted the code. He pasted it in an empty file, slightly changed the name of the class, and made some modifications in a couple of lines. He ran the application, tested something on the screen, and said "thanks" without any traces of irony.

I couldn't resist my curiosity. "So... are you committing that code?" I puzzled asked while looking at the screen, then to his face​, back to the screen... "Yes!" he quickly replied without giving me the chance to look to the infinite. I thought it would be a Good Thing™ to explain him that Copy & Paste Driven Development™ is a Bad Thing™ sometimes. Explaining to a junior developer why that technique should be avoided is not the same as explaining it to your manager*, so I decided to tell Mr. W. J. a story about copy & paste in software development.

"It's funny," I started saying. "Some years ago I was working in a company and did something like what you did," I continued. "I copied a big portion of code, pasted it somewhere else and made a small adjustment," I added. "I didn't realise my boss was there when he poked me in my shoulder and said «don't do that again»," I convincingly finalised**. "Why did he say that?" Mr. W. J. puzzled asked while looking at the screen, then to my face, back to the screen. "I don't know..." I defeatedly replied while looking at the screen, then to his face, back to the screen, then to the infinite...

* It highly depends on the manager and the junior developer in question.

** I switched roles while telling this short story to be more empathetic with Mr. W. J. Did you think I was a copy-paste maniac? I think Mr. W. J. was. I saw him copying and pasting identifiers that were 2 or 3 characters long sometimes.
Share:

Friday, January 16, 2015

Semantic coupling





Code Complete is one of those books every developer should read. There is a section in chapter 5 of this book which talks about coupling. Although coupling between software entities is not totally avoidable in all of its flavors in even simple programs, there is a special kind of coupling that we developers should all condemn: Semantic coupling. According to Code Complete:
"The most insidious kind of coupling occurs when one module makes use, not of some syntactic element of another module, but of some semantic knowledge of another module's inner workings"
I have written some semantically coupled code, I must confess. Not a very shocking confession, though. I have found out that pretty much all the developers I have worked with, have semantic coupling in their criminal records. With the aim of making the programming world a bit more lawful, let me show you two basic examples of semantic coupling I found in my own code:

Disclaimer: Class and method names have been changed to protect the author's customers and the author's customers' customers.

Example 1. Avoiding calling a method because another method does it.

class SomeUIComponent {
  public void init() {
    setSizefull();
    ...
  }

  public setSizefull() {
    ...
  }
}

class AnotherClass {
  public void smartassMethod() {
    SomeUIComponent c = new SomeUIComponent();
    c.init();
    // I know I need to call c.setSizeFull() but I also know
    // SomeUIComponent.init() will call that, so it's fine :D
  }
}

No, that is not fine. And stop smiling. I have also done this while thinking, "I know this is not very good, but most of the instances of SomeUIComponent will be full size, so let's put that in the init method." Even if the reason sounds okay, that is still semantic coupling, my friend.

Example 2. Downcasting.

class User {
  ...
}

class MightyUser extends User {
  public mightyMethod() {
    ...
  }
}

class AnotherClass {
  public void method() {
    MightyUser u = new MightyUser();
    doThatThing(u);
  }

  public void doThatThing(User u) {
    // I know they will pass a mighty one, so let's cast it :D
    MightyUser u2 = (MightyUser) u;
    u2.mightyMethod();
    ...
  }
}

Let's cast it? You cynical developer. That is downcasting. And stop smiling again. Sometimes I catch myself thinking, "I should change the method's signature," but I find a reason no to do it. Maybe it's impossible to change the signature due to external constraints (the method is declared in an interface or superclass, for example). It might sound like a good reason, but again, still semantic coupling.

If you find something like the above while coding, look at it as an opportunity to think of a better design. There is plenty of room for improvement when you face that phenomenon called semantic coupling, a disgusting flavor of coupling you don't really want to taste. Then you can smile if you want.
Share:

Friday, June 13, 2014

Talking Progress Indicators

Willing to learn Vaadin 7 in a funny way? Here there is an excerpt of my book Vaadin 7 UI Design by Example: Beginner's Guide.
Author: Let me introduce you to a friend. ProgressIndicator, reader. Reader,
ProgressIndicator. 
Author: Now that you know each other, let's work together.

ProgressIndicator: Cool, what's the task to do?

Author: Well, our awesome algorithm is taking too long and users are just leaving our state-of-the-art web application. So ProgressIndicator, we need your help to give
the user some feedback about the progress of the process.

ProgressIndicator: Sure.

Author: Thank you sir. Take a look at our original application implementing this Java Thread performing our high-tech algorithm: 
 public class ProgressindicatorUI extends UI {

  private class HighTechAlgorithm extends Thread {
    public void run() {
      try {

        for (int i = 0; i < 10; i++) {
          sleep(1000);
        }

      } catch (InterruptedException e) {
        e.printStackTrace();
      }
    }
  }

  protected void init(VaadinRequest request) {
    final VerticalLayout layout = new VerticalLayout();
    layout.setMargin(true);
    setContent(layout);

    Button button = new Button("Start awesome algorithm");

    button.addClickListener(new Button.ClickListener() {
      public void buttonClick(ClickEvent event) {
        new HighTechAlgorithm().start();
      }
    });

    layout.addComponent(button);
  }

} 
ProgressIndicator: Wow! That's an awesome algorithm.

Author: Thank you. It took us months to implement it. Anyways, we would like to add you, Mr. ProgressIndicator, to our layout, so you can tell the user how the progress of the algorithm is going. Is that OK for you?

ProgressIndicator: Sure. Let me place myself as a private member of your UI class.

Author: Of course, come in. And please add yourself into our main layout: 
 public class ProgressindicatorUI extends UI {

  private ProgressIndicator mrProgressIndicator =
      new ProgressIndicator();

  // ...

  protected void init(VaadinRequest request) {

    // ...

    layout.addComponent(mrProgressIndicator);
  }
} 
ProgressIndicator: What a nice place. Really high-tech. 

Author: Yeah, we painted it Vaadin color.

ProgressIndicator: My favorite color!

Author: Nice. For each iteration of our algorithm I will update you, OK?

ProgressIndicator: Yes please.

Author: Cool. You accept values in which range?

ProgressIndicator: Give me a float between 0 and 1.

Author: OK. There you go: 
 public class ProgressindicatorUI extends UI {

  // ...

  private class HighTechAlgorithm extends Thread {

    public void run() {
      try {

        for (int i = 1; i <= 10; i++) {
          sleep(1000);
          mrProgressIndicator.setValue(i * 0.1f);
        }

      } catch (InterruptedException e) {
        e.printStackTrace();
      }
    }

  }
} 
ProgressIndicator: Thank you. I think I'm ready.

Author: Great! Let's run the app. Are you ready reader? You have been kind of quiet lately.

ProgressIndicator: Yeah. I think she/he might be overwhelmed by the high-tech algorithm.

Author: That's reasonable. Let's test our application: 

ProgressIndicator: Cool. I'm working properly!

Author: Wonderful job ProgressIndicator. Thank you very much.

ProgressIndicator: My pleasure.
Share:

Wednesday, December 4, 2013

Comments: A deodorant to mask code smells

Don't get me wrong. Comments are useful and not all of them have the olfactory purpose of the famous analogy I'm using in this article's title. So, what's so wrong about comments that programmers are willing to even dress a shirt about this odorous matter? Let's say we have this fragrant method:




 nastyMethod() {
  // connect to database
  ... Code to connect to the database ...

  // create default configuration
  ... Code to create the default configuration ...

  // load configuration
  ... Code to load the configuration ...

  ... and more, and more, and even more of this...
}

The problem here is that the comments are saying what the code is doing. Comments should say WHY the code is doing something, not WHAT the code is doing. Moreover, this typically leads to the Long Method anti-pattern putting in risk two basic OO design principles: Interface Segregation Principle and Single Responsibility Principle to say the less.

Make your code self explanatory:

 betterMethod() {

  connectToDatabase();

  createDefaultConfiguration();

  loadConfiguration();

}

connectToDatabase() {
  ... Code to connect to the database ...
}

createDefaultConfiguration() {
  ... Code to create the default configuration ...
}

loadConfiguration() {
  ... Code to load the configuration ...


You might argue "this extract to method thing will lead to classes with too many methods, making them difficult to understand". Well, use the Extract Class refactoring if you reach that point. Remember: The object oriented programs that live best and longest are those with short methods.
Share: