Monday, March 26, 2007

Times are a changin'

Some of you might've noticed that I missed my regular sunday blog-post yesterday .

The reason is obviously the same as everyone else's these days: I'm out of time. Yup, I just ran out of it.

I like keeping up to date on a wide range of subjects. These roughly inolve:

  • Java programming (EE, 1.5)
  • Dynamic languages (ruby)
  • Object oriented design
  • Aspect oriented programming
  • Building, testing
  • Web programming
  • Agile methodologies (Scrum, XP)
  • Content management systems
  • Portals
  • Lots of other stuff going on in the blogosphere
Most of these are essential to any developer, but still it is too much ground for me to cover.

In order to be able doing my day job, as well as keeping on blogging and also having a personal life, I'm performing some drastic changes on my scope of attention. In concrete, I'm going to leave the CMS and Portal bits behind and focus on more "core"-like technologies. Don't get me wrong, I still have a huge interest in these two fields, but being that they are so huge and hard to follow, and that they're not really part of my daytime job anymore, I'm going to have to constrain myselves to the upper part of the list.

That's just all about I've got time for, naturally. Next sunday I'll try to post back on a harder topics, talking more about low-core programming and specific technologies I'm trying out. For those who enjoy my posts about content management and have little interest in programming: I apologize, but you might just prefer unsubscribing at this point. Thanks for reading, whatever you decide :)

Sunday, March 18, 2007

How I became a certified Scrum-master in two days...

I'll asume that most readers are somewhat familiar with Agile methodologies. Scrum is one of these, as is eXtreme Programming and Crystal. It is a framework that avoids taking too much control over how you do projects, but adding a few core ideas and rituals that could be of use to any kind organization. If you aren't familiar with Scrum or any other agile method, read up on it now. Here's enough to get you started :

Scrum Alliance's intro

Now, for us that have the privilege of working in a company that can see the long-term benefits of spending a decent fortune sending you off on a two-day course, we kickstarted our Scrum-ways by doing Jens Østergaard's course for becoming certified Scrum-masters (cool title, eh?). It is not an expensive course by itself, but it costs the company alot to take us all of our projects for a whole day (the course was friday and saturday).

Before the course, I honestly figured I knew enough of Scrum to do fine without it, but it would be nice to have the title, and maybe widen horizons a bit.

I'm not going to go through the content of the course, but I can tell you that Jens is an excellent presenter, I learned some Scrum basics I've missed along the way (especially about project roles). I learned a few wise steps to take for introducing Scrum into a project or organization.

I would definitely recommend the course for people who want an introduction to Scrum, and also people who are going to "sell Scrum", meaning getting their customers to accept it instead of horrible traditional project plans. You can read/practice yourself up to the same knowledge (after all, Scrum principles are easy, and mostly it is about using common sense), but this course was a nice compressed version for those who do not have time/resources to educate themselves into Scrummers.

Funny how many of those Agile web-sites seem to be powered by Rails Studio. Pretty clear that the Ruby on Rails community seems fairly connected to the Scrum one. Noticed all those nice urls ;)

One of those little funny coincidences of life; this is a graph over last weeks visits (RSS hits excluded). Look familiar?



But honestly, I can't write any more. Still recovering from yesterday's St. Patrick's Day celebrations.

Sunday, March 11, 2007

The Programming Designer

Most developers prefer to seperate design from functionality. This is a noble goal, but sometimes hard to implement. In my experience developing web applications, the most typical collision between design and functionality happens in JavaServer Pages, the most typical templating format of web front-ends in Java web applications. Most readers know JSP's, but for those who don't, think of it as Java's PHP, or the templates we use for producing HTML.

However, a problem which is still at large in web applications today is that these templates are designed by Java developers, or pure programmers with little knowledge of web design and web standards. Or worse, programmers that believe they do know web stuff when they actually don't, or don't know how important the web front-end really is.

The problem with programmers doing these JSP's is that that they are doing design, sometimes even when they don't have to. The classical example of this is putting layout of the entire page in<>'s because they can't handle CSS. Tables are even used for lists. They embed JavasScript and styles in the HTML. If they do use CSS, they might inconsistently use classes and id's.

And by the end of the day, the result of the programmer's futile attempts at doing web design ends up plain ugly.

Then to the rescue: The web designer.

The web design is delivered in the shape of a couple of example static HTML pages with CSS and JavaScript files attached. Shipped and dropped in the lap of the programmer.

What follows are several strenuous days of the programmer picking at the JSP, trying to make the web design fit and look like the web designer's example.

There are two ways to avoid this pattern. The first one is: Programmers, steer clear of web design. Just leave the design till later on. Learn the basic DOM-elements of HTML you will be producing, and use it in a consistent way.

