Ionrock Dot Org

I just read this article on naming variables. I thought it was kind of funny, but what is really funny is that I, as a geek, thought the article was funny in the first place.

Yesterday I was talking to Patrick about working on some new features for the Q site. Specifically, we want a project management tool that is integrated with out other systems. With a testing environment in place I have been able to make a table and get some basic output to a page. Nothing to be proud of yet, but it looks like it will be an interesting experience. I think my biggest struggle with it may be not having to deal with the mundane details of the site.

What I have found in using frameworks and working in PHP is that understanding the model of how the system works allows you to take programmatic shortcuts to become more productive. For example, in TurboGears, I could add to the tg-admin command line tool to scaffold some forms. In .NET this is much different. The underlying model is somewhat hidden behind Visual Studio. Visual Studio provides the framework, organization and administration of the site. Seeing as I would rather use Emacs than an IDE, this way of working is rather odd to me. On the up side, it is something new to learn and I get to expand my horizons a bit, so no worries.

In the mean time, we don't have a good system of tracking projects and keeping organized. We the the ever present Outlook, but I hate the interface and believe I will never enjoy a groupware suite with many forms. I am interested in checking out some Emacs based solutions for keeping notes and todo lists, but from what I have seen, most are rather complicated. I don't know that I want to spend the time to learn more key bindings and patterns for a tool that may not really be of much help.

Along these lines I am thinking about how I can use Trac more effectively. Specifically, I think I want to create a Todo list of sorts with Trac just using the available tools. I am not really sure how this will work just yet, but I think I will be using RSS for monitoring aspects (changes to the wiki, checking in source, etc) and see what I can come up with. I am also thinking I could use something like a blog for taking notes or making todo items. My biggest need is a tool that I can access and work with very quickly. When I have to change my workflow just help me to remember, I feel like I am wasting time. Wish me luck.

It is funny to see how problems change as issues get handled. I remember when I first started working with Rails and how impressed I was with ActiveRecord. Looking back, the issue was not nearly as difficult as I thought, and once I became used to having an ORM system, it was easy to find similar tools in other languages (PHP and Python).

Again, looking back at Rails, I found that the ORM is just half the battle. The efficiency of Rails is in its ability to link the ORM with the forms and the validation of the forms. Furthermore, it all revolved around the declaration of the objects. I remember being frustrated when I changed my object because often times I had to zero out my work, but in reality, the gains I got regarding form creation and validation were huge.

Now, I am sure if I had continued to use Rails for projects, I would have ran into problems. Even in my limited experience with it, I ran into some issues that were a pain to fix. But, I also noticed that problems I run into now with things like TurboGears were non-issues in Rails. This is frustrating but also edifying in that I have the opportunity to see the trade offs directly.

With that said, my issue now is forms. Simple text forms are a breeze and things like dates are even getting manageable. The problems start up when you try to validate while adding complex forms. Actually, I suppose my issues are not really problems. My frustration is that I have to write code for something silly like a form. I should be able to declare a data store and a template like filter and be done with it. The data store should be authenticating the data and the filter should be handling the formatting and style. The problem with too much automation is when you need to customize in which case a filter/template tool could handle making changes (similar to layering in XSLT).

These are not simple problems and I think in the end my resolve will be to make a go at solving them myself for my own purposes.

In other news, Patrick the wise has completely revamped the WebWorks site!!! This is great news because we have made so many changes at the company and this new site reflects not only a new vision, but new productivity. The whole site was updated and revamped in only a few weeks time! Congrats to Patrick and the Marketing team for making the magic happen.

Today I took a moment to read k10k and check out some design sites. When I first started becoming interested in computers and technology, flash and the design community fueled my fire. Needless to say, I never became much of a designer. Some times I wish I had spent more time on art and design. A friend of mine who never seemed to be much of an artist ended up going to New York to go to art school. After seeing some of his work, I was genuinely impressed. It sometimes makes me wonder if I could have done the same thing. All in all though, I think I am not cut out for design. My poor hand writing skills and lack of skill in choosing quality colors seems too large a roadblock.

The bigger reason I don't think design is for me is I really like programming! I know there are some very good developers that are designers, but what I enjoy most is dealing with systems, and not just UI issues or visual programming. I get a bigger kick out of databases and system design than making things look nice.

Today I noticed a list of links about eclipse on developerworks. There was a small list of links regarding web development that all focused on Java, which just seemed odd to me. I am not sure why this has never caught my attention before, but there is a lot of material regarding web development using Java or C# that has no mention of HTML outside of sparse clarification of the output.

