Installed Kubuntu Today

For the longest time, I have always had a goal to be Windows-free. Many people I work with feel that it is pure apostasy, because I have worked in Microsoft shops in the past 10 years or so. But frankly, I am particularly sick of Windows as a whole. If I can still continue doing my work without having Windows on on my HP Pavillion dv9008nr laptop, then I think I am set.

So, I installed Kubuntu 9.04 (Juanty Jackalope) today. It was the most painless installation of Linux that I had… ever. It was even less painful that my initial installation of Ubuntu 8.10 (Intepid Ibex) on the family desktop (recently auto-updated to Jaunty).

My laptop wireless has the ever painful Broadcom chipset, which historically has been a problem on both 32-bit and 64-bit systems. But I found out that they got off their butts and started to provide drivers for Linux. So, after enabling the closed source drivers, my wireless just worked period. There was no manual configuration that I had to do, no driver to look for, and no searching through outdated documentation for clues on configuring everything.  Do you have any idea how refreshing that is?

Here are other refreshing things:

• The NVidia chipset for graphics acceleration worked with zero configuration.
• All of my external devices worked.
• Even though I like the GNOME interface in Ubuntu, I absolutely love the KDE interface in Kubuntu.  I am ecstatic that I went in that direction.
• BZFlag looks / feels much better on Linux that on Windows.
• The best system for tools I already use on Windows: Pidgin, GNU Emacs, Steel Bank Common Lisp, Mozilla Firefox, and others.
• Even Adobe Flash has decent performance, even though there is no 64-bit native version for Linux. Most YouTube videos do work, even in full screen mode. So, I can deal with it for now.  (Adobe is now the new Broadcom, IMO).
• The default Remote Desktop (RDP) client allows me to connect to my Windows desktop at work, basically completing my minimum requirements for total conversion.

So, I look forward to writing more about my experiences on Kubuntu.

Groovy Baby, Yeah!

Working in mostly M$ shops in the past 10 years or so, coupled with my home projects in the functional languages, I don’t get to do much with Java or the JVM anymore.  But today, it was treated to my first experience in programming in Groovy.  The tool that I use to test SOAP web services, SoapUI, is built upon Java and uses the Groovy as embedded scripting language to manipulate the testing environment.

I must say that it is a pretty neat.  Just using it as a scripting language seem to be natural, almost like Python or Ruby. Even though I did not use any advanced features such as closures, builders, or regular expressions, I hope that I can give it a try some time.

Teagan’s Surgery

 

 

 

Teagan is having surgery today.  You can follow his status here. Good luck, my son, and get well soon.

Google Maps: Superman in Metropolis

Last year, I was visiting my brother and his family in Paducah, KY.  While visiting, I heard that there was a statue of Superman in Metropolis.  Metropolis is just across the river in Illinois, but I decided to check out the Harrah’s Riverboat casino instead of visiting the statue. Thanks to Google Maps, I can see it for the first time.

April Fools Day: Aluminum Foil Cubicle

Well, this year for April Fool’s day, I decided to pull the classic cubicle prank. I (with the help of others) wallpapered a collegue’s cube in aluminum foil.

It’s not like it was an original prank, but I think I wanted to try it once. I honestly do not know how he would react, so I may die tomorrow. At least I’ll die on my terms.

 

Hey, it's nice and shiny!

Personally, it took longer than I expected, too.  It’s hard to get every detail correct without ripping the foil.  The original idea had us wrapping the flat panel monitors, but I thought it may be a fire hazard, so we left them alone. The black on silver provided a good contrast, no?

We are a stickler for detail. Each one of the pens and pencils in that cup are individually wrapped.  Attention to detail is important.  We honestly though that the prank would have sucked if we did not wrap the writing utensils and other items on the desk itself.

Attention to detail is quite important!

Real World Haskell

I received by copy of Real World Haskell yesterday from Amazon.  The book is thicker that I thought, which makes me think that it should have been made a hardcover.  But, I’ll just need to be careful, I guess.  

In the past 24 hours or so, I was able to read up to the fifth chapter on writing a Haskell library.  Even though that I read the draft of the book and seen people make comments, I am surprised that there are a few typographical errors in the few chapters that I read so far.  But, that should not distract anyone.  

