The Demented Ravings of Frank W. Zammetti Visit for all things me


Building a homemade Dropbox/Time Machine thingy for vanilla file systems

So, I've had a dream for some time... but before I get to that, let me give you some necessary background...

I've got a server at home, and on that server are various directories (as servers tend to have!). One of them is a directory full of assorted documents. These documents are edited by myself and other members of my house. Documents are created, deleted, sub directories created and deleted, things renamed, all the typical file system activities.

Now, my server is well-protected in terms of backups: the server has a nice RAID array in it for starters, with real-time monitoring and reporting rolled into it. I've got Mozy running, so I have off-site backups covered. Plus, Mozy can do backups to an external hard drive at the same time, so I do that as well for an added layer of security. On top of all of that, every two weeks I image the entire data array to a different external hard drive. If that wasn't enough: every month I burn the most critical stuff to a couple of Blu-Ray discs, and once or twice a year I ship a copy off to my mom in another state.

In other words:

  • I'm incredibly anal about data retention (yes, I've been burned before)
  • I'm really not very likely to lose anything of value off that server

But, here's the thing: all that backup stuff doesn't do one significant thing for me and that's versioning. That's where that dream I mentioned comes into play. You see, I've also got a Subversion server running. What I'd really love to have happen is for at least certain directories on the server be checked into Subversion. That's easy to do of course, but the problem arises when you try and tell your wife or kids how to work with version control. When you aren't used to that thought process it can be pretty foreign. Besides, even if you're used to it, do you really want to have to worry about checking in changes every time you edit a file? Because even I don't really want to.

So... wouldn't it be great if there was a way I could have the server monitor the directory for changes, and when any are seen, automatically check the changes into Subversion?

Yes, it would be great... no, check that: it IS great, because I BUILT IT!

The title of this post is courtesy of a Twitter buddy of mine, Nick Carter (@thynctank). When I was explaining what I was doing, that was how he described it back to me and when I thought about it, it really was a very accurate description!

Ok, fine, preliminaries done, let's get to brass tacks! How did I pull this off?

First, let me say that this is a Windows server. If you're running a *nix variant then you're on your own. For Windows though, check out the app Directory Monitor from DevEnterprise.NET at It's the first part of the equation, namely (and unsurprisingly, given it's name) the directory monitoring. This app is fantastic... it's highly configurable and Just Works™. It's also exactly the ticket.

