Subscribe
Posted on June 26th, 2006
I’m not normally one to post political stuff here, but this particular story quite amazed me. It seems that the New York Times published a report last week that the Bush Administration was tapping into the international banking transfer program to track international wire transfers without a warrant. But the Bush Administration didn’t want the NYT to publish the article, just like they didn’t want them to publish the one about domestic wiretapping.
Now, Rep. Peter King is calling on Attorney General Alberto Gonzales to prosecute the paper, calling them treasonists. In the AP article, it ends with the following:
Gonzales has said the First Amendment right of a free press should not be absolute when it comes to national security.
I found the article where he said that (had to use the Google cache since CNN says the page isn’t there anymore). On the contrary, I think that the right /has/ to exist. We’ve seen examples already in the past of the government trying to wrap things up as National Security issues so that they couldn’t be touched. Don’t get me wrong, I don’t think that news media should do things like reveal the location of soldiers. But I think they have every right to find out and report on things that the government is doing wrong. They are a vital part to the checks and balances system here in America.
I’ll be keeping a close eye on this, and writing to my reps if it moves forward any more. I encourage you to research the issue as well, and to write your representatives one way or the other.
Posted on June 23rd, 2006
Recently I updated some of my configuration files on my Gentoo box. When I brought it back up, X had died and eth0 was failing with “configuration not set for eth0″.
After about an hour of searching for why eth0 wasn’t coming up, I paused and stepped back from it. I realized that my USB hub wasn’t lit up, meaning that USB wasn’t being recognized. Since I use a USB dongle for my Wireless adapter, it made me realize that it wasn’t working either.
I found out that hotplug, which controls when you plug in a new device in Linux while the system is running, has a complement coldplug which registers USB devices when the system has started up. Appararently up until recently hotplug also registered devices at startup. But the configuration change “fixed” that, and since I didn’t have coldplug registered to come up at boot, the USB devices weren’t being recognized.
So, I emerged coldplug (luckily I had it locally!) and added it to the boot runlevel. I restarted, and whammo! I had eth0 again.
So, in summary, if eth0 is not being recognized, make sure your system actually sees the device, whether it’s a pci (with lspci) or USB.
Posted on June 22nd, 2006
I’ve been at several organizations, both large and small, who keep the same chant over and over that offshoring is the key to getting your software cheap. When it comes up, it never seems to be to be a good solution, and so far that’s panned out. None of the offshored projects have succeeded. That’s right – none. They’ve either been cancelled, or completed but then thrown away. Generally any code is rewritten before we fix it in house.
From time to time on the TDD and XP mailing lists, questions come up about doing TDD/XP with offshore teams. While there are elements of XP that can be done – including TDD if the team is aware of it – one is lucky to find teams who do that. And usually goes against the low bid. Why? Well, Brad Wilson on the TDD list captured exactly what I’ve always thought, but didn’t put into the right words:
Let’s be honest here. If you’re off-shoring, the implication is that cost is more important than quality. You will spend a lot (in terms of man hours) trying to re-inject quality into the process. I think you are fighting the wrong battle, personally.
In other words, if you want something done fast and cheap, offshoring is probably right for you. If you want a quality product you are going to have to pay for it, whether that be a local team or remote. Fast, Cheap, Good – Pick 2. We’ve all heard it, but seem to want to throw it out when it comes to offshoring.
To be fair, I don’t think it is the fault of the offshore developers. Sure, I’ve seen offshore devs who claim to be experts in everything, but need help writing a simple C# class. But the bigger problem almost always comes to communication – you can’t predict what you want upfront, but they are going to build exactly what you tell them to build. Without an ongoing relationship where developers and customers can understand one another to build what they need, it’s almost always going to be not as good.
In /Lean Software Development/ Mary and Tom capture this idea perfectly. They discuss Toyota, and how the Die engineers are expected to know a lot about what should go into the door panel, and stay in constant communication with the leads so they can make changes as they go. This also means they have to delay decisions until the last responsible moment. Without that relationship between knowledge of the product and communication with the leads to understand the customer demands, the die engineers couldn’t be nearly as effective. Neither can the software engineer who is handed a spec and expected to build it in isolation.
So, quality and speed are possible in a software project. But to acheive it, you have to be willing to spend the time and money on the communication and relationships necessary for those building the software to understand your project – and you.
Posted on June 20th, 2006
Recently, we had a core NUnit test failing on Mono/Linux. It was expecting the CultureInfo to be set to a certain pattern of string (xx-XX, or [a-z][a-z]-[A-Z][A-Z]), but when I ran it, it was coming back blank.
Since CultureInfo is something that is usually read from the underlying OS, I inquired on the Mono list about it. It turns out that Mono checks two environment variables – LANG and LC_ALL. So in order to get Mono to see your language culture – do:
foyc@dilbert $ LANG=en_US
foyc@dilbert $ EXPORT LANG
foyc@dilvert $ echo $LANG
en_US
Posted on June 19th, 2006
During the time off with the new baby, I was able to catch up on some reading. I came across two great articles that are worthy of reading.
The first is from Esther Derby. She wrote an article on the Scrum Alliance site entitled 7 Questions to Ask Yourself Before You Begin Coaching. It’s a great article, and covers some very good points. If you read it close enough, you find that underlying a lot of the points is that you need to have the ability to communicate, and especially to listen.
That’s where Michael Webb’s article Eight barriers to effective listening comes in to play. In it, he covers some excellent barriers that we’ve all put up on our road to clearly communicating. For example, Michael says, about “Knowing the Answer”, the first barrier:
A simple strategy for overcoming the “knowing the answer” barrier is to wait for three seconds after the speaker finishes before beginning your reply.
Three seconds can seem like a very long time during a heated discussion, and following this rule also means that you might have to listen for a long time before the other person finally stops speaking. That’s usually a good thing, because it gives the speaker a chance to fully vent his or her feelings.
The little one is doing well – she gained 10 ounces in 3 days! and has been keeping her mom and dad quite busy. It was a great Father’s Day present to have her home, and it will be tough to head back to work on Wednesday. Maybe I can keep working on a way to virtual pair program…
Posted on June 14th, 2006
At just past 2am last night, June 14th, our first child, Annabelle Katherine was welcomed into the world. We had gone in for an checkup at 7:30 am on Tuesday the 13th, and they decided to induce at 8am. Thanks for all of the support, and be sure to check out her gallery:
Posted on June 12th, 2006
It’s always amusing to me when people find out I build software for a living and get this, “Well, that must be hard!” expression. The funny thing is that bulding software, fiddling with bits on a computer, isn’t terribly difficult. If I need to add 2 numbers, any language will do that, and even if I had to write in assembler, it wouldn’t be all that hard.
The hard part of building software is dealing with people, your users. Case in point: I’m building a new website for tracking user groups and other location-based types of things. Converting an address to a lat/long for mapping is fairly straightforward. I know what to expect from the webservice I call that does the geocoding. I know what to expect if my database goes down.
What I don’t know is what the user at the other end of the line is going to do. Will he ignore all of the fields and just hit submit? Will he enter a bunch of fake data? Will he enter a city/state that is different from the zip code he enters? Will he first type it in Word, and the paste it using IE which retains the smart quotes? Will he even be a he, or just an automated script someone wrote?
And that, my friends, is the hard part of software development. I have a book from 1995 called Practical C++ Programming written to a developer who has practically no experience in programming. Sure you have to start somewhere, and using that book things like arrays, pointers, I/O, etc, don’t seem that bad. But throw in a sprinkling of real users, and let chaos reign.
One of the things I like most about Test Driven Development is that when we get those edge cases, we do something about it. We write a test that seeks out the bug (or defect, depending on your school of thought). Once that’s written, showcasing the expected behavior, we fix it, and we guarantee that it stays fixed for as long as we run that test.
So, bring on the users. I’ll be ready with my tests and we’ll dance the dance of war (while we deliver value, and do the simplest thing that could possibly work!).
Posted on June 10th, 2006
Follow-up: I found that I had a bug in the program anyway, and it was in the untested part of the code (imagine that!). The correct way to expand variables is “#{variable}” not “${variable}” which was just a typo on my part, but something I had no tests to catch.
I just started a new project for a web site (non-work related) I am very excited about. One of the things I have to do is make a call to the Yahoo Maps API to Geocode some information. I wanted to wrap the functionality into a class to make it easier to call from my app. I decided to spike a solution to see what it would take. So my first pass looked like:
require 'open-uri'
require 'rexml/document'
include REXML
class LatLngDecoder
#...
def retrieve
open("http://yahooapi?city=#{@city}&state;=#{@state}") do |response|
@status = response.status[STATUS_RESPONSE_CODE_POSITION]
if @status == "200"
xml = ''
response.each_line do |line|
xml += line
end
doc = Document.new(xmlString)
@latitude = XPath.first(doc, "//ResultSet/Result/Latitude/text()")
@longitude = XPath.first(doc, "//ResultSet/Result/Longitude/text()")
end
end
end
end
Once I had it working, I tossed it out and decided to test drive it. The first piece I knew would be easy was the XPath expressions. I’m using the excellent REXML, and started by writing the following tests and making them pass:
require 'test/unit'
require 'LatLngDecoder'
class LatLngDecoderTest < Test::Unit::TestCase
def setup
@latLng = LatLngDecoder.new("Test", "FL")
@xmlString = "
end
def test_fills_lat
@latLng.getLatLngFromXml(@xmlString)
assert_equal(38.95, @latLng.latitude)
end
def test_fills_lng
@latLng.getLatLngFromXml(@xmlString)
assert_equal(-92.33, @latLng.longitude)
end
end
To pass it, I just took the piece from the spike and put it in it’s own method. Unfortunately, that left me with the API call and processing the return element, which looked like:
open("http://yahooapi?city=#{@city}&state;=#{@state}") do |response|
@status = response.status[STATUS_RESPONSE_CODE_POSITION]
if @status == "200"
xml = ''
response.each_line do |line|
xml += line
end
end
end
from the spike. I knew I needed a way to test that I was processing the response back from the api call correctly, without having to actually call it. Especially because I knew I would be writing tests for the status.
So I broke open my Programming Ruby book, but couldn’t find what type of object the open-uri’s open call passed to the block. Then I dug up the docs for open-uri, and found that:
OpenURI::OpenRead#open returns an IO like object if block is not given. Otherwise it yields the IO object and return the value of the block. The IO object is extended with OpenURI::Meta.
Aha! So I pulled up irb, and found out that the open call returned a StringIO object. Further, from the docs, it looks like open-uri mixes in OpenURI::Meta. Knowing that, I was able to write my next test:
def test_get_xml_from_io
mockIO = MockStringIO.new(@xmlString)
mockIO.status = ["200", "Success"]
@latLng.process_response(mockIO)
assert_equal("200", @latLng.status)
assert_equal(38.95, @latLng.latitude)
assert_equal(-92.33, @latLng.longitude)
end
So my test wanted a method which got passed an IO object it could then pull out the methods from. Creating the MockStringIO object was amazingly simple. How simple? Here is the entire class (don’t blink):
require 'open-uri'
class MockStringIO < StringIO
include OpenURI::Meta
end
Yep! That’s it. With that, I was able to get the class down to:
def retrieve
open("http://yahooapi?city=#{@city}&state;=#{@state}") do |response|
process_response(response)
end
end
def process_response(response)
@status = response.status[STATUS_RESPONSE_CODE_POSITION]
if @status == "200"
xml = ''
response.each_line do |line|
xml += line
end
getLatLngFromXml(xml)
end
end
def getLatLngFromXml(xmlString)
doc = Document.new(xmlString)
@latitude = XPath.first(doc, "//ResultSet/Result/Latitude/text()")
@longitude = XPath.first(doc, "//ResultSet/Result/Longitude/text()")
end
So still not perfect (I couldn’t figure out how to test drive the actual call without either doing a form of D/I or writing an acceptance test), but I was pretty happy with the results. And being able to mock the IO object was just an absolute joy.
I’m looking forward to getting the new project online. It’s not anything big, but I think it will have some cool features that I am pumped about.
Follow-up: I found that I had a bug in the program anyway, and it was in the untested part of the code (imagine that!). The correct way to expand variables is “#{variable}” not “${variable}” which was just a typo on my part, but something I had no tests to catch.
I caught it by doing some manual testing, so I extracted out the creation of the URL into a method which I could then test that the variables were being created correctly. Another great example of where we shouldn’t write code without a failing test.
Posted on June 10th, 2006
Last week, the big news was about Congress voting on the Net Neutrality act, which the telecoms say is vital to keep the internet from having a total meltdown. One of the favorite targets of the lobbysts is Google. Why? Well, according to them, Google and other content providers are getting a “free ride”. For example, Mike McCurry had this to say:
But regulations pushed by Amazon, Google, eBay and the other companies would essentially prohibit data transfer arrangements between high-speed access providers and big content companies. The inevitable results: Companies pay less for the Internet’s build-out, consumers pay more and progress slows on providing affordable broadband.
But, and here’s the gotcha, consumers pay to go to Google.com, but Google pays for them to come. Yes, the one thing they neglect to mention is that Google, Amazon and other high-traffic sites pay for the outgoing bandwidth, making them a consumer as well.
But there’s something else in that story. Mike also says:
Data from a video or phone conversation has to be prioritized differently than data from a standard Web site access.
Which is a true statement. And if that is what the telecoms were truly after, it would be great. But if I choose not to use Time Warner High Speed Digital Cable Phone Service Internet Food Delivery And Movies (c), and instead just get internet and use Skype, Google, and order pizzas online, the telecoms shouldn’t have the right to downgrade my traffic. Which is exactly what would happen – traffic to Skype, and others like it, would be deprioritized in the name of “premium services”.
No thanks. I already have access to premium services – I can get a T1, or a connection with an SLA. So unless the priority traffic is going to be an open standard (all VoIP calls get prioritized, regardless of the carrier or service (or cost) by all service providers), I’d rather the chaos of the internet remain.
The sky isn’t falling, the internet isn’t melting down, and it’s not all Google’s fault. Maybe the telecoms should take instead a cue from Google and hire some engineers who can actually come up with solutions instead of just laying blame.
Posted on June 8th, 2006
This is what I miss about Tampa. A federal judge there Tuesday was fed up with the constant bickering of two lawyers who couldn’t solve even the most basic queries without court intervention. So he did what all of us would probably like to, he ordered them to play Rock, Paper, Scissors on the steps of the courthouse, with the winner getting to pick the resolution of their latest dispute.
What I find most amusing is that, since the lawyers agreed to it, this is basically case law, so other trivial manners could be solved like this. Now that’s an interesting form of justice.