Tuesday, December 22, 2009
I just installed it on a 64-bit XP box, only to see this screen when I tried to run it:
Having no idea what this means, I googled it. (which quickly pointed me to the readme, which is linked on the download page for the toolbox itself. Silly me, I should have read it first. The readme document used a very wild font, but it boils down to this:
Without a hotfix, the toolbox does not work correctly on Windows XP 64-bit. The hotfix you need is supplied on this page (also linked in the readme). The details don't look related to shadow copying, and you have to jump through a couple of hoops to get it.
After you 'View and request hotfix download', give Microsoft an email address, and submit a form...you will get an email with a link to the hotfix, and the password for the password-protected zip file it contains with a password that changes weekly! I have never before had to 'request' a hotfix file, let alone enter a password - I completed the process diligently though, as a secret agent might do, and now the Intel SSD Toolbox is working on my Windows XP x64 machine.
NOTE: The reason it's so much work to download the hotfix is probably because, as of this writing, the hotfix has not undergone full testing. Also, it is a very specific hotfix for Windows 2003/XP x64*. It recommends staging (i.e. non-production upgrade first). You should backup your files and perform this on a non-critical machine first, or update at your own risk.
* windows XP x64 is based on Windows 2003, so it is distinct from 32-bit XP.
This post is for personal reference, as well as for the 10 seconds it might save someone else out there. It seems like kind of a strange edge case...
Monday, November 30, 2009
I noticed that past the half-way part, it became difficult to have enough complete content to write about. I had plenty of ideas, but many of them weren't really refined or complete enough to make a good post about without further effort. I can see how writer's block could really suck.
Of the topic ideas I listed in my October post, I covered most of them to varying degrees. There are some that I have not yet written about, though:
- More on SSDs
- Java 7 feature (my thoughts)
- Test ownership
- Notable programming books in the last 1-2 years
- More on build tools (Maven 3 and Gradle, specifically)
- My Erlang experiences, as I learn it
- Solving my Apache/HTTPS/TortoiseSVN authentication issues
- What are some notable programming books in the last 1-2 years?
- Guice, and other dependency injection frameworks (I have not used Spring or Guice)
- Taking Linux Mint for a spin (version 8 just came out)
- Experimenting with Saros, the Eclipse Distributed Pair Programming plugin (I've yet to try it - but I am enthused!)
Sunday, November 29, 2009
- I finished reading 'The Tipping Point', and started my next book
- I did poorly on the Erlang front - I only read a few pages and installed the Erlang package for Windows. I need to do better next week.
- I did finish Java Puzzlers
- I did NOT experiment with any more new build tools. I fail on this one.
Goals for the week starting 11/30/09:
- Continue reading 'Pragmatic Thinking & Learning'
- Get through the first 2 chapters of 'Programming Erlang', and if possible, code a Project Euler problem solution in Erlang.
- Practice my TDD more
- Post on Monday, completing my 1 post a day for a month goal as part of NanoWrimo
Saturday, November 28, 2009
Pragmatic Thinking & Learning: Refactor Your Wetware, by Andy Hunt.
I started reading it early in the week, and it will be part of my nightly reading until I finish. I'm always interested in better ways to learn - and I saw Andy Hunt's talk on this prior to it becoming a book. I'm not sure why it took me so long to get around to it - but it's finally in my goals and I'm reading away :)
In the queue after this is:
- Java Concurrency In Practice
- Filthy Rich Clients
What are people reading these days? It's been a few years since I've looked at a recommended reading list.
Friday, November 27, 2009
If you're not familiar with the book - most of the puzzles showcase a smallish snippit of code, with the question of 'what does it print' (or does it even compile). These puzzles are fun to think about, but most of them don't involve writing any code. (Some of them DO ask you how to write code that accomplishes some strange behavior, though - but only a few).
I'm looking for, or rather I suppose I'm writing about what I will do next. I have a couple of ideas - one being to finally march my way through Programming Pearls. The favorite book of one of my favorite professors in college. It provides ample coding exercises - many of which involve low level tricks.
Another idea that didn't occur to me until I started writing this entry is Project Euler. It's a great source of coding problems. I've done maybe a dozen previously, but as of this writing there are 265 of them. What's great is these are the type of problems that are useful to repeat again in different programming languages.
What's got me focusing on this is some recent posts I've read about Coda Katas. In particular I read this post on the Object Mentor blog tonight. There are a lot of links to other material there.
One further idea is to look up problems from the ACM's International Collegiate Programming Competition Problem Set Archive. There are countless good programming problems on that page.
There is definitely value in practicing what we do. This applies to any craft - but it seems to be sometimes neglected in ours. I think some kind of coding practice (in addition to testing practice) will be in my goals for next week. In particular to solve a new Project Euler problem or two, and to maybe do one from Programming Pearls as well.
What resources do you know of for good programming problems?
Thursday, November 26, 2009
I'm really glad MySQL exists. It's just really pleasant to develop against. It couldn't be simpler (well, maybe it could be - but I challenge someone to provide me with an existing example) I've developed both Java and C++ applications with Microsoft SQL Server and Oracle, and while I think there are good tools in both of those realms (especially in the case of SQL Server), MySQL is just so light weight and easy to develop against by comparison. It just rocks. As with anything, it isn't perfect - but I am thankful I get to use MySQL.
I'm thankful for the great variety of virtualization software that is available today. VMWare and VirtualPC have been around for a long time, but now there's also Virtualbox, and on my Mac I use Parallels. I can virtualize on any machine I use. Hardware CPU support makes it even better. Virtualization rocks as a tool for experimentation, and it has plenty of other uses. For instance, we currently do our WAN testing by using VMware server and a WANem Linux ISO
Tuesday, November 24, 2009
- Findbugs plugin (less useful once you have Continuous Integration that reports this, but still cool)
- EclEmma (Code coverage highlighting in Eclipse with an Emma junit test runner)
- SwingExplorer - very sweet way to delve through swing code and familiarize yourself with the GUI code in a project
Monday, November 23, 2009
So far I'm very pleased with the transition, and I haven't had any major issues. A few applications had issues installing explorer context menus, but that wasn't a perfect situation even on XP 64-bit, and I've mostly sorted it out at this point. Every Windows 7 machine I currently use is a 64-bit install. For the last year I've been 64-bit (XP) on my work machine, so I am already familiar with any platform differences there.
UAC doesn't bother me - I'll most likely dial up the setting a bit, as the default isn't strong enough protection.
One thing that currently gets me is I can open my.ini (MySQL configuration file) in notepad (from explorer), but then I don't have permission to save the file once I edit it. It would be nice if it prompted me, instead of just failing. I do not see a right click menu option for "open as admin", but running notepad from an admin console solves the problem.
I tried "Windows XP Mode" for the first time today at work (it being Professional - which is a requirement). I was unimpressed with the performance of the installation of our app (4GB install and tens of thousands of files), but the actual execution speed of running applications in it was fine. I'll probably use it occasionally, but I don't think there are a whole lot of cases where I will need it.
What transition issues are people hitting? I'm curious how many people are trying it, and more curious when business roll outs will start in earnest.
Sunday, November 22, 2009
- My emphasis on fast tests has gained some stickyness in the office. I have a way to go personally, but progress is being observed.
- Read another 50-60 pages of 'The Tipping Point'
- Did 2-3 more Java Puzzlers (in the last, 'advanced' section)
- Made daily blog entries - one week and one day left to achievement of my larger goal
Goals for the week starting 11/23/09:
- Finish reading 'The Tipping Point'
- Get through the first 2 chapters of 'Programming Erlang'
- Finish the remaining Java Puzzlers
- Experiment more with new build tools
Saturday, November 21, 2009
It's been 4 years since I read Pragmatic Programmer, but I haven't really put serious effort into any completely different languages. I'm going to make it a goal to start learning Erlang for my LOTY, learning something new each week. Fortunately, I already have Programming Erlang, so I should have some good material to guide me.
If you are in the Java world - there are some great candidate languages that can run on the JVM. Meaning you can start playing with them right now in a Java environment. Scala and Clojure are probably the most frequently mentioned, but I believe there are over 200. This makes it really convenient to try new languages, as if you want to showcase any projects to friends, all they need is Java.
To sum up - there are less excuses to NOT try a new language these days. There are a ton of options out there, so try one and have some fun. I'd love to hear some suggestions.
Friday, November 20, 2009
In his post, he provides a starter project that can be grabbed from a Mercurial repository and used to practice TDD. The basic code is already layed out, including the first few tests. He even describes how to turn on a setting in Eclipse that will run your tests every file save. Slick - I didn't even know that was possible. That is serious TDD.
I consider this a personal testing homework assignment - I encourage anyone reading to do the same.
I will try to remember to post my resulting source & test code when I finish.
Thursday, November 19, 2009
Doesn't Hudson know how to automatically install JDKs now, you ask? Why yes, it does, but it doesn't always have the latest JDK updates. Apparently update 18 fixes some obscure issue that one of our customers has, and according to Ninite it is already out, but I can't yet find it on java.sun.com.(Apparently snapshot releases can be found here.)
After deducing the JDKs use an MSI installer (although packaged within an exe), I enabled verbose logging and found out the names of the feature groups:
On to the point, to perform a silent installation (in this case jdk 1.6.0_17), simply do:
jdk-6u17-windows-i586.exe /qn ADDLOCAL=ToolsFeature,SourceFeature,JavaDBFeature INSTALLDIR=c:\jdk1.6.0_17 REBOOT=ReallySuppress
- /qn means "No UI"
- INSTALLDIR is self explanatory
- REBOOT has a few options, I chose ReallySuppress
- ADDLOCAL - Specify a comma-separated list of features you want from the list shown earlier, or you can use ADDALL
At last, I have my auto install script that I can remotely run on a bunch of machines with PsExec.
Wednesday, November 18, 2009
It's about time I took a closer look at Gradle. The most obvious cool feature is that you can write your build scripts using Groovy. This is sweet. Beyond that, it is probably easiest to list Gradle's own summary, as of this writing:
- A very flexible general purpose build tool like Ant.
- Switchable, build-by-convention frameworks a la Maven, for Java, Groovy and Scala projects. But we never lock you in!
- Groovy build scripts.
- Powerful support for multi-project builds.
- Powerful dependency management (based on Apache Ivy).
- Full support for your existing Maven or Ivy repository infrastructure.
- Support for transitive dependency management without the need for remote repositories and pom.xml or ivy.xml files (optional).
- Ant tasks and builds as first class citizens.
What I think has extremely high potential is the idea of pluggable build frameworks, a la maven support. Use all of the best pieces of tools from one - Gradle. I think they could go a really long way with this, and it will remain a strong contender as I also take a closer look at some of the new Maven 3 features.
Downloading and extracting gradle-0.8-all.zip, one thing is immediately obvious. Comprehensive documentation and examples FOR THE WIN!
I can't even describe how frustrating playing with maven 2 was three years ago. Documentation was hard to understand, and the basic example tutorials just didn't cover my needs. I ended up banging my head a lot, when all I really needed was some good sample poms illustrating all of the tool's features. Gradle provides this out of the box and scores major points for it. I haven't even looked at the website docs in detail yet, but they seem easy to follow.
Tuesday, November 17, 2009
Here's a presentation that happened all the way back in April. I'm sure there are more recent ones, so I'll try to update with additional links. There are (not surprisingly) quite a lot of good posts on the Sonatype blog. In particular, there is a series of posts titled "Paving the desire lines". It's very satisfying reading a developer talk about the small finishing touches to a project with real passion. I haven't read the whole post yet (and I spot 2 parts so far), but it has my appetite whet.
Maven 3.0 alphas have been coming out recently, with Alpha 3 coming out last Friday. I just grabbed it tonight (seems to be alpha 4 now) and took it for a quick spin. To test it, I built Hudson/main, which has 4.0.0 POMs.
This merits close following...
UPDATE: Walter linked a more recent video+slide presentation by Jason van Zyl
Monday, November 16, 2009
If you navigate to the 'What Build Tool are you using in 2009?' poll (I can't post a direct link, sorry, but there are only 3 polls to choose from), you will see quite a selection of tools.
Unfortunately, right now I'm that single Maven 1.x user (along with some Ant). It's tough - things work well enough, but there is no direct path to Maven 2.x for us (oh maven.xml, you looked so helpful, but you've trapped us!). In its defense, this project was using Maven 1 back in 2004. It's not surprising that in 5 years some cruft has accumulated.
I am fed up with having to write build scripts in XML, so even if a Maven 2 migration path was simple, I'm not sure it's desired. Gant would get rid of the XML while keeping familiar territory - but I feel like I need something richer than basic Ant. Gradle looks very promising, and I've been meaning to read up on some of the threads on where Gant and Gradle are going to get a better idea of things, but I haven't yet.
Lo and Behold, while pulling up links for this blog post... I stumbled upon a post about Maven 3.
Support for several build script file formats? YAML, Groovy? Hell yeah! I am going to have to do my research on this one.
I wasn't quite sure where I was going with this post, but I think I'll sample some of the build tools I've mentioned (including early maven 3 builds) and report in on them. If I'm motivated, maybe I will do a 'Hello World' project in each build tool. Gant, Gradle, and Maven 3.
Sunday, November 15, 2009
- Much of my week was reactionary, so I didn't write much new code and I fail on the 'test more' front.
- I read another 100 pages of The Tipping Point
- I did a couple more Java Puzzlers (on 83 or 84 of 95?)
- I wrote and posted my book review
- Updated Hudson on latest build server to use 1.333
- Continue emphasis on testing
- Continue reading 'The Tipping Point'
- Continue doing Java Puzzlers
- Keep posting daily
Saturday, November 14, 2009
What's a vertical mouse, you say? Mine looks like this:
The concept is that by keeping the hand in a neutral position, wrist pain will be alleviated - and it does.This mouse is amazing. It has basically eliminated my wrist pain. There's just one problem, well, two.
- They're hard to find (the website looks somewhat abandoned)
- They're expensive for what they are
Now this is a mouse made to address a specific problem. I'm not advocating widespread use (but maybe I should? It would make my life easier...). I literally do not travel without one when I know significant computer use will be in order.
What, if any, special input (or other devices) do you rely on for PC use? Have you taken the time to find a good keyboard (and normal mouse)? If not, why not??? If you spend half of your day using something, it should be as comfortable as possible.
Friday, November 13, 2009
Here is the interesting bit - it can't really be tortoise' fault, as it clearly still knows the password based on the following behavior:
After it prompts you for the password that you had it remembering (that you had told it to remember previously), if you hit cancel and try your commit again, it won't prompt and it will work. Clearly the credentials remain stored, but some client/server interaction causes it to fail to authenticate sometimes. This happens very frequently. Most of us don't even bother checking the box anymore. (which would be a better practice from a security standpoint, but we all have our faults)
The moving parts:
- Subversion 1.5.x Server
- Apache 2.x
- TortoiseSVN (1.5.x)
- Active Directory (our authentication is against our standard AD credentials)
Thursday, November 12, 2009
Inspiration and General Value
I got the book after attending the 'Career 2.0' talk at NEJUG. Like the talk, the book ranks very high on the inspiration front. After all, the talk is why I started this blog. If you're looking for ideas and a general kick in the butt, this is a good book for you. I enjoyed reading it, and I feel I got a good value out of it. As a direct result of reading it, I've been actively working on my career, setting goals, and generally doing more good things.
I even credit the book with successful weight loss. In it, there is a very profound statement regarding goals. If you don't break them down into steps you do today, they don't get done. I can't eat dessert tonight if I want to lose weight. "I'll start dieting next week" does not work. Neither does I'll write tests tomorrow, or I'll learn a new language next year. This applies to everything in life.
Polish, Quality, and Nitpicking
Now that I've talked about how motivational the content is, I have to take a step back and report in some unfortunate quality issues. To be frank, there are a lot of editing errors, as well as some print errors that detract from an otherwise good experience. I find it really distracting when I read a sentence that has extra words that don't belong, or that are in the wrong order. As below:
...it's possible for you to be unexpectedly job hunting at the time same as hundreds...Now I can forgive an error or two, but there are a lot of what I would deem trivial wording issues that caused me to re-read sentences 2 or 3 times. These should have been caught prior to print, and hopefully these were fixed in the digital version, or in future print versions. Mine, however, has some serious issues. There are grey box side stories in various parts of the book. There were 2 instances where a sentence was cut off by a grey box (or a sentence in a grey box abruptly ended) and never finished. Content is missing. I also assume that in a digital version this would not have happened, and it is some artifact of things getting cropped badly in print only. Either way, I have the print version and this really bummed me out.
I enjoyed the book, errors aside, and there are some good stories and good advice in it. There are hand-drawn sketches throughout the book, which I found a refreshing change from the usual. I will certain be referring to the book in the future, and will be re-reading certain portions. Were it not for the print issues, it would get a strong recommendation. As it stands - I would say try the digital version if you want to read the book. There is definite value, there are just a few distractions as well.
Wednesday, November 11, 2009
You can enable the extra options by unchecking the checkbox for:
Preferences -> Java -> Use Reduced Search Options
Here's the before (with appropriate part of right click menu cropped in each version):
And here is after:
It's incredibly useful to be able to do easy searches for read and write access on your variables, so hopefully someone out there sees this for the first time. Hats off to my boss for sharing this knowledge with the rest of us today - he has used it for a long time.
Tuesday, November 10, 2009
I'm not sure if it just felt like it happened quickly, or if it really did. At the moment I'm not feeling like firing up wikipedia.
After a certain point, it seems like it became less important. Once I spent 8-10 hours a day on a PC at work, I no longer needed to do this at home. Somewhere along the line, though, something was lost. It's hard to be enthusiastic about a work machine. Sure, you want it to be fast and not get in your way, but at the end of the day, it's just not the same.
I went from 1-2 years between machine upgrades to 4 years - and I barely cared. There's still something special about doing it yourself, though, so this summer I finally upgraded from an Athlon X2 4200+ to a Core i5. That's not the whole story, but it will suffice for now.
The point is - building out a new PC, finding out all of the various motherboard pros and cons (and quirks!), selecting the other components, building it - it's been invigorating. The experience has really renewed my interest in experimentation at home. I want to try new operating systems again. I want to try X, Y, etc. It's interesting to see how things have changed, and how they haven't (You STILL end up staying up all night to setup that new machine - something ALWAYS doesn't go right). That Is The Law.
I actually enjoy using a desktop again. With Windows 7, I'll actually reinstall my OS again for the first time in a long while. (well, I've been reinstalling since Beta 1 came out) The list goes on.
I find myself reading articles late into the night, reading books, feverishly seeking more knowledge. I am excited about computers at home again.
You don't need to splurge for the latest - nowadays, hardware is cheaper than it has ever been. When I got my first 4 megs of RAM, it was $32 a megabyte! Now 4GB of DDR3 is $100. Dual and quad core CPUs are more affordable than ever. I am amazed at how lucky we as enthusiasts are these days :)
When's the last time you've upgraded? When's the last time you built a machine yourself? You may find it's a very rewarding experience. Build a file server. Build a box just to experiment with spare parts on ebay. Or use a virtual machine with a new operating system. Experiment!
Monday, November 9, 2009
1) Keeping code modular and well encapsulated
The usual good coding habits help a lot here. This is mostly the obvious splitting the duties of code (a la various MVC inspired patterns). There are some improvements over standard MVC, though. Model View Presenter, for instance, is really sweet. Currently one in-house favorite is to have a PresentationModel / View, which is a variation of that.
2) Minimize the amount of GUI code to test (make a view that doesn't have any real logic to test)
This is where Passive View comes in. Passive View is pure awesomeness. (why did I ever write views any other way...) There's very little to test if your view doesn't DO anything but display GUI components and have action handler calls. In Passive View, it's illegal for the view to ask for anything. All data is pushed to the view, it does not 'request' anything. The only permitted calls are action handler methods for when GUI components are interacted with. This action handling can even be turned into an interface, so that the view doesn't even have a real reference to the presenter/controller/etc (pattern-dependent).
Your 'OK' button not doing anything is very rapidly found even without automated tests, so as long as the real logic (which is completely absent from the view) is well tested, you are in good shape.
3) Using GUI testing frameworks (like Abbot) that simulate a user. There are similar frameworks for testing webpages...
It is possible to do automated testing of GUIs even if the first 2 items need work or are deemed insufficient. We use Abbot to automate GUI testing of important parts of our application. The tests run the same way other JUnit tests run. Most would deem these functional (not unit) tests, and I agree, because the time impact of powering up a real GUI (especially one you can't disconnect from your system) and physically typing input and clicking buttons is very noticeable.
Generally, lack of encapsulation and too many dependencies are again a real hinderance and bog down GUI testing. If you can mock out or easily disconnect the GUI from the usual, live system, then speed should be less of an issue. So with proper effort invested in 1&2, I aim to get #3 in the general ballpark of unit test times. I don't think that, following 1&2 strictly, I would write a large amount of abbot tests, but I want to try proving it's possible to have nice, isolated and relatively fast GUI tests if you want them. Maybe I'll do some speed/effort analysis on this at some point - because I'm that much of a geek.
Sunday, November 8, 2009
- My test-writing improved, but still isn't where I want it to be. I did write some tests, but not enough.
- I didn't get around to trying Guice
- I finished reading the Career 2.0 appendix, so now it is officially complete
- I read the first 50 pages of The Tipping Point
- I did a few more Java Puzzlers (on Puzzle 81 of 95?)
- Grabbed latest Hudson, but time was an issue so it isn't staged yet.
- Continue to focus on test-first and writing fast tests. Test more than I did last week.
- Continue reading 'The Tipping Point'
- Continue doing Java Puzzlers (aim for 2-3 more)
- Use Mockito more, and prepare to give a demo to coworkers
- Write a book review on 'Career 2.0' and post it
Saturday, November 7, 2009
In 2005 my primary display became a Dell 2001FP (20" LCD, 1600x1200), and my P95f became my secondary. For around a year I've wanted to find a new primary display, and I searched for several months before I settled on one.
It's 2009 - LCD technology should have advanced quite a bit since my last purchase, and you can buy more, larger, and cheaper displays than ever. Why is it so hard to find a display with good all-around characteristics? I'm apparently not the only one with this problem.
I care about:
- Color accuracy
- Response time
- Input lag
- Warranty, dead pixel replacement policy
- Adjustable stand (height, swivel, and ability to invert display vertically)
- Viewing Angle
- Menus and general configuration ability
My search was for a 22-25" display with a resolution of 1920x1200 or higher. Being used to 1600x1200, I wanted to maintain at least the same vertical resolution. I also wanted IPS, as it seems to have the best characteristics of the three (best color, low input lag (though more than TN), good response time). In the $350-750 range, I wanted a display that fit my needs.Good IPS displays before the $1000+ range seem quite hard to find.
One of the biggest challenges is where to BUY an LCD from. You want absolute certainty you will be happy with the color, and you want to be safe from dead pixels. Big box stores typically don't carry higher quality LCDs, since most people just want something cheap. I ruled out Newegg, as they have an 8 dead pixel policy before a display is eligible for return. No thanks - I do other shopping there, but not for an LCD.
Along the way, I've found a great LCD review site: TFT Central. After reviews ruled out some of my other choices, I noticed a new display that just got release: The Dell Ultrasharp U2410. This is a 24", 1920x1200 H-IPS display.
After getting past some sore spots with Dell's panel lottery in the past, I came full circle back to Dell. Why? They have VERY good guarantees on their displays.
- Zero dead pixel guarantee
- 3 year advance exchange program if the LCD ever has any issues.
It's a no-brainer. I don't want to buy a display I'll rely on for many years without assurance that the beginning of the experience will be problem-free.
It's been a month since I got it, and I am very pleased with it :) If you're an enthusiast - treat yourself to a nice display. It will last you a lot longer, and be far more satisfying than a new videocard, cpu, or any other piece of hardware that will get out of date in a year. Those are nice to have too, but are best enjoyed with a good display.
Friday, November 6, 2009
So, getting back to the Law of Demeter. It's most easily summarized as:
“Only talk to your immediate friends”It is also summarized as don't use too many dots. i.e. foo.getBar().getSomethingElse(), but dot counting isn't really what it 's about...
At the end of the day, it's just about proper encapsulation if you ask me. Friends to me are direct dependencies, i.e. objects that are relied or operated on.
When a class A needs another object B (or is made to operate on object B), it should need it because of object B, not because of something in another object C that's in B. That violates encapsulation and exposes the internals of B. B then can't be refactored, because A relies on C.
Now, it's reasonable for A to operate on things inside B, as long as that is where they live and they art a part of B. Testing makes the distinction obvious, because if the access is proper, then exercising and testing the code is simple. If the access is stretching further than it should, then testing will be noticeably more work.
Mocking frameworks can make testing easier in these situations, but refactoring is probably still necessary. I found it necessary in some code I was working on this week, though I would call it gentle refactoring. It felt natural, and really wasn't a lot of work. I am still finding the tests hard to write, but I will keep at it.
I'm one day away from surviving writing daily for my first week of National Writing month. It's been a learning process so far. I'm rambling and not really cleaning up my writing yet - it's intentional so I can just focus on writing regularly. Hopefully at some point it will sound interesting.
I am noticing I have a lot to learn, and a lot to write about testing. I will continue to do so, but I think on the weekend I will sidetrack to some general computer stuff. Most notably I want to talk about my latest PC building escapades, and how much it has really restored my enjoyment of computer use in my spare time.
Thursday, November 5, 2009
Wow. Seriously, wow.
The syntax is exceptionally sweet, and additionally quite clever. A coworker and I dived into how it figures out what method to stub today and that alone was enjoyable.
Mockito will definitely be a valuable tool to have in the testing toolbox.
Wednesday, November 4, 2009
Now, while quite a lot of technologies are involved in development, for me (right now), the most important to mention when dealing with files are: Java, Subversion, Windows, and Tortoise SVN. I'll throw in one more - the filesystem (NTFS).
Using the command line is part of my nature, so when I get into the office in the morning one of the first things I do is open up a command prompt and 'svn update' my working copy.
Imagine my surprise one day when I couldn't update, because Subversion claimed one of its .svn/... files was corrupt or missing. Cleanup didn't help - it wasn't actually a Subversion problem. It was a file path problem. The svn FAQ actually has great information on this.
Enter the windows API maxium file path limitation of 260 characters. What's annoying is that it isn't ALWAYS the limit, in fact the unicode version of the API has a much more flexible limit (thousands of characters). Why then, does Windows Explorer, even in Windows 7, still use the API that has the 260 character limit? *
I deal with this issue again and again. I generally don't create file paths this long, but it doesn't matter - because I work as part of a team. I think it's reasonable for people to have descriptive, rich naming for their stuff - I just wish it wasn't so painful. Once files are in version control, then build tools, installers, and all kinds of things MIGHT have an issue depending on where the files are checked out and what file API they use. It's just not an issue I should have to deal with.
I don't want to worry about long file paths - this is a simple request. Of course, simple problems for computers aren't always simple. In fact, they usually aren't, but the fact that the API exists but that it isn't already the defacto, default API used by Windows itself frustrates me.
I want to be clear - this isn't a limitation of NTFS, Java, or Subversion. They are all quite happy to deal with long filepaths. It's the Windows file API. It's just easier than normal to get into bad situations when you have tools that will very happily (as they should!) create and deal with long filepaths, only to have your operating system tell you the file doesn't exist or can't be accessed.
* Probably backwards compatibility
That's my rant for the day.
Tuesday, November 3, 2009
system and look at what is actually involved, there may be ugly parts. Especially in ensuring testability, as I am committed to unit testing this code.
In my quest to test more (and test FIRST), I looked at what would be required to add the functionality, and specifically, how to test what I was adding.
Here are the issues with testability and excuses I came up with:
- No unit test exists for the immediate classes in question (shame on me - it's my code)
- The code has a GUI - this usually makes testing harder
- Too many external dependencies!
- I haven't tested this exact type of code before (aka: I don't know how)
Taking a look at my model, it already relied on more external objects than it needed to for the required functionality. The requested enhancement would (if the pattern continued) require further addition of some heavy weight dependencies. Bye bye testability!
Fortunately, I had both the testability presentations still in my mind, and a coworker who had already solved this problem.
The feature in question is for administering users in a system. Among the things being manipulated are name, manager, credential reset, licensed features, and now - a user's preferred currency code (at the end of the day - a String). Great - slap in a few getters and setters, and we're done! Well not quite - currency code lives on a currency unit which is supplied by a unit system, well, which comes from this other big thing. You get the point. If I was lazy, I'd just pass this big other thing to my model so it could do its job. I'm not going to be lazy - I'm going to pay attention to the Law of Demeter.
This model don't really care about the 'other big thing', or the 'unit system', or anything other than that being able to set a user's preferred currency to Australian Dollars, therefore they have no place in this particular model.
Instead of that, my model will take a data source that can give it valid currency codes and set a user's currency code. Just a simple interface with a couple of methods that will be easily mockable for testing. While I'm at it, I'm going to pull out the existing extra dependencies (there was fortunately just one) that weren't needed. Now my interface has four methods, and I don't need any hulking database-requiring objects to get my model moving. A little shuffling here and there, and very little additional code, and my model is now much more easily tested. Suddenly the "I don't know how to test this" feeling has weakened a bit now that my class is simpler.
I want to write further on my take on the Law of Demeter, but it's 11:45PM and I need to submit an entry daily so I'll have to wrap this up tomorrow.
Afterwards, I plan to cover making testing the GUI easier.
Monday, November 2, 2009
- Test first. Write unit tests before, or alongside any new code I write this week.
- Try out Guice
- Finish reading the Appendix of Career 2.0 (I've been slacking!)
- Begin reading 'The Tipping Point" by Malcom Gladwell
- Continue doing Java Puzzlers (I am on Puzzle 78 of 95)
- Start staging an upgrade to the latest version of Hudson
Sunday, November 1, 2009
This week I found not one, but two good presentations regarding testable code. Firstly (seen @ the UCOSP blog) was a link to the slides for a presentation done by Misko Hevery & Cory Smith at OOPSLA '09, entitled: "Tutorial: How to Write Hard to Test Code" (PDF Google Docs link). There are quite a few slides, and in addition to illustrating bad practices, there are plenty of examples of writing more testable code as well. Highly recommended, entertaining and educational slides.
The second is a project I already knew about, but never got around to trying. Guice. If you haven't used it (or another Dependency Injection library), I encourage you to watch the youtube video on the main Guice page. The presentation itself has general tips on writing more testable code, and towards the end gets into more advanced examples using Guice. The general principles apply whether or not you use it.
I'll post again with further thoughts once I've had a chance to play around with Guice.
Thursday, October 29, 2009
My goal will be to write a blog post every day. Short or long, every day. Starting Sunday. Formatting cleanup to come later, the emphasis is purely on WRITING. The actual idea is from National Novel Writing Month. This will only serve to further the motivation and push I got from reading Career 2.0
I need to start ramping up ideas and topics now, so I'll jot down a few.
- Test ownership - how do you solve the 'nobody owns this unit test failure' problem
- Build scripts (Ant, Maven, Gant, Gradle, Etc) - where are we today, and what makes sense to move to in the future, various pains, etc
- Java 7 features - I've meant to post about these for a while. Which ones are interesting and still being included...
- New languages to try - I need to pick a new language to learn this year. I think I have an Erlang book kicking around that I need to read...
- Notable programming books in the last 1-2 years?
- Ergonomics in computing (wrist pain is becoming a real issue for me)
- Apache+HTTPS+SVN authentication issues (TortoiseSVN cannot remember password)
- More on SSDs
- The search for a quality LCD Display
- Report in on my recent PC upgrade
- Talk about Windows 7 in the context of both home and work
- at least one Book Review
Thursday, October 22, 2009
The feedback cycle is simply too long.
After 5-10 minutes of frustration I usually seek out an online regular expression tester to ease my pain. Today I found Regex Tester and it rocks.
With instant as-I-typed feedback on my regular expressions (valid, what matches were produced for the sample string, etc) I completed the regular expressions I needed very quickly.
From now on, this site will be my first step in creating regular expressions.
Wednesday, October 7, 2009
The list was already fairly comprehensive, and I generally agree strongly with all of the points.
Daily meetings are a tough one for me - I agree in principle, but I've yet to get down a daily meeting practice that doesn't occupy at least 20-30 minutes of my time. I've been in a SCRUM situation (as a remote user) for several months before, and that may have only taken 10 minutes. I enjoyed the urgency of wanting to have good progress to report each day, but the meeting always seemed to collide with my lunch time due to timezone differences, so that has probably predisposed me to negative associations. I want to believe in daily status though, even if it is a limited to myself and my direct superior. I think I'll put it down as a goal to establish as routine within the next couple of weeks.
Weekly status meetings is the absolute longest time period that I think a group of several small dev teams can go between syncing.
One point I would expand on - test automation - is that I'm passionate about automation in all forms. While I think 'test automation' definitely deserves it's own bullet, general purpose automation of daily tasks for developers and non-developers alike ALSO deserves mention.
As an example, our Hudson builds push an installer and database dump to a share location with enough information that new builds of our software can be automatically installed by a simple script that QA and other non-devs can run. (Yes, QA also tests our installer manually of course) This is just one example, but it applies everywhere. Just about any repetitive task that can be automated should be automated. I do think instructions for how to do automated tasks without the automation should be well documented, though.
I love having peer reviews for all code check-ins. Having had this as standard practice for the last 2 years, I will not be satisfied with any work environment where this is not mandatory. I believe it is an essential part of delivering quality software.
I may need to update this from time to time, as I haven't really declared a list of my own - this is more of a commentary, but at least it's a start.
Tuesday, October 6, 2009
Last week I completed 3 Java Puzzlers and read Career 2.0 each night. I have continued to read nightly, and will finish the book this week.
I didn't get around to spending much time on Stack Overflow, but the goal was mostly to throw in something programming-related last week.
Wednesday, September 30, 2009
For ages, I've wondered how in most cases, java will mysteriously be in your path in windows, even though there is no Java install directory in the path. (it will certainly be a version that was installed with a proper installer, at some prior point, but not necessarily the most recent version you've installed) To fix this, I generally put %JAVA_HOME%\bin; at the front of my PATH environment variable after defining JAVA_HOME to point to the Java install I care about (something Ant, Maven, and other dev tools often care about having defined...).
I've always wished I had the 'which' command in Windows, so I could locate which Java executable was in the path. Finally, by chance, a coworker was debugging an OpenGL crash with an Intel GMA graphics card and substituting DLLs in what he thought was the 'run' directory, and he realized that it wasn't picking it up when he put it in the directory of the JDK bin he thought it was using... When he checked process explorer, lo and behold... C:\WINDOWS\SYSTEM32\java.exe is what was running. What the heck??? I find this strange, yet there it is.
I have always thought it was registry magic, or some other trick that caused Java to end up in the system path unless you put it as the FIRST path entry. Instead, FIRST just means AHEAD of the System32 folder. (Several apps likely to be in a dev environment often put themselves at the front of the path, subversion, oracle, etc...so I never noticed that the usual first entry in the PATH is this...and I typically put entries at the END of the path except when I know there will be other entries fighting for this position)
It's funny how sometimes mysteries like this go on for many years - maybe it's a simple Eclipse feature nobody knows about, or some maven quirk, that we never take the time to fully investigate and understand...we just come up with the rule and follow it - at least it's what I've observed.
If anyone can shed some light on this, I'd love to hear it. Is this practice generally acceptable to pollute the SYSTEM32 folder with executables? For now, I am satisfied to now know why I need to put my java/bin at the front of my path...
Tuesday, September 29, 2009
- Continue doing 1 Java Puzzler a day
- Read a few pages of Career 2.0 each night
- Answer one StackOverflow question this week.
My testing and metric related goals aren't gone, but are on hold this week.
Monday, September 28, 2009
I was pretty faithful to the puzzler a day (as it's a fun break from the normal day), and probably did 1 puzzler a day. I can't emphasize enough how useful (and satisfying!) it is to learn the quirks of a language that you use day-to-day (in this case, Java). It's good knowledge, and 'Java Puzzlers' presents it in an entertaining fashion.
On the unit test front, I probably updated or added a unit test one day of the week, in a section of code I already had pretty good coverage with. I did not get around to writing my first Abbot test. My issue has always been writing the first test - it's easy (and enjoyable) to follow in the footsteps, once they are there, but it seems like a pretty solid trend that untested code stays as untested code - there is an initial barrier of resistance still (maybe the code is hard to test, maybe the coder is lazy, or maybe test-driven just isn't strongly enough part of the mindset to jump-start things)
On the findbugs section I'd say I failed - there's no lack of warnings to fix, but they are often in a foreign area of the codebase. I did examine our warnings reports in Hudson, but didn't fix any.
I find that sometimes I'm hesitant to perform an obvious fix in a section of the codebase most requently updated/maintained by another developer. Prior history (just google Debian SSH) dictates that sometimes applying fixes that a code metric suggests in code you aren't familiar with is a bad idea. The code I'm looking at isn't as delicate, but it still deters me somewhat. We'll see how I cope with this as I really want to better embrace Findbugs.
On the Hudson front, I frequently spend an hour or two getting everything building (especially tricky in Eclipse at times, as the heavy generics often confuse Eclipse's compiler, since it does not use javac). Afterwards, I don't know what I should work on and it is late at night. Time dicates I should probably find a bug to fix, but it's often hard to find a good starter. I think I will keep this goal of contribution, with a renewed focus or speaking with the devs that hangout in #hudson on IRC. I'll just ask if there's an area I could help with in a small way. Hudson remains the single most useful bit of Java software I've ever used - the benefit the project has given our team is tremendous.
I'll have to come up with a list of follow-up goals and any strategies for better accomplishing them
Sunday, August 23, 2009
Saturday, August 22, 2009
Thursday, August 13, 2009
One of the things he recommended we all do is create a blog account to write about problems we encounter and solve in development. One attendee created one during a break at the meeting - I settled for after I got home. I already have a personal blog, but I wanted to dedicate one to coding.