Tuesday, May 13, 2008

socialdevcamp east

Last weekend I attended SocialDevCampEast in Baltimore, MD.

SocialDevCamp East is the Unconference for Thought Leaders of the Future Social Web

Where is the social web going? It's going mobile, to geocentric services, and to open platforms. A community of like minded developers, social media gurus, CEOs and thought leaders from DC to Boston came together to discuss the future of the social web. Check out the link above to see the participants and topics.

Thanks to all the wonderful sponsors, volunteers and participants that made it so awesome.

I particularly enjoyed the session with Bill Mill where we built out a simple application on the Google App Engine platform. The last session concerning startups/VCs was really good too. I liked the thoughts from Jared Goralnick and Nick O'Neill pointing out the strengths of the east coast.

I can't wait for the next camp in the fall.

Saturday, April 26, 2008

Rails Session Management

I have been trying to determine strategies for implementing sessions via Ruby on Rails. I am particularly concerned about scalability and session replication across multiple servers in large scale sites. What is the proper choice? Here are some options for session management with Rails:

  1. No session
  2. PStore
  3. ActiveRecordStore
  4. MemCacheStore
Using PStore writes to a local file system which doesn't scale across multiple servers unless it is a shared directory visible to them all. This isn't very practical across multiple data-centers. ActiveRecordStore uses a DB which means each access of the session objects may use DB resources. Again this isn't scalable.

Thus, MemCacheStore looks like the way to go for most web applications. There is a great discussion of it by Stefan Kaes.

Is Merb better at this? Anybody else using another solution?

Wednesday, April 16, 2008

Ruby

Tonight I attended my second NovaRUG meeting. Dave Thomas of The Pragmatic Programmer discussed the Ruby object model and Paul Barry discussed Merb. There seems to still be a lot of development and refinement of the language and implementations at this point (including the best frameworks like Rails, Merb, and ORM). There is a good chance that Ruby will be a great language for rapidly creating high quality applications.

  1. It has a very strong object model.
  2. It has good support for unit testing.
  3. Syntax is simple.
  4. There is a decent developer community to support and champion it.
It will still take a high commitment to execute at the craftsman level, but with good methodologies I think some great code can be developed. I am currently researching the best book for an introduction to the language. Suggestions?

Tuesday, February 26, 2008

New O'Reilly Title

Thanks to a colleague, I recently came across this book that is being created O'Reilly Software Craftsmanship: From Apprentice to Journeyman by Dave Hoover and Adewale Oshineye. It builds on The Pragmatic Programmer: From Journeyman to Master by Andy Hunt and Dave Thomas and the Software Craftsmanship title by Pete McBreen.

As they point out, the book is not available yet. But you can comment on the chapters as they are being written. What I like so far is it seems to blend the pragmatic examples of the earlier Dave Thomas book with the principles presented in McBreen's book. It appears that the book is very early in development (for example Chapter 1 references what you learned in Chapter 3) and maybe has some reorganization down the line. But the ideas are worth considering for any software craftsman and I am eager to see what the final product is.

Technorati Profile

Thursday, January 31, 2008

Accidental Perceived Functionality

Recently I learned of an issue with an application where presentation of a resultset in the UI led end users to assume the order of the resultset was a feature of the application. This is a pretty common scenario that I have seen with many applications both on the web and off. Usually it is the result of not using an ORDER BY clause in the SQL query or not having any logical column to sort by in the resultset. The problem is amplified in the case where the end user is the one who created the data in the first place and believes that the order they created the data (via the GUI normally) is perserved by the application. In time, the resultset from the scenario described above may be returned in a different order. Consult your RDMS guru for all the scenarios where this might happen. I have seen it occur during import/exports of data, database replication, and during updates to tables where all rows are affected.

Regardless of the cause, the net result is guaranteed to be user complaints about an issue with functionality (ordering of the resultset in the UI) which was never intended to be a function of the application. This is what I term accidental perceived functionality (no doubt, somebody has a better name). Please post other examples of this (so we can all learn).

Tips to avoid this situation:

  1. Hire a good business analyst to capture all requirements (including eliminating possible points of confusion). This won't necessary avoid the problem, but will increase the odds.
  2. Make it a habit to always include an ORDER BY clause in all SELECT statements.
  3. During table definitions always provide a column that allows ordering of results in accordance with the desired functionality (capture by requirements)
  4. Thoroughly unit test the results sets (including order) of your DAOs.

Friday, January 11, 2008

Why Refactor?

Was discussing this today. Refactoring is the process of modifying code without changing the external functionality of the code. Check out Martin Fowler's book on the subject for more detail. Off the top of my head I came up with the following examples of why:

  1. Increasing readability (changing variable names, method names, etc.)
  2. Increasing performance (faster sorting, introducing caching, clustering techniques, etc.)
  3. Decoupling classes
  4. Increasing class coherence
  5. Fixing broken windows (unused objects, unreachable code fragments, etc.)
  6. Simplifying (Introducing Enumerations, constants, putting common functionality into a single method)
  7. Reorganizing packaging of classes
  8. Further abstraction and extensibility

For the principles exemplifying 3, 4, 7 & 8 see Uncle Bob's Principles of OOD. All of the above (except # 2) can be thought of as reducing complexity. And it is a lot easier to be successful at #2 if you can reduce complexity.

Thursday, January 10, 2008

Twitter Widget added

Removed my Twitter URL and added the Twitter Widget to the sidebar. Enjoy.

Wednesday, January 02, 2008

Twitter

Added my Twitter URL to the links.

Thursday, November 08, 2007

CIO&CTOLive! Awards Ceremony

Attended this Tech Council of Maryland event last night. I didn't hear any mention of software development, but the emphasis on the strengthening role of IT in business strategy made it clear that methodologies which connect the technologist to the business side of the house (such as Agile Software Development) are going to be key.

Friday, June 15, 2007

Java Persistence API

Is anyone using
this yet?

I am thinking of using hibernate in a new project, but wish the Java Persistence API was implemented by Apache.