But remember that no matter how well the programmer uses div's and id's in the most elegant scheme of definitions, the web designer will definitely come up with his/her own ones that must be complied with across all the JSPs in an application (and there are often quite a few of these, mind).

The second way to avoid the pattern is the programming designer. The programming designer is a very rare breed. They are creative personas with an understanding of usability, colors, spaces and kindness to the eye in general. They also have basic skills of programming, master CSS and JavaScript, and are in essence able to work on the same JSPs as the programmers do. Not creating functionality or content though, but simply tweaking the div's and the id's.

Needless to say, the interests and motivations of a designer are very far from those of an innate programmer. I think one could even draw the conclusion that these two professions draw quite opposite personality types. Perhaps this is also why we often detest the products of eachother.

Me, as a programmer for instance, I hate doing web design. I can never figure out a set of good colors that work. I can't get CSS stuff working, it's just stuff bouncing around. And personally, I'm a functional person, not esthetical. I can't see the point of improving design once you have achieved usability, although I do of course recognize that there is an actual need for this in attracting use and success of an application. What more, I envy this effect that often leaves the designers being the heroes of a successful web application as they make the outlook, the good looks, the bells and whistles.

Good architecture and good programming goes unnoticed (meaning that it only gets noticed when it's done badly). Yes, I am jealous :)

Still, spite the gap between our personas, I have seen programmers successfully venturing into the world of web design, as well as designers learning the skills and becoming adapt programmers. Some have even been doing both since they started of with their own LAMP application and had no way of outsourcing design nor programming. These are programming designers. I believe that EVERY web application project should bring one of these on board.

They have a role all throught the project. From the beginning they can maintain a prototype application of static HTML pages. Moving on the start assisting the development of the infant JSPs, making sure that the programmers take no wrong turns in the use of HTML. Continually, they do their magic and paint the functional application with their magnificent colors, scripts, images and layouts using the optimal techniques of seperated CSS and JavaScript files. They ensure that the application follows all relevant standards of W3C, ensuring accessability and correct design in all Internet browsers.

I would also like to note that inversion of design/design injection can be done with SiteMesh, which is a great tool for templating and page modularization. This is a good way of giving the programming designer a file/decorator/template where he or she can work freely while not interefering with the tangles of the programmers.

Saturday, March 10, 2007

dot com parties, search engines and newsfeeds

Yesterday I was at my first dot com party, I think. Search engine people (developers and optimalizers), marketing people, designers, concept developers, interaction experts and consultants, and free beer/wine for everyone.

It was enjoyable to mingle around and talk to these people that thrive on the borders of my own industry (being software programming). But I also got a spooky feeling of déjà vu. Might be a sign of things to come. I do think we have a bubble burst ahead of us, maybe less then three years from now, maybe even this year. It depends on whether we, the industry as a whole, will be able to stabilize our growth in time.

Enough doom's day speculation. Talking to all these bloggers I began thinking about my statistics and news-feed (those of you who are more observant noticed that I outsourced the feed to FeedBurner when I upgraded to the new Blogger. This was mainly for the purpose of quick and easy feed statistics.

However, I've noticed a recent drop in hits/visits. According to my new year's resolution I want to achieve 200 weekly visits by the end of this year. I recently had a short bounce over 100, but after that it has dropped and stabilized around 80.



At the same time I've seen the FeedBurner number of subscribers rise to 26. I don't know how much these subscribers read my blog. I would think FeedBurner can't really tell either since they are continually pinged by various blog aggregators, so no point in measuring hits there.



Update: Found another interesting graph (number of FB subscribers):



A FeedBurner upgrade promises to give me the real numbers. I'm gonna try out the free trial and see what I get. They claim that by loading a small GIF into the blog-post they can track how many views a blog-post gets. If that works it sounds like a pretty accurate measurement of blog traffic. I'll post back with the results in a couple o' weeks.

With TotalStats you can see how many times each item in your feed has been viewed and clicked. Views are tracked by using a 1×1 tracking gif that when opened in a newsreader will render and we'll be able to count a view for you. Clicks are simply clicks on the headline of the item which will bring readers back to your site.
I like what this guy has done with abstracting away the link to traffic his feeds with some web server configing. Unfortunately, being hosted at Blogger doesn't leave me much control of the .htaccess file.

There is also some critisisim about. What does happen if FeedBurner goes out of business? Will you guys be able to find back to this blog and get a new newsfeed url? I think so :)

Wednesday, March 07, 2007

