Archive for September, 2009
Not really, but I did read an interesting post on CodingHorror that struck a chord.
The average consumer/business user doesn’t really get email, in my opinion. At the end of the day, it’s an asynchronous medium for the kind of communication that either (a) requires a documentation trail from the get-go, or (b) doesn’t require an immediate response.
I grow tired of email marketing, joke chains, and supposedly funny pictures in my inbox. My inbox is for bills, password change confirmations, and (hopefully brief) communications/notifications from entities that I do business with. It’s also the new proxy for communication across the Atlantic with my family in the UK and across state lines, but in this regard it should do nothing more than act as an electronic form of a physical letter.
Want to sell me something? Get it on a search engine or an ad on a blog that I follow. Nothing bothers me more than unwarranted solicitation (electronic or otherwise) from companies that I have never heard of.
Where does the irreverent fun go? Facebook. Post me links and random comments, send me stupid pictures of your cat, whatever you want. For me, Facebook is for bathroom reading, Twitter-esque brevity, and random photos captured in the whim of the moment. I may miss your funny post, but I’ll live. In direct opposition to my stance on email, don’t market to me on Facebook or bring up business concerns – It’s not the right channel. It’s for this very reason that I wonder how Facebook makes any money, since I find nearly all their apps to be obnoxious and marketing-driven; I avoid them like the plague.
If you send me your opinions via email, I’m unlikely to read them while sifting through my unread messages. If I care about what you think, you’ll find yourself in my Google Reader subscriptions. If you don’t have a medium for publishing to RSS, I’m happy to do without your wisdom.
Luckily, I think the next generation has already figured this all out. Their instant embrace of text messaging as the medium of choice is proof enough. I’ve already realized that I am starting to miss the boat because it takes me a while to give up my old paper- and desktop-computer-based ways in favor of iPhone-enabled solutions. Not because I am reticent to do so, but because my brain is not wired to think of my iPhone as the Swiss Army knife of daily living. I’m getting better at it with some effort, but my kids won’t even have to think about it; they’ll just instinctively know which gadget/app/thought helmet will serve their needs the best.
There’s no such thing as choosing one or the other; they are two extremes that you have to find a balance for in your software team. I’ve both wasted time attempting to direct the untalented/unmotivated and provided excessive direction to those that didn’t need it. Hopefully I’m getting better at metering out each in appropriate doses.
These days, I’m lucky to have a small enough team that we can selectively hire, but I feel for larger organizations that don’t have that luxury and find themselves needing to fill a seat due to the sheer volume of work. Sooner or later you can find yourself forced to compromise and hire somebody that might get the work done, but ultimately will do more harm than good. No level of direction will save you from these guys; you’ll either be looking over their shoulder all the time (in which case you might as well just do the work yourself) or will take a peek at their work occasionally and wish you’d never hired them.
The Orlando tech market is unfortunately stocked with mediocre programming talent, especially for Java programmers. This is mainly Sun’s fault. The original J2EE spec was so badly conceived and over-marketed that almost every Java developer with any work experience has been trained in the J2EE way: start with the manufacture of an anemic domain model, tie it inexorably to the container, and sweeten the deal by making it impossible to test. Couple this with the sheer volume of Java projects undertaken by nearly every organization on Earth (most of which were led by non-technical managers with no respect for/understanding of solid software development principles) and you end up with a pretty sorry state of affairs.
I’ve been fortunate to either know or find some good talent in our murky local talent pool, but it can take me months of tedious interviews to hire for a single position. For the future of Highwinds, I’m hoping that as we continue to grow we can support a co-op program. It’s sadly true that the most talented engineers don’t tend to use traditional recruitment means to find work, so you have to find them while they are still young, impressionable, and in college and snap them up before anybody else gets to them. I’m being overly sinister of course, but getting the first shot at hiring somebody from college in exchange for a few semesters of apprenticeship under a seasoned team strikes me as a good deal for everybody involved.
And once they are on board? Let the enablement begin.
Joel Spolsky recently blogged about what he calls a “duct-tape programmer.” The blog post made the rounds with a few people at the office after my boss brought it up at lunch yesterday.
From what I read, Joel’s opinion is that it’s better to ship usable software than spend time engaging in architecture cosmology, which nobody with a moderate amount of experience and any sense would disagree with. However, Joel makes his point by drawing two totally different extremes and making some statements that completely conflict with both my experience and common sense.
The first extreme is the “duct-tape programmer.” Joel lists a person of this description’s attributes as the following.
- Not afraid to speak up when another programmer is pitching an overly-complicated solution.
- Comfortable with a 50%-good solution that ships over a 99% solution that nobody uses.
- Focuses on shipping as a top concern.
- Avoids complicated coding and difficult frameworks/libraries/languages/techniques that are too hard for the human brain to handle.
- Doesn’t give a shit what others think about them.
- Spends little to no time writing unit tests.
- Smart enough to do things like xor the “next” and “prev” pointers into a single DWORD (which makes you wonder how they are not smart enough to work with some of the languages/libraries/frameworks/techniques that are apparently so hard to grasp – but whatever).
The second extreme is the “architecture astronaut.” Here’s the attribution for this person.
- Likes over-complicated solutions too hard for the average programmer to understand.
- Bullies other programmers in to using their frameworks/solutions by relying on the level of complication in code that only they understand as a barrier to objections.
- Likes multiple inheritance.
- Spends more time writing frameworks than shippable code.
- Attends design pattern meetings.
- Speaks at conferences, writes articles and books.
I have a little perspective on this since (like most software engineers with a few years under their belt) I’ve both been and dealt with both personality extremes during my career. Both extremes are equally damaging to software products in different ways.
Let’s start with the duct-tape guy. I’d say most of the attributes for this personality type are positive qualities; pragmatism, the self-confidence to disagree with bad ideas, a tendency for choosing the simpler approach, and a focus on making a shippable product. The quality of this guy that really bothers me is the lack of use/respect for unit testing, and the tone Joel takes with unit testing in general in his post. The argument seems to be that unit testing takes too long to do and doesn’t support rapid development and isn’t worth it.
This is utter nonsense. I’ve been on projects where the only reason we were able to ship in a short timeframe is because we unit tested early and often, and were able to spot bugs within seconds of them being added to the codebase, which saved time we would have spent debugging broken code later in the product lifecycle.
The thing with unit testing is that you have to be pragmatic with it as well. Looking to hit 100% coverage? You’re wasting your time. Only testing a handful of methods? You’re missing out on important stuff that will bite you in the ass later. Writing the core of an app with a GUI? If you wait to test until the GUI starts coming together, how do you know your code works? I’ve met nobody, and I mean truly nobody that is good enough to write code the first time and get it right every time. In the absence of unit tests, you find yourself manually testing everything from whatever presentation technology/transport you are using to ensure that it works, which is both slow and error-prone. The point is, choose a reasonable amount of coverage (60%-80% tends to be the sweet spot in my experience) and use it to your advantage.
So what about the astronaut? Well, this guy suffers from two problems: he’s not a very good programmer, and he has an awful manager.
Why isn’t he a good programmer? My experience has been that programmers go through four stages when learning a language or framework. As a novice, they barely understand what they are doing and mainly follow the advice of others. As they gain competence, they acquire understanding at a level that makes them productive. As an advanced user, they start pushing the limits of the technology and doing tricks with it, but their solutions are complicated and inelegant. As an expert, they learn to get the seemingly complicated stuff done in a manner that others can understand with little effort and put to use just as easily.
Clearly, if the astronaut is making frameworks that are that complicated, they aren’t helping anybody. Using Spring as an example, the reason it’s such an excellent framework is that that it makes every part of itself so easy to use. The source code I have seen in Spring is terse and easy to follow, even though it deals with advanced techniques. This is the mark of expert programming worthy of respect.
Why does his manager suck? Because they’re not keeping this guy on a tight enough leash to focus on what’s important, which is getting stuff done and writing maintainable code that anybody can walk in to and change. Instead, the astronaut is stroking his ego writing frameworks and libraries to “prove” how awesome he is at using the language. I can say this with confidence because I’ve been there and done it earlier in my career, and just like the astronaut, I pulled the wool over my manager’s eyes as well. Luckily, I came through the other side, but I’ve seen lots of people get stuck at this stage. They are easy to spot: they are the people who write code that only they understand – not because it’s good, but because it’s unreadable and unnecessarily complicated. A true expert with the language would certainly be able to slog through this spaghetti, but they’d spend most of that time wanting to punch the astronaut in the face for making it so hard on everybody else instead of making something elegant.
That’s not all. There are some other things that simply don’t make sense or conflict with themselves in Joel’s post.
If you write an app with no unit tests and ship it, unless you either (a) never have to change it again or (b) wrote a trivially tiny app, you are likely to find yourself having a really hard time refactoring/adding to it. After all, you’ve got no test suite to validate your changes and prove that you haven’t broken anything. The only way you could even say that you were confident the code still worked in the absence of a test suite is to be able to hold all the details about the app in your head (every branch, every scenario, etc.) which Joel already stated is too hard for the average programmer.
If you are using a technology that is overcomplicated and/or is buggy (C++ on Windows, CORBA, COM, etc.), then use something else. Techniques like multiple inheritance aren’t so much difficult to grasp as they are generally acknowledged as a code smell in 90% of use cases. And to say that multi-threading is going to doom your project because it can be complicated is really kind of a stupid thing to say; there are some things that simply can’t be done effectively/performantly without multi-threading. Its use should be limited in scope accordingly and written by somebody who understands threading. I don’t think anybody writes multi-threaded code for the fun of it, except perhaps for the astronaut who we’ve already proven is an epic douche to begin with.
There’s a general tone to the post that any time spent on creating utility library/framework code and/or researching elegant solutions is wasteful. This is a bad generalization. I once had to help save an app at the eleventh hour that one of the guys on my team had spent two months writing. It had failed an embarrassing number of QA drops due to input validation failures. Why? He hadn’t spent any time writing a basic framework for the validation concerns of the app, and every time he patched the bugs found in QA, something else got broken or acted inconsistently with other parts of the app. I sent everybody except me and my programmer home, spent an hour writing a simple validation framework, and we spent the night plugging it in to the app. It passed QA the next day. When I asked him why he hadn’t taken the time to do this in the first place, he said he was under pressure to get the app delivered and didn’t have time to implement a cleaner solution. It goes without saying that excessive architecture is wasteful and damaging, but no architecture at all is just as bad. Liek everything else, you need to be pragmatic and pick sensible battles.
To summarize: no doubt, programmers should spend 90% of their time writing shippable code that is useful to end users, implemented in the simplest way, using the easiest thing that works. However, to unilaterally throw out unit testing and claim that any level of design work or framework implementation is a bad quality is a dangerous oversimplification that I fear many of the people following Joel’s blog may be inclined to interpret as good advice.
I wanted to try out the DirectoryStream class in nio.2, but unfortunately it’s in Java’s 1.7.0 JDK and Apple hasn’t seen fit to get that out yet.
I was able to get most of the way through the build process described, and hit a roadblock.
Compiling /Users/mporges/bsd-port/hotspot/src/share/vm/runtime/arguments.cpp rm -f arguments.o g++ -D_ALLBSD_SOURCE -D_GNU_SOURCE -DIA32 -DPRODUCT -I. -I../generated/adfiles -I../generated/jvmtifiles -I/Users/mporges/bsd-port/hotspot/src/share/vm/asm -I/Users/mporges/bsd-port/hotspot/src/share/vm/c1 -I/Users/mporges/bsd-port/hotspot/src/share/vm/ci -I/Users/mporges/bsd-port/hotspot/src/share/vm/classfile -I/Users/mporges/bsd-port/hotspot/src/share/vm/code -I/Users/mporges/bsd-port/hotspot/src/share/vm/compiler -I/Users/mporges/bsd-port/hotspot/src/share/vm/gc_implementation -I/Users/mporges/bsd-port/hotspot/src/share/vm/gc_implementation/concurrentMarkSweep -I/Users/mporges/bsd-port/hotspot/src/share/vm/gc_implementation/g1 -I/Users/mporges/bsd-port/hotspot/src/share/vm/gc_implementation/parallelScavenge -I/Users/mporges/bsd-port/hotspot/src/share/vm/gc_implementation/parNew -I/Users/mporges/bsd-port/hotspot/src/share/vm/gc_implementation/shared -I/Users/mporges/bsd-port/hotspot/src/share/vm/gc_interface -I/Users/mporges/bsd-port/hotspot/src/share/vm/interpreter -I/Users/mporges/bsd-port/hotspot/src/share/vm/libadt -I/Users/mporges/bsd-port/hotspot/src/share/vm/memory -I/Users/mporges/bsd-port/hotspot/src/share/vm/oops -I/Users/mporges/bsd-port/hotspot/src/share/vm/opto -I/Users/mporges/bsd-port/hotspot/src/share/vm/prims -I/Users/mporges/bsd-port/hotspot/src/share/vm/runtime -I/Users/mporges/bsd-port/hotspot/src/share/vm/services -I/Users/mporges/bsd-port/hotspot/src/share/vm/utilities -I/Users/mporges/bsd-port/hotspot/src/cpu/x86/vm -I/Users/mporges/bsd-port/hotspot/src/os/bsd/vm -I/Users/mporges/bsd-port/hotspot/src/os_cpu/bsd_x86/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"16.0-b08\"" -DHOTSPOT_BUILD_TARGET="\"product\"" -DHOTSPOT_BUILD_USER="\"mporges\"" -DHOTSPOT_LIB_ARCH=\"i386\" -DJRE_RELEASE_VERSION="\"1.7.0-internal-mporges_2009_09_23_22_44-b00\"" -DHOTSPOT_VM_DISTRO="\"OpenJDK\"" -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -pthread -fcheck-new -m32 -march=i586 -mstackrealign -pipe -O3 -fno-strict-aliasing -DVM_LITTLE_ENDIAN -Werror -Wpointer-arith -Wconversion -Wsign-compare -D_XOPEN_SOURCE -D_DARWIN_C_SOURCE -c -o arguments.o /Users/mporges/bsd-port/hotspot/src/share/vm/runtime/arguments.cpp cc1plus: warnings being treated as errors /Users/mporges/bsd-port/hotspot/src/share/vm/runtime/arguments.cpp: In static member function 'static void Arguments::set_aggressive_opts_flags()': /Users/mporges/bsd-port/hotspot/src/share/vm/runtime/arguments.cpp:1398: warning: format '%d' expects type 'int', but argument 3 has type 'intx' make: *** [arguments.o] Error 1 make: *** [the_vm] Error 2 make: *** [product] Error 2 make: *** [generic_build2] Error 2 make: *** [product] Error 2 make: *** [hotspot-build] Error 2 make: *** [build_product_image] Error 2
A little Googling led to this thread on the OpenJDK mailing lists. Apparently there are some issues installing 1.7.0 on Snow Leopard, although one of the guys got it working by using gcc-4.0 and g++-4.0 rather than the 4.2.x versions installed on Snow Leopard.
I don’t really feel like installing older gcc and g++ versions on to my Mac and modifying the build to use them, so I’m hoping they can get this addressed soon so that OpenJDK will build on the mostly-vanilla Snow Leopard distribution.
When using Apache Axis, you often want to generate the service stub code from a WSDL file provided by the remote API developer. We recently ran in to this situation at Highwinds.
What we wanted to do was keep the WSDL in source control, and use Maven to build the source from the WSDL at build time during the generate-sources lifecycle hook. This seemingly simple task ended up taking me some time to figure out – not because it was hard, but because there are so many bad implementations of Axis plugins for Maven out there, and Google has all of them in its sights.
Finally, I found a really nice implementation by the Codehaus guys. Here’s the POM for those of you who might be interested. Enjoy!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69
<?xml version="1.0"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd"> <modelVersion>4.0.0</modelVersion> <name>Sample Axis-Maven Project</name> <groupId>com.maximporges</groupId> <artifactId>axis-maven</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>jar</packaging> <build> <plugins> <plugin> <groupId>org.codehaus.mojo</groupId> <artifactId>axistools-maven-plugin</artifactId> <version>1.3</version> <configuration> <!-- The plugin navigates your source src/main/** tree and finds your WSDLs for you; just name them individually in a <wsdlFiles/> element. --> <wsdlFiles> <wsdlFiles>MyWsdlFile.wsdl</wsdlFiles> <wsdlFiles>MyOtherWsdlFile.wsdl</wsdlFiles> </wsdlFiles> <!-- This is optional, but lets you explicitly namespace the generated code. --> <packageSpace>com.whatever.i.want</packageSpace> </configuration> <dependencies> <!-- Required for attachment support; you can remove these dependencies if attachment support is not needed. Note that if you do want it, you have to specify the dependencies both here in the plugin and also in the POM dependencies. --> <dependency> <groupId>javax.mail</groupId> <artifactId>mail</artifactId> <version>1.4.1</version> </dependency> <dependency> <groupId>javax.activation</groupId> <artifactId>activation</artifactId> <version>1.1</version> </dependency> </dependencies> <executions> <execution> <goals> <goal>wsdl2java</goal> </goals> </execution> </executions> </plugin> </plugins> </build> <dependencies> <dependency> <groupId>org.apache.axis</groupId> <artifactId>axis</artifactId> <version>1.4</version> </dependency> <dependency> <groupId>javax.xml</groupId> <artifactId>jaxrpc-api</artifactId> <version>1.1</version> </dependency> <dependency> <groupId>javax.mail</groupId> <artifactId>mail</artifactId> <version>1.4.1</version> </dependency> <dependency> <groupId>javax.activation</groupId> <artifactId>activation</artifactId> <version>1.1</version> </dependency> </dependencies> </project>
Eclipse’s software installation process is something of a train wreck. So, when I finally crack the code for installing a particular plugin, I feel compelled to both (a) document the arcane path and (b) share it with others.
As a result of my workhorse “Java + FB Plugin” Eclipse installation steadily progressing in to a state of unworkable slowness and a fresh Cocoa-native build of Eclipse hitting the scene a few months back, I decided to install standalone Flex Builder alongside the Cocoa Eclipse build. The Flex Builder standalone edition is really lightweight, but I like to round-trip debug on my local machine, so by having both FB and the Cocoa Eclipse build I can run Flex in FB and a Java server in Eclipse and do round-trip debugging.
After installing FB standalone, I decided to install m2eclipse in to it. m2eclipse is an excellent plugin for working with Maven directly from Eclipse, and since we use flex-mojos at Highwinds, it’s a necessity for making our build and dependency resolution process seamless.
Typically, this would be a simple process: set up the m2eclipse update site in FB, run the installer for new features, select it, resolve dependencies, and be done. But no, God forbid it be that simple. If you simply resolve the handful of dependencies indicated by Eclipse during the installation one by one, the plugin doesn’t show up. After finally figuring out the magic incantation required to install m2eclipse in to FB, I have documented the process below.
Klaatu… Verata… Necto! (a.k.a. How to Install m2eclipse in to Flex Builder 3)
1) Install Flex Builder 3 standalone
2) Go to Help => Software Updates => Find and Install
3) Select “Search for new features to install”, hit Next
4) Click “New Remote Site”, entering http://m2eclipse.sonatype.org/update/ as the URL and naming it whatever you like.
5) Check the box next to the site that you just created in step #4. Also select “Europa Discovery Site” and “The Eclipse Project Updates”, select “Automatically select mirrors”, and click Finish.
6) Expand the tree for the m2eclipse project site. Open the “Maven Integration” project and select the “Maven integration for Eclipse (Required)” item as well as the “Maven POM XML Editor” and “Maven POM Editor.”
7) Eclipse will complain that you don’t have all the appropriate dependencies. Expand all the top-level trees in the view you are looking at (i.e., “The Eclipse Project Updates”, “Europa Discovery Site”, “Eclipse GEF”, etc.)
8) Click “Select Required.” About twenty dependencies will be selected in all the different trees. Some are for Eclipse’s modeling framework, others for the Web Tools Project, etc.
9) Click Finish. Eclipse will download a metric assload of files and prompt you to restart FB. After the restart, Maven will be installed.
I hope somebody else finds this useful and doesn’t have to spend an hour figuring this out like I did.
My buddy Sean Tierney recently posted on taxation for fast food. The topic touched on the health insurance debate presently taking place. I posted a wall of text to his comments section, but I thought I would repost it here since I’m interested in what people have to say about the future of American healthcare.
First, let me give you my political perspective. I’m an Independent, but I’m also a big believer in free-market principles and smaller government, which my educated friends tell me are Republican ideals. I’m the kind of person who doesn’t mind paying taxes and seeing them put to use for the greater good, but I don’t trust government institutions to make these decisions very well. In my experience, government is great at slowing things down and making them harder, which is why I believe they should continue to be in charge of regulating the free market, but doing so at arm’s length. I also think the government is a necessary evil where there is no viable business model for a service needed by the public.
So with that in mind, let me present my healthcare proposal.
Max’s Healthcare Proposal
I’d like to see healthcare insurance go the route of car insurance, using the same free-market principles but putting the responsibility on the people and not the government.
Start by reducing medical costs by making it possible for doctors to charge less for their services. Obvious solutions include malpractice tort reform; that bit will probably require the government to get engaged, but perhaps not at the federal level.
Once doctors can charge less and operating costs are lower, insurance companies can charge less for their health insurance policies. At this point, my employer should increase my salary by some portion of the amount they used to pay for my health insurance. I’ll then take this money and will go shopping for health insurance on my own, just like I buy my car insurance.
Insurance carriers will be forced to offer competitive pricing and innovative methods for cost reduction to win my business. This will include removing bureaucracy, simplifying billing practices, and implementing efficiencies in their own organizations (probably with technology). Likewise, doctors can innovate to offer affordable care, allowing them to better compete for my business and be innovators in cost reduction also using similar means. Dinosaurs who don’t want to change will go out of business; good riddance.
With those changes in place, it’s now up to me to take care of myself. If I eat crappy food, smoke, and don’t exercise, my medical and health insurance costs will be higher, financially motivating me to change my behavior. If my behavior doesn’t change, eventually economic forces will leave me no choice but to change, or I will die and remove myself as a problem. If my behavior does change, the tobacco and unhealthy fast food companies will suffer as they lose my business; they will also either change their products or die. Once again, good riddance.
This leaves open the issue of the uninsured. This is where the government would be involved once again, offering some solution that would probably need to be paid for by taxation or reduction in costs elsewhere. I think these are reasonable solutions to this problem.
Obviously, I’m drastically oversimplifying what would be a long and difficult process, and a lot of things would have to happen in sequence with proper effect to make this work. To be honest, I don’t know of another solution that would enable the free market to solve our healthcare crisis, and I’m pretty sure based upon past experience that the government won’t be able to come up with a solution that doesn’t suck.
Welcome to the latest incarnation of my blog, which is now hosted on DreamHost and driven by WordPress. I kicked the tires with importing my content from Blogger last weekend, and decided to pull the trigger today while recovering from having my wisdom teeth yanked from my skull on Friday.
I’d like to give credit to the people with design skills that made my theme possible. After a little digging I found a theme that was pretty close to what I wanted, and customized it a bit with some artwork from Exploding Dog.
Unfortunately, the new platform won’t make my writing any better; I’ll still be blogging about how much I hate computers and what an awful programmer I am. However, now that I can easily publish some extra pages, I have designs on expanding the site content a little to include my musical/home studio interests, and maybe even some of my white papers and presentations from the past. I hope you enjoy it!
Oh, and if you don’t get the tagline, just watch this.
Most Popular Yelling
- Scrolling Large Data Sets in Flex Charts (41)
- Configuring Tomcat SSL Client/Server Authentication (19)
- Fixing "Bluetooth audio failed" Error Message on Mac OS X with Sony DR-BT50 Headphones (16)
- How To Become A Software Engineer/Programmer (15)
- Speak and Spell Samples (13)
- Using Axis's wsdl2java in a Maven Build (12)
- An Objective-C Tutorial for Enterprise Java Programmers (12)
- On A Personal Note (10)
- Abandoning ColdFusion? (9)
- Adobe Says: "Thousands of Developers are using CF 8" (9)
Stuff I Like
- October 2011
- August 2011
- April 2011
- March 2011
- January 2011
- December 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- January 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- January 2007
- December 2006
- August 2006
- July 2006
- June 2006
- April 2006
- February 2006
- December 2005
- November 2005
- October 2005
- August 2005
- July 2005
- June 2005