Showing posts with label Design. Show all posts
Showing posts with label Design. Show all posts

Monday, 3 November 2008

A Musical Note

I spent last month at home on holiday (is that an oxymoron?) feeling lethargic as people do on holidays. As a result I did not touch my computer much and only spent a few hours learning Erlang.

However, I did get to learn music and ended up spending 1-2 hours per day in front of the electronic keyboard that I bought for my kids . I have to admit, I am not good at music at all - I did use to excel in singing in primary school; but since my voice broke I lost all enthusiasm on music - my parents sending me to a violin class where I was the only boy did not help either. Until last month, as I fiddled around with the piano/keyboard, I revived my thirst for knowledge on music and piano-playing. It turned out that piano-playing is really easy to learn (at least to start) if you are a fast touch-typist. So I relearned the basic music theory 101 by following the wonderful book Total Piano. As an IT professional geek, I couldn't help finding many striking similarities between the musical and computing worlds.

First of all there are the patterns in music. As a matter of fact, all musical pieces are based on establishing some patterns and then repeating them - there are quite a few symbols in the staff to represent repetitions (i.e. the GOTO statement). It seems like composers are lazier than system designers Also, there are chords and each chord has many variations - broken, harmonic, minor, etc. Again, it's all about repetition and reusing.

Then there is the arrangements. The same music can be (re)arranged to adapt to different environments/scenarios - e.g. to suit different musical instruments (e.g. piano solo, string quartet), or to suit different players (e.g. beginner vs. pro) etc. Thanks to simple arrangements of many great works included in the book, I was able to play some very interesting pieces and keep getting fully engaged in the learning process. By the way, how many AJAX'ian web frameworks have you come across recently?

Well-known musicians also remake other people's songs to boost their own career. Yesterday, I read an interview with Seal and his upcoming new album of remakes of classics that 'appealed' to him. In it, Seal revealed that quite a few young people in their 20s had not heard the original version of the songs. So Seal's version was the first time that they heard them and Seal kind of re-introduced the great classics back to the young generations. I hope the youngsters don't mistake Madona's American Pie with the original.

Every now and then I can hear curses coming from across the office when my colleagues cannot find some features in their MS Office 2007. I have mixed feelings about the ribbon interface of Office 2007 - I like the look and feel but hate the fact that so many features have been rearranged so that everytime I want to use them it's Easter all over again. I am sure if someone has never used the older versions, he/she will like the new ribbon interface.

Perhaps learning from the closed-door design experiences, Microsoft is openning up their design process for some of their major products - e.g. Enginnering Windows 7. On the other hand, music creation is usually an extremely personal experience, unless you are charged to write some propaganda piece or the national anthem (I will vote for Waltzing Matilda anytime for Aussie national anthem)!

Meanwhile, I'd better get back to practise the beautiful piano solo arrangement of Beijing 2008 Olympic theme song - You and Me.

Wednesday, 3 September 2008

The Sorry State of ADO.NET Entity Framework 1.0

A few months ago I test-drove the ADO.NET Entity Framework 1.0 Beta 3. While I enjoyed certain aspects of EF, such as LINQ and graphical modelling, the overall experience of using EF hasn't been that great. In fact, my very first blog on this site was dedicated to EF bashing. My major complaint about EF was its intrusive approach to ORM - instead of using PONO (like in Hibernate), it generates bloated relational database-centric data entity models. This is against the domain driven design method. Another problem I encountered was its shoddy implementation of lazy loading (or lack of it, as a matter of fact).

I then realised that I was not alone in feeling disenchanted by EF. In the same month of my blog, several hundred people have signed up on the ADO.NET Entity Framework Vote of No-Confidence open letter, many of whom are from Microsoft's Most Valued Partners (MVP). In last month's issue of Visual Studio Magazine, the article A Vote for Transparency gave a blow-by-blow account of events on the controversy surrounding EF, including the aformentioned open letter. So Microsoft decided to make the EF version 2 design exercise a more transparent process. This no doubt is a step forward. However, it is too little too late for EF v1. Looks like EF v1 will not receive any significant improvements or address any of the communities concerns in the open letter. In fact, I doubt that any EF design improvements have been made into .NET Framework 3.5 SP1 (released in August 2008) since EF 1.0 Beta 3 (released in December 2007).

On a side note: although some people whine about JCP program being slow (e.g. the Java closure debate) and sometimes committee-driven, comparing to the traditional closed-door design pattern like EF v1, JCP is a great leap forward and the result speaks for itself. The JCP specifications are more readily accepted and adopted by the community than a proprietary one like EF.

Saturday, 16 August 2008

ORM Frameworks and DBA Friendliness

Database programming used to directly rely on tools provided by the database vendors, such as ESQL-C from Informix, Pro*C from Oracle and Sybase. Using these tools makes the business logic (C/C++ code) mingled with and dependent on the database design and logic (SQL code).

The emergence of Object-Relational Mapping (ORM) frameworks solved this problem by decoupling the code and the database assets. Nowadays, when designing software, it's not a matter of using ORM or not for the designer, but rather which ORM framework to use.

