Saturday, April 30, 2011

Spring!

Yesterday was my last day at Karos Health. It was an excellent term with amazing people, and innovative software and technology. I'll definitely miss working there. They gave me a remote controlled helicopter as a parting gift.


How cool is that!










In other news, I'm quite excited to start my next semester. It'll be my first Spring school semester, and I hear the campus is awesome this time of year. I'll try to enjoy as much of it as I can with Real-Time. :P I will be taking:
Software Design & Architecture
History of Mathematics
Real-Time Programming
Distributed Systems


Should be a fun semester. :) I found out that one of my co-workers taught my 
Distributed Prof. :P


I also have REAP next semester, which should help me meet my excitement quota for 
the semester.


In other news, the Ignite Waterloo for Spring has been announce. I went to the one in Winter,
 and it was excellentI highly recommend that you check it out, if you get the chance.

Tuesday, April 26, 2011

Importance of Data Visualization In Agile Teams

I went to an Agile P2P meeting after work today. The speaker was Jason Little, an agile coach. He seems like a very interesting guy. I like how he doesn't seem to get bogged down by what "agile" says you should do, but rather he focuses on getting actual results. It's refreshing to see.

Anyway, he was talking about the importance of data visualization in agile teams. By displaying data in concise and intelligent ways, major problems become much more evident. Problems that are hidden by poor data presentation can become glaringly obvious when you display the information in the "right" way. Uncovering these problems is a huge part of improving what you do as an organization. For example, take stories in your electronic issue tracker. If you have a lot of bugs in your issue tracker, you might not see it right away because of the way they're organized. If instead you put all your issues on coloured sticky notes on a board, and you see a clump of red tickets, it becomes immediately obvious that your software development process might have serious quality gaps. If you further organize those tickets by time, you can visually see when a lot of those bugs were discovered (and can guess when they were introduced).

The importance of data visualizations doesn't only apply to agile though. Data visualization is important in a lot of fields. Humans suck at looking a unorganized data and making sense of it. Computers are much better at this. Data visualization will be very important in the future to help humans make sense of the immense amount of knowledge available in some fields. Like in the agile example above, some problems might become glaringly obvious if you organize and display the information in the "correct" way. The cure to cancer might be hiding in the data, and it's just a matter of showing it the right way before it jumps out to someone.

Okay. I'll stop procrastinating now and finish off that work report.....



....



or watch Community.

Monday, April 25, 2011

SOAP And REST

For my work report this semester, I decided to talk about RESTful web APIs and how they compare to SOAP based APIs. Conclusion: SOAP sucks. Here's a pretty interesting, fictional conversation that pretty much summarizes why SOAP is generally awful. Basically, SOAP rebuilds a lot of what's in HTTP from scratch. And to top it off, they use HTTP just as a transportation protocol, ignoring all the application level protocol stuff.

This is one of the biggest reasons why RESTful APIs are better than SOAP equivalents. For one, they use more than just HTTP PUT, so they get some free perks from HTTP (like cache-able GET calls). Because RESTful APIs are build as a thin layer over HTTP, you can even use your browser for testing. In practice, this has saved me loads of time. RESTful APIs also tend to actually use things like HTTP status codes, instead of reinventing error handling like SOAP does. SOAP just returns HTTP 200 (which indicates success  in HTTP world), but the response body might contain an error. What? Who thought that was a good idea?

In general, RESTful APIs are simpler (partially because they reuse parts of HTTP) than SOAP. They don't have to have every aspect XML-encoded, and there's no need to for something like WSDL (which, I should mention, is a clusterfuck).

So when you have a choice, always go with RESTful APIs. There are occasionally times where you might need to use SOAP (like when you need something like WS-Security), but for almost all applications, RESTful APIs are a much smarter choice.

So here's the 200-word version of my 2000-word work report (and I got to use the work "clusterfuck"!). :)

Saturday, April 16, 2011

How I spend my 9-5

For the last two weeks at work, I've been working on a new team, developing an application called Rialto Consult. For those of you that are curious, you can read about it here.

