It's Time

I spent all day watching Golden Girls. Don't judge me. I think it's time to go back to work.

The Joys Of The Craft

Perhaps my favorite programming quote is this one by Fred Brooks, author of The Mythical Man-Month:

"...There is delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures..." 

- Fred Brooks in The Mythical Man-Month

If you haven't read The Mythical Man-Month, I really recommend you do. It's a fantastic read for software engineers. It's funny that it was first published in 1975, and yet its completely relevant today. The problems Brooks describes in the book can still be encountered in the software development world today.

Christmas Upgrades

I spent a good chunk of Christmas installing Windows 7 on my parent's ancient machine. In hindsight, putting Windows 7 on a machine this old was probably a bad idea. The Ethernet controller didn't have drivers for Windows 7, so we couldn't connect to the internet for a while. I had to do a lot of sketchy things with drivers to get it to work. After we got internet, Microsoft Updates downloaded all of the other missing drivers, and this fixed most of the issues. Unfortunately, one of those updates also screwed up the boot disk image. :/ Not impressed. After a little more black magic from the recovery disk, I think we're back up and mostly working. Hopefully, I can figure out all the outstanding issues tomorrow. I hope my Ubuntu install goes smoother.

In other news, Dani visited with her family this morning for brunch. It was nice. :) I am going boxing day shopping with them at 7am tomorrow. Crazy, I know. Maybe I'll pick up a new USB stick or something.

Anyways, Merry Christmas! I hope you have a great holiday season!

Exceptions in Java

Java has two types of exceptions: checked and unchecked. Unchecked exceptions are the traditional exceptions you see in languages like C++ and C#. Checked exceptions are essentially more explicit versions of unchecked exceptions. Checked exceptions require that the developer explicitly declare what exceptions a method could throw. The compiler will then enforce methods higher in the call stack to either catch the exception, or propagate it to a higher level.

Checked exceptions are a feature specific to Java. It was introduced into Java as an experiment, and the general consensus from developers is that the experiment failed. This is probably why no newer languages support them.

What's the problem with checked exceptions? They seem like a great idea in theory. They allow the code to be explicit with all error handling code, and make it impossible to forget to catch an exceptions. Unfortunately there are a lot more drawbacks with checked exceptions.

My main issue with them is that they clutter the code quite a bit. There is a lot of extra noise that goes into your code when you use checked exceptions. Not only does this make the code less readable, but it slows down development. For instance, you should not have to catch every single exception when you are writing test code or quick prototypes. A lot of the time, developers will just "swallow" the exceptions with empty catch blocks, because there is no intelligent way to recover. Does your tiny app really need to catch OutOfMemoryExceptions around every statement that might allocate memory? Even if you do catch it, how will you gracefully recover? The extra verbosity becomes noise that clutters the program's logic.

This argument reminds me of static typing vs. dynamic typing. If you choose static typing, you lose some flexibility, but gain some extra static analysis from your compiler. The same thing applies with checked exceptions, however the benefit they offer isn't worth the inflexibility.

What are your opinions on checked and unchecked exceptions in Java?

Introduction to Genetic Algorithms

Here's a nice little introduction to Genetic Algorithms. Although the problem they solve (generating "hello world") is rather silly, it's a good introduction to the world of Genetic Algorithms. If you are interested in the topic, you should check it out.

This is another good article. Again, this problem (solving N-Queens) isn't the best. A deterministic algorithm can solve the problem much faster.

The best problems for Genetic Algorithms are ones that don't have known optimal solutions. Another important property is that partial solutions can be crossed over to make a better solution. Without this property, your genetic algorithm will essentially degenerate to randomly guessing at the solution. In fact, I'm curious to see how much better some Genetic Algorithms perform when compared to a random algorithm. You can generate a lot of random guesses while a Genetic Algorithm goes through a generation.

It would be cool to make an app that allowed you to encode genetic algorithms without using a traditional programming language. Instead, the user would use a simple, domain specific language to encode the genetic algorithm. Then the program would be able to automatically calculate and display run statistics. Perhaps this should go on my Pet Projects queue.