In my mind, Web Development revolves completely around HTML (and I do mean XHTML as well). I don't mean that CSS "hacking" and XHTML "programming" is development because it really is just handling presentation details without logic. This is not a rip on those who are CSS/XHTML experts of course. I just do not consider it programming or development.

I am sure that most Java and C# web developers do understand HTML more than the articles might suggest. My only issue is that it seems that it is not in the for front of what they do. When I used to write GTK+ programs with Python, I consistently found myself learning more about GTK+ than solving hard problems. The toolkit was a crucial area that I needed to understand if I wanted to be successful. It seems this should be the same situation for web developers (Java or otherwise). Of course,I should point out that I could be totally wrong in how I see Java and C# web development. But, if the docs don't push understanding of all required technologies, then the folks reading them are not going to learn what they need to know.

Last night I added documentation for a small application I wrote. I had written it a while ago so I updated some of the content and fiddled with the output in ePub. What was really nice was that I used the WebWorks Help API to call the help set. It was so *easy*! I have commented to clients before that the API was available, but I had no idea how simple it was to use within the scope of a developer position. There is a wide array of ways to handle context senstive help with little to no changes in how a developer works. Brilliant!

Last night I talked to my dad for a bit on the phone. Like many men before him, it seems as though he has been bit by the bug of technology. A broadband connection, wireless and a new PDA has brought about a new enthusiasm in using computers that I have honestly never seen in my dad. Since becoming a programmer and general technical guy, I am seen as Tech Support to most in my family. My dad's new desire to geek out has brought about longer conversations on the phone that revolve around reading installer messages and opening control panels.

