Between my work, traveling back to home and frequent power cuts, my blogging hasn’t been very regular recently. I haven’t been suffering from any sort of writer’s block, in fact I have a list of about 7-8 topics that I’d like to write about. However there has been one thing that has kept bothering me for quite some time: the size of my postings. I’ve been trying to use this blog as a way to tell the world about the things that I learn and discover as I pursue my career as a computer science student. However many of the things that I deal with daily and which I think about are quite complex and takes long discussion to get everything together. At the same time I would like to be able to post new things everyday or at least every alternate day. Often these two things don’t really go together add being an avid reader myself, I understand that it can be very trying to read something long on a topic like computer science. Hence the question: do I write small compact blog posts on a regular basis, or do I write longer essay-style posts where I can talk at length about the topic?

I’ve been looking at some of my favorite technology oriented bloggers to possible solutions to my dilemma. My favorite bloggers is Steve Yegge, who without fail writes long, sometimes rambling, but always interesting essays on an approximately bimonthly basis. While I find his essays thoroughly entertaining, they are a bit too big for something that I would want to write. More importantly, I certainly want to post more regularly than twice a month. Paul Graham’s essays are somewhat shorter, but are also published at a similar frequencies. Again, brilliant, but not quite what I’m aiming for.

Perhaps the closest to what I’m acheiving would be Jeff Atwood’s Coding Horror. Atwood posts regularly (almost everyday) and his posts are of a good length, long enough to make you feel a sense of actually reading something worthwhile, while being short enough that you don’t need to set apart an entire hour to go through them. Though occasionally he does err on the side of excess, they are nowhere as long as Yegge’s posts.

Of course, length isn’t a separate consideration in itself. It’s closely tied to the content of what I write. Recently I’ve been writing more from a software engineering standpoint, though I would like to write posts of a slightly more theoretical nature (especially since I’m getting increasingly interested in compilers and programming languages). While I’m willing to accept that such topics might require slightly lengthier posts, I really don’t want to turn my posts into mini-theses.

Long blog posts also mean longer time investments on my part, something that is a very important consideration because of the heavy course load I plan on taking. Perhaps the best way for me to decide the issue is to think about how much time I would be willing to invest on a daily basis. On average a blog post right now takes me about 40 minutes to one hour to write. I think that it is a good amount of time for me to spend write now. Considering my typing speed, that translates to about 1000 thousands, even considering looking up pertinent links and confirming information. 1000 words might be pushing it a bit, (that’s about one average sized college paper), but much less would probably be too small for me to clearly say everything. 800 to 1000 words seems like a decent size from what I’ve been reading. I think a good idea would be to to have a number of sections which are more or less self-contained in terms of content.

I’m going to trying to work on trying to control my size and structure. However at the same time, my primary concern will be content, so even if I need to write longer or shorter posts to give a coherent, well paced account of everything I need to say, so be it. I’m sure my readers read other tech blogs, so any comments as to what you prefer would be good very much appreciated.

Ubuntu and desktop Linux have come a long way in the past few years. Ubuntu is currently one of the most popular, if not the most popular distro for desktop linux users. It was my first distro and though I no longer use it, I’ve always acknowledged to be a well-polished piece of work and I always recommend it to people who are just starting on their personal Linux journey. Like most other things in computers, getting used to a new operating system is made easier if there is a good source of documentation available. Beginning Ubuntu Linux, published by Apress is a particularly good example of documentation geared towards to the new user. I’ve reviewed the previous versions of the book and I find that the books have kept improving just Ubuntu itself.

One of the things that makes this book particularly appealing for me is that it starts out with a brief but informative review of the philosophy and history surrounding Linux and Ubuntu. I personally believe (and I think that many other Linux users share this) that there is much more to Linux and open source software than simple technical excellence. It is a way of thinking and acting that I find very appealing and which I wish others to understand. This book does its part in helping new users understand the culture that gave rise to the software that they will soon be using.

The book continues the practice of understanding that most of the people reading it will be Windows users. As a result the chapters dealing with installation also tell users how to properly back up their data and how to smoothen the transition. The guide through the actual installation process is also very in-depth and well written. Partitioning is often the most confusing part of the installation for a new user. I’m glad to see that partitioning has been dealt with very well with all the options in the install process carefully explained and the pros and cons weighed carefully. The chapter dealing with common installation problems is as good as before but now includes information on more than just installation problems. I particularly liked the section on how to deal with resolution and other common graphics problems since these can be very frustrating if not dealt with properly.