End of Exam Plans

Tomorrow is my last exam. DB can die. Rawr!

Plans for Dec 22 6:30pm - Jan 03 9:00am
- Clean Roslin House.
- Play a lot of video games. :)
- Play with Toronto friends.
- New Years with Girl.
- Do Christmas-y type things with my parents.
- Play with GWT more. It would be awesome if I could apply it to some project, but I don't have any pet projects to work on right now. :/
- Finish that git book. Git seems pretty nice, after reading all the literature. Before I was blindly using it without knowing any of the theory.
- Finish that SE course.
- Find a nice little genetic algorithm challenge for Willis and I to do. We want to see who can create a better GA for some problem. Should be a fun little project during our work terms. Any ideas?

What are you guys going to do after exams? Presumably a lot of you are already done. Waterloo drags on with exams forever. *Sigh*

Inheritance vs. Composition

For a while, I've heard people say things like, "always prefer composition to inheritance". Today I looked into this argument more. Turns out the real argument should have been "Don't use inheritance at the wrong times". Durr. Essentially, this boils down to the "Is-a" vs. "Has-a" relationships we all learned in whatever Object Oriented 101 course you took. If two things share an "is-a" relationship, you can use inheritance. If it's a "has-a" relationship, it should be included through composition. For example, a patient has an ID, and a patient is a person. Following this rule will get you out of most of the problems with using inheritance wrong.

Another, perhaps more important, thing to consider is the Liskov substitution principle. It basically says if I have class D derive from class B, I should be able to replace all instances of B with D anywhere in my program. The program should behave exactly as before. If it doesn't, D should not have inherited from B. An implication of the Liskov substitution principle is that "is-a" really means that every method in the base class applies to the derived class. That is, if all birds can fly(), and a penguin cannot fly(), it shouldn't derive from a bird. For development purposes, a penguin is not a bird.

Another place where inheritance is probably inappropriate, is when you create linear inheritance chains. This is simply there to anticipate change someday, but it complicates code unnecessarily today. Merging the classes would be simpler (and by extension, safer) today. You can break them up again when you actually need the hierarchy, and it will cost just as much then. The difference is that you pay the price (in both time and complexity) only when you need it. I've talked about this issue before.

Anyway, I should probably go back to studying for exams, instead of watching Software Engineering lectures at French universities. La la la.

Health Analytics Challenge

The Heritage Provider Network is offering a $3 million prize for an algorithm that can predict future hospitalizations based on patient data. This seems like a very cool application of machine learning. If I knew more about machine learning (or anything, really :P), I would totally participate. This sort of application would be invaluable to the health care field. Imagine having the ability to predict future problems with a patient, years in advance. That would cause a huge improvement in the quality of life.

If any of you know anything about machine learning, you should try out this challenge. It's set to start around next year. You could make a huge difference in the quality of life of people. I suppose $3 million would be nice as well. :P

A Good Software Engineering Course

I found this SE course recently. It seems very good. I sincerely hope Waterloo's Software Engineering courses are this good. I guess I'll find out in my next two academic semesters.

You should take a look at the introduction lecture. It is a fantastic description of what Software Engineering is, and why it's important.

EDIT: "We will have a project, and we WILL be changing requirements on you." Well done. This is a fantastic way to learn about Software Engineering.

Version Control Models

I've started reading Pro Git, a book on how to use git correctly. I figured it would be good to know all the ins and outs of git, since I'll be using it at Karos Health. The book does a pretty good job at summarizing the differences between the various version control methodologies. It certainly cleared up some things in my mind. Here's the page that talks about it.

To be honest, distributed source control systems seem like overkill, but that might be just because I haven't worked on projects big enough (ie. not a Linux kernel). At BBM we used TFS for source control and everything seemed to work smoothly. The project I worked on was only around 300 KLOC though.

In other news, I probably passed Physics. Here's hoping. Now I get to relax for a bit and do all my "easy" exams. :)

Do any of you guys have experience with git? How do you like it?

Crisis

I've decided my true calling is in the arts now.

I'm going to write a novel.