The next part of the equation is having an Subversion client installed. I loves me some TortoiseSVN ( If you're not familiar with it, it's a GUI client for Subversion that integrates with Windows Explorer itself, so you interact with it via context menu entries on files and directories. Fortunately, it also ships with a command line client and that's what we need here. In theory you can use whatever client you want, so long as it's in your path.

The final part of the equation is a VB script that handles the Subversion interactions. That's the bit I wrote and it's kind of the engine of the whole thing. Here's that script:

' **********************************************************************************************************************
' Automated Subversion check-in script by Frank W. Zammetti.
' This script is intended to be used with the Directory Monitor application from DevEnterprise.NET
' (  The goal is to real-time monitor a directory for changes and when they are detected,
' execute this script to automatically check all changes into Subversion.
' Notes:
'		1. It is assumed that the directory being monitored is a proper working copy of a directory already under
'			 SVN control.
'		2. Directory Monitor must be started with admin privs or the file writes in this script may fail.
'		3. You should be able to monitor multiple directories and handle changes with this same script, however, since the
'			 file writes use the directory of the script itself as the target for file writes, each directory you wish to
'			 monitor should have its own copy of this script and it should be in a different directory from all others.
'		4. This script assumes that it is passed a command line argument that is the fully-qualified path to the directory
'			 being monitored.  Without that, this will all fail horribly.
'		5. There's no error checking throughout this script... partly because there's not a heck of a lot that seems to be
'			 possible in the first place, and partly because what may be possible wouldn't seem to buy us much anyway.
' For more information on using this script, see my blog post here:
' **********************************************************************************************************************

' Create objects we'll need throughout.
Set oShell = WScript.CreateObject("WScript.Shell")
Set oFSO = CreateObject("Scripting.FileSystemObject")

' If script is already running, abort.  This shouldn't really be necessary because Directory Monitor should be
' configured to not allow concurrent executions, but it's a little added safety net.
If oFSO.FileExists("running.txt") Then
End If

' Determine the path of this script.  This is needed to properly target our file writes.
sScriptPath = Wscript.ScriptFullName
Set oScriptFile = oFSO.GetFile(Wscript.ScriptFullName)
sScriptPath = oFSO.GetParentFolderName(oScriptFile)

' Write our "running.txt" file to avoid this script running again until this execution is done.
Set oRunningFile = oFSO.CreateTextFile(sScriptPath & "\running.txt")
oRunningFile.Write "running"

' Start creating our results file.
sResults = "----------------------------------------------------------------------" & VbCrLf
sResults = sResults & "Script starting " & DateInfo & Now & VbCrLf

' Grab the command line argument so we know what directory to work with.
sTargetDir = Wscript.Arguments(0)
sResults = sResults & "Target directory = " & sTargetDir & VbCrLf & VbCrLf

' Get the list of changes in the target directory.
sCmd = "svn status " & Chr(34) & sTargetDir & Chr(34)
sResults = sResults & sCmd & VbCrLf
Set oExecStatus = oShell.Exec(sCmd)

' Only continue once the command completes.
Do While oExecStatus.Status = 0
	WScript.Sleep 100

' Iterate over the changes and handle each appropriately.

	' Get the next change.
	sLine = oExecStatus.StdOut.ReadLine()
	sResults = sResults & sLine & VbCrLf

	' Determine SVN command to execute.  Note that only adds and deletes require
	' use to do anything, the SVN ci command takes care of modifications.
	sOp = ""
	If Left(sLine, 1) = "?" Then
		sOp = "add"
	ElseIf Left(sLine, 1) = "!" Then
		sOp = "delete"
	End If

	' Execute the command, if there is one to execute.
	If sOp <> "" Then
		sCmd = "svn " & sOp & " " & Chr(34) & Trim(Mid(sLine, 2)) & Chr(34)
		sResults = sResults & sCmd & VbCrLf
		Set oExecOp = oShell.Exec(sCmd)
		' Only continue once the command completes.
		Do While oExecOp.Status = 0
			WScript.Sleep 100
	End If

Loop While Not oExecStatus.Stdout.atEndOfStream

' Fire an SVN ci command to commit all changes.
sCmd = "svn ci " & "-m " & Chr(34) & "Auto-Commit" & Chr(34) & " " & Chr(34) & sTargetDir & Chr(34)
sResults = sResults & VbCrLf & sCmd & VbCrLf
Set oExecCommit = oShell.Exec(sCmd)
' Only continue once the command completes.
Do While oExecCommit.Status = 0
	WScript.Sleep 100
' Capture the output of the command in our results.
	sResults = sResults & oExecCommit.StdOut.ReadLine() & VbCrLf
Loop While Not oExecCommit.Stdout.atEndOfStream

' Epilogue in the results file.
sResults = sResults & vbCrLf & "Script finished " & DateInfo & Now & VbCrLf & VbCrLf

' Write results to file.
iForAppending = 8
Set oResultsFile = oFSO.OpenTextFile(sScriptPath & "\results.txt", iForAppending, True)
oResultsFile.Write sResults

' Delete our "running.txt" file so this script can run next time it needs to.
oFSO.DeleteFile(sScriptPath & "\running.txt")

Copy this down and save it to a directory (NOT the one you'll be monitoring!) and name it commit.vbs and set it aside for now.

Putting all the pieces of the puzzle together is pretty easy. Let's say we're going to monitor a directory C:\docs. The first step is configuring Directory Monitor. Here's the main Directory Monitor window:


As you can see, I've already done the configuration and have even had some events triggered during my testing. I'll walk you through the setup screens that got me to that point. If you're adding the directory for the first time you'd be presented with these same screens. Here's the first one:


This is actually the most important of the bunch (well, one of two key tabs anyway). You'll need to check off the events you see checked here to ensure you capture everything that happens in the directory, but no more. You'll also likely want to monitor sub-directories, but that's up to you. The next critical thing is to ensure you exclude any changes that happen in the .svn directory. Failing to do that will result in an endless loop or script executions when we add in the execution of the script (ask me how I know!).

The Text Log tab can be left alone, but for the sake of completeness, here's what it looks like on my machine:


The Execute tab is the other key tab, and here it is:


Browse for the commit.vbs script file and select it in the Execute box.  Directory Monitor should modify it to look like what you see here.  Now, in the Parameters box, add the %dirpath% placeholder.  That will be passed to the script so it knows what directory to work on.

Like the Text Log tab, the Sounds, Emailed and Database tabs don't matter in my use case so I've left them with default setting.  But, just to ensure you don't miss anything, here they are as I see them on my machine:




At this point, hit Save and you're basically done!  Directory Monitor will now start monitoring the directory and will fire the script when any changes occur.  You should see a couple of command prompt windows flash across the screen whenever it does. I'm working on a way to avoid that, but it only winds up mattering if you've got a lot of activity in the directory and need to work on the server. In that case, just pause monitoring in Directory Monitor and you should be fine. During this processing, the results.txt file will be written so you can see what happened.  As an example, here's a couple of runs recorded during my testing:

Script starting 1/18/2015 3:20:48 PM
Target directory = C:\docs</code>

svn status "C:\docs"
M C:\docs\_Our Movies.txt

svn ci -m "Auto-Commit" "C:\docs"
Sending docs\_Our Movies.txt
Transmitting file data .
Committed revision 5777.

Script finished 1/18/2015 3:20:49 PM

Script starting 1/18/2015 3:20:59 PM
Target directory = C:\docs

svn status "C:\docs"
? C:\docs\test - Copy (2).txt
svn add "C:\docs\test - Copy (2).txt"
add - A C:\docs\test - Copy (2).txt

svn ci -m "Auto-Commit" "C:\docs"
Adding docs\test - Copy (2).txt
Transmitting file data .
Committed revision 5778.

Script finished 1/18/2015 3:21:00 PM

Script starting 1/18/2015 3:21:00 PM
Target directory = C:\docs

svn status "C:\docs"

svn ci -m "Auto-Commit" "C:\docs"

Script finished 1/18/2015 3:21:01 PM

Script starting 1/18/2015 3:21:42 PM
Target directory = C:\docs

svn status "C:\docs"
? C:\docs\test - Copy (3).txt
svn add "C:\docs\test - Copy (3).txt"

svn ci -m "Auto-Commit" "C:\docs"
Adding docs\test - Copy (3).txt
Transmitting file data .
Committed revision 5779.

Script finished 1/18/2015 3:21:43 PM

Script starting 1/18/2015 3:21:43 PM
Target directory = C:\docs

svn status "C:\docs"

svn ci -m "Auto-Commit" "C:\docs"

Script finished 1/18/2015 3:21:44 PM

Script starting 1/18/2015 3:22:05 PM
Target directory = C:\docs

svn status "C:\docs"
! C:\docs\test - Copy (2).txt
svn delete "C:\docs\test - Copy (2).txt"
! C:\docs\test - Copy (3).txt
svn delete "C:\docs\test - Copy (3).txt"
! C:\docs\test - Copy.txt
svn delete "C:\docs\test - Copy.txt"

svn ci -m "Auto-Commit" "C:\docs"
Deleting docs\test - Copy (2).txt
Deleting docs\test - Copy (3).txt
Deleting docs\test - Copy.txt

Committed revision 5780.

Script finished 1/18/2015 3:22:06 PM

Script starting 1/18/2015 3:22:06 PM
Target directory = C:\docs

svn status "C:\docs"

svn ci -m "Auto-Commit" "C:\docs"

Script finished 1/18/2015 3:22:07 PM

Script starting 1/18/2015 3:22:07 PM
Target directory = C:\docs

svn status "C:\docs"

svn ci -m "Auto-Commit" "C:\docs"

Script finished 1/18/2015 3:22:07 PM

Script starting 1/18/2015 3:22:47 PM
Target directory = C:\docs

svn status "C:\docs"
? C:\docs\work
svn add "C:\docs\work"

svn ci -m "Auto-Commit" "C:\docs"
Adding docs\work

Committed revision 5781.

Script finished 1/18/2015 3:22:48 PM

Script starting 1/18/2015 3:22:54 PM
Target directory = C:\docs

svn status "C:\docs"
? C:\docs\work\test.txt
svn add "C:\docs\work\test.txt"

svn ci -m "Auto-Commit" "C:\docs"
Adding docs\work\test.txt
Transmitting file data .
Committed revision 5782.

Script finished 1/18/2015 3:22:55 PM

Script starting 1/18/2015 3:22:56 PM
Target directory = C:\docs

svn status "C:\docs"

svn ci -m "Auto-Commit" "C:\docs"

Script finished 1/18/2015 3:22:56 PM

Script starting 1/18/2015 3:23:15 PM
Target directory = C:\docs

svn status "C:\docs"
? C:\docs\aaa
svn add "C:\docs\aaa"

svn ci -m "Auto-Commit" "C:\docs"
Adding docs\aaa

Committed revision 5783.

Script finished 1/18/2015 3:23:16 PM

Script starting 1/18/2015 3:23:21 PM
Target directory = C:\docs

svn status "C:\docs"
! C:\docs\aaa
svn delete "C:\docs\aaa"

svn ci -m "Auto-Commit" "C:\docs"
Deleting docs\aaa

Committed revision 5784.

Script finished 1/18/2015 3:23:22 PM

As you can see, this file will just continue to grow unbounded (another thing I intend to remedy later) so if you're going to have a lot of activity in the directory and are worried about space you may want to comment out the lines in the script that write it (at the cost of a loss of logging obviously).

Well, that's basically a wrap! I can't claim any of this is rocket science or anything, at the end of the day it's pretty simple, but it's quite a useful script and achieves my stated dream 🙂 If you find it useful too then by all means, have at it! If you make any enhancements I'd love to hear about them... this thing is running on my server now so I have a vested interest in it working correctly and running well so if it can be improved I'd love to know about it.


My Prometheus theory

Ok, let's get this out of the way quickly: If you haven't seen Prometheus yet and don't want anything spoiled, LEAVE. NOW. QUICKLY. DO NOT READ ANY FURTHER!

This is your last warning!

Lots of evil spoilers in 3...



Still here?

Ok then, you asked for it...

I just saw Prometheus a few hours ago. Good movie, but not great. However, it did the one thing that I think was mainly intended, and that's to engender conversation. My son and friend that saw it with me were talking about it most of the way home. I threw out a couple of obvious explanations for things to them and we bandied about a few theories about some less obvious things.

But, sitting there watching TV a little while afterwards I had a bit of a revelation. Here's what I think was going on that I didn't catch during the movie...

The saucer ship in the beginning... the first thing you assume is that was from the same species as the Engineers. But, upon further reflection, I don't think that was the case. I think that's a different species entirely (or possibly an offshoot of the Engineers).

I was thinking back to some of the early script reviews I saw... they all brought up the mythological aspect of Prometheus having stolen fire from the gods and Zeus casting him out for it. That was brought up in the movie too. All along I've seen everyone, me included, assuming the human race was supposed to be akin to Prometheus.

Now though, I think that's entirely wrong. I now think it's the Engineers who are supposed to represent Prometheus.

I think they stole the bioengineering technology from the saucer people, I'll call them for now. In the opening of Prometheus we see an Engineer ingesting the stuff and being torn apart, his body falling into a river below. The assumption you make is that was seeding life, most probably on Earth. I think that's wrong though. I bet that Engineer was assuming he'd be transformed into a God, into one of the saucer people, by ingesting it. Obviously he was wrong. Whether that somehow seeded life or not, by accident in that case, I'm not so sure. I tend to doubt it actually. I think that was basically Prometheus being "cast out", so to speak, and the saucer people were there watching. Notice they were leaving at that point. They probably knew what was about to happen and figured "ok, fine, you just go right ahead and mess yourself up".

So, was the black stuff a biological weapon used by the Engineers, as the captain suggests? Maybe, but then the question is who is it to be used against? We're led to believe the Engineers were coming to destroy humanity. Why would they do that though if they created us?

I have two theories on that.

First, it could be that the Engineers did NOT create us and it was in fact the saucer people. I'd suggest then that the opening scene did NOT occur on Earth. In this case, the Engineers discover Earth, and the creations of the saucer people, and set out to destroy said creations. Maybe they're doing this all over the galaxy, kind of "rebelling against the Gods" so to speak.

The second possibility is that we were created by accident, maybe as a result of what that Engineer in the opening scene did (which there's some evidence for based on the DNA breaking/reforming stuff seen there), and they're just out to fix that mistake. All indications so far are that the Engineers are a malevolent species, their actions in Prometheus seem to support that. Maybe they just don't want to see another species rise that could rival them, or maybe they just hate anything created by the saucer people, directly or indirectly. If the Engineers view the saucer people as their Gods, as would kind of be implied by the whole Prometheus mythology, then they may not like the idea of having competition for their attention. Sort of wanting to kill your new baby brother so you keep getting your parents' attention 🙂

Whatever the case, I'm now pretty convinced that what happened to the Engineer in the beginning, whether it was on Earth or not, wasn't what he intended or expected to happen. I'm also convinced there's two species besides humans in play here, the Engineers and the saucer people. I could have the exact plot wrong around those facts, but I think those two things will prove to be true in a potential sequel. I hope I'm right too because I think that actually makes the storyline FAR more interesting and opens up many more possibilities. Might we have to join forces with the Engineers against the saucer people later? Might we need the help of the saucer people against the Engineers in an all-out war? Maybe all three species are up shits' creek with the creation of the Xenomorph species. Lots of possibilities. But if it's fairly straightforward, as in the Engineers seeded Earth and now for some reason want to destroy us, well, that'll be perfectly fun I'm sure, but a little bit of a letdown.

Another possibility to explain why they might want to destroy us: did you notice the dating of the Engineer head? 2,000 years roughly. Also right around the time of Jesus. I wonder if the Engineers sent one of their own to check up on us, whether that was to check up on their creation or to see the status of the "mistake"... and we promptly crucified him! Might that have pissed them off? Oh, I'd say it might have 🙂 Maybe they were on their way to spank us at that point when all hell broke lose on their bioweapons storage world and they didn't get around to it (bigger fish to fry and whatnot). That's not a bad storyline either. But, that leaves the question of why the different ship in the opening scene. Sure, there's every chance there's simply different ships in the Engineer fleet, but for some reason I doubt that. I think there's a deeper meaning to that one detail and I think it's something along the lines of my theory above.

One other point that I have a theory on is the effect of the black goo... we see it basically destroy any creature it comes in contact with save Shaw and the worms. Why is that? Well, clearly the stuff manipulates life on a genetic level. What's the common pattern here? Well, you'll note that everyone affected by it except for Shaw was a male. We don't know the gender of the worms of course... maybe they were female, or maybe they were asexual... but either way, could it be that when the goo encounters a lifeform with reproductive capabilities it uses that capability to its advantage? At first I thought the squid creature that Shaw takes out of herself was supposed to be a "mutated" Charlie sperm, but now I'm not so sure. I instead think it's more likely the stuff used her reproductive capabilities, broken as we're told they were, to create a forerunner of the well-known facehugger. The worms, if they were asexual, might have just been mutated. Or maybe they were female, which I think I prefer in theory because we see one try to enter one of the crew (I forget which), and that makes me think of impregnation. Maybe that was a failed attempt at a Xenmorph reproductive entity? In either case, males it just destroys outright, that's my thought.

Well, hopefully Prometheus does well enough to justify a sequel and we find out for sure about all of this. No doubt it's a compelling storyline either way. Funny thing is, if you subscribe to ancient astronaut theory as I do them Prometheus is in many ways just rehashing concepts you're already quite familiar with. That dulls it a little bit frankly for me. But still, this is heady stuff that is well worth exploring in a well-made movie. Prometheus was that for sure and so long as Ridley Scott is involved in any sequel I'm sure it will be completely worth my hard-earned money next time around no matter which way the story goes!

Filed under: Uncategorized 1 Comment

Debunking Planet X/Nemesis/Nibiru colliding with the Earth on or before 12/21/2012

So, let's put this right out front: I'm not a scientist. Not an astronomer, not a physicist, not a cosmologist, not even a boring old chemist. What's worse is that I've historically been pretty bad at math! Oh, I've gotten better over the years through a concerted effort to do so, but I'm certainly not going to be mistaken for... well, even a competent high school senior!

And while I'm not a scientist per se, I am VERY, VERY into science. I read a TON of stuff, much of it WAY over my head, but I read it anyway. I usually get lost in the math pretty quick but the conceptual descriptions I'm quite good at grasping. I've on a couple of occasions had a chance to talk to some actual, real scientists and they've come away fairly impressed by my ability to carry on an intelligent conversation even given my lack of understanding the details where the math is necessary.

I'm what you'd call an amateur scientist I suppose. I've built my own Tesla coil, I've build my own CO2 LASER and I can converse about quite a few high-concept science topics without sounding like a complete and total buffoon. Just a partial one 🙂

That all being said, those that follow me on Twitter know that I occasionally like to throw out a series of tweets were I have some fun with math to try and figure out some weird stuff... like how many hard drives you'd need to store enough information about an average human body to be able to build a Star Trek transporter... or how long it would take you to walk to the moon if we could build a bridge to it... or how many planets in the galaxy are likely to have intelligent life on them... and so on.

Today I saw some posts about Mayan predictions and how there was a planet out there, lurking, ready to take us out. I'd certainly heard all that before, nothing new, but it occurred to me: shouldn't it be possible, with some math, to prove once and for all whether this was even possible? Hmm, worth a shot!

Here goes...

First, some facts we'll need to try and pull this off... you'll be scratching your head initially wondering how any of this matter, but trust me, it does:

1. The Earth moves around the sun at about 62,000 mph
2. The moon is about 2,200 miles in diameter
3. The diameter of the Earth is about 8,000 miles at the equator
4. The moon is about 239,000 miles away from the Earth, on average
5. There are 204 days until 12/21/2012, or 4,896 hours (as of this writing obviously!)

For the sake of this thought experiment, let's assume that Planet X is the exact same size as the moon and that it's moving at the same speed as the Earth, because, well, we need SOME size and speed here and those seems as good a guess as any other.

That means that by 12/21/2012, Planet X will move a total of 303,552,000 miles (4,896 * 62,000).

Now, if we trust that the Mayans are correct and that 12/21/2012 is in fact the correct day of our demise than we know that Planet X must currently be 303,552,000 miles away because any closer it'd get here before the appointed doomsday, making all our preparations turn to poo, and any further and we'd be in the embarrassing situation of the Mayans being a bit... umm... premature 😉

Since planning for the end of the world seems to me to be something we should be fairly accurate about, we'll assume those figures are right.

So, there's something else we can now calculate: the apparent size of Planet X as seen from Earth. Now, this is of course where math starts to get in my way a bit, but I THINK I've got this right: if we divide the total distance Planet X will cover (303,552,000) by the average distance of the moon (239,000) we get 1,270. That's how much further away Planet X currently is than the moon. That means that the apparent size of Planet X will also be 1,270 times smaller than the moon appears. Remember the moon is 2,200 miles in diameter, so if we divide that by 1,270 we find the answer being 1.73.

In other words, Planet X should appear in our sky at about the same size as an object 1.73 miles in diameter at the same distance as the moon.

At least, I THINK that's right 🙂

Now, assuming for the moment I got that all right, what it tells me is that we likely would have noticed such a thing. While I agree that 1.73 miles in diameter isn't very much, I think even with the naked eye you can approach that sort of resolution when looking at the moon itself. The surface features we can see with no binoculars or instruments probably isn't too much more than that (well, not MY eyes, because they suck, but young whipper-snappers with youthful eyes!) Certainly with binoculars you can see that sort of detail and with telescopes you obviously can.

Now, this all leaves out one very important detail of course, and that's reflected light. As everyone reading SHOULD know, assuming you paid ANY attention at ALL in school, the moon does not emit light, it reflects sunlight. The same is true of every body in our solar system except for the Sun itself. So, it would be true of Planet X (putting aside the possibility of an alien civilization riding in on it that has cities ablaze with artificial lighting of course). So, the question would be if Planet X would now be reflecting enough sunlight to be visible to us on Earth.

Well, let's see: 303,552,000 (which I'll just round up to 304 from now on because my fingers are getting tired!) is roughly midway between Mars and Jupiter. Obviously we can see both of those objects, but they're also quite a bit bigger than Planet X in our thought experiment (Jupiter of course dwarfs it, but Mars, while bigger, isn't as big a difference) and so reflect more sunlight.

Hey, guess what's out there between Mars and Jupiter? The asteroid belt! Now, the belt ENDS roughly half-way between the two, so it ends roughly where Planet X would be now. But, the bottom line is we certainly can see asteroids from Earth, albeit not with the naked eye and not even particularly easily with telescopes and whatnot. But we CAN. And remember, with Planet X we're talking about an object MUCH larger than any asteroid we've ever seen.

So, the bottom line is that I think we COULD see Planet X right now, but not with the naked eye, and it would probably take a bit of luck to spot it with telescopes since we don't know precisely where in the sky we should look.

I think ultimately what this means is that the Mayans COULD be right, and we COULD all be looking down the barrel of a shotgun that's going to go off on 12/21/2012, but it'll probably be another 2-3 months before we can look up in the sky and know with our naked eyes.

Hey, whattaya know? Just in time for the kids to go back to school! "Ok class, today we'll be learning about how we're all about to get hit on the head by a giant space rock... but don't worry, duck-and-cover still works!"

Filed under: Uncategorized No Comments

Eric S. Raymond, I have a bone to pick with you

Tonight at the Philadelphia Java User's Group meeting I had a chance to hear Eric S. Raymond, aka ESR, speak.  Eric's an interesting guy to say the least who frequently has opinions that many consider incendiary.  Tonight was no exception.  This was the first time I've ever met the man in person so going in I didn't really have any expectations (aside from what I know of him generally I mean).  What I got was a lot of interesting anecdotes, a few thought-provoking comments and a lot of opinions on various things.  It's always great to hear someone who clearly has so much experience and knowledge talk and I'm very glad I had the opportunity to attend.

Honestly, I found myself agreeing with most of what he said.  I believe Eric and I have a lot in common, a lot of thought processes that are, to a large degree, the same.  I can tell for sure that he's got a similar "old-school" mentality and a set of experiences similar to my own (although there's certainly significant differences).  Some of what he said, like his comments on architecting systems in layers (vis a vis, design a low-level set of APIs, then build a command line on top of it, then a GUI if and when it's needed, he gave The GIMP as a great example) strongly echoes my own feelings based on a lot of experience, so I was absolutely receptive to that.  Some of it, such as his feelings at Python, I was a little more ambivalent about, although it makes me want to dive into a few things that I otherwise may not have (Haskell for example, something I DEFINITELY want to look into).

One thing he said though I disagreed with quite a bit.  He was talking about coding standards.  Now, on the surface, he didn't say something that was totally against my own thoughts on the subject.  He basically was saying that coding standards are nice, but aren't THAT important, and even if you have standards you shouldn't be overly anal about them.

I basically agree with this.  I think I put a little more importance than he does in standards generally, and I CAN admittedly get anal about it sometimes, but the idea of generally not going to that extreme I do agree with.  I've always said I'm less concerned with everyone on my team following the same set of standards religiously than I am with each developer being self-consistent.  Nothing annoys me more... nay, nothing PISSES ME OFF AND GETS ME INTO A MURDEROUS RAGE more, than a developer who can't decide how many frigging tabs they're going to use between two different methods, can't decide if they like their braces on the end of a line or alone on the next line or can't decide whether they're going to write comments on not, can't indent consistently or name variables in a meaningful way, and so on.

However, on the other hand, he was too soft on the idea of coding standards for my tastes.  This bothers me because I think he's missing a key point in the whole discussion, which is that developers who write code that doesn't adhere to SOME set of standards, whether a codified set of standards or their own internalized standards, not only write aesthetically unpleasing code that is difficult to read (really the less important aspect of standards) but also, in my experience, they write crappy code ("crappy" as in more buggy and more difficult to maintain).

In a nutshell: if you don't have the attention to detail and self-respect for your work to write clean-looking code then you aren't going to write clean-WORKING code either.

It's a systemic problem, something I've witnessed far too much of.  Supposedly "professional" developers who can't be bothered to format their own code well and who don't write their code in a consistent manner also write code that has more bugs, sometimes paralyzingly difficult-to-find subtle bugs, and code that is much harder to maintain and extend.  They tend not to comment worth a damn and they usually do little in the way of planning and thinking about architecture before just starting to mindlessly hack away.  It's a detriment to an organization for sure, no matter if it SEEMS like they produce well because they always hit deadlines.  Hitting deadlines is well and good, sure, but doing so at the cost of cutting corners and writing code that is brittle (meaning it can't be extended without breaking something) and will need to be replaced a year down the road serves no one well.