Once installation is complete the book goes on to describe with an equal amount of care how to perform various day to day tasks and how to customize your system. The section that deals with Linux equivalents is also comes in very handy for new users who just want to be pointed quickly in the right direction. The book geos beyond describing simply the core operating system and the user interfaces. Of particular note are the sections devoted to how to use multimedia systems. You’d be hard-pressed to find a computer user who doesn’t have a substantial collection of various music and video files and this book helps newbies get up and running with minimal effort. This new edition keeps the sections on using OpenOffice and the BASH shell but adds substantial material regarding the new automatic multimedia setup, the 3D graphics effects that have the Ubuntu desktop much more visually appealing and also on security and encryption. There is also a mini-tutorial on using the GIMP for basic image manipulation which I think shutterbugs will find handy.

The last part of the book is devoted to slightly more advanced topics such as package management, backups and automation and remote access. Personally I feel that package management deserves a more central place, right alongside installation, but the book’s modular structure means that this isn’t much of a problem. Overall the last few chapters act as a springboard from where newbies can start another journey to the level of power user and beyond.

The book as a whole is well laid out and material is clearly separated. The use of sidebars and small tips and warning sections means that a good amount of extra information is presented without interrupting the main flow of the text. There are also lots of links to other information sources where the interested reader can go to for more in-depth information. Most of these are freely available online sources and the full URL is often provided resulting in minimum effort for the reader. For Windows and Mac OS X users there are also pointers to third party tools that might make migration easier. The book is replete with high-quality black-and-white screenshots which add to the complete guide experience that the book provides. The third edition updates everything to be in sync with Ubuntu 8.04 and comes with a double-sided DVD containing a ready-to-install image on one side and various ISO images of the Ubuntu derivatives on the other. In essence the book has everything that a user would need to get up and running with Ubuntu.

The book is at a reasonable price of $39.99 and I think it’s a good investment for anyone looking to jump into the world of Linux. Even though you’ll get the most from this book in the first few weeks after installing Ubuntu for the first time, the later parts of the book will serve as a handy quick reference for those types you find yourself needing to dig under the hood. There is certainly a large amount of information online which means that books of this type are not strictly necessary, but at the same time it can make things a lot easier to have a quick reference close at hand. My litmus test for this sort of this sort of product is generally: would I give it to my mom? This time the answer is yes.

By the time you read this, I will probably on my 16-hour flight from Newark, USA to Mumbai, India. Though I rather like flying (I like machines in general). I don’t really fancy being stuck in a small cramped space with lots of other people for long periods of time. Why can’t the laws of physics just be simple and allow cheap instantaneous teleportation between arbitrary points? Anyway, enough bitching and complaining on my end, I’ll save it till after the flight. Even though I’ll be stuck on a plane for 16 hours, I do not intend to waste all that time simply getting bored. So here is a list of things (in no particular order) that I might try to do during the flight.

1. Sleep

Come on, you don’t seriously expect me to be at my productive programmer best on a plane do you? A nice airport waiting room, maybe, but not on the plane. Let’s face, despite my love of flying after an hour or two I will want nothing more than to land. So I will try my best to sleep through as much of the flight as possible. Unfortunately, I’m not much of a sit-up sleeper so I don’t know how much of my time will actually be spent sleeping liking a baby. Speaking of babies, I sincerely hope there aren’t any babies near my seat. I like babies, but not near me on a plane.

2. Read

The all time classic timepass activity. Now the question is, what? I don’t have many fiction titles at hand and the ones I do I’m not inclined to read on a plane. I would consider taking something I’ve already read before and know I like, but from past experience I know that’s not a good idea. My choices right now are between a number of really good popular-science type books that I’ve been wanting to read, but haven’t gotten around to, or one of the equally well written computer/science engineering books that I need to take along. I was seriously considering taking SICP, but I’ve found that the best place to read that book is in front of a computer with a Scheme interpeter open so that I can work through the examples as they come. I could do some paper programming, but the tray holders aren’t very conducive to having a book and a large-ish notepad open at the same time. And it is simply an exercise in frustration to paper program on small paper. I’ll probably take up Roger Penrose’s The Emperor’s New Mind and something else a bit lighter.

3. Design

