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.

Over-Engineering

Over-engineering has started to become a pet peeve of mine. Sometime I feel like my thoughts on architecture follow a pendulum. It goes from the extreme of abstracting like crazy and applying design patterns out the ass, to the other extreme of not thinking about generalizing at all. Eventually, I hope to settle down at a reasonable point in the middle. Give me a few years.

I think our current DB schema is a little over-engineered. Granted, we wanted to challenge ourselves to do something new with the project, but it ended up costing us a good deal in development time. Not so cool with OS in the way. In "real life", we would have saved time in the long run, since the project would probably to stay around for 5 years. The time used to set up our architecture would have made up by speeding up all those years of future development. Unfortunately, our application has the lifetime of a month.

I think that a good rule of thumb is to write the simplest code possible, without coding yourself into a corner.

Do you need to unit test that class? No? Then don't make it an interface. Changing this later isn't hard, but working with a system where every single class is an implementation of an interface is harder. Adding unneeded complexity to your code will just make your system more error prone.

Do you really need to every function to be less than 10 lines? Well is it hard to understand your code? No? Then don't bother. Reading through a file with hundreds of three line functions is a nightmare. It's really cool when you can read the high level function as if it were pseudo code, but understanding how everything works becomes much more complex. And again, complexity will lead to more error prone code.

Do you really need to make that Singleton thread safe? No? Then why would you? It's trivial to make that change later, when you actually need it.

With that said, it's important that you don't code yourself into a corner. You shouldn't make a system that's hard to extend. It should be easy to extend when the need arises. Until then, leave it alone.

Making Carts Using Genetic Algorithms

This genetic algorithm tries to generate an optimal cart with two loads to traverse some static terrain. Complete with a nice little animation. :) I want to look through the source, but I don't have enough time now. Hopefully I'll remember to check it out after this week is over.

In other news, the deadline for DB was pushed back to Monday. It's appreciated, though we are close to done anyway. Maybe the OS deadline will be pushed back as well. :P

Anyway, time to prove things are NP-complete. lalala

Final Push

This week is going to suck...

The two projects are due this week. DB is due Friday, OS is Sunday. (and there's that pesky algorithms on Thursday :/). DB is very close to being finished. We are in the testing phase right now. Hopefully we will write our last lines of code today. OS is much, much further from being completed. In fact, we have 0 feature implemented, and we are still unsure about how everything works. We have some framework code working, but that really isn't impressive. Hopefully with DB out of the way, we can focus all our time on this and figure it out ASAP.

At least after this week is over, the crazy course load is done. I'm not expecting exams to be that bad. At the very least, it won't be a super busy time for me. This means I'll have time to sleep (and not have dreams about OS and DB)! That'll be the life!

How is your last week looking?

Architecture Lessons at 3AM

I learned a nice architecture lesson last night: Think about error handling early. The wrong time to think about it is at 3AM after most of your functionality is built in.

Originally, our architecture relied on returning null on failure. The levels above would check for this and handle it appropriately. There are a few problems with this. The problem that impeded us the most is that we were unable to differentiate between various kinds of failures for some method. In hindsight, this isn't a very clean way to handle error handling in general.

The first solution we tried involved an external error handling class. Our model (and data access code) would set flags in this static error handling class to indicate what went wrong. This meant that every time someone wanted to call on the model to do something, they would have to remember to check the error handling class to see if anything went wrong. This created a coupling between this error handling class and our models. If you forget to check that error flag, your code would fail silently or cause unexpected behavior. We eventually scrapped this idea in favor of exceptions.

Exception were better because any failure would force the programmers to deal with it immediately. If they forgot to catch the exception, the program would crash right away, and with a very clear reason (like SQLException). You could not simply ignore the error and continue running in ignorance like with the other static error handling technique.

After we decided on exceptions, we started talking about whether we wanted checked or unchecked exceptions. More fun debating there. All this happened after 2AM. I am always hesitant to make important design decisions at that hour.

We eventually decided to go with checked exceptions. This means changing almost all of our classes (including all our tests). Granted, the changes are fairly simple and straightforward, but it's still going to cost us some time to re-factor everything. Had we thought about error handling straight away, we could have saved some time.

Moral of the story: Think about error handling during your planning phase!

On an unrelated note, Willis and I got 97 on OS A2. Hell-freaking-Yeah!

The 7cubed Project

Check this out: http://7cubedproject.com/

7 UW programmers making 7 apps for 7 days. Very cool. Today is Day 5.

Day 1 was Quick Cite. With this mobile app, you can scan any book and the formatted bibliography will be sent to your email.

Day 2 was UWChat. This lets you check into UW rooms and have chat sessions with people in the same room as you.

Day 3 was Minehub, a dynamic Minecraft server.

Day 4 was supposed to be something called "AwesomeTracker", but unfortunately they were unable to ship it on time. They said that they'll get back to it after the week is over.

This seems like an interesting test of the limits of agile programming. The group says that a highly skilled team of developers can successfully follow an agile methodology where they measure releases on the order of hours. So far, it seems to be working quite well. Of course, there have been some hiccups. The failure to ship on day 4 is perhaps the biggest. The other big one is that during the rush to get Quick Cite out, they accidentally shipped code with the email functionality commented out. I think that these sort of problems are almost unavoidable when you are developing this fast.

In any case, I'm really interested in what else they can create. This seems like a really cool experiment, and a lot of fun for the coders involved.

Sanity Progress

I was feeling quite overwhelmed yesterday with the amount of work I have to do. Third year is hard. :/ In first year, they were all like lalala "If you can adjust to first year, the rest is easy". In second year, people said lalala "If you can get through second year, you can do the rest". Bullshit. Third year has been orders of magnitude harder and more work. First and second year courses don't have projects requiring more than 100 man-hours of low level C programming. Perhaps it's my fault for taking 2 project courses and algorithms at once... Maybe the next couple semesters will be easier (especially if I don't take Compilers and Real-time).

I am feeling better today. Our OS prof was nice and went through a lot of the assignment requirements in lecture today. I feel like I actually know where to go now, instead of poking through the OS/161 kernel aimlessly. :P DB also seems to be progressing fairly well. Hopefully we'll be feature complete for tomorrow or Thursday. If this was Amnesia, I would be surrounded by white light and my sanity would go up a level.

However thanks to this crazy workload, I feel like I'm coming out a stronger programmer. Writing code for an OS is quite humbling.

How much voltage does your program need?

Apparently Intel thinks they can create CPUs with up to 1000 cores. It'll be interesting to see how much of a change this will spur in Computer Science and Software Engineering.

I know some schools are already teaching multi threaded algorithms and concurrency. I can see this becoming more and more important in the future. I am getting really excited for the concurrency course at Waterloo.

Also, the Intel cores contain hooks that let you change the voltage to the cores. This sounds like yet another crazy thing for programmer's to consider in the future. I used to think that these issues were stupid. How much could they possibly reduce it by? Who cares how much voltage your CPUs are using? Google does. Saving 1% of CPU voltage will save the company thousands and thousands of dollars. It's pretty crazy.

Anyway, 4 assignments left in 2 weeks. Woo! OS an DB are both due in less than two weeks. Why does the end of the school year have to be so busy?

Ukrainian Folk Short

My dad sent me this video this morning. It's nice. I totally remember visiting family in Ukraine, living in a village like the one in the video. It must look weird to other cultures. Why are there random flies in the house? Why are people singing at the dinner table? Are they using a scythe? What's with the clothing? It seems weird how I've seen all these things in person, and now I live in a very different place. It's a cool feeling.