Writing clean code that is formatted in a consistent fashion, commented well, obviously architecting the code in a reasonable fashion, these are things true professional developers do as a matter of course.  In fact, they don't know how to NOT do it!  Even when they're writing a one-off "quick hack" program, they still do it.  Part of it is experience of course- the experience of knowing that the one-off hack projects have a tendency to become frequently-used mission-critical applications without ever intending them to be... this is something newer developers usually don't realize (through no real fault of their own perhaps).  Better the program is written well to begin with, just in case.  Most GOOD developers don't even have a true set of standards they adhere to, usually nothing codified in any real way... they simply have a very naturally consistent style that they rarely break from.  It's as natural as writing any code and it's just an expected part of the job, or at least it should be.

You know, being a good developer isn't about algorithms or Big-O notation or patterns or architecture or syntax, at least not for the most part.  It's about logical thought.  It's about that exercise most of us had to do in school where the teacher makes you give them every step to make a peanut butter and jelly sandwich... inevitably you miss steps that in retrospect are incredibly obvious.  Guess what?  YOU WERE PROGRAMMING BACK THEN!

And I bet, if you could remember the experience, you could clearly see that some people just "got it" and some didn't.  The ability to break complex things down into manageable parts and then describe them logically is the core of programming, just like it was during that school exercise.  Way too many developers nowadays seem to fail the basic "thought test", and I haven't yet determined if its something you can learn or not.