My research project is somewhat stagnated at the moment and it’s fairly obvious (to me at least) that we need a new design to control all the things that are going on and are likely to happen soon. I think some time of my flight at least will be spent thinking about this design. If I have space left over I’ll take the Design Patterns book because I think I’ll be using some of those patterns to come up with a working design. And it’ll be nice to be able to think without being near a computer for a change. The control language we’ve been using will also need some fairly heavy changes, so that’ll be something else (which I am more familiar with) that I’ll have to think about.

4. Plan

I’ll be starting sophomore year at college soon. This year is going to be interesting. Not only am I mostly done with all my mundane requirements, I’ll be involved in some research throughout the year and I plan to take a self-designed independent study. I need to do some thinking about the study and also about what new languages/technologies I want to learn. I read Steve Yegge’s 10 predictions today and I think I’ll also try to make some sort of predictions regarding the state of the computer world for the sole purpose of seeing how much I understand the things going on around me.

5. Draw

Like many children, once upon a time coloring used to be my favorite sport. As a programmer I’m often doodling design diagrams and pseudo-flow-charts and other random interaction stuff. I might just feel inclined to try and turn on the creative juices a little. I’ll probably be doing a fair amount of doodling as part of my designs, but I don’t have to stop there.

6. Music and Podcasts

I’ll make sure that my iPod has a full charge which will easily last it the whole flight and more. I have a good 10 gigs of music and 10 episodes of the Stack Overflow podcast to listen to and I hope all that, if nothing else, will keep me partially alive. I might even look around and see if I can find some more interesting Podcasts and audiobooks. No, I won’t consider movies, because I can see absolutely no point in watching a movie on such a small screen.

7. Sit and stare

Yes I’ve done this on my last flight and it’s actually quite easy. You sit and you stare, that’s it. You don’t have to look at anything particular and you don’t have to react to anything either. Of course if you’re doing this, you’re probably in the last stages of boredom before it becomes terminal and chances are you’ll need rehab once you land (lugging heavy luggage sometimes helps). I’m certainly hoping I don’t get to this stage, at least not until I get to the part where we have to buckle down for landing and there is really nothing else to do.

Once I’ve landed and have sufficiently recovered thanks to my mother’s cooking, I’ll list all the things I actually did, that is, unless I’m in boredom rehab. I do hope it won’t come to that.

When I showed off Firefox 3’s smart address bar to a friend of mine a few days ago, his first reaction was: “Wow, that’s cool” and half a smile. A second later the smile was gone and he let out a disappointed “Oh but that’s going to take up so many resources”. Let’s leave for the moment that my friend was not the tech-savviest person in the world and that he would probably not be able to list exactly what those “resources” were supposed to be. What his remark got me thinking was simply: “Is it really a bad thing if my software takes up many resources?”

I suppose the core issue here is that computer users don’t really care about resources. Most of my friends wouldn’t be able to tell me the specs of their computers and much less what those specs meant. What they are interested in is quite simply, speed. They want their software to be zippy and fast, so do I, so does everyone (I hope). When my friend said that Firefox 3 would take up more resources, what he really meant was “My computer will run slower.” He quite innocently equated less features to mean lightweight and hence faster. It’s an honest mistake, but that doesn’t change the fact that it is not really correct. Tweaks and customizations to programs can often increase actual program size and complexity but give better performance. Apple has been doing with OS X for years now. Many users and benchmarks will vouch for the fact that though OS X has been gaining features, it’s also utilizing computer resources more efficiently.

Of course, it’s undeniable that the general trend is towards programs that use more resources. After all, more resources does mean more maneuvering room, more stuff to build with. And resources to keep increasing. Our computers today are vastly more powerful than those available at even the start of the decade. And we’ve been reaping the benefits with more sophisticated software: better visuals, increasingly powerful desktop search and increasing higher resolution data formats.

At the same time, many people both programmers and not, are becoming increasingly worried that modern software is bloated an unwieldy. Just as Moore’s Law has been giving us faster processor, our software acts as a Moore’s Law Compensator. Our computers still take a long time to boot up and become usable, most programs don’t start in the blink of an eye, in essence, somehow the user doesn’t really see all the power that’s tucked under the hood. This has led to a growing trend in lightweight software, especially in the more tech-savvy community.

Among Linux users this dual nature of modern software is very evident. On the one hand Linux systems can now sport powerful 3D window managers and task switchers good enough to rival Vista or Leopard. On the other hand, there have been a wave of new minimalistic window managers lacking ant graphic splendor whatsoever.

