Migratr 1.02 – Small Maintanence Update
I’ve recently seen an upsurge in bug reports, which, after much research, all seemed to be stemming from one bug in Migratr: Basically, Migratr depends on the .NET Framework 3.5. The installer, however, was only checking for & downloading the .NET Framework 2.0. For the first time in my life, the bug in my software was in the installer, not the application code itself. You can only imagine how long it took me to track this down:)
Anyway, here’s a maintainence release for you. If you already have Migratr and .NET 3.5 installed on your machine, there’s no need to download this version. If you have been experiencing crash issues with Migratr, though, please download this version and give it a spin, so that either the problem gets magically fixed, or we narrow it down significantly:)
Enjoy the release!
Big Giant Download Button Of Extreme Justice:
Downloaded a total of 56304 times
Migratr 1.01 – Quick update to ordering flickr images.
I’ve gotten a lot of feedback from a lot of users who are using Migratr to move photos between flickr accounts. Because of the way flickr orders photos (they place the most recent photos first), downloading from one flickr account and uploading to a different flickr account flips the ordering of all your photos, messing things up for users who (like myself) tend to treat flickr as a sort of “photo lifestream”.
So I decided to make a quick update, and flip the ordering. Basically, in the new version, photos are downloaded from flickr Oldest-To-Newest, instead of the default Newest-To-Oldest.
Also, a small bugfix for the new upload interface- There was an issue where if a photo was checked under multiple “sets” for the set-style photo services (flickr, 23hq, zooomr), it would upload the photo multiple times.
This has been fixed.
Enjoy the release!
Downloaded a total of 56304 times
-Alex
Migratr 1.0.0 – New Upload UI, Phanfare 2, and OMG ZOOOMR
Sometime around a year ago, I posted my first version of Migratr. It was a small application, with one screen and six buttons, whose soul purpose was to help me (and anyone else who wanted), move their photos from Flickr to Zooomr.
Needless to say, Migratr has changed a lot since then. It has a genuinely easy-to-navigate UI, lets you move photos and metadata in any direction between a solid selection of different photoservices, and has been embraced by the photographic and web-enthusiastic communities.
It did have one fatal flaw, though. Upon the release of Zooomr’s Mark III release, the API was “temporarily disabled” for a week, which turned into a month, which turned into a year. Migratr could not interact with the webservice which had been its initial inspiration. To say I was saddened, to say I was frustrated, to say I “sort of nagged” Kris Tate about getting the API back up and securing access to it, would all be understatements. I was seriously bummed. I hated disabling the Zooomr button in the Migratr UI. And oh my god, when it came to Kris, I was like some sort of mother in law from hell. Honestly, I tried to be polite about it, and whether he believes it or not I DID restrain myself. But I bugged him, relentlessly, mercilessly. I did it over email, IM, the zooomr-dev google group, and his zipline. I simply refused to take “soon” as an answer (good thing, too). Eventually the service got to a point where he could hand out API keys, and Kris was kind enough to hook me up. I said in earlier posts that I wouldn’t feel Migratr was 1.0 until it had Zooomr support back. Friends, users, countrymen… That day is finally here.
New Features in Migratr 1.0.0:
*Zooomr Support
*Phanfare 2 support (Phanfare 1 support is still active, as a different button)
*New Upload Screen
Major Changes
*Backend change from .NET framework 2.0 to 3.5 (Might require its own download, depending on your setup)
I made the hop from .NET Framework 2.0 -> 3.5 because the new additions to the framework are amazingly helpful to my ability to develop Migratr efficiently, and write elegant, maintainable code that I can immediately understand when I look at it again a month after writing it. I’m sorry it will require a 20 MB download for you if you’ don’t have it already, but I can tell you with complete honesty that from my end, it’s a major contribution to the development process.
The new upload screen bears explanation. Instead of simply choosing the folder on your hard drive to upload from and letting Migratr go to town, “Choose a folder” will instead load all your photos into a tree of checkboxes, labelled by filename. From here you can actually choose which files you want to upload to the new service. They tree out by album they are contained in, too, for easy organization.
After you’ve selected which photos you actually want to upload, just hit “Start Migrating” to actually start the migration. Neato, huh?
So far all of you who have been itching to get in or out of Zooomr (or the new version of Phanfare), hit the download button and enjoy!
Downloaded a total of 56304 times
Lines Of Code – Dispelling The Myths
You see stuff related to Lines Of Code (LOC) everywhere on programming blogs. People discussing it as a metric of project size, or of programmer productivity, often drawing conclusions in absolutist tones such as “fewer lines of code means less bugs”. I’m writing today to dispute the idea that anything related to LOC is absolute. And I’m going to do it one myth at a time.
LOC As A Metric of Accomplishment or Project Size
This one is old, and most experienced programmers now officially reject it outright. But still, I feel it worth repeating: The number of LOC you write in a single day is worthless as a metric of what you accomplished that day. After all- If someone wrote a 1000 line class in a single day, and you wrote the same class in 500 lines (and maybe tossed in a little extra functionality while you were at it), who was more productive?
As a metric of project size, it makes a little more sense, but just barely- The Wikipedia article on LOC mentions that “Many useful comparisons involve only the order of magnitude of lines of code in a project.” That at least makes a little sense. One can reasonably assume that the same set of programmers, using the same language, will be able to accomplish more with 10000 lines of code than with 1000.
Ambiguity: Too Many Ways To Count
The next issue is this: How do you COUNT lines of code? That same Wikipedia article linked above has an interesting example:
for (i=0; i < 100; ++i) printf("hello"); /* How many lines of code is this? */
How many lines is that? One for the line? Two for logical seperation of forloop and print statement? What if you wrap the line in curly braces, one on each line, and move the comment to it’s own line, so it looks more like
for (i=0; i < 100; ++i) { /* How many lines of code is this? */ printf("hello"); }
Did you see that? I just took one line of code, and turned it into 5! Things get so much more confusing than stylistic issues like this, though. What about libraries? What about frameworks? Jeff Atwood wrote a post a couple of months ago wherein he mentioned that the original version of Basecamp had been written in only 600 lines of code. Given that Basecamp was written using Ruby on Rails, which handles all sorts of crazy things for you, I think the more honest metric would have to be the 600 lines of basecamp, plus however large the RoR framework is, plus the code RoR generated for them when they started the project. Money says it’s more than 600 lines.
I’ll give you another example. Currently, the amount of code I’ve written for Migratr is 5000 lines and change. However, Migratr uses FlickrNet, a popular .NET library for interacting with the Flickr API. FlickrNet, if you download the source, is more than 12,371 lines of code (according to the unix util “wc”). I’ve also incorporated a few other libraries, all of which are linked in Migratr’s “about” page. Why? Because I didn’t want to write those 12,000 lines. Someone already had, and they did a fantastic job of it, and I didn’t see any point in re-inventing the wheel. So the total code involved in Migratr is, at this point, more than 17,000 lines. I’ve written 5,000 of them, and I’m the sole developer of Migratr. But I wouldn’t dream of saying “I built this application that interacts with a whole slew of online photo services and migrates all your photos and does all this neat stuff, and it was only 5,000 lines!” No. MY contribution was 5000 lines, but Migratr depends on a lot more than that.
The point being, where do you draw the line? Is Migratr a 5000+ LOC project? or 17,000+? Do you only count LOC if you have access to the source of the library you’re using? Do you only count the code written for your specific project? Could I export Migratr’s backend as a library and let someone write
public void migrate(String filepath) { ImportFromSource(Services.Flickr, filepath); exportToDestination(Services.SmugMug, filepath); }
Did you see that? My whole project was just replaced! Some twerp in a garage somewhere just re-wrote Migratr in 5 lines of code! It doesn’t matter that it depended on my 5,000 line library, which depends on (among others) 12,000 lines of the Flickrnet library. You only saw 5 lines. It was only 5 lines.
But clearly, since 5,000 is more than 5, I can at least say that I was more productive.
The relationship between line count and bug count only goes so far
The idea that “Less lines of code mean less bugs” is some sort of universal absolute is the biggest of all the LOC myths. In a desperate effort to nullify your “oh snap, time for a flamewar” reflex, I’m going to add a couple of disclaimers before I get into this. Any reference I make to a programming language is not an attack on that programming language, just an attack on the abuse of that language. Also, I realize that reducing the amount of code required for a specific task can help reduce the bug count, but only so far. I’m saying there’s a limit to this. Here’s the line I want to draw for you.
Reducing the code involved in a task will only help reduce the bug count IF THE PROCESS MAKES THE CODE MORE READABLE. Past that, you’re probably creating lines of code that do more than one thing per line, and thus increasing the number of bugs possible per line of code.
Perl programmers are especially frightening in this regard. I really love PERL and use it instead of shell scripting languages such as BASH whenever possible, but there’s something in the PERL culture that demands it’s programmers to try and do something in the fewest number of characters possible. There’s even a name for this as a sport- It’s referred to as “Perl Golf”.
Really quick, can you tell me what this is?
-pl s!.!y$IVCXL426(-:$XLMCDIVX$dfor$$_.=5x$&*8%29628;$$$_=$_!egfor-4e3..y/iul-}/-$+ /%s''$';*_=eval
I’ll give you a hint- It’s not a cat walking across my keyboard. If that was your first guess, though, we’re at least on the same page. This was the winning entry in a game of Perl Golf: The problem was to write a Roman Numeral Calculator in the fewest characters possible. Submissions can be found here. Now, this is an amazing piece of code. The person who wrote it is clearly very skilled. The fact that Perl makes code like that possible is pretty impressive. The problem here is that people write code like this outside of PERL golf, and think to themselves, “it’s only one line, so it must have fewer bugs than a 50 line solution”. Really? Because if I had to debug one, I’d have definitely gone with the 50 line solution. And don’t tell me that that one line of code worked on the first, second, or 5th try. The 50+ line solutions might have, but not that catwalk.
Writing unmaintanable code does not reduce the bug count for a project. A friend of mine coined a term for code like that- “Write-Only Code”- a takeoff on the permissions you can set with chmod. Think about it: Readable, writeable, and executable. Shouldn’t code be all three?
Another quick example:
(0/:l)(_+_)
The first time I saw this snippet, I thought someone was, via emoticons, trying to re-enact the facial expression one wore when seeing “Goatse” for the first time. It’s not actually a story told by emoticon. It’s a piece of scala code that sums the elements in a list. And I just don’t see it as having been easier to write than a forloop. It’s definitely not as maintainable. This piece of code, actually, prompted a conversation with a friend about holding a “code or emoticon” contest, but we really couldn’t come up with any serious contenders to this one. Maybe some Perl Golfers could throw their hat in the ring?
I want to state too, that for this section, I’m well aware that I didn’t provide buggy one-liners. I provided working one-liners. This is because I was trying to emphasize, the point isn’t if it works or not- The point is if you can tell by looking at it what it should do. If you can’t, it’s unmaintainable. If it’s unmaintanable, then even if it works the first time, it’ll produce a slew of bugs as soon as anyone tries to modify it.
So, in essence- Stop paying attention to Lines of Code. They’re impossible to count in any useful way. They’re a crappy metric of project size or personal accomplishment. And they don’t control how many bugs your code has. You do.
-Alex
0.9.91 – Minor Bugfix for Zenfolio
Quick release to fix a small bug. Migratr couldn’t download photos in a private data set from Zenfolio, even though you were the owner. It was something I wasn’t implementing correctly in the API.
Thankfully, an astute forum member brought it to my attention. Special thanks to MSPhotog!
To download the fix, just click the ever-popular “big giant download button”.
Downloaded a total of 56304 times
