Went to Zagreb and maybe lived to tell the tale

I went to Zagreb today with my colleague Hrvoje Hudoletnjak to the monthly WebUG meeting. There were two topics:

• Lightswitch by Gjuro Kladarić, FFZG
• Hybrid Mobile Applications by Matija Šmalcelj, Pet minuta

I was really excited to go there. It was an opportunity to learn and to network with some like minded people over the mountain (Istra where I live is separated from the rest of Croatia by a mountain named Učka). 
What I was looking for is more Lightswitch education. I just started some Silverlight development my self and the idea of Lightswitch intrigued me. There are a lot of applications being developed in pure code today which could just easily be developed by a Lightswitch-like tool.

In my opinion developers tend to be to high horse about development practices and techniques. The majority thinks if something wasn't developed in pure code, using the hottest techniques and frameworks its something to keep quiet at leat or at worst to be ashamed of.

Latter experience taught me some lessons. For the majority of LOB applications nobody really cares how we do it except us. Now, I'm of the opinion that we should care how we do what we do. But I also think that we can do a good job by not being such asses about the way we do things regularly. For somethings there is no need for unit tests, for somethings database design is just enough. Not to mention that not everything needs to be a three layer architecture and that some forms with code behind and a data store are the proper solution for some LOB applications.

The Lightswitch presentation was purposefully short.  It reminded me about Microsoft Access and my faith in the tool just sunk. It seems it wasn't really what I hoped it would be. The presenter repeatedly pointed out that this tools isn't for the regular developer but for fairly advanced administration personel. Ok. I can achieve more with Drupal, CCK and Views.

The second presentation, about Hybrid Mobile Applications was really interesting. The presenter works in a company specialized in social networks and mobile applications and he illustrated the business case for developing Hybrid Mobile Applications, e.g. web applications written for webKit and run inside a native wrapper in order to give an illusion of a native iPhone or Android app.

Whats the deal here? If you want to write a cross platform mobile app you need to write a separate implementation for each platform. One in objective-c for iPhone, one in Java for Android and so on. With Hybrid Mobile applications you just write (or take an open source one) native wrapper e.g. an application that internatlly starts the browser as a control and that resizes its self that all browser specific features are hidden from the screen thus leaving the page content. The real application is written using webkits HTML5 capabilities CSS3 animations, Javascript local storage, geolocation etc.

The application runs inside a single html page and the entire source code is shipped as single build with the wrapper thus by just changing the wrapper one can ship the same code on any native mobile application. The best thing is that the user doesn't know he is using a web application.

The most important thing  is to develop the application with no connectivity in mind, which is really easy by the existence of the local storage api that gives to the developer a full fledged relational database to use.

The development is really cheap also. The developer needs a webkit browser (Google Chrome or Safari) an IDE (Eclipse comes to mind) and a couple of mobile frameworks to ease the development effort.

 Here are a couple of links given by the presenter:

• http://jqtouch.com/ 
• http://www.sencha.com/products/touch/ 
• http://jquerymobile.com/ 
• http://cubiq.org/iscroll
• http://code.google.com/p/geo-location-javascript/
• http://www.phonegap.com/
• http://www.appcelerator.com/

The presentation gave me a couple of ideas about some project I might do:

• A mobile Mantis Bug Tracker interface
• Hmm thats all just one ... :(

Of course I still have some learning to do about WPF 4  and MongoDb. I will wait till I learn those with other activities.

Automed User Inteface Testing

User interfaces components are hard to unit test with standard unit testing framework. There are several reasons for that. In my opinion the principal is the fact that user interface components rely heavily on the interaction between the user of the system and underlying framework of business(or other objects) supporting the user interface control. And sometimes, is quite hard to remove the component from its natural environment for testing purposes, as is the case with ASP.NET web components.
The solution to this problem is two fold. First all domain and infrastructure objects should be logically and physically removed from the user interface and unit tested separately using convectional testing methods. This is nothing new, there are numerous design philosophies associated with that (for example the MVC design pattern always so popular with web development frameworks). The second is to to test the user interface component attached to its underlying system base, in a separate - clean - environment specially prepared to for testing purposes using automated unit testing tools.
For example and ASP.NET application whose user interface is composed by a separate web component library and relies heavily on client side code to facilitate heavy user interactions with few page reloads in order to maximize user experience (ah, the oh so popular Microsoft buzz word of the moment) and to reduce stress load on the system. There are five distinct parts to this application:

• ASP.NET user interface


• ASP.NET web control


• ASP.NET web control domain objects (entities, repositories, services and specifications)


• Javascript user control attached objects


• Javascript domain object

All these parts compose the user interface of this theoretical (and so typical application). First , lets us remove all domain objects. Both client side and server side object can be tested using respective testing environments. Now for the remaining three elements there is no way of testing them separately. And, also there is no practical need. Because the goal of testing user interface components is not to see if each of them works correctly as a separate unit (it is impractical , because the amount of mocking requires a separate framework of its own - often custom made for one project only) , the goal it to test the user interface as one system (logical separated by functionality, just to give some order to the mess) in order to provide to the team and to the customer that the system which is built provides requested functionality.
This is accomplished by using automated unit testing frameworks. One that I especially like is Watin, an open source project under active development which allows any developer to programmatically test the user interface of any web application inside Firefox and Internet Explorer (which we are the two browser mostly tested by web developers).
Watin is a good framework. Of course there is place for improvement, by what is accomplished now is very useful in enterprise strength projects. For anyone who has developed with javascript using this framework will be easy and will come naturally.
I would recommend it for everyone doing serious web development in any environment and with any tools.

Designing proper HTML code

I think there is a need to engineer HTML code in a web web application, the same way server side and client side code is engineered. I'm posing my self the question how?
For standard programming languages I use UML, but UML can't be applied to HTML. Html denotes the structure of a hyper text it doesn't model interactions or functions. It can't be effectively described with standard software engineering techniques.
HTML code is simple, and short and anybody can learn to do it in one hour. It would seem to the causal user that HTML doesn't need to be specially engineered. I think that is not the case. Every web application is always finally rendered into HTML. All user interactions are defined by how the page is structured in HTML, the way the server side code is structured depends on the way HTML is structured and the ease CSS can be developed also depends on the way HTML is structured. Not to mention cross browser and cross platform portability.
It really matters if a developer uses tables withing tables, or a series of stacked divs. It really meters the decision between table cells and unsorted lists or paragraphs. When put in perspective, most problems I've encountered in my career as a web developer had to do in a way with badly engineered HTML.
I think it is critical to find a way to design and plan markup code for web applications. If we as engineers spend so many hours a day preparing or code and our applications to be of the maximum quality, I think it is imperative to spend the same energy on HTML.
I know what you think. HTML is not serious, it is for kids not engineers. But look around you. Web applications are everywhere, and so it is HTML. Without HTML there would not be the world wide web as we know it. Its simplicity is what it drove web applications inside and outside the corporate firewalls. And neglect to properly engineer HTML code is one of the root causes of the poor qualty many web applications suffer.
It just came to me today, this idea. I spent several days designing several objects in UML, documenting them, writing them, testing them, writing and thinking about unit test, automating them, and it all worked as a charm. But when it got down to HTML and its sister cousin CSS I worked as newb coding like hell without preparing out a head, doing a crap job on a critical part of the application I'm working on. I can't put it there like that. I have to rewrite it tomorrow to increase the quality of the code I'm producing. But how many hours of work would I saved if I engineered my HTML code in the same way I engineered my javascript and C# code?

Web applications as web services

My running theory is that a typical web application is in reality a web service - distributed and reliant application. It is no surprise , I think all experienced web developers know it. On one side we have the server machine which runs HTTP server that is handles traffic to and from our server side application. The technology that is used to build the server side application is irrelevant. Nowadays you can use almost any programming language known to man to build a server side application. It is a matter of taste, really and of course client expectations. What is important is the fact that our application responds to request trafficked through the web server with code that is transmitted to the client using the HTTP protocol, and which is "compiled" into an client application inside the browser Virtual Machine. That client application is then able to send request back to the server for a new set of code which in turn will replace the existing application with a new one.
Well, that was true in the past, and not so much today (I'm talking about web apps here, not pages - I make a distinction between the two) because we have WEB 2.0 client apps that send request to the server for periodic updates for the client side code without the need for the complete user interface deconstruction we always experienced in the past, with what the ASP.NET guys called the old post-back model.
So if we think about our web apps in this way is no wonder that we need a team to build even the smallest of web apps. Excpecially if we wanted to build them right.
Web application developers experience a host of problems regular developers don't even know about. First there is the whole browser compatibily issue. CSS, HTML and javascript do not render on different browser, different browser verisons or event different operating systems in the same way. A piece of client side functionality that works in Firefox on Windows wont work on IE. If we are building a big app, we need specialized teams for each browser family in order to provide the maximum stabiliy and user coverage for our apps. Thats one problem we all know and hate for the life of us. But one problem that is often overlooked and not discussed out loud is the fact that HTML as a UI generating language was not designed to build UI for web applications. The original goal of the language was to ease the disemminationa and aviability of scientific papers between scientist. Not building applications.
And thats a big problem. If you've ever done javascript heavy applications you often encountered problems and you had to generate tons code to solve them , just because you wanted to implement a functionality that would take in desktop application several lines of code to implement.
I'm really glad that with HTML 5 they are going to fix or attempt to fix the problem. And what Micrsoft did with XAML in Silverlight and WPF and Mozilla with XUL is a real step towards the solutions of the problem. Thats how real web applications should be build in the first place. Why do I need to regenerate the entire UI with every click of the mouse, and why do I have wait so much time for stuff that should be handled on the client. The only thing that should be shuffled across the net is Data, not code to be compile again and again on my computer. It is not practical, it is not functional and it is not friendly. And what really bothers is me is the notion that building web applications is easy, is fast and simple and that kids could do it and its not real software engineering work. And what bothers me the most is that the notion often comes from people who know absolutely nothing about web apps.
First you have to wrap your head around the service generated and absolutely reliant client, than you have to learn and really understand five different technologies , of which four are have several critical difference based on the virtual machine they are executed upon (HTML, CSS, JavaScript and XML). The only simple thing (simple in the fact that you have to know one variation at the time ) is the server side language.
And you can do so much with the web, and it really pains me to see that people don't really understand it and to see so much problems that arise from that ignorance that could be easily solved if the applications in questions were developed with little more understanding what it takes to build a web project.
To build a web product you need to have to following people:
A web designer
A graphical artist
A javascript engineer
A RIA animator
A RIA programmer
A server side engineer
A database administrator
A system administrator
A really, really good architect
And what is important a leader with a vision and understanding what the platform requires of the people that are building atop it.