Logic is, at its most basic level, simple, elegant and clean.  Your code should be a reflection of that, in form as well as function.  It should be a reflection of the ordered mind and thought patterns that produced it.  But you also have to write it with the realization that others will have to deal with it too, others that will likely have a mind that works a bit differently than yours... and you'll have to deal with it too, and it'll inevitably be after the point you've forgotten writing it!  Writing code with good habits in the first place will make all of that so much easier.  In fact, I'd say it can make a developer who fails the "thought test" at least passable.

And sure, there are exceptions to all of this... there are top-notch programmers who generate code that looks pretty bad... but it works, and works well.  There are developers who know every last technical detail, have an amazing grasp on computer science concepts and can throw together highly complex code without much effort.  Hey, those guys are amazing to me too.

But I sure don't want to maintain their code!

My headline here was obviously meant to be a bit sensationalist to get visitors... hey, I'm not immune to such vanity!  I actually suspect Eric would agree with most of what I'm saying here, and certainly I didn't come away thinking we had a huge difference of opinion on the subject of coding standards.  Like I said though, for me, it's about something a bit more than what I thought he expressed at tonight's talk.

I'll try and summarize it thusly: TAKE PRIDE IN WHAT YOU DO!  Maybe that's really the key to it all.  My dad, and I bet yours too, often said "if it's not worth doing right then it's not worth doing at all", and that's an adage I believe in strongly, and it applies to writing code as much as anything else.  We all have time pressures, deadlines to meet and most of us have more work heaped on us than we would in an ideal world.  It's certainly not EASY to be diligent and do things the right way instead of just the expedient way.