Basically, the application allows physicians in one physical location to create radiology orders at a different location. One typical use case could be something like this: Hospital A runs a 24/7 radiology reading service. Hospital B, C, ... , Z have 24/7 emergency response departments, but unfortunately they don't have any radiologists on site overnight. So while these hospitals can capture radiology images, they do not have anyone to read them. Thankfully, Hospital A wants to offer their radiology reading service to these other hospitals. Right now, the workflow goes something like this: Someone comes into Hospital B at 2AM with some emergency. The hospital decides that they need some images taken and read. Once the hospital captures the images, they will fax an order over to Hospital A. Assuming Hospital A gets the order without any problems (fax machines suck), their radiologists will start reading the images. Often, having access to previous images ("relevant priors") is very useful, so the radiologist calls Hospital B and requests some images. These are sent over. Once the radiologist has enough information, they'll read the images and write(or more likely, dictate) a report summarizing their findings. That report gets faxed back to Hosptial A, where they decided what to do next. The whole process is complex, unreliable, and slow.

Now with Rialto Consult, the workflow becomes much more seamless. In many ways, the experience is indistinguishable from both parties being in the same physical building, even if they're in different cities (or even countries!). Essentially Consult offers a shared worklist. Both hospitals see the same worklist of radiology orders and their states in the workflow. When Hospital B wants a read done, they simply create an order in the system. That order is automatically sent electronically to Hospital A, along with a summary of the patient's history (including those very useful relevant prior images). Hospital A can then view the images, see the patient's medical history, and get relevant prior images. The radiologist can do all this from their workstation without having to call anyone. The radiologist's report is also automatically transfered to the original hospital, where they are notified of the results immediately. The entire process is much simpler, more reliable, and more cost effective.

The software is very cool and solves a real problem in the industry. The specific section I've been working has to do with audit records. When anyone does anything with the system or your patient information, an audit record is generated. There might be as many as 40 audit records generated for one patient to go through the workflow I described above, so you can imagine that there are literally millions of these records to deal with. I was working on a system to store and display these records in an intelligent way.

Okay. Maybe I should actually work on that work report now instead of randomly blogging. :P

Friday, April 15, 2011

Life Dilemma #8

Today was FedEx day at work. Basically, It's a free day (24 hours) to work on whatever you want. The motto is "Deliver Overnight", hence the name. I started by playing with SmartGWT, a very comprehensive GWT framework. Check out their showcase. It's pretty impressive. Has anyone ever used it before? I'd love to hear your thoughts. At some point I took a break from SmartGWT and helped a colleague work on the software the validates the software licenses. That was a very interesting and different project. I feel sorry for the compiler that had to compile the code I produced. There was some effort to obfuscate the code. It was a fun project, but I feel dirty for violating every coding practice I've ever learned. :P

This last week got me thinking about what I want to do next co-op term. Working at Karos Health has been an amazing opportunity. I enjoy working with all my co-workers, and I have a lot of fun at work. The people are all very passionate and skilled at what they do, so it's a real pleasure to work with them. There's a lot of support for professional development. For one, everyone at the company seems immensely talented, so just working with everyone on a daily basis provides a lot of opportunity for learning. On top of that, the company invests a lot in professional development in the form of lunch and learns, book clubs, and trips to various UX and Agile P2P meetings. The actual software that we build is also very cool. We are coming out with products that don't exist in the market yet! It's very exciting stuff.

The dilemma is whether or not I want to go back there for my next co-op term. I think co-op is really awesome because you get a chance to work for up to 6 different organizations, all with different people, using different tools, and in different business markets. This is an incredible learning opportunity. I thought that I would learn more if I were to work somewhere else, but now I'm not so sure. I'll certainly get a chance to work with a brand new group of people, but I don't know if it's worth leaving such a fun job behind. If I do go back to Karos, I would like to work on server-side code. If I do that, I would be able to work with a (slightly) different group of people in the company, and use different tools. I guess I'll have to think about this a lot more in the upcoming months. I guess this isn't really a bad dilemma to have.


