Ionrock Dot Org

My Weblog

Enjoying CSS Frameworks

Traditionally, I'm not much of a framework guy. The big issue for me is that I don't like learning a framework, only to find out it is not going to work in the long run. Whether the framework actually doesn't work or I'm just avoiding it is arguable. One area that I've found frameworks to be extremely helpful as of late is in CSS. I used to really enjoy the idea of CSS, but now I dread it. Browsers make things hard and realistically supporting them all is a nightmare. Javascript is having something of a hey day primarily because there are a set of libraries that make the browser issues manageable. CSS frameworks make an effort to do the same thing.

Not researching very deeply, I've gotten the impression that CSS frameworks are somewhat controversial. If you don't understand how to use CSS, then don't hide it behind a framework because it will only bite you later. I'm sure this is true to some extent, but at this point in my life, I'm sick of messing with hard issues that don't matter that much. I want two or three columns and my text to line up right so I can move on. I gave the YUI Grid CSS framework a go and it made things easy, so I was done and could move on.

One negative I've heard about the YUI CSS framework is that it forces you to change your markup. This does kind of stink, but lets face it, if I have to redo the template, I'll change the markup anyway. I'm sure there are big enterprise problems and issues that have to meet some ridiculus requirements, which make this idea an issue, but I'm going to stay away those.

There are other CSS frameworks out there that I might look at sometime, but not anytime soon. I'm pretty happy with YUI. I'm also happy I found a good tool for getting rid of some of my CSS issues so I can move on.

Staying in a Terminal

Since starting with YouGov, I've had to get a little more serious about my shell usage. I've never been a huge commad line junky. It has never been something I avoided, but delving into intricate find, sed, awk and grep operations was never my forté. While I'm still far from guru status, I'm beginning to catch on. The big change for me has been using Emacs in the terminal. I could have used VNC or used a remote X session but it seemed like a better option to just get serious about my command line skills. Jamie is something of an inspiration when he starts vim-ing it up as well :)

It has been something of a challenge but now that I've started down the path of terminal enlightenment, I doubt there is a way to return to the world of GUIs. The best aspect of learning command line tools is that they not only help you to get a job done now, they can be helpful later in terms of small scripts or even applications. Once you take a little time to really understand the command line options and learn a few details, it is much easier retaining the information. Of course practice is also helpful!

Seeing as I like to keep my "work" environment the same, I've also switched over local development to a terminal session of Emacs. This was a bit harder to do since there are a few occasions where grabbing the mouse to explore some code can be helpful. That habit has been kicked pretty easily, although there are still times it would be nice.

Also, I finally got around to switching my caps-lock and control key. This has been very tough to get used to, but I think it is actually somewhat helpful. Before, I found that my pinky just sat on my control key the whole day. This put my hand in a somewhat awkward position, and eventually, my left hand started to hurt in a rather scary way. After a day or so of the switch, things started to get slightly easier. It takes a little more mental attention when typing, so I've paired my changes in keyboard mapping with pushing myself to become a better typist. Accuracy has always been my biggest issue when it comes to typing, so that has been the focus.

Python in Large Projects

Lately I've been thinking about my experiences as a developer learning new systems. Having done a little job hopping as of late, it has become apparent that there are many issues involved when learning a new system, especially when the system is written in a dynamic language. This all started learning an XSLT based system (with some C#), then Ruby/Rails and now Python. Before this, I worked for a company that had a relatively standard C# desktop application. Thinking back, I found it relatively easy to start coding on the C# application. I would find where the issue was happening and start working my way out until I found where a fix should be. I had an IDE to help me along the way and rather specific stack trace to follow. The language was the biggest frustration in that I felt I had to constantly be reading documentation and simple operations took a great deal of work. Python, on the other hand, has been the least of my issues learning this new system.

The hardest aspect is seeing how the different objects and data interacts within the scope of the system. It is a difficult detail to verbalize because in so many ways, the system seems clear. The problem is that with language features such as duck typing and in our case, utilizing exec, following the interactions becomes complicated. Also, at my current job, we have created specific languages for our users, which means that there is a further abstraction of taking the language and executing Python. While it is not insurmountable, it could feasibly be too difficult to do without an original author present to discuss the details. This is not because the code has issues, but rather simply because following the flow of data and the execution stack is just too difficult.