But really, that's what separates the true professionals from the pretenders.

Treat your code like the artistic creation it in fact is, but strive to make it more like an engineering discipline.  Combining those two schools of thought properly will lead you to a good place!

Filed under: Uncategorized No Comments

Android – You’re Doing It Wrong

I've begun to see a pattern of people posting their opinion of Android, especially those coming from other OS's, with one point that I find more than a little ridiculous.  Since I still move in webOS circles a bit I've seen it there certainly, but also from a few people coming from iOS or Blackberry.

The refrain goes something like this:

"I don't like Android because the built-in apps are lacking.  Yes, I know, I can customize Android a million ways to Sunday, but I shouldn't HAVE to in order to get a device that rocks, especially when <insert competing product name here> has great apps built-in".

There's usually some minor variation on that theme, but that's the underlying thought: these people seem to be saying that customizing is in some way bad and that the out-of-the-box experience should be top-notch and because it's not (something I'd frankly agree with) then Android is somehow flawed.

My reaction is always the same: you're doing it wrong.

Also, the REASON you're doing it wrong is because Apple has, whether you realize it or not, told you so.

Let me put it this way: have you EVER heard someone complain that Windows isn't that great out-of-the-box?  In terms of apps I'm talking about, put all other factors aside (stability, performance, etc)... ever hear someone say "Gee, Windows sucks because the built-in file manager (or web browser or eMail client or whatever else) isn't very good?"

