I Can Be Slow At Times
I can remember the first time I read about Representational State Transfer (REST). I’m not sure that I got it right away, but the principles have started to make sense to me. I am currently building a back-end to server up data for me, and I am using Cherrypy, and a REST style architecture. I first read about REST about five years ago – the article spent a lot of time discussing Web Services and UDDI. Basically, I think in missed the boat five years ago, but now I get the pleasure of being a late-adopter for a change.
This other thing that is making sense to me is Microformats, and ahah. I do not want to say much about my reasons right now, but I can remember when I first started programming. I would come across code that seemed complex, and I would trouble myself for hours trying to understand why it had to be complex. I felt overwhelmed and intimidated. In time, I began to appreciate that simplicity is a virtue.
In the past few years, I have worked on code written by others that was very difficult to understand. Sometimes, complexity is unavoidable, but then, it should be hidden and exposed in a way that makes it easy to use. Working on a personal project has been a chance to build tools and take approaches that make sense to me. I am having fun.
I will leave it up to my reader to read the material I link to – it speaks for itself. I will say more about it later, but not now.
I Am A Cheater
You cannot be good at everything. I admit that I am not a designer. I have forced myself to achieve a level of competence, but that is all. I can imitate the design of others. Perhaps my biggest shortcoming is my limited ability with graphics programs. However, I comfort myself by patting myself on the back about my many other skills. Rather than saying that a lot of designers are better than I am, I tell myself that many programmers are worse.
In order to get by, I cheat. For example, I am building a prototype of a web application and I created rounded corners by using a rounded corners tool on the Internet. I also need help with the hex values for colors. I also use widgets and controls in my applications – why write that code, if someone else has already done a great job? I am particularly fond of the Rico accordian widget.
I try to produce compliant xhtml, and to comply with other standards. Accessibility matters, too. I rely on the web developers toolbar to check my work. There is always something I forget.
As a consultant, I am often interviewed by technical people in government departments. They frequently arrive with a gun loaded full of questions. Then, they aim at my head and fire as quickly as they can. They believe that they are measuring my ability, knowledge and competence. To a point they are, but often, the area of expertise they are testing me on is a very small part of what I think I know. Much of it can be looked up if I need it.
Lately, technical people have asked me about design patterns. Typically they ask me to name three, and then ask a few detailed questions about one of them. I usually refresh before these interviews by reading a general article at Wikipedia. I also like this C# specific resource at dofactory. Next time I do one these interviews, I am going to pick three design patterns, and I am going to teach myself how to draw the UML representation of the pattern – that should impress.
The other question that I get asked is to describe a time when I have used one of these patterns. This is difficult because I often work on code that was written by others – and they do not use design patterns. The other way I cheat is that I find a place in the code to implement a design pattern so that I have something to say at the next interview. Often, the use of the pattern was not necessary per se, but it does ME good to be able to describe the work to get a job later.
Using techniques and approaches because they are hot can be good for your career, but you owe it to your client to learn on your own time. Also, use the technique in a conservative way to solve a real problem. I have been called in on projects that were disasters because the developers reached beyond their grasp. Once, I worked on code that was extremely confusing because the developer thought he was applying the model-view-controller architectural pattern. Boy did he blow it!
Many job interviewers put emphasis on being able to demonstrate skills and knowledge on the spot. For example I have been asked about the syntax for creating inner or outer joins. Come on! I use a tool to build my views and queries. I often forget how to write the sql when asked on the spot. These things do not matter.
It would be great for an interviewer to ask a resource how he or she cheats. It might also be great to say, “You knew this was going to be a technical interview. How did you prepare?”
All day long, I forget things, and I cheat. I reuse the work of others regularly. All the time, I prepare for technical interviews by studying stuff that may not even come up once the job starts – it’s about jumping through the right hoops to get the job. Sometimes, I cheat a little by using a technique that is not strictly called for just to be able to put it on my resume. For example, I recently used an Ajax toolkit in part of a web application because Ajax is hot. My client did not care one way or the other, but now I can sell that skill to the next bidder. I am a big fat cheater.
SQLAlchemy: It’s Magic!
I have been writing some code using Cherrypy and SQLAlchemy. The most compelling reason for using this framework was that I wanted to preserve my ability to leverage my code against multiple databases. Right now, I am using MySQL, but later I can just as easily use this code against a PostgresSQL database, or even an Oracle Database. Other than that, I probably would not have used it – better the devil you know, and all that.
Having used it, though, I can see the appeal of such frameworks. I have some learning to do, but I like the code I wrote. At the same time, in the past, I have put much of my effort into writing stored procedures, and then I have written the code to use the stored procedures. My stored procedures became an abstraction layer to talk to the database. I try hard to provide for all usage scenarios. Developers who used my databases often did not have to write SQL themselves. However, this is a good approach only if the ability to use multiple databases on the backend is not required. I need to keep my options open.
This morning, I came across a library that simplifies using SQLAlchemy. It takes the activemapper approach, and it is called Elixer. The basic concepts apply in other languages and frameworks – see ActiveRecord.
This is the direction of things to come: we are going to be managing data using objects. The underlying database may be a relational database, but the layer that developers will touch will be an object layer. This is what is being done, and a whole bunch of people are going to have to catch up. One-to-many relationships are represented by objects that contain a parent entity, and a collection of child objects. This makes sense for programmers. That is the way they think.
If you think about it a little, you will realize that the experience of using one of these frameworks against a relational database will be very much the same as using a purely object oriented database like DB4O. This will have the effect of making it easier for developers to transition to object persistence based approaches that do not use an RDBMS.
I believe that the factor that will determine the choice of approaches will be the need to provide business intelligence and reporting functions. There are people who use popular reporting tools that work with the popular database products to build reports for users in the enterprise. These people are not programmers, nor should they be. Given the wide range of reporting tools that exist, and the common approach that is used to write queries across various relational database products, I do not expect the object oriented databases to make inroads in the enterprise right away.
However, the object oriented approach is going to become the way developers write code against relational databases – its already happening. The launch of the next version of Visual Studio should be very interesting. Please note that the code looks much more like SQL – that is going to be useful.
The other consideration is that there is a mature way to approach data modeling and database design. The cool thing about DB4O, or even SQLALchemy, is that it makes it easier to write code that deals with data. But, I do not see these products being mentioned in the same breath as database normailization. I am sure that design techniques will be considered and elaborated once objected oriented data persistence is more widely accepted. Best practices will emerge.
However, so far, I am pleased with my decision to use SQLAlchemy – it’s magic. I can achieve my goals with less code. Once I get going, I can create a new feature against an existing database with more agility and less pain. Also, I can chose to use a different underlying database and continue to use my code base with very few changes, thus reducing vendor lock-in.