Anyway, last night, during our virus protection conversation it hit me that the concept of "Enterprise" computing is non-existant in the Apple world. What tipped me off to this was when my dad was installing AVG (free virus protection that doesn't get in your way like McAfee/Norton). It was asking him some question about updating the software and whether or not to restart. My dad felt it should just take care of itself. I mentioned that there are many instances where that wouldn't be a good idea, none of which he understood. My dad has been using Apple's the Mac SE.

In the PC world, every application has consider things like corporate file shares, VPN connections, central authentication systems and remote home directories. The result is that applications cannot reliably make decisions because there are too many variables that can make them break. In some senses, I think this is kind of fun for guys like my dad because there really is a sense of satisfaction when you get your virus protection up to speed. It is a complete waste of time in that it doesn't help you get work done, but it does mean you did something that is essentially restricted to the world of computers.

I have commented on this concept of trusted environment before and even in the context of Apple's hard link between hardware and software. In thinking about Apple in the enterprise, it seems that it is just too easy to poke holes (whether real or not) in Mac OS, which makes it almost impossible to use in the enterprise. The enterprise environment relies on a feature list and Apple does have the longest list of features unfortunately. Shame on Apple for giving people the impression their computer should do the work.

Recently the push to services has become a bit more real. There have been some meetings and the like that have suggested how things may change now that we are focusing on services. I am not the person to talk to regarding large changes, so no details will come from me. What I can comment on is my attitude towards change.

My initial reaction to the suggested changes was rather negative. I am not sure it was justifiably negative, but it was rather frustrating. After a bit of simmering things did cool down. In some ways I can give myself credit for this, but what really allowed me to keep cool was the fact that I trust my fellow co-workers in their desire to do the right thing. It is important to realize that I said *desire* and not something such as ability. The desire allows for changes when things are going correctly, when the ability is a black box that must be trusted. In the end, I was able to discuss my concerns and I am sure that no matter what happens, we will be making decisions to the best of our ability, which is the best anyone can ask for. Kudos to a great team!

To change gears a bit, I saw X-Men 3 last week. In my youth I had a subscription to a couple different X-Men comics. I was very excited after watching X-Men 2 because it felt like the comics and had the same massive complexity in one movie. One of the greatest things about X-Men, and Marvel in general, was the way everything could tie in together. A great example is how Rogue was able to get super strength and fly because she sucked the powers out of Marvel Girl (I think that was her name). That sort of crazy linkage to other comics and characters is just nuts! Sure, it is a little far fetched, but these are comic books after all.

But back to the movie... Without spoiling anything I was seriously let down. From a strictly entertainment point of view, it was fun to watch, but the comic lover inside me felt somewhat duped. The second movie walked the line between comic accuracy and a good movie plot. This third movie looks like it tripped on that same line and just sort of layed there trying to pick itself up.

My only regret is that I didn't stay until after all the credits. I will just have to rent the stupid thing when it comes out on DVD to see what I missed.

The past few weeks have been pretty tough. I have been travelling along side having many things to do at home. The result is that I am pretty tired. I would not say burned out because, despite my obvious working too many hours, I am still enjoying programming and thinking of interesting things to do with our product. With that said, you can't work 12 hours a day for three weeks without getting a bit tired. Having to spend a good portion of time on my one holiday weekend was also rather frustrating, but hopefully all my hard work will let me retire very early and I can buy a big RV and just travel.

In other news... With the push for services in the company it looks like there will be a few organizational changes to help offer more help to those working in services (like myself). In some ways I am bit leary of this sort of change, but I do know that there needs to be changes. I think I am just a bit of a control freak in a weird way at times, so I am working hard not to jump to conclusions or have a negative attitude for no reason. The good side of all this is that if there is something that isn't working or has real problems, I am totally free to talk to decision makers about the issue and mostly likely get things changed.

On a more general note, I have been seeing some important aspects of being a consultant. I read an article about being a tester from Joel Spolsky a while ago and one point he made is that finding a good testers is an ongoing process because they will invariably get sick of it. I think this is similar with consulting. A consultant needs to love coding and technology. Ideas need to flow freely and dynamically in order to solve problems and generate new possibilities for customers. The other side of this is that a consultant needs to be able to communicate complex technologies to customers. There are two reasons for this. The first is to help them to understand some tool or process they will be performing. The second is more subtle and involves communicating potential solutions to the customer. This second piece is very important because it pushes the customer to use his/her imagination to solve problems. Imagination, besides being an amazing exercise in creativity and plain old fun, is what helps to bring in the big bucks.

So, moving back to the testing article, I think that outside the programming side of being a consultant, this envoking of the imagination is something that is hard to find. What's more, no consultant that loves to code and is excited about technology will want to do it all the time. In fact an overload of "imagination envoking" could burn out a consultant faster than massive amounts of Javascript! The point here is that as we look to the future of services, if we can find a good way to keep the customer imagination pumping, then we can solve interesting problems and make the big bucks. This means keeping the people in the game fresh for getting folks thinking.

Last week I went to Huntsville, AL to do some training for a client. It went pretty well overall. In an effort to enjoy myself more when traveling for business, I made a commitment to try to eat well. I had a pretty cruddy steak at TGI Fridays, but the two beers that went along with it made up for bad food. The next night I went to the restaurant next door to the hotel. It mentioned something about "lonestar" in the name, so I figured it had to be awesome. Unfortunately, those folks who try to market to Texans don't feel the need to actually research what Texans actually enjoy. The result was YACS (Yet Another Cruddy Steak) and the worst "Texas" steak sauce I have ever had (produced in New Jersey no less). Less than amazing meals aside, the trip wasn't so bad, and even in the midst of my mediocre dinners, I found that I was enjoying myself.

The actual work portion of the trip went pretty well overall. The training sped by pretty quickly and the trainees were very interactive. I did learn a good deal about Frame, which is very good. There was one trainee who was not actually an employee, but a contractor for internationalization. He was a nice guy and knew a lot about Frame, although I kept getting the impression that he was trying to sway them from using ePublisher in a way. It was a strange situation because they were very happy with the product and what it could do, while at the same time wanting to find some other solution or not get locked in. All and all though, I think I made it clear that we try to provide an open solution that is meant to meet needs and not lock people into bad systems.

The worst thing about the trip was running into bugs. First off, before going into my rant on silly bugs, I should mention that everyone was blown away with the size of Quadralay as a company. They really couldn't believe that Quadralay was so small, and yet had such a complete product line. This fact alone put me in high regard as they came from teams of 30+ developers that produced less quality products. Back to bugs though... The biggest bug that I found was when working with a stationary in ePub 9.1. If I create a project from a stationary and add a document with a xref that was not available when the stationary was created, those xrefs will not be read and cannot be edited. This was a very frustrating bug that I was told had been fixed for 9.2. Nonetheless, it is very embarassing.

Embarassing as it was, bugs like this are not really that big of a deal. When I am sitting in front of a class as a developer, it is hard because I am seen as not only an expert but a creator of the product. They feel like they can simply ask, "Why didn't you do this right" because I am sitting right there. When this happens it is very frustrating to say the least. For one thing, our developers are my friends and smart developers! I hate to see flaws in their code exposed in a public and somewhat embarassing way. It is also frustrating because I make an effort to describe our application in a way that supports more business, so small problems make this hard.

As frustrated as I was at the time, a day or two later I realized that bugs just happen. Considering the robust and open nature of our product, our bug count is pretty low and fixes seem to happen very quickly. I also realized that most bugs are really just silly mistakes that are bound to happen. Programming is never a fuzzy task, so writing code that gracefully handles different requirements flawlessly is near impossible. My resolve is that next time I do training and run into a bug, I am just going to take the heat and smile knowing that it is probably fixed already!