In other news, I got an offer for a UW REAP position today. I am very excited to work on that project next semester. It will be an incredibly busy semester with Real-Time, but it should be one of the most interesting semesters so far. I'm excited (and scared).

Thursday, April 7, 2011

Git >:@

While git is a very cool and powerful version control tool, it's command line UI is just awful. The fact that there are no fully-featured GUI alternatives(that don't suck) makes things even worse.

Let's talk about staging. I would say that a staging area is not useful in the majority of cases. Why is the default behaviour to force a staging process? Most of the time it's just an annoying "durr. stage everything please" step before you commit.

Then there's the actual commands. Want to add a file to be tracked?
git add <file>
Want to stage an already tracked file?
git add <file>

Why is it necessary to overload this command? At least these make some sense. How about unstaging?
git reset HEAD <file that's staged>

Really? reset? Why would you choose that instead of, you know, unstage!

Want to revert back to the previous commit? git revert would make sense... Too bad it's
git checkout -- .

Checking out previous commits makes sense, but the fact that you have to do it by copying and pasting an SHA-1 hash code sucks.

How about untracking and removing files. Well there's:
git rm <file>
which will remove the file from your working directory, and untrack it. There's also
git rm --cached <file>
which will just remove the file from git, but keep the actual file in your working directory. Why --cached is the flag they choose, I'll never know. What's wrong with --tracked?

I could go on and on. I like git because of how powerful it is, but I hate how many usability problems it has. It makes the learning curve much steeper. I've been using it for 4 months at work now, and it still throws me off every once in a while because of how unintuitive it is.

New Projects At Work

I haven't been posting as often as I usually do, mostly because I've been extra busy at work. I started working on a different project this week with my team. It's very exciting, since this is a production application that will be used by real institutions very very soon. The previous project I was working on was a research project, so obviously the quality and usability requirements are very different. I can't say things like "We'll deal with that later" anymore. :P Not too mention it has to play nice with other vendors. Let me tell you. This is not an easy thing to accomplish. The standards that exist are not as useful as I would expect.

I also need to start working on that silly work term report soon. I'm writing it on RESTful API design. I've worked on half a dozen of these APIs this work term, so I think it should be fairly straightforward to write. Hopefully it won't be too painful.

Friday, April 1, 2011

A Lot To Learn

Today at Karos Health, we had a retrospection with Declan Whelan, an Agile coach in the Waterloo area. I thought that it was very interesting. I came out feeling like I still have so much to learn about this industry. I pretty much feel this way every couple months. :P It's a weird feeling. I think I'll come out of university feeling much stupider than I felt when I came in. I guess having an awareness of what you need to learn is pretty important though.

So here's a list of things I would like to work on; my personal improvement backlog. :P Priority to be determined.

- Test Driven Development. I feel like won't really understand it until I actually spend a few weeks doing that. I am still unconvinced of it's benefits, but I think the best way to really decide its effectiveness is to actually practice it.

- Pair Programming. I've already done a little bit of this at work and for school projects, but I think the cross-training that it provides is really useful, and I'd love to try it for longer periods of time.

- Language Expertise. I still want to learn some language really really well. I think C# is a good candidate for this. It's still my favorite language.

- Technical Expertise. There's just so many technical things I don't know about. How do you do secure network communication? How can you ensure high availability? How can you efficiently do *? What standard libraries exist for doing *? I would like to know so much more about these topics.

- Agile. All my agile knowledge comes from many different informal sources. I think I should try to learn it more formally by reading through a book, or taking a course or something. There are a lot of fundamental things that I'm still trying to figure out, and I think that formal training would be very useful.

- Healthcare. There's so much to learn about the being a developer for the healthcare industry. There's various protocols: HL7, DICOM, and frameworks for working with them like XDS. I know very little about how these protocols work. I know even less about the interoperability problems that arise from having many different protocols.

This list is a little overwhelming. I don't know where to start. Instead of doing a "breadth-first search" into these topics like I have in the past, I'd like to dive into one of them and get to know them very very well. Too bad I'll have Real-Time next semester. :/ I guess I'll make time after that. :/