I feel myself personally affected by this double trend: I myself use a tiling window manager called Awesome. I shun IDEs, preferring to use the very lightweight Vim from a simple terminal. Firefox is just about the only graphical program that I run. At the same time, I love OS X Leopard. I think the UI is quite beautiful and I’ve become an avid user of both Expose and Spaces. Not to mention the fact that somehow fonts seem to look much better on OS X than on any other operating system I’ve ever used. Performance-wise OS X is much better than Vista which takes much longer to start up and respond on a far superior system.

Being a programmer myself, this issue is particularly important because I think about performance almost all the time. Whether it’s deciding whether to use a high-level language like Python, or lug it out with something closer to the metal like C, or which graphics toolkit to use, I have to factor in resource-use. I’m still not sure about which way is better. Software bloat is bad. Very bad. At the same it doesn’t make much sense to let all that computing power sit there unused and the benefits very often outweigh the price to be paid. For the time being, I’m calling it a truce and letting the decider be something less tangible than performance benchmarks: user experience. If you can use heavy resources but deliver a solid user experience, then go for it. An incomplete user experience for the sake of a lighter program might be occasionally justified, but not all the time. However a bad user experience along with heavier system requirements is definitely a bad thing, to be avoided at all costs. After the best software is not the one that uses least RAM or has the prettiest interface, it’s the one that gets the job done without getting in the users way.

If you’re a computer science student like me, then you probably write a fair amount of code. Depending on your coding style you probably write a fair amount of comments too. But do you write about your software or do you just write your software? Chances are you don’t. College computer science courses aren’t exactly writing courses (no matter how much typing you do). While part of a project may involve documenting the concepts behind your program, or why you made a particular design decision, you hardly ever write something like a manual for your software. However, if you’re planning to write production software at some point, especially if you’re thinking about creating something independently or as part of an open source project, then writing a manual might be more helpful than you think.

Writing a manual is more about than just putting together instructions on how to use your software. It’s important to put yourself in the place of someone who will be using your software (and is probably not a programmer). For you your program logic makes perfect sense (if it doesn’t, why is it even there?) but sometimes what makes sense from a programming point of view isn’t quite so simple from a user point of view. Looking at your program from a user’s point of view let’s you think in terms of what’s really useful and necessary rather than what’s easiest to program. Writing a manual is a good way to put yourself in the user’s seat.

The first things that come to mind whiel writing manual is the user interface. How is easy is it to do simple tasks? Where are the most important parts of your UI located? Is their a general cohesiveness in the way things are put together? Are there some things that you know your program is capable of, but are almost impossible to do due to the UI? Theses are all questions that directly affect how your users’ experience. And so they are top priority. If you find yourself taking up two pages describing something that the user will be doing dozens of time each day, then something needs to be changed.

A critical review of the interface will lead to deeper program logic. Are things which appear close together and related in the UI similarly close together in the program? Are the UI and the program logic equally clear and intuitive? Are you unintentionally exposing internal structure to your user? While writing the manual you should keep an eye out for any bad designs, you should also be thinking about missing or broken features. While that doesn’t mean you should implement everything that comes to your mind, sometimes some features are useless without supporting features. After all, your clients aren’t interested in the features themselves, they want to get their work done. If you find yourself writing about how not to do things or what can’t be done in your manual, rather than how to do them, then your program probably needs more work.

Having a written manual for a small art program, I’ve realized that there’s a fairly direct correlation between ease of use and ease of description. If you can explain a function and how to use it in a few lines, it’s probably mcuh better implemented than a description that takes up half a page. The first version of my program was a fairly tedious text-based program which went out of style around the same time as Apple BASIC stopped shipping. The descriptions for each option and how to get to them were equally complicated. Putting together a simple GUI not only made interaction easier, it also choppped down the interaction part of the manual to a few bullet points.

However, when you’re writing a manual it’s fairly easy to write from a developer’s perspective. After all, you have the guts of your program in your head, and you probably already know half a dozen unobvious little tricks and workarounds. You’ll either forget to put them in the manual or you’ll remember and think that they’ll make as much sense to others as they do to you. Chances are they don’t and you really don’t want to be putting workarounds in your manual if they’re hiding a bug. Fix the bug and then write the rest of the manual.

I’m starting to think that all students should at least once have a project that requires writing a user manual for non-programmers. Years of writing code and tearing through algorithms can make you think very differently from the average office worker using your program. It’s necessary to get in touch with your users and how they’ll be using what you give them. So the next time you write your great new world changing program, take a few hours off and write a manual for it.