This post brought to you by PWU.

IBM AI Jeopardy

IBM has created a supercomputer AI system named "Watson" that will challenge all-star winners Ken Jennings and Brad Rutter in Jeopardy. This article talks a little more about it.

I am very curious as to how this will turn out. Apparently "Watson" will use natural language parsing to interpret the questions. If "Watson" wins, it will represent a huge leap in AI. We've already seen some very impressive natural language parsing from Wolfram Alpha. I want to see  how much farther this concept can go with a budget from IBM.

So? Place your bets! Human or Computer? My money is on the AI killing the Jeopardy veterans. I guess we'll find out in February. What do you guys think?

Note To Self

Note to self: Do not completely neglect a course throughout the term just because it's a first year course and it seems much less challenging (and interesting) than your other courses. This makes exam period 204% less fun. Damn you, Physics! Why did you have to be so much less interesting than my other courses this semester? A lot of times I was like "Go to physics" or "Work on OS for an extra hour". Guess what I choose to do most of the time. :P 

In other news, algorithms went pretty well! The hardest course I've take so far in my university career is over! Woo! They were nice on the exam. They could have killed us (much like they did on the assignments), but instead they gave us tons of marks for doing simple things like tracing algorithms we had to know.

If I survive Physics (Thursday), It should be smooth sailing for the rest of my exams. I am not too worried about the OS and DB finals. After that, I will have time to do some more preparation for my work term. Specifically, learning as much as possible about GWT, and learning the ins-and-outs of git using this book (Jesse should be happy :P).

Japanese Multiplication Method

I just saw this video through Gizmodo:


Very cool way to multiply numbers. Don't think it's more efficient than the traditional method we were taught, but cool nonetheless.

Anyone want to prove it's correctness? :P

The Sound Of Sorting

This is a little old, but it's cool nonetheless. The sounds of various sorting algorithms.



I am in exam study mode. Bleh. Starting Tuesday, I have an exam every two days until the end (22nd). Unfortunately, my two hardest exams are first. I have to learn first year physics by Thursday. Woo! At least it should be smooth sailing after that.

Facebook Hackers Cup 2011