It’s not like I have not programmed in Haskell before, but I wanted to see the hype behind this book myself. The book is an interesting read. In fact, I learn something new about the language that I did not know before I seen the book.  Looks like I am going to enjoy this!

Reading Programming Erlang

A few weeks ago, I received my copy of Joe Armstrong’s Programming Erlang: Software for a Concurrent World.  I was quite impressed.  It was a great introduction on the Erlang programming language and more importantly, concurrent programming. After reading the book, I am not sure if I fully understand it’s true power.  

What do I mean? The idea of having a language that is built for fault-tolerant, distributed, concurrent, mostly real-time applications may come as a pipe dream to some. To me, Erlang is the real deal. It’s simplified view of concurrency makes it easy to create high performance systems.  It’s share-nothing attitude toward memory and communication allows for high process scalability.  The simple fact that Erlang is a functional language allows these two concepts to exist.

There is just no equal in mainstream languages. Some may think that it was designed at some University and it’s nothing but a toy language.  The truth is that Erlang was created by a real company, by career engineers, to solve real world concurrent problems, and used in real products. So, one cannot really use that argument anymore.

 As recommended by the author, I have to read the book again and again.  I hope that I am able to read it again before I receive Real World Haskell in a few weeks.

Design Smell: Violating LSP

Sometimes a framework impedes on development so bad, it makes you somewhat angry and feeling helpless. I encountered something today that gives me headaches just thinking about it.

Suppose I have framework in C# 2.0 that models document folder that contains one or more documents. The framework defines an abstract base class, Document:

public abstract class Document {
// Implementation removed.
}

And concrete document types:


public class PurchaseOrder: Document { ... }
public class Quote : Document { ... }
public class Invoice : Document { ... }


And a DocumentFolder class, the have properties for retrieving each of the concrete document types:

public class DocumentFolder {
  public List<PurchaseOrder> PurchaseOrders { get { ... } }
  public List<Quote> Quotes { get { ... } }
  public List<Invoice> Invoices { get { ... }}
}

Let’s say I want to collect every PurchaseOrder, Quote, or Invoice document in a DocumentFolder to perform work on them.  Since all these documents derive from Document, I should be able to create a generic list of type Document and use List<T>.AddRange() to collect  them all.

DocumentFolder folder= LoadFolder(id);
List<Document> docs = new List<Document>();
if (folder.PurchaseOrders != null)
  docs.AddRange(folder.PurchaseOrders);
if (folder.Quotes != null) docs.AddRange(folder.Quotes);
if (folder.Invoices != null) docs.AddRange(folder.Invoices);

Then, use the List<T>.ForEach() operation to perform common work on
my Documents, using an anonymous delegate:

docs.ForEach(new Action<Document>(
  delegate(Document d) {
    DoSomething(d.LineItems);
  }
));

But, I get an error upon compiling. After troubleshooting it, I found that the LineItems property is declared as protected internal, and therefore not available to classes outside the executing assembly:

protected internal List<LineItem> LineItems
{
  get{
    /* Implementation removed. */
  }
}

Each of the three concrete documents override the LineItems property using
the new keyword and calls the base class’ version, effectively crippling
the whole point of having abstract base classes to begin with:

public new List<LineItem> LineItems
{
  get { return base.LineItems; }
}

*sigh*

After pounding my head against my computer,  I accepted this design smell and moved on. This example is a  violation of the Liskov Substitution Principle (LSP), which states in a nutshell:

Methods or functions that use references to base classes must be able
to use objects of derived classes without knowing it.

I could not store a list of the base class, populate the list with instances of the derived class, and perform useful iteration. The workaround resulted in three blocks of iterative code that looks almost alike.  So, I will be addressing this problem with my peers in the near future.  In the meantime, back to coding. Later.

News IQ Quiz

Tonight, I took the Pew Research News IQ Quiz. It is a set of 12 questions on current events and people. At the end of the quiz, the site asks you some basic demographic info about you. I was surprised at my results: I apparently had a perfect score.

But what was more interesting was the graphs showing my percentile rank vs. others.

My overall results.

Other than the obvious, my overall results does not show much, in my opinion. There were only 12 questions, so missing one question could prove bring someone down a good percentage. I would think that 50 questions would be better. But given the short attention of the Internet, I think I understand why quiz needed to be short and sweet.