As my research project continues our software is gradually growing more and more features, and we’re adding new functions almost everyday. While it’s certainly a very good feeling to be adding functionality, it can also get ungainly very quickly. About two weeks ago, Slashdot posted a very interesting query by a person interested in doing a PhD on software design principles. Since then, I’ve been giving more and more thought to the role that industry-style software engineering principles play (or should play) in computer science research.

Research in science has been mostly held to be separate from engineering. Chemistry research is not performed in quite the same way that chemical engineering is. Even in cases where there is significant amounts of high technology equipment is used (the LHC is a good recent example), the engineering teams are separate from the scientists. However, computer science is not really a typical science at all. Research in computer science faces many of the same problems that software development faces:

• Multiple people working simultaneously on large and growing codebases (team management).
• Adding or removing features without requiring major rewrites (extensibility).
• A way to collect large amounts of data and detect failures (testing and error logging)
• Having multiple copies of the experiment running, with different parameters (scalability and version control).
• Last, but not least, the experiment should actually work and produce results (in corporate terms, the software should ship).

Keeping the similarities in mind, what lessons can we as researchers learn from industry techniques and practices (by industry, I mean open source as well)? I’m not sure what other researchers do, or if there is some sort of standard procedure, so I’ll just talk about what my small team has done to make our work easier.

Divide and conquer:

The first thing we did was to carve up the various parts of the project. While my two teammates took up the core engine and the output system, I chose to deal with the human interaction part. At the same time. we had regular meetings where we planned out how our parts should interact as well making high-level descriptions of what each part of the code should do. This meant we could each develop our code largely independent of the others while still having a fair idea of where the whole project was going.

Throwing away version 1:

Though our first version was a working program, we made it keeping in mind that we would probably have to change a lot of things, possible even rewrite it. As a result, we developed it quickly, and focused on making it “just work” without adding too many features. This allowed to get a good feel for what the rest of the project would be like and let us make important decisions before we had invested a lot of time into it. In research you often don’t know what you’re looking for until you start looking, and this was the case for us. Our throwaway version gave us a better idea of which direction our research was heading, what concepts had been explored before, what was new and how difficult various aspects were.

Strict Version control:

Right after we started working on our post-throwaway system, we moved all our code to a Subversion repository on our college’s research cluster. We do are own work in our working commits and perform daily commits and updaes. Our repository is also divided into trunk, branch and tag directories to keep separate the most recent copy, older releases and other milestones. This way we can see the evolution of our project at a glance more easily than having to check out older versions. This comes in particularly handy, since being a research project we tend to be looking at what we did before and what results we got rather regularly.

Coding conventions:

Another post-throwaway decision was regarding coding styles. We fixed general naming and commenting styles, decided on tabs vs. spaces (4-space indent, in case you’re interested) as well as a number of minor things that weren’t project-threatening, but could have led to unnessecary confusion later on. We also keep detailed records of how we’ve changed our codes and any bugs we’ve introduced/fixed on a common wiki meaning that everyone is always up-to-date on changes.

Personal freedom:

By standardizing some aspects of our project, we’ve been able to have greater freedom as individual researchers. All our code is in platform-independent Python. Besides that our only other common tool is Subversion, which is also freely available and easy to use. By choosing open source and platform-independence, we have been able to have three developers work on three different platforms using different editors, IDEs and SVN clients. We can work equally well on our own machines sitting in our rooms, on the computers in our CS department’s labs, or even from the Mac Pro computers in the Arts buildings via SSH. It’s hard to quantify how much easier this independence has made our work. This has meant that we didn’t have to rush to the CS Lab’s whenever we had a thought or problem and we could whenever we wanted, however we wanted as long as we stuck to some simple rules. Scientists and programmers both need a certain amount of freedom and we’ve been able to secure this freedom by a proper choice of tools and techniques.

Things to do:

It’s been almost four weeks since we started using software engineering practices for our research work. We don’t know how things would have turned out had we not implemented the practices that we have. However we have come to rely heavily on the framework and guidelines that we have built for ourselves. At the same time, we’ve come to realize that there are parts of our project that could benefit from adopting some more industry-standard practices. I’ll end with a brief list of the things we plan to implement in the next few weeks:

Robust error handling: We’re currently using some very ad-hoc methods to handle errors and track down bugs. But we’re in the process of building a flexible, yet robust error handling and reporting system into our project. Since we intend our tool to be used by non-programmers, we need to implement a system that won’t mean looking at the code everytime something goes wrong.

Flexibility via a strong framework: Our work has turned out to have more applications than what we originally intended for it. As a result, we were considering forking our code into two separate branches. Though we still haven’t reached a proper decision regarding this, I’ve personally been trying to redesign our project into a “framework + dynamic modules” system. This is purely a software engineering effort, since it will mean a lot of refactoring and restructuring, but will not have much of an external effect rather than making our job easier.

Unit testing and other automation: Till now, an important part of our work has been getting user feedback, partly because our system is very visual intensive and also because we weren’t quite sure what we were looking for. Now that we have a better idea of where our project should be headed and what we should be looking for, we can begin to automate some parts of our work. However we won’t just be checking for bugs, but rather generating a large number of results and then further improve our system to get what we want.

I’d love to hear from anyone who’s been involved in computer science research projects and has opinions of how to use software engineering principles to make things easier/more effiicient.

For the past few days, I’ve been looking into Apple’s Cocoa infrastructure in some detail. The reason once again stems from my research projects. All our code is in platform-independent Python meaning that we can develop on any of the 3 popular operating systems and then run on any others. This has been a great advantage since the three members of our team each run different OSes. For most of the time our project was purely command-line and text input based, using graphics only for the final display. However we have now come to the point where we need to fork our system into two different systems: one for architects and one for artists. How each program will develop is something that we will work on over the next few weeks, but one thing is clear: for the artists at least, a purely textual interface will simply not do.

Till now our system had been accepting an instruction file as input. While this method of using a instruction was very powerful (we could essentially embed our own programming language), this not the direction we want to go with the artists. And besides, not every artist wants to sit down and right pages of instruction to draw a picture, we might as well ask them to write the program themselves. It would be best to create a GUI for them to use. Even before this had been clear, I had written a simple interface that was essentially a text editor containing a hook to our Python backend. It was written in Tk, was exceptionally ugly, but got the job done.

Now I think the Tk toolkit is capable of letting me create the entire GUI interface that I have in mind and it will be cross platform as well, but there’s one problem: it’s ugly, especially on the Mac. I think this is because the Python Tkinter version doesn’t use Aqua (like Tcl/Tk), but rather uses X11. Though I spend a lot of my time in Vim and at the command line, I’m still a fan of good looking user interfaces (see my last post). As a result I would feel rather guilty about making something that I know would look bad on the platform it would be used most. So like a good programmer off I went to find a solution.

I thought I would be able to use Cocoa to create a front end, especially since Xcode now has support for the PyObjC bridge. Unfortunately this has turned out to be much harder than it at first appeared. Cocoa is Apple’s very powerful object oriented API. It is almost everything you will ever need to create a Mac application. While it allows to create native applications by leveraging the powerful infrastructure Apple provides you, it also doesn’t allow you to perform the sort of rapid duct-tape styling programming that Python and UNIX encourages. In Python it’s very easy to write your core application in Python with any number of GUI front-ends that are easily interchangeable. Cocoa, on the other hand, is not another GUI toolkit that you can simply add to the mix. If you want to use, you’ll have to invest a certain amount of time in learning your way around.

Python can’t communicate with Cocoa directly. To  have your Python programs leverage Cocoa, you need to go through the PyObjC bridge. Though the bridge is certainly effective and I could use it, I’ve been having troubles finding decent documentation. Apple’s own tutorial is the sort of document I’m looking for, but it is dangerously out of date. Lacking a proper tutorial, I would have to figure out a lot of things on my own. Once again, a large time investment.

Considering that I have only two weeks left to make real progress on my project and that learning Cocoa or Objective-C was not my original goal, I’ve decided not to pursue that avenue at the moment. I would certainly love to learn Cocoa at some point in the future and PyObjC seems like it could become a very powerful tool. But I simply don’t have the time at the moment. I am going to start working on a proper GUI interface in Tkinter. Perhaps sometime later this year, I’ll get back to some Cocoa.

I installed Firefox 3 yesterday on both my old G4 Mac and my Windows laptop. Arch linux, which I normally use doesn’t have a package for it yet. Firefox 3 has a number of new features, which are being talked about on almost any random technology site, so I won’t bore you with them. I’ll just focus on one thing that I like: the changes to the user-interface.