Facebook just posted their Hacker Cup 2011 Competition. I was thinking of participating. I should have time, since I'll be on my work term by then. It's been a while since I participated in these sorts of contests. I had some fun with them in high school. If you want to work for Facebook (I don't), this seems like a great way to get their attention. I can imagine that the problems will be similar to the Facebook puzzles. Perhaps I should do some of those for practice.

Any of you planning on participating?

Hacking Google Interviews

This site talks about all sorts of interview questions Google likes to ask. It has educational materials and Do's and Don'ts. You should check it out, especially if you have interviews coming up soon. Enjoy!

Cyber Terrorism and Wikileaks

This is so dumb. For real. Attacking websites under the guise of protecting free speech and protesting is stupid. I sincerely hope these people get busted and charged, but I know that will never happen. I can only hope that they realize that attacking these sites is only going to make people dislike Wikileaks even more.

Lessons Learned From OS

OS was defeated last night. It was amazing. And we only had to stay up to 5am and go through ~450 broken builds! As I mentioned earlier, OS teaches you a lot about programming. You will come out a much better programmer, though not because you know how an OS works.

Here's the things I learned during this crazy project:

- Planning out everything before development is a really good idea. You should not be programming before you know how all the parts will interact. If that's not possible, you should take time to make your implementation very flexible, since it might have to change (sometimes radically).

- Pair programming is a good idea. Especially at 4am when you are both only half awake. We caught a lot of potential errors this way. We found pair programming especially useful for A3, since the work didn't really divide up very well.

- Overworked developers do sketchy things. After the 13th consecutive hour of development and debugging, you will do just about anything to get the job done. We definitely ignored some engineering "best practices" during our development.There are certainly sketchy solutions in our code. If we were maintaining the OS later, now would be a good time to re-factor everything.

- Debugging is hard and will take you double the time you allocate for it.

- A girlfriend that make you an OS care package(with BACON!) at 2am is amazing.

- Finally getting everything done is very satisfying and worth the trouble.

- Assert those stupid things that you think can never happen. They will happen and cost you hours of frustrating debugging time.

- Tests suites are invaluable. It's even better if you can run them all in under a minute.

- Bitmaps can do some things blazingly fast.

- Your physical memory manager probably shouldn't give it's own frames to other processes. This will end poorly for your physical memory manager.

- Low level programming sucks.

- C sucks. 

What did you learn from OS or other crazy workload projects? Technical or otherwise.

Now it's time to finish up DB and sleep for 8294534529 hours. Wooo!

Common Interview Questions for Java

Here's a few more common Java interview questions for those of you going for interviews in the next couple months. I've been asked about half of them in the past.

Also, OS IS DONE! I was so happy last night! I'll make a post later on today about all the things that I learned. If this course is good for one thing, it's teaching you a lot about programming (and how you work under pressure). The OS knowledge seems secondary to that.

Place Your Bets!

Will Willis and I have to pull an all nighter to finish OS?

Things left to do:
- Update our code to use our new physical memory management.
- Implement page replacement
- Write a 4 page design doc.

Hours left: 42 at the time of posting.

I really hope we don't have to. I now understand first hand why you are not supposed to overwork your developers. :/

The Effectiveness of Test Driven Development

I've always been curious about Test-driven development (TDD). I've been told that it speeds up development time, because you can reduce the amount of bugs hiding in your code. With TDD, you are more likely to find bugs right away, and not months later when it's harder (and more costly) to fix them. Although I agree completely with unit testing as much of your code as possible, I don't think that TDD is the best way to produce these tests. Apparently, I'm not the only one who feels this way, and there is a lot of debate going on in this area.

According to case studies done by Microsoft and IBM, TDD teams took 15-35% more time to develop the applications, but the bug density was reduced by 40-90% compare to more traditional projects. The problem is that some (most?) projects can't afford to delay feature development time by 35%.

The main idea behind test driven development is:

1) Write tests for a feature you are about to implement. These tests should fail at this point.

2) Write the minimum code required to satisfy these tests.

3) Re-factor the code, making sure that none of the tests break.

I think my main objection with TDD is step 2. I don't think writing the minimum code first and then refactoring is a good way to encourage good architecture. At the very least, it's more time consuming than it needs to be.

For me, the final design for something (especially small features) is pretty straight forward, but requires writing "extra" code. That is, I could implement the feature in a simpler way if I wanted to. However, implementing it the "stupid", simple way first, and then refactoring it seems like a waste of time to me.

Perhaps part of the problem is that I've never used TDD in a professional environment. Maybe I'll get a chance to at some point. Until then, I prefer to write my unit tests after my feature is implemented.

What do you guys think about Test driven development?

CT Imaging And Radiation

I just read this article about the benefits and drawbacks of CT scans. According to the article, CT use has increased by 16% a year, since 1995. The problem with CT scanners is that they expose patients to more radiation than other means of medical imaging. Some people are wondering if the benefits outweigh the risks, although most of the medical community agrees that CT scans are worth the risk.

Certainly CT scans provide radiologists with much higher quality images.

The left is a CT scan somewhere in the abdomen. The right is a traditional chest x-ray. Clearly, the CT scans provides the radiologist with a lot more information, at the cost of more radiation. CT scans are one of the few effective ways to see that much information inside a human body.

Are there other options? Of course. MRI is another very powerful imaging technology that can provide even more detail than CT.

MRI is one of the only imaging techniques that can see soft tissue in detail. It's also one of the only imaging technologies that is completely non-invasive. No radiation is used and it's 100% safe to use. So why haven't MRIs replaced CT scans? Money. MRIs are a lot more expensive than CT scans. I think one important research topic in the medical imaging field is how to bring down the costs of MRI. The increase in availability of these machines could have a huge positive impact on health care quality. It would allow doctors and radiologists to see a great deal of information in the human body, without putting the patient in any risk.

It's interesting to see how these technologies will change in the future. Hopefully I'll get a chance to see how they work first hand during a work term down the line or something.