How to write unmaintainable code

Here's a fun read on how to write unmaintainability code. For job security, of course. :)
This is probably the best thing that came out of my Architecture class. >_<

REAP Review

The client presentation for REAP were yesterday. The various teams presented their ideas to the REAP exec team, as well as to some stakeholders that might be using the products of our research. All the presentations that I saw were very interesting. I'm looking forward to seeing what that subsequent REAP teams do with the progress made so far.

Our presentation on the Mixed Reality Interface (MRI) went fairly smoothly(Note to self: avoid making last minute demo changes. >_<). We talked about our plans of using the MRI table to create virtual museum exhibits to enhance user go-ers experiences in museums. Because of the playful and tactile nature of the table, kids would be quite attracted to this sort of exhibit. We are currently working with the Earth Sciences museum on campus to create a mining exhibit as a proof of concept. The museum is currently converting a hallway in the building to be a mini mining exhibit. We hope to be able to get a virtually enhanced exhibit to go along with the physical one by around the end of October. One of the subsequent REAP teams will be putting in a lot of game design effort into making this project happen.

After the presentations, we all went to celebrate with lunch at the University Club. I always wondered what was in that building, and now I know. :P Weee!

In general, REAP was a great opportunity. We got to meet some great people in the digital projection industry, as well as work with some really bright people. We also got a chance to meet with people from all sorts of industries, like museum curators and home designers. The REAP members also got to play with all sorts of cool technologies. Other than the MRI table, we got to play with Microtiles, Unity, and Sketch Up, all while getting paid.  To top things off, we also got a lot of training throughout the semester, including a few sessions on Agile project management. :) As far as part time jobs go, this was a very rewarding one. :)

If' you're interested in joining REAP in a future term, you can apply on the REAP site, but I should mention that hiring for the September term is finished. They still might need people for on-demand work (especially people with game design or game development background). If you are interested in one of those positions, you can email REAP or myself. :)

Car Futures

The most productive thing I've done this summer is plan out my car owning future.

Currently, 1999 Chrysler Intrepid, Black (value < $100 at this point)

Sadly, this car is almost dead. Thankfully, my parents are replacing their red 1999 Chrysler Intrepid soon, and are planning to give it to me. :) It has about half the kilometers and is in much better shape (value ~$500)

After I drive this car to death, it'll be time for my first real car purchase.
Jaguar XF (value ~$60 000)

I think I will feel obligated to to take up golf as a hobby at this point.
Then I'll upgrade to a Jaguar XK (value ~$100 000)

The red brake discs pictured above will be replaced (and burned >_<).
Finally, the holy grail of my car journey, Aston Martin DB9 (~ $200 000)

Yay!

This might be a little ambitious. I feel like I might need a reasonably priced sedan between the Red intrepid and the XF. Not sure what that might be yet. :/

This list will also probably change very soon. Specifically, the next time I watch Top Gear.

Spring Terms and Unity

With two weeks of classes left, I've decided that Spring school terms are a bad idea. I don't feel very academic during Spring terms. All my other Spring terms have be work terms, and I really enjoyed those, but school terms are different. I have to constantly be thinking about what I have to do for my other classes. I'm just not in the mood for it. I just want to sleep in and watch TV (currently, Top Gear and Dr. Who). That doesn't help that 8:30am class. :P Thankfully, I have only three courses this semester, one of which is very interesting. Unfortunately, the others are pretty disappointing. One more assignment rush, then exams, then a few weeks of real summer before I start work in the Fall. Thankfully, this is my last Spring school term.

On another note, I got a chance to play with Unity over the weekend. Unity is a 3D game engine with a powerful editor that minimizes the amount of code you need to write to get something to work. We will be using Unity during the final few weeks of REAP, as we try to create a demo of a museum exhibit on mining. I'm really glad that I got a chance to get paid to learn Unity. :P

My first impressions is that Unity is very powerful and simple to use. You can get a remarkable amount done without knowing how to program. Scripting is very important, but a lot of it is already done for you. For example, you can just drag-and-drop a collider mesh onto an object, and it instantly inherits collision physics. It's a very powerful tool. I'm looking forward to using it in the next few weeks. :)

The Human Aspect Of Software Engineering

As a computer scientist/software engineer, it's easy to forget about the human aspect of what we do. We are often so immersed in very technical parts of the software that we forget that everything we do is for a human. If we don't keep that human in mind, the product really suffers. No matter how technologically innovative a piece of software might be, if there isn't a real, useful human connection, the software will ultimately fail. In that sense, considering the human aspect is the most important aspect to consider when writing software.

Modern development treads seem to be making steps to consider end users more during the development process. For example, agile development stresses getting early involvement from users, to ensure that the human aspect of software is always addressed. They also encourage frequent updates and demos to customers to ensure that they are always satisfied by the product.

I suspect that a lot of usability issues stem from not considering the squishy thing between the chair and monitor. Most of user interface work seems to be figuring out the best way to create that connection between the cool techy thing the developers did and the human using it.