My results by gender.

The gender results are quite interesting. I am not exactly sure what the percentiles mean relative to my percentile score, but the graph definitely shows that men pay more attention to the news than women. There, I said it. I am sure that there are very smart women in the world, but statistics don’t lie. In America, most women just don’t care about current events.

Take my wife, for example, she buys newspapers for the coupons. She reads comics and the Parade Magazine that is included in the Sunday edition, but that’s about it for the newspaper. On the Internet, she mostly reads are the silly stories that show how stupid people can be (via Digg or Reddit). She is a smart cookie, but I do think she can answer most of the questions on the quiz. I sent her the link to the quiz, so I will see in the next few days,

My results by age group.

In one aspect, this graph is not surprising. The older you are, the more you know current events. I remember when dad was alive, he read the newspaper a lot. He not only read the newspaper every day, read every single bit of it. Just like my dad, people 50+ like to read the paper or watch the news.

Under the covers, a disturbing fact also shows. The gap between 18-29 and the 30-49 group is huge, which can only mean that people under 30 are living under a rock. With the abundant amount of news available on the Internet, one would think that the most tech savvy group would excel. What can I say? This group is more interested browsing social networking sites that learning current events.

What’s worse? This graph only shows results from people who actually took this test! I think if you were to ask people in the 18-29 group these question on the street, I would imagine most of them will not get half the questions correct. Hey, you can even see evidence of this on The Tonight Show whenever Jay Leno does his Jaywalking segments.

My results by education level.

The educated reads more than the uneducated, so this graph does not surprise me either. But, like the results by age group, the gap between a high school graduate and a college graduate is huge. What is not clear is why. There are many people who don’t go to the college. Some are educated in a trade skill, which does not count as college by my understanding.

My dad, who I mention earlier, falls into the category. He did not go to any college, but he was a 20-year veteran of the U.S. Army and in the radio and television electrician by trade. So, if he were alive today, what would he get on this test? I think that he would have scored well, because of his reading habits. Without that habit, I think he may be close to the 29th percentile.

Taking this test, it occurred to me that key skills to knowledge is the ability to read, the ability to pay attention, and the discipline to care. Without those skills, one become a empty shell of a human with little understanding of the real world. I think it ultimately shapes the personality, the perceptions, the biases, and the fears that make up one self.

Beautifully Lean Documentation

Your development team spends a lot of time creating formal functional specifications, design documents, and general documentation. They create a nice class diagrams, sequence diagrams, or flowcharts to be included. Sounds like your team did everything it should, right?

Well, not exactly. Where is the software? Documentation is nice, but one thing that I learn is that creating developer documentation is seriously overrated. The documentation end up being practically worthless in the end, mainly because of simple, organic growth of your software.

In many organizations, any documentation that does exist are most likely out of date, because no one wants to update them. The documents end up in some hole on your company’s intranet and will stay there forever. Even if your documentation is current, there is *no* guarantee that anyone would read or understand any of it. Other developers, QA analyst, business analysts and management don’t really want to read a 50-page document on your favorite piece of code. They will often skim it, with often a small subset of knowledge how it really works. As time passes, the amount of trust in documentation diminishes because the audience knows that the software changes.

I am not saying that there should be *no* documentation, but your documentation should be like a good book. It should captivate your audience and more importantly, be relevant to the current situation. The most valuable documentation has correct context and has need. Creating documentation for the sake of documentation will doom your project.

So, beautifully lean documentation is key to success. What does this mean? Well, there are many strategies for agile or lean documentation. However, to have beautifully lean documentation, I take a more minimalistic approach:

• The source code itself is probably the most valuable documentation any developer can have. Therefore, I make it a point to create meaningful comments and use documentation generation systems wherever possible.
• I think that the user stories provide better context for the software than any other written documentation. In essence, user stories detail what the software is suppose to do. Couple user stories with acceptance tests, the system becomes validated.
• If the software has external service interfaces, then those need services need explicit documentation. There is no real way around it. However, the documentation is used as reference at this point and it usually only documents the service interface.
• I normally document just the design decisions that I made. This gives developers an understanding of what I considered and, more importantly, what did *not* work. This will save other developers some time on research.

So, when I am working on a new product architecture, creating beautifully lean documentation allows me to concentrate on the software.