Most ORM or entity frameworks (Hibernate, JPA, Entity Framework) out there generate SQL statements automatically and hide the internals from the developers and rightly so. However, this creates another problem: to optimise the SQL statements, it is usually a joint effort between the developers and DBAs (or data architects) - the DBA should have the final say in how to shape the SQL queries and to design/modify the database schema to suit the usage pattern of the application(s). Now that the SQL statements are auto-generated by the framework and the DBA cannot design or examine the SQL code up front, the control of the DBA is diminished.

This loss of control may not be a problem for custom-built/one-time applications, or applications with a simply data model. However, if you are dealing with a large/complex product that has to be implemented in different environments, then it is crucial to have full control over the database deisgn and deployment and how it is to be used.

To have the visibility to the SQL statements up front, there seems to be two options:

  1. resort back to JDBC/ADO.NET... to mix the SQL statements with the business logic code - not advisable
  2. use a framework that exposes the SQL statements - iBATIS SQLMap

Strictly speaking, iBATIS is not an ORM framework - it maps the objects with SQL statement query input/output. There are two distinct advantages of using SQL Map:

  1. The database-specific code (SQL statements, connection strings, etc.) can be centralised and totally separated from the core (Java/C#...) code. This makes the code decoupled from the database and more portable across different databases;
  2. All database CRUD are specified in native SQL which are DBA friendly, making it easy for the DBA to review and participate in the design of these statements.

Because iBATIS does not map objects with tables, it makes it ideal for applicaitons that have to use legacy databases which did not adhere to object oriented design or have totally different structure from the object model.

Therefore, if you are involved in software product development (as opposed to custom-built one-time projects), DBA friendliness should be a factor to be considered when deciding an ORM framework.

Tuesday, 5 August 2008

Why Not Five-teen?

My four-year-old son has just learnt how to count. As a newbie, he has not memorised all the numbers. So sometimes, he improvises and derives the number words that he needed. For example, when he sees '15', he would read it as 'five-teen'. He is OK with the numbers that are 'regular', such as 14, 16, 17... But he could not readily read the irregular ones all the time, such as 11 and 12.

At this young age, he has not been 'tainted' by all the variations and irregularities of the English spelling and pronunciation rules. It is natural that he follows the 'logical' way to come up what he thinks and seemingly to be correct.

The English language is full of exceptions and variations in its rules of spelling, pronunciation and grammar. These inconsistencies make English not an easylanguage to learn comparing to many others.

When it comes to computing languages and APIs, consistency also determines whether the language or API is easy to learn and use (although now people are talking about more advanced topics, such as fluency). Let's take GUI frameworks as an example.

When building graphical user interfaces, we need to put some widgets/components onto the canvas or another widget. So there is a parent-child relationship: the parent is the container, the child is the object being put inside the container. There are two ways of saying this relationship:

  1. parent.addChild(child)
  2. child.setParent(parent) or specify the parent in the child's constructor

Most GUI frameworks use the first syntax - such as Swing, Windows Forms, WPF, ASP.NET, GWT, Echo2. For example, in Swing:

JButton button=new JButton("Clear");
button.setActionCommand(command);
button.setToolTipText(tooltip);
button.addActionListener(this);
...
JPanel buttonPanel=new JPanel(new FlowLayout());
buttonPanel.add(button);

In these GUI frameworks, the same widget cannot be added to more than one container. If you did, then it either complains at runtime or gives undesired odd results. But the API allows you to make these mistakes and your code compiles without error. So this is an inconsistency in those framework APIs.

To fix this problem, SWT/JFace takes the second approach by using the constructor:

Composite buttons=new Composite(this, SWT.NONE);
...
Button clearButton=new Button(buttons, SWT.PUSH);

This way, you cannot mistakenly set more than one parent for the widget.

There are other languages and frameworks that take a third approach by creating the child widget inside the code block of the parent. For example, in Wicket:

public abstract class BaseAddressForm extends Form {
...
  void initForm() {
  ...
    add(new Button("clear", new Model("Clear")) {
      @Override
      public void onSubmit() {
        log.info(getModelObject());
        resetModel();
      }
    });
  }
...
}
Similarly, in JavaFX script:
...
bottom: FlowPanel {
  content: [
    Button {
      text: "Clear"
      action: operation() {
        model.selectedAddressIndex=-1;
      }
    },
...

The above are exmaples within a single framework. When we have to deal with multiple frameworks the problem becomes more obvious. Normally, we don't expect different frameworks/languages to follow the same rules. However, when one framework is an add-on/extension to another, our expectation changes. For example, GWT-Ext is an add-on to GWT. However, its API naming conventions are not consistent with that of GWT: in GWT the method name getText() is used to get the text label of a widget (e.g. a label, button, etc.); but in GWT-Ext the method is called getValue(). Also, in GWT, the Command is widely used (in a similar way to the Action class in JFace). However, in GWT-Ext event listeners have to be explicitly created...

Don't get me wrong, I love using GWT and GWT-Ext. But these little inconsistencies hinder productivity when using this mix.