Firefox 1 and 2 sported a UI that seemed to be uniform across platforms. However this uniformness across platforms also meant that Firefox didn’t quite look like the other applications for the platform. This isn’t really a big thing, especially considering the horrible UI inconsistencies introduced in Windows Vista. But at the same time, it’s little touches like this that can make or break an app. Sure there were skins, but you really want something like that to builtin. One of my favorite pet peeves was regarding Firefox 2 on OS X. The buttons for various web apps like Gmail or the Google search page’s search button would show up as ugly Windows 95-ish rectangular boxes rather the sleek Mac buttons. It was something that really irritated me, since I spent a lot of time in Gmail. I’ve been glad to see that the new Firefox fixes that and adopts a very native look and feel.

I also upgraded my G4 Mac to OS X Leopard today. I had been putting it off since it has only a 1.25GHz processor and less than a gigabyte of RAM. However, it turns out that my fears were mostly unfounded. It took about 20 minutes to install and it runs as fast as Tiger did. The only noticeable difference is that the boot and login times are somewhat longer. But considering that I rarely logout or shutdown, that isn’t really an issue at all. I’m surprised by how Apple’s development takes into account older machines and actively works to extend their lifetimes. This stands in sharp contrast to the effect that Windows has as the Great Moore’s Law Compensator. In fact I will go as far as to say, that some things actually run better on Leopard than on Tiger, the Leopard-Firefox 3 combo in fact seems to very capable.

On Tiger I always experienced Flash videos being somewhat choppy irrespective of what browser I used. That problem no longer exists on Leopard. Furthermore, the UI changes to Firefox fit right in with the overall darker look that Leopard sports. I’m really looking forward to using Spaces, which should come in really handy as I start doing Cocoa application development. I was also impressed by how little impact Spotlight scanning the disk had on performance. I would never have known it was going on if I hadn’t tried to use it. There are some features of Leopard which I won’t be using such as Time Machine ( I have a homegrown SVN backup system), and that will probably mean my system won’t be under a full load anytime. If it turns out that my system can’t handle (considering that I’ll be using Xcode fairly heavily), adding a gigabyte of RAM might help speed things up. I had been considering buying a new Macbook to last me until the end of college, but it seems like my current machine will be all the Mac I’ll need for a few more years (or at least until Snow Leopard hits the stage).

I’ve just returned from meeting one of our clients for my summer projects: a professor in my college’s art department. What we have developed over the last three weeks is essentially a way to stitch together fixed images into probability-controlled tilings. However, it turns out that what our artist friends really need is more fine grained image control. They want to be able to create much more interesting patterns combining both images and geometric patterns. As I was explaining how our program worked, I realized that our instruction language model was rather complicated and not really suited for what the artists needed. So it seems, that our program is really not a very good match to what the artists need.

At this point, there are a number of things we could. We could go back to the drawing board, start from scratch and rewrite our system according to what the artists need. We could also try to build in top of our existing program and try to add and modify it to bring its functionality close to what we need. However, we need to keep in mind, that we had also planned to use this system to create a automated urban planner. We still haven’t met with the architect yet, but it seems like our system might be a better fit for what she needs. But that doesn’t answer the question: what do we do?

Now if this were a real software project with a delivery deadline, this state of affairs would probably be a very bad thing. Luckily this is still very much a research project so there’s quite a lot of leeway. Unfortunately, we’re still not quite sure of what exactly we have to do. It seems that our general architecture is still valid and will work, however the details will have to be remade. We’ll need a new way to generate the patterns from the instructions, simply stitching together images won’t do. It is possible that we will need multiple drawing systems working on top and parallel to each other. The instruction language also needs to be changed to make it more suitable to the artists’ need. We currently have a system that is geared towards placement of individual large scale elements, and nothing that deals with simple pattern generation. Ideally we would need a blend of both.

At this point, it’s easy to get disheartened. After all, we’ve spent almost 3 weeks creating something that we just learned is pretty close to useless. On the flip side, we are certainly not going to get bored. From a personal standpoint, this has still been a success, I’ve learned about parsing methods and language design. The experience that I’ve gained will make it easier for me to help develop a language that is powerful enough to express everything that the artists want to, while not requiring them to spend days learning it. It also means that the next version will also hopefully be developed much faster and more smoothly than the previous two versions. I am going to make it my personal project to see how fast and efficiently we can develop subsequent versions.