It's easy to forget that most people are not very technologically savvy. You'd be surprised at the amount of people who don't know that you can right click. I think it's really cool that Interpolation search is O(log(log(n)).. Most people, however, don't care about this at all. They do care about reducing their search time in your software though.

It's important to always keep this human aspect of software engineering in the back of your head at all times. It can really improve the software you produce.

Character Encoding Fun!

Let's talk about character encoding. This seems to be a common blank area of knowledge for a lot of developers.

Joel Spolsky found this to be true, so he wrote this great article about character encoding and Unicode. I really recommend that you give it a read. It's a little old (2003), but still completely relevant.

If you are feeling too lazy to read his summary (I blame summer), you can read my even shorter summary.

1) There is no such thing as "plain text strings". You should not assume any given string is in ASCII. You, in fact, have no idea what the string means until you know how it's encoded.

2) Unicode is a character set that to hopes include characters from almost all languages. Unicode is not an encoding though. Older character sets, like ASCII, mapped characters ('A') to numbers (65), which got encoded as the binary representation of that number. Unicode maps characters to something called code points. These code points look something like U+0065. These code points are then encoded using some encoding system. There are many ways to do this encoding, but perhaps the most common is UTF-8.

3) Unicode is not always encoded as 2 bytes. UTF-16 is a specific encoding that encodes Unicode in (at most) 2 bytes. This is not true in general. For example, UTF-8 can be up to 4-bytes long, and UTF-32 is always 4-bytes.

4) UTF-8 is backwards compatible with ASCII for the first 8 bits. This means that UTF-8 is backwards compatible with ASCII.

5) Code points can be encoded any many ways. You can even encode Unicode code points using old-school ASCII encoding. What happens to code points that ASCII encoding doesn't define? They show up as ?. If you've ever seen international data that appears as ????????, it means that the encoding they are using doesn't support those code points.

I hope this fills in some of these character set and encoding knowledge holes. :) Now I should probably do one of those assignments I have due this week (>_<). School terms in the summer suck.

Google+ (and -)

Google's attempt at the social market, Google+, came out the other day. It's an interesting application.

The first thing that strikes me is the UI. I think Google+ has a fantastic user interface. It's simple, clear, and easy to learn. One thing that I really like is Google's attention to details in their user interfaces. Whenever you click "+1", there's a little animation of the number rolling up. If you delete a "circle", there's a little animation of it rolling away off the screen. These little things contribute to a great user interface.

Compared to the Facebook UI, Google+'s UI is a breath of fresh air. However, Google+ only has a tiny (really tiny) subset of Facebook's features. This probably contributes heavily to Google+'s simple UI. I suspect that when (if?) Google+ gets all the features that Facebook has, the user interface will become a lot more cluttered. With that said, it's not hard to beat Facebook's user interface.

This sort of leads me to one Google+'s biggest drawbacks. They really offer a very limited subset of Facebook's features. There are no events, messages, chat(EDIT: Just kidding. They have chat), or even "wall-to-wall" posts. An application API is also missing (Farmville+!). Granted Google+ is still at a very early stage, so it might get a lot of those features later.

The other big drawback is userbase. It is very hard to have a successful social networking application without a lot of users. People won't switch to Google+ until their friends switch. Of course, their friends are thinking the same thing. I think Google can overcome this problem fairly easily though. Perhaps we'll see migration tools that let you quickly populate your Google+ account using your Facebook data.

There are a few neat features in Google+. The one that impresses me the most is the idea of Circles. With Circles, Google+ lets you place your "friends" into various groups. Then you can choose which groups, or circles, can see what content. This is a nice way to keep your family from seeing your status updates about drinking and partying.

Another benefit is that Google has a much more sensible TOS than Facebook. They also have a better history of protecting things like privacy. I know for a lot of people, this is a very big deal. I personally don't care too much about this one. When you put things on the internet (especially on a social networking site), you always risk that everyone might be able to read it. This is why I never post things like my phone number on Facebook (even if its just for "Friends"). The only information I have on Facebook is information that I would feel comfortable telling strangers.

A huge problem I've had with Facebook is their rollout strategy. They seem to be fans of release early, release often, but they suck at it. It is almost a weekly occurrence when a major piece of functionality is broken. Facebook doesn't take enough time to do regression testing before they push updates and it really bugs me. Just because you can fix it fast doesn't mean you can ship it in a broken state. >_< I've found Google to be much better in this area. They also progressively add to their software, but it isn't crippled every week by stupid release strategies.

I'll keep an eye on Google+ going forward, but they have a lot to do before they can realistically hope to beat out Facebook.

Java is Always Pass-By-Value

This is probably the biggest common misconception in Java. It's starting to become a minor pet-peeve of mine. :P People say things like "Java is pass-by-value for primitives, but pass-by-reference for Objects.". This is not true.

In fact, Java always uses pass-by-value. The trick is that Java always stores references to Objects. When you pass in an object to a method, the object reference is passed by value. This is different than pass-by-reference. Java makes a copy of the reference variable and that's what the method uses. While a lot of the time you won't be able to tell the difference, there are some important cases where this makes a difference.

Here's an example:



The output of this program is:

a: 5
b: 10

This is unexpected behaviour if you think that Java is really pass-by-reference. What this code really did was swap two copies of references, not the references themselves. This caused me a few headaches in the past.

This is a misconception has been around for way too long. Spread the word. :P