Technical Podcasts

If there is something the web as surely changed, it was the way that software engineers need to work. It is now a crucial aspect of our work to be able draw from the huge internet knowledge base out there in an efficient way to get to the right answers. Part of that information extraction is related to the keeping-up-to-date effort that every developer is required to accomplish to continue to be productive. While previous a software engineer could rely mostly on print material, nowadays we need to rely as well on content available on the net. Podcasts are such a source that can bring an amazing amount of information to the mix of knowledge one needs these days. If you are a software engineer and have not jumped into the podcast wagon yet, I suggest you do so. Here is a list some technical podcasts that we hear at Tizra:
  • The Java Posse: a fantastic podcast on Java development. Containing news info update, analysis of tools, overall software development discussions.
  • Software as She Developed: pretty interesting podcast on software development. The author Michael Mahemoff is the author of the Ajax Design Patterns book so you can expect this podcast to bring in a good amount of that experience.
  • Audible Ajax: name says all, a really good podcast on Ajax.
  • Software Engineering Radio: good presentations on software engineering in general. Covering topics like agile development, SOA, development processes, etc.
  • Javapolis: one of the best Java conferences around. You can find podcast feeds for some of the presentations in here. A free way to "be" at the conference.
  • TalkCrunch: a really interesting podcast on web 2.0 companies.
  • Venture Voice: talks and discussions on entrepreneurship.
  • PodTech's Entrepreneurship Podcast: talks and discussions on entrepeneurship.
And the list will keep growing....

Scarcity Amid Abundance

One ramification of Chris Anderson's economics of abundance argument was nicely summarized by David Hornik:
don't do one thing, do it all; don't sell one piece of content, sell it all; don't store one piece of data, store it all. The Economy of Abundance is about doing everything and throwing away the stuff that doesn't work. In the Economy of Abundance you can have it all
But for most publishers this has been easier said than done. They may have an abundance of content, but building, feeding and tuning current online distribution and marketing systems is enough of a resource hog to dampen the experimental spirit at all but the richest. This, as you may have guessed, is the problem we're working on at Tizra. We think we're pretty close to solving it.

User Centered URLs

Tom Coates recently picked up a great post on a how much better a nice, intelligble URL scheme can make almost any web application. It's a place where system architecture and information architecture often diverge, and where thinking holistically about both at once from early on can result in software makes as much sense to people as to servers.

Leave Web Enough Alone!

Jeremy Zawodny is rightly torqued about the needless complication of tools that purport to help with information sharing. The web's always had that pretty well covered, thanks to the simple magic of the URL. Anything you find, you can bookmark, email, or with a tinyurl, disseminate on a cocktail napkin. If my dear grandfather had been born later, he probably would never have picked up the habit of mailing articles lovingly clipped with a pen knife, and instead would have referred me to his feed. Zawodny points to a bizarre assortment of pop-ups, forms, and other unwelcome surprises that result from the "helpful" new sharing features, and notes...
they seem to be placed on the sites under the assumption that I'm too stupid to send email (to the people I presumably email frequently already) with a URL in it... Thanks for the confidence boost.
At Tizra, we're more inclined to say thanks to for the opportunity to do better. Our AgilePDF™, for example, gives every page of an online PDF its own URL, so that users can find them, bookmark them, and yes, share them just the way they would any other web pages. Call us uninventive, but sometimes it's better to exploit rather than fight the standards and user habits that have made the web the fastest growing medium in history.

The importance of continuous integration

Leading a team of developers in the effort of building a robust, quality software product should involve the establishment of some process and tools to assist the team effort and serve as a safety net for the errors of getting people to work together. Continuous integration is, I believe, a crucial element of that process. Introduced by Martin Fowler and Matt Foemmel (see article Continuous Integration), continuous integration establishes the practice of frequent integration of work developed by the several team members verified by automated build and testing of integrated code within a clean sandbox. This practice is valuable for several reasons:
  • It promotes the development of a clear process of building/deployment independent of any specificity of developer's platforms. Code that exists on a single platform only is bound to become dependent on specific aspects of that platform without anyone really noticing the dependencies until trying to port to other platforms. The existence of the integration clean sandbox allows these specific dependencies issues to not go unnoticed.
  • It promotes the development of testing. Being based on the premise of "test often" it makes the testing development part of the team's process. The fact that there is a platform built specifically for build and testing verification transforms, from the developer's perspective, testing efforts into an even more useful and justifiable effort.
  • It allows for quick detection of code integration issues by providing the clean slate for bringing all the code together. The little quirks of code combining can be detected by effective smoke/regression testing.
How hard is it to put in place continuous integration ? It depends a lot on where you are in your development process when you decide to take it up. If your team already makes use of build tools (e.g. Ant, Maven, even Make), makes use of a version control system (e.g. CVS, Subversion) and already does some kind of automated testing (e.g. xUnit) it can become pretty straightforward (You do use these don't you?!?). Continuous integration becomes simply a matter of setting up the integration sandbox and establishing the automation to detect changes in the version control system, building the changed system and testing the changes. You do not even need to go very far to accomplish that. You can find already systems that give you the continuous integration functionality that you need. At Tizra we have chosen to use the Cruise Control open-source, free framework for our continuous integration process (BSD-style license). It does pretty much what we need to do and keeps us on top of any integration issue that might arise from our development effort. It provides us unit tests results gathering, reporting and historical stats gathering for all checks. Continuous integration should be, in my opinion, an important practice for any serious software development company and I, for one, will make every effort to ensure it is put in place in every project I work with.

PMD static Java code analysis tool

How many times have you, in your developer life, smacked our head and screamed "that was sooo obvious!" upon discovering a bug ? And how many times those were pretty simple bugs that could have been caught just by looking closely at the code and finding a silly mistake ? I'm guessing too many times.... :-) PMD, no real meaning to the acronym (see here), is a pretty handy tool that if used with some frequency can help you at least save your head from the smacking. PMD is a Java code analysis tool that draws from an experience-driven rule set to look into your code and flag possible mistakes. From unused imports to the always error prone braceless if statement, PMD can give you a pretty good coverage of what you can do to improve your code and reduce the probability of making a silly mistake. PMD can be run from within your ant or maven build file should you want to make running it part of your build process. You can find plugins for most of the popular IDEs to make it even simpler to run it and enhance your code. PMD is extensible letting you add your rules should you wish to enforce any kind of rule to your project. Finally, PMD is open sourced, licensed under a BSD-style license and available at sourceforge. All in all a pretty cool and valuable tool to improve your development process and maybe keep your development team a bit saner.