Digging deeper into CMS requirements (#5: The last one)

This is the fifth post about digging deeper into content management requirements. See also

I know I was going to rant about agile development and Scrum soon, but what the heck; I'm inspired! Today I'm gonna finish off the CMS Requirements thread and describe THE most important requirement of all. And hopefully on sunday I will explain how all these requirements are interconnected by two key principles:
  • Open Source
  • Open Standards
Now writing about the other requirements has been quite a booring affair. They have just been sort of basic explanations that can lead up to sunday's post.

However
, this requirement is no ordinairy rabbit! It's not measurable, you can't actually describe it, and it's darn hard to implement! It is a utopical state software, an *ility of the highest degree.

2 years of CMS research, coffee drinking, chocolate-chip cookie eating and hard thinking made me believe that the most important requirement of a content management system is...

Extensibility

There ye have it. The number one thing that comes back to kick me in the head after having delivered a top-notch user friendly CMS is this:

Customer: "Oh, the new homepage looks great. Can we put our boat/customer/shop/weather/blog/forum/registry/directory/services up there?"

Extensibility. The quality of software that allows you to extend basic functionality with new custom tailored stuff. The last 20 or 10% that you need to get the perfect CMS.

There are many factors that multiply into this one. Stuff like plugins, portlets, parts and widgets are implementations where people have tried to put extensions. Modularity is factor, as is simplicity in the code base.

But the most common factor in extensibility is openness and agreements. Standards.

If I can understand my CMS, I know how to extend it.

This is actually a quality in most software! In fact lower level software like programming languages and operating systems are based on the very possibility of extension.

But we are talking about CMS'es here. And they deal with content. Content is historically not a very extensible format. You define your SQL schema or file-format, and you stick to it. Once you start using it you can forget anything about extending the use of your content, translating it, exporting it in a usable format, or importing other kinds of content. At least not for anything less than a fortune in developer costs. There are no content standards (well, some are appearing, like RDF and JCR).

If we do settle on a content standard that offers us the possibility to extend the use of our content we can start developing CMS'es that can realise the potential of extensible content.

Yes, you can extend your CMS for user registration and profile editing. You can expose your content as blog-posts. You can create articles of content that are either news, weather-forecasts, image-libraries, data-sheets, documents, and so on and so forth. You just need the content format to do so.

Let us stop hammering content into relational databases! Stop pushing maps and references into flat tables. Stop creating portlets, widgets, plugins and templates just to display your table-relational data a certain way.

Instead store your content in a generic way, and expose it a generic way. These are the principles the Internet is built around; standard storage format and standard transport format. We seem to have come a long way on the transport format, but are still way behind on the storage format because of greedy, properitary vendors that have not sooner come together to standardize content storage.

Well, I think that rant was a bit of a head start on sunday's post, but I'll hold on to the rest of it for now. In the future I'm gonna slide in on a track which focuses more on the field of open source and open standards, and let me add that I haven't been reading up on my Open Source Journal recently, so if I am obviously repeating any ideas that others have published, let me know.

Need to write invitations for the upcoming St. Patrick's day party :)

Sunday, March 04, 2007

I'm gonna be the Wiki-techie! (oh no)

I was recently contacted by Atlassian's Wiki Evangelist (yes, appearantly that's a real title!), Stewart Mader. He asked me to consider their new site, Wikipatterns.com, and also forward the site to my dear readership. Done!

In other but related news, I've been (somewhat unwillingly) appointed our next Confluence administrator. This means I'll be given full control over the wiki (muhuhaha) , meaning in effect I'll be able to try out new plug-ins, manage spaces, bully people around, etc.

It also means I'll have to do upgrades, booring user adminstration, figure out funky stacktraces that are appearing in Confluence for some odd reason, fix the database, etc, etc.

The main reason I have volunteered to do this job is that no-one else wanted to do it, and I believe our Wiki is far too critical to leave in the hands of our IT service provider like our CTO would've had it. When are you people gonna understand that Windows is not meant for hosting?

Additionally, I'll hopefully learn alot about Linux, DNS stuff, routing, network, hosting java applications, databases and user management (with LDAP).

These things aren't always relevant in my daytime job, but sooner or later the software we produce will end up in the hands of IT techies who want the software to work, log and do error reporting in a certain way.

And when all boils down to it, Confluence is still a java web application that runs on Tomcat, which is very similar to the products I develop. Having been responsible for hosting Confluence will therefore make me a better software developer.

I've got lots of other things to blog about, but no time to do them right now. Subjects include:

  • Finalizing the CMS requirements with its most important element: Extendability
  • How I became a certified Scrum Master (and what I learned)
  • The programming designer, the new breed of web developers
Stay tuned.