There is not an obvious solution to this problem but there are definitely ways to help work around the issues. When I wrote C#, I was able to follow the stack rather easily using Visual Studio. While this seems like huge win, that stack could be enormous and when a branch could have occurred, things became complicated. In Python, often times the stack has been very small and easy to manage with the difficulties being in finding where functions are and when they get called. For me, etags have been a very helpful way to find the code I'm looking for and it also helps a great deal in understanding the code base. In fact, Emacs' rgrep and tag search have made the physical challenge of finding code very manageable.

Past finding functions and classes, the hardest thing is finding couplings. When the original authors look at the code they see where aspects overlap and interact. Learning to find the relationships is a matter of communicating what variable names actually mean and what sort of patterns you might find within the scope of the design. What I mean is that there are often specific development patterns that are expected with certain objects. This is not always easy to spot because the patterns might rely on subtle requirements that have been developed, where to the untrained eye it appears to be a potentially unoptimized piece of code. These kinds of issues are largely a communication problem and as such have some obvious options for solving.

Communication is never easy, so there isn't an easy fix. Some obvious things to consider are comments and documentation. While these help, it can also make the code harder to maintain. As soon as a comment is out of date, it runs the risk of leading things in the wrong direction. A better option is simple glossary of variable names. This allows you to make a simple lookup file that can be queried for potential object types based on the variable name. It also can help in specifying a variable naming scheme that keeps the readability, while supporting discoverability. I'm sure there are many other means of helping to improve the learnability of large Python applications, so please leave a comment with ideas.

I Can't Play a CD?

Every once in a while I will realize I have some CDs that I haven't ripped yet. I'll take a minute to rip a few and enjoy the idea I've increased my digital music catalog. Today, The Pixies record Doolittle came up for ripping. I put it in my computer and nothing really happened. My drive spun, iTunes seemed to want to do something, but nothing came of it. Having used Windows for a while, I took a stab at ejecting the disk and trying again. No luck.

While I can't confirm anything, my guess is that the CD has some stupid DRM that is stopping me from using it on my computer. This is frustrating to say the least. Even if I just wanted to listen to the CD in my computer, I'd be out of luck. Nowadays, we don't even have a stereo. Instead we opted to just use an older laptop as something of a media station. If this had been a happening get together and everyone wanted to play ping pong while getting down to Debaser, the party could come to a screeching halt.

I see why businesses want to "protect" their investments. A business spends its time and money creating something of value in order to make more money. Allowing people to copy or use their product without getting paid hurts the business as well as everyone else who must make up for the lost revenue.

The problem is that there is a blurry line between protecting your investment and not competing. DRM is an effort to remove the requirement to compete in the market. The concern is that their product is not good enough to warrant being paid for, so measures need to be taken in order to stop competition. This is a bad idea of course because the consumer suffers and it lowers the bar in terms of product quality.

Thinking of the current state of the music industry, it makes me wonder. Are labels actually struggling for money simply because the quality of the work is poor? Is the real issue with the lack of money in CD sales the fact that the majority of CDs don't end up meeting the demand due to the quality? I'm sure this is a simplified argument, but it still seems at least partially true.

Music industry postulating aside, it was pretty frustrating my CD wouldn't play.

Why Computer Science

When I went back to school, I did not major in Computer Science. This has not ended up being a negative in terms of finding a job, but I do regret not taking Computer Science. My major did provide some advantages. I learned to make presentations, work on teams, organize a project and generally do many of things programmers are known to have difficulty with. The problem is, in my quest to become a better communicator, I ended up missing a good portion of the raw skills that would have most likely been more helpful.

The biggest aspect I think I missed out on was the typical "hard" CS course. I never really had a defining course that blew my mind in its difficulty, while opening my eyes to a higher level of thinking. Many folks say things like operating systems or algorithms is this kind of course, so it is no wonder that these are two areas that I feel lacking.

The grass is always greener on the other side of the fence. I've met many computer science people who have no clue as to what programming is really about. They simply press F5 in Visual Studio. Little do they know that their tools almost always function through a command line application that could be used without a bulky, 60 second loading IDE with Intellisense. So, in some ways, I'm glad that my schooling did teach valueable lessons such as version control, project management, and presentations.

Things are definitely going well for me, so I really don't have any room to complain. I work for a great company doing something I love. What's more, is I get to work from home and keep a relatively flexible schedule, which helps trying to keep a musicians schedule. So, if I had to do it over again, I'd probably have done Computer Science, but seeing as things turned out OK, the bigger point is to make your own luck by working hard doing what you love.