*IF* you answer yes and *IF* you're being honest, then ask the logical follow-up question: did you hear that before or after Apple started becoming popular and mainstream again? ("again" in this context meaning since the iPhone came out)

I'd bet the answer is no most of the time to the first question and yes to the second in all cases where it was yes to the first.

The thing is, Windows has always been a PLATFORM, a foundation.  You're expected to build upon it.  That means getting the apps that YOU like and that YOU want to use.  The apps that come with it, by and large, are very basic, just enough to allow you to get started until you find the apps to take their place that really meet your needs.  And this has always been good enough- in fact, Microsoft has always been watched carefully when it comes to bundling.  They've had a tight leash on them for years in that regard.  But regardless of that, the fact remains that Windows has for the most part always been separate from the apps you run on it and it's always been a natural (if unspoken) truth that you don't expect the apps that ship with Windows to be anything great.  You EXPECT to have to load your own apps.  This is flexibility and freedom and exactly how everyone has always wanted it to be.

Until now it seems.

Why is the expectation any different with Android?  Why don't people view it as a foundational platform, shipping with, for the most part at least, basic apps to get you started and that you are EXPECTED to customize?  Why is this flexibility and freedom EVER seen as a bad thing?

Because Apple has told you it is.

Now, I'm not saying they've come right out and stated it as such.  What I mean is that Apple has, really always but especially since introducing iOS (and after working the early kinks out) done very well in providing some excellent apps with the OS.  No, maybe not always the best available, but usually not too far from the top, certainly better than some of the default apps Android provides.  For example, the iOS eMail client is, in most peoples' minds, a better eMail client than what Android provides by default.  I'd personally agree it is for the most part (I know some people claim the GMail client is fantastic but I hold no opinion on it personally since I don't use it).

So when I say Apple has "told you" this is how it should be I'm really saying they've set that expectation, and if Android or any other OS doesn't at least meet what iOS provides then it's somehow not as good (and the comparison works against any other competitor as well).

But, it's a flawed expectation.  I'm not blaming Apple for anything here by the way.  There's no problem with them providing good apps out-of-the-box.  In fact, for many people that's all they'll ever need and they'll be quite happy.  So be it.  Who am I to complain?  But, to then turn around and use that against Android is unfair because Android comes from a different place.

Apple likes to control the experience of its users.  In some ways that's a plus (it's usually a good experience, generally speaking, for most people), but in some ways its a negative (you give up some freedom of choice by accepting it).  Apple has a much more "appliance-like" approach to its products: you take it home, turn it on, and you're rockin' and rollin' with it.  But, the experience they designed FOR you is, to a large degree, the experience you're ALWAYS going to have (ignoring jailbreaking and really doing some hacking of course, I'm talking just average, every day users).

Android, by contrast, is philosophically very different: YOU are in control at a very fundamental level.  The experience you have is UP TO YOU.

Don't like the launcher that comes with your Android device?  No problem, choose one of the many alternatives.  Default eMail client not doing it for you?  No sweat, there's others to choose from.  Not a fan of the basic Android browser?  Cool, grab Dolphin or Opera or Firefox or even Google's own Chrome and you're good to go.  You have these choices, and yes, you may decide you don't want to put in the time and effort to decide which apps are best for you, but you have that opportunity, and moreover, Android is almost designed so that you are EXPECTED to do that.  I mean, you don't make it as easy as it is to switch launchers, in some cases RADICALLY altering the way you interact with your Android device, if that's not the unspoken expectation.

Put it this way: how ridiculous would it be for someone to say: "You know, Windows only gives me Notepad to edit text with... I can't do formatting, bullet lists, tables or any of that cool stuff I want to do, therefore Windows sucks"?  It'd be pretty ridiculous and you'd quickly and rightly point out: "Dude, go get Microsoft Office or LibreOffice or Symphony or one of the other office suites and you'll have exactly what you want!"

It's a question of expectations.  Apple "tells" you to expect a solid out-of-the-box experience, and you accept it because, let's face it, Apple has been MASSIVELY successful with it.  But Android "tells" you that you'll get a solid core and an OK set of default apps out-of-the-box and it's up to YOU to make it really suit your needs.

Now, if you don't have the time and inclination to put in the effort that Android to an extent demands, no problem, just keep using your Apple products.  I'm sure you're happy with them and that's fine with me.  Many people use Macs too and I know many don't alter the default experience very much either and they're perfectly happy with it.  That's cool with me.

But it's not fair to turn around and bash Android for not being what Apple thinks a computer (smartphone, tablet, whatever) should be.  It's not fair to say "Android sucks" just because you don't want to exercise the freedom it provides.  And don't misunderstand me: Android is certainly NOT perfect, and there's very legitimate gripes people can and should have with it (including me).  But the tired "the default apps aren't good" is just that: tired, played out, unfair and more than a little ridiculous in the first place.

Android is, at least in this regard, fundamentally about freedom and flexibility.  The competitors' products are not.  They take a very different tact on things.  You as a customer are perfectly free to decide which philosophy suits you best and go with it, and neither choice is more valid than the other for any given individual.  But if you're decision point is "the default apps in Android aren't as good as X, Y or Z's default apps" then, as I said at the start:

You're doing it wrong.

Filed under: Uncategorized 2 Comments