WaveMaker

In a recent forum thread regarding multi select data grids, Larsvader claims shame for not looking in the wiki for the information he needed. His sentiment is commendable,  but I can not help but think that I share, if not bear, the burden of that shame.  Why ? The knowledge he needed was available, yet he did not find it.

If Larsvader ‘forgot’ to look in the wiki, how could the site better help ‘remind’ him ?

The world was rather different one year ago. Lehman Brothers still existed and the WaveMaker Developer Community was little more than a cool and increasingly active forum site.  We had begun work towards launching a wiki. Today the site is more active and offers more developer resources than ever before.

The value of the site to WaveMaker users however, has increased exponentially due to the community members themselves. Folks like Niek, Lenny and the custom widget king, Tom regularly and repeatedly prove that collectively we are far more knowledgeable than any individual.  The collective ‘brain trust’ factor of the community dwarfs that of just a year ago.

The example Larsvader was looking for was in the wiki ‘Dev’ space,  aka ‘the dev’.  The dev space is multi functional. It acts as an index to the forums while giving community members a place to exchange knowledge beyond the forum format. It often can continue into details that the main documentation does not cover. It also may be unpolished  at times and have typos or rotten links in places. As such, it has not been promoted as a site entry point or landing page.  Maybe that should change ?

Like the community itself, the dev and all of the wiki are far more powerful with the contributions of the collective brain trust. In that spirit I request your input regarding ‘the dev’. If community members are not in the habit of looking in the dev for solutions, how will you ever think to contribute content to it ?  Should a direct link to the dev be on the community home page ?  If you find a forum thread that should be required reading on a topic , is it easy enough to add the link to the wiki ? If not, how can we make it easier ?

The collective brain trust of the WaveMaker community is nothing shy of amazing.  Thus I turn to the collective and ask how can we better capture and share the knowledge of the collective ?  For at the end of the day, we all want more tips, code snips, examples and samples AND to be able to find them when we need them.

See you on the forums.

A long time friend who runs a construction business has a twist to the classic remodeling adage. He says it can cost at least twice as much and take at least twice as long as you thought to complete the work. Developers often warn against comparing software to physical buildings. Their reasoning is sound enough, but I will suggest this is a maxim worthy of exception.

Last Friday, the first 5.0 ‘dev build’ installer packages went out to our community ‘dev build club’, a group any community would be proud to call its own. Getting those initial packages out the door certainly took longer than anyone here might have guessed.

WaveMaker 5.0 introduces some very cool new features. Derek has led a yeoman effort on documenting these features and changes in the the WM 5.0 documentation. Moving from 4.x to 5.x is a bit like a kitchen remodeling. Some things are rather different looking. Developers get more of the screen real estate for the canvas, for example. However, a service variable is still a service variable. That is, we may have moved the kitchen sink, but it still functions like a sink, and carrots still do not spotanesouly vanish.

We’ve received some excellent feedback on the dev builds. A big, big berdankt to Niek, aka Malamut, for his comments, bug reports, and suggestions. To further abuse the remodeling analogy, the dev build users are helping us ferret out potential mint green and harvest gold 1970s remodeling nightmares in the making. Thanks to everyone participating the dev build process!

Grazie millie also go to Tom, Philip, AlanB, Rolando and the other members posting their custom widgets, integrations, and templates.  They’ve developed some really neat stuff  and we’ve accordingly expanded the ‘Show n Swap‘ section of the wiki to better show case these gems. It’s been really rewarding to see folks hit that eureka moment in their development efforts. Provisioning those results back to the community site has enabled others to build on top of those successes and resulted in even more shouts of “eureka.”  As the community develops momentum, it is developing more than cool code samples, it is also developing teamwork.

The next 5.0 dev build is to go out in the next few days. We shall see if we have a few more inadvertent orange and tan shag lined cupboards to um, paint before we can open up the release. Hey, colorful shag seemed groovy at the time. Right ?

This brings us to to one project analogy that I believe few, if any, would argue with. Any project is more rewarding to work on and the result more exciting when it is done as a team.

I found Herve’s recent forum post on performance interesting for a variety of reasons. Foremost, it provides a bang on summary of performance considerations in WaveMaker application development. It identifies the common bottlenecks of WM apps and summarizes the techniques developers are using to mitigate those bottlenecks.  If you are concerned about the performance of your app, the thread is worth a read.

The post and its resultant discussion suggest a possible derivation of Linus’s Law. The ‘formal’ version of Linus’s law states: “Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone.” Unfortunately, client performance design is not well covered in the current documentation.  There are performance suggestions and methods shared by others on the dev site. Herve took these tidbits, did some testing of his own and packaged it into a nice overview of the topic. From this we could possibly derive that “Given a large enough community, almost every aspect of the project will be documented”.

As Herve found, rendering lots of components is expensive. A new version of the rendering engine is in the works. This new engine significantly changes how the rendering engine does what it does but unfortunately just will not ready for 4.5. It needs more development and testing. Payload gains from improvements such as enabling GZIP compression in the tomcat server are expected to be included in the 4.5 release.

This brings us to what I consider the most exciting aspect of that thread. Linus’s law and our slightly dodgy derivation take the form of: given enough active users, good things happen.  All the laws require a critical mass of users for those good things happen.  Improving application performance is undoubtedly a good thing. It is not entirely speculative to conclude that some hypothetical threshold was crossed somewhere that enabled this goodness to happen.

More and more talented people from around the globe are participating in the community every day. Improving performance is just one example of the good stuff that has resulted.  What strange and wonderful things might emerge in the coming months? In what ways will the community help drive WaveMakers development and maturity? I, for one, can’t wait to see that the answers will be.

Keep those questions coming. Keep on posting your tips and tricks, but most of all: keep riding the Wave.