Ed Brill has posted a blog entry where he asks for feedback about what IBM Lotus means to us, so hereby I'll share my opinion on this topic.

So, what does IBM and/or IBM Lotus mean to me? I'll be freely mixing experience and perception here:

• Lotus Notes and Domino have a special place in my heart. They are great products, products that I worked with in the first years of my career. Products that I'm still passionate about, even though I've been slightly out of touch with the platform lately. I'm not bothered at all by the fact that IBM absorbed Lotus, maybe because I'm too young to tell the difference between both periods in time.
• To this day, I still think IBM makes the best laptops in the world, the glorious Thinkpad, even though Lenovo makes them now. I have a very positive association with this hardware and therefore disliked the "move" to Lenovo.
• IBM in general to me is a huge company with huge resources and elite scientists that mainly focus on large enterprises. As someone pointed out in the comments at Ed's site, there is not a single product or service of IBM that I use as a consumer.
• IBM in general to me is cumbersome to deal with. I remember a few years back when I had to visit their Software Catalog. We jokingly called it sixteen-step shopping at the office, not even mentioning the fact that we needed to authenticate twice and had to spend hours finding even the most basic software. Another incident is related to their shopping experience. I once had to purchase 3 Lotus Notes seats for a very small customer. I will not even begin to tell the horror I had to go through just to BUY one of their products. I'm not asking for free support here. I have money and want to spend it on them, why on earth would you make this difficult to me? This only increased the perception that IBM is interested only in big customers. Note that I actually had few interactions with IBM directly, but those were very cumbersome to say the least.This is not to say that they ARE cumbersome.
• Speaking of few interactions, my perception is that IBM is quite out of touch with the development and user community of their products. I've been working at this large enterprise for years now, and pretty much anyone in the application development teams across the world knows me by now, yet I never had any contact with IBM or a representative. Whilst I did not really need that contact anyway, the contrast with this other company, Microsoft, is huge. Since Microsoft is in, without any initiative on my side, they found me in a matter of weeks. Now they spam me to death, invite me to free seminars, send me trial software and tech magazines, involve me in internal decision making sessions, co-fund proof of concepts, and their experts drive across the country regularly just to visit us and share news and knowledge. At all times they know which internal company events take place that matter to them. All for free, without any initiative on our side. I'm not as naive to think that this isn't in the best interest of Microsoft itself. Still, the difference is too big to ignore. Microsoft understands marketing, building communities, getting buy-in and spoiling developers. In my perception, IBM does none of these things outside the boardroom, and that's my story in what once was a 120,000 seats installment. Admittedly, I'm sure I could get some support and resources from IBM if I've searched hard enough.
• Another aspect of IBM Lotus being out of touch is in the products themselves, mainly the Lotus Notes client and Designer client. This has been discussed many times, and I'm seeing great improvements now, so I won't go into this again. I'm sure you know what I mean though.

In summary, I still cherish the products that IBM Lotus produces. I do have some negative perceptions concerning the support for small customers, developers and end-users, but am also seeing great improvements in these areas, thanks to the great work of Ed and others. Although I'm not in the position to give advise to IBM, I'll still give it a try:

• Increase your reach at customers, don't limit yourself to the boardroom. Get to know the stakeholders, key developers, key internal events, etc. Support customers at all levels and increase your buy-in. Oh, and give away free stuff.
• Give the development community the credit they deserve, these are the people defending your products every day. Implement at least their most requested features in a timely manner. Provide a development experience that is not embarassing compared to other platforms, and provide free express versions of development tools.
• Continue (and enlarge) recent initiatives that bring IBM better in touch with the community, and continue to improve the user experience of end-users.
• When you advertise in the consumer space, hire someone who has a clue what a consumer is, what they want, understand and what their problems are.

Whilst some of my ramblings may be perceived as negative, it surely is not my intention. I love IBM Lotus software, its community and only wish the best for it.

Coding for Jungle Dragon has finally started, so here is a small update...

I've mostly been working on the user management module, because almost everything in Jungle Dragon evolves around a user. User management for an internet-based web application is not something to take lightly, even though the general user experience I'm looking for is pretty standard:

• Users can sign up using a simple Registration form
• When validation is passed, the users gets an activation email
• After clicking the activation email, their account is active
• Next, they can login
• As a logged in user, they can access and edit their own preferences, including changing their email address, reset their password, etc

You'd be surprised at how much coding is required to implement the scenario above in a robust, secure way. I'm making good progress though. In my current development I'm focusing on the code and working of the scenario, a fancy user interface will follow as the last phase of the project, which is far, far away. So far I have the basic user registration and activation logic working, as well as the login/logout procedures.

The registration form is simply a view that is loaded by the registration controller. The form posts to this same controller, which takes care of the validation, and makes use of my User model class to interact with the database. I still have to code the forms to reset a password, or change the user's email address, as well as an admin view for managing users.

As for the authentication part, I'm making use of a slightly modified version of the Auth library. This library is not part of Code Igniter, yet it is a popular user-contributed library. Once properly configured and optimized for your situation, you can protect pages that require an authenticated user easily:

$this->load->library('auth');
$this->auth->restrict();

If users are not authenticated, the above statements will redirect the user to the login page. Next, upon successfull authentication, they will be redirected to the originally requested page, and their session will be set (using encrypted cookies). From then on, one can easily gather the session info of the user:

$logged_in = ($this->auth->logged_in()) ? true : false;
$logged_in_username = $this->auth->username();
$logged_in_userid = $this->auth->userid();

Further down the project, I will greatly enrich the Auth library, because authentication in Jungle Dragon is more complex than this simple binary system. For now, I really like the mechanism and ease of use.

Another baby step that I took was to implement a first part of the KarmaEngine. The KarmaEngine is a mechanism that rewards users karma credits based upon their actions and various circumstantial parameters. In terms of implementation, you can see this engine as a class that receives all kinds of events. It investigates the incoming event, and based on its parameters it will return the karma credit reward. So far, I have implemented only a single event. When a user signs up for Jungle Dragon, they will receive a signup reward of 100 karma credits. Even though this example is simple, it is conceptually interesting. Simply put, when all events are coded, I will have a single place to control and balance actions and rewards.

I know it must be boring for some of you to read an update like this. The project is in a very early stage and there is nothing to see yet. Still, in order to give both you and me some sense of progress on the long road to project completion, I'll continue to report on updates occassionally, as dull as they may be ;)

I know I keep rambling about how great the Code Igniter PHP MVC framework is, but I just keep finding new gems inside it. I was on my way to start coding for the Jungle Dragon project.I decided to first work on the user registration form, as pretty much everything in the project evolves around users. The registration form is similar to those of other sites:

• User must supply a username, password, and email. They must type the password and email twice and they need to match the first field. The username must not already exist, have a minimum number of characters and contain allowed characters only. The email address must be in a valid format. There are also check on the maximum amount of characters per field.
• Next, there is a list of optional fields
• Finally, the user must check that they agree with the Terms of Use.
• Should any validation fail, the user's initial values are not lost, the form is simply updated with specific error messages per field.

Easy enough, right? True, this is easy, but you would be surprised at the amount of validation code the above scenario would produce without any help.To be specific, we're talking about 23 validation rules for just 5 technical fields, and only 3 functional fields. That's a whole lot of if statements!

Luckily, help is around the corner. Code Igniter has a Validation class that bring down the amount of code for the above scenario to this:

There's only some slight additional plumbing code to be done in order to customize error messages but it's all easy. Note that I have also configured Code Ingiter to automatically apply XSS filtering on all posted values.

Another interesting feature is the callback mechanism. Code Igniter obviously has no way to know how it should check if a user already exists in the database. In those cases, one can simply write a custom function that resolves to true or false and sets the custom error message. Next, you refer to this custom function in the rule definition.

This just saved me many hours, as Code Igniter has done already.

Last week I announced my new project idea called Jungle Dragon. After such an announcement, my natural tendency is to start coding as soon as possible. I mean, why not? Very few developers enjoy documenting a design. Since I'm the only developer on the project, why would I document anything but the code itself?

The answer is: size. And complexity. The functional and technical base of Jungle Dragon is too large to fit in my boney head. I might be able to fit it in, but I'd lose sleep over it. I tend to apply the "Just Enough Design" principle to my work, which essence comes down to scaling the need for design and documentation to the size and complexity of the project. In other words, design where it makes sense, in order to support the code base, not just as a project formality.

Having said that, I'll hereby take you on a short tour on how I'm applying this concept to Project Jungle Dragon.

Just Enough Design for Jungle Dragon

I've been thinking about project Jungle Dragon for months, at a conceptual, technical, and personal level. In order to capture my ideas and clarify the concepts and goal of the project, I've created a two-page project brief:

It may sound crazy to do this for a one-man project, but I disagree. When I'm at my lowest during the long development phase, this document will remind me of the goal of the project, and hopefully reinforce me. Plus, it kind of feels like a relief to put your thoughts on paper like this.

With the tiny project brief completed, it is time to make some high level implementation choices. I documented this in a one-page architecture diagram. In essence, it documents the main building blocks, choice of technology, layers and framework components. Like the project brief, this is mostly a one-time upfront effort that acts as a reminder.

Note that I try to make the design documents look good, and sometimes even brand them. I don't do this to show them of on my blog. Rather, it provides me a positive, yet serious association with the project. Plus, my girlfriend thinks they're pretty, although she probably does not even know what it is.

Up next is the functionality. A common industry method to design or document functionality is to make use of use cases. I like them for personal use too, but only if a project is of substantial size:

Note that I use the UML notation freely. Instead of connecting actors to use cases, I color-code them. Not to be a rebel, I do this simply because otherwise the document would become too messy. Don't worry about perfect UML compliance, the point of design is to get your idea across. In this case, the project has a lot of functionality. Without a use case overview, I would get lost pretty quickly. Plus, the use case is a nice starting point for the database model:

The database model is actually the first design asset that is not just documentation. This is the actual design of the database that will be used at run-time. Needless to say it is of crucial importance. It is my preference to visually design a database, print it out, and have it on my desk while coding. In my experience, this is also the design asset that changes the most, so don't worry if your first version is not complete.

Next is the class diagram:

There's much to say about class diagrams. First, some people prefer to first design a class diagram and then the database diagram (domain-driven), others prefer it the other way around (database-driven). Since this concerns a PHP project, I prefer to go for the database-driven method. Another consideration is the available tooling. When I develop in Visual Studio, I can visually design a class diagram and it will sync with the actual code, thus the design is actually part of the code. In the case of PHP, it is simply a seperate document.

One could argue to not create a class diagram for such a project at all. The reason I still do is that objects!=data, in other words...your objects may look different and have different relations than your database model. It also depends on the architecture of your application, you may not even use objects. In my project, the point of the class diagram is to document the model classes and their relationships. I do not bother to include all class attributes from the database model, as that would lead to a lot of duplicate work when the database model changes.

Phew. With that out the way, we can start coding, right? That's what I did. Full of confidence I started working on the user registration and management module. After a day of coding, I started to realize how complex it really is. I was not happy with the structure of the code, in fact I had trouble understanding it myself! Realizing my mistake, I went back into design mode, and documented the various user management routines:

I'm using UML Audit diagrams to document the flow, decisions, states and errors in the processes. With this clearly documented and thought out, coding the module itself becomes easy. Again, documenting this routine did not feel like a pain, it was more like a relief.

Concluding

So far for the little design tour of Jungle Dragon™. It is by no means complete, I'll likely add design assets as I go along in the project. Anyway, here is a short summary of my design tips:

• Design is not a goal in itself, it must support the project. Therefore, apply just enough design to the project as needed, no more.
• Try to use industry standard notations, but don't be afraid to deviate from them where it makes sense.
• Have the courage to admit a mistake, go back into (re)design mode and enrich your designs. Iterative design always wins from big, upfront designs.
• Care for your designs, make them look nice, understandable and friendly.
• Mentally position yourself to embrace designing as a relief, rather than a pain. You will automatically make this switch as soon as you have created some designs that really work for you, instead of against you.

A very common, modern way of developing web applications in any platform is to apply the MVC (Model View Control) design pattern, which roughly works as follow:

• The View displays data supplied by the Model. Typically, this is done using a templating system.
• In the View, users generate actions (by visiting a URL or clicking a button) that get mapped to a Controller.
• The Controller recieves the event, checks it (validation, security, logging, etc) and where needed requests or updates data in the Model.
• Finally, the controller will redirect the user to the action result page, again making use of the Model to display data.

Code Igniter, a PHP MVC framework that I use to develop JungleDragon™, has implemented the MVC pattern as described above. There is a nice little extra though: the Front Controller. Combined with Code Igniter's excellent URL routing, you can do some pretty powerful, elegant things. Allow me to explain...

Let's have a look at the following URL:

http://www.jungledragon.com

This would trigger the Front Controller (index.php) to be requested, since no explicit controller was passed in the URL. Since no controller method was passed either, the default method index() will be called. What about this one:

http://www.jungledragon.com/register

You'd expect this URL to trigger the register controller, but this is not the case. What happens is that again the Front Controller is called (index.php), which will dispatch control to the register controller (using the register controller's default method index()). One more example:

http://www.jungledragon.com/articles/edit/lion

You've guessed it. Again the Front Controller (index.php) is called, which dispatches control to the articles controller. From the articles controller,the method edit() is called passing in the argument "lion".

In summary, no matter what URL get's triggered, the Front Controller is always called first, even though this is transparent to the end user. Why is this so great? Here are a few things I could come up with:

• Centralized loading of global libraries and variables that are needed on every page
• Centralized logging and statistics logic
• Centralized authentication and session handling
• Centralized error reporting  
• Centralized caching logic

Having a Front Controller as the entry point to all other controllers is like having a little web server inside your application. I'm definitely excited about this.

There's one more thing I wanted to show you concerning Code Igniter's URL routing. Have a look at this example:

http://www.jungledragon.com/articles/lion.html

Code Igniter allows you to map extensions to controllers. In this case, the user (and any crawler) sees what appears to be a static URL. In reality, the Front Controller is still called, which will dispatch control to the articles controller to display the item "lion". Not only does this provide pretty URLs, there's two other major advantages:

• I can move around and rename scripts, change my host, and in the most extreme case, even switch platforms, without any user needing to update their bookmarks ever.
• Should I have a need for a caching mechanism later on that generates static HTML files, no user needs to update their bookmarks as the URLs never link to any script or platform-specific extension.

Concluding, a Front Controller combined with proper URL routing makes the life of you, your users, and search engines easier :)

Note: You can still make use of a Front Controller even though you do not use Code Igniter or PHP at all. Technically, it consists of only two parts:

• Rewrite rules for the URLs, either at the level of your web server or at the level of your application. For Apache, this is simply a .htaccess file.
• The Front Controller script, which parses the segments of the URL and dispatched control to the right controller based on these segments.

Continue reading...

	Articles
	Blog entries
	Comments