I finally got back around to working on Where is Io again, trying to get myself past this hump that I’ve had in front of me for a couple of months where I know exactly how I want something to look…. and I have no idea how to do that with the layout tools provided. After almost 14 years of hacking on web applications in my spare time I’ve got a set of tricks that I understand pretty well. Given an end goal, I can do a pretty good job of getting html to look like it.
I remember with fondness when I got myself a copy of DHTML the Definitive guide, which had 200 pages of all the html tags, all their style attributes, when they were supported, what they did, and some examples. That, and the “view source” button on every browser, made learning HTML layout something that was feasable.
The mobile application space lacks both of those things. While there is a decent amount of open source applications on top of Android, they cover a very small set of similar appearances, so I definitely find my motivation can sometimes wane while trying to figure out how to right align columns in a table.
I think this explains a lot about why Flash isn’t going away any time soon. Learning new layout paradigms is a heck of a lot harder than learning a new programming language, and that kind of investment is far more of a lock in than a language. It’s the reason my Chumby will probably never end up with any custom widgets from me (as I’d need to learn Flash), and the Meego effort has a very dim future (C++ and Qt… in 2010… really?). At this point I’m willing to put in the time to learn a new layout and UI model for Android because I’ll be able to use it on my phone and my TV, but my interest in having to get good at a 3rd UI paradigm is just not thrilling.
Update: I managed to get over the hump with learning a bit about building custom components. Hopefully that means a new release of Where is Io out this week.
I’ve been using Drupal for a number of community websites for the past year. Overall I quite like the system and how customizable it is.
What I’m not really thrilled by is the way the module structure exists on drupal.org. The problem is that drupal core is a very small number of modules. The bulk of useful functionality comes from user contributed modules. So far so good, many projects run the same way.
The real issue is that the drupal project maintains a centralized CVS infrastructure for module developers. There is a pretty formal process to get accepted as a module author, and no real way to get CVS access to just fix bugs. The net result is that after finding 3 bugs in the date and callendaring modules, creating patches for each on my own environment, and submitting them upstream, only 1 has gotten looked at. The fixes were submitted about 8 months ago, and I’ve pinged a few times. I also wrote the author directly on one of the modules.
The root cause of this issue is that drupal has centralized infrastructure, but decentralized decision making. It is a classic community wherein github would be a good solution.
I’ve been an absentee maintainer before, I know that sometimes interests change, and you move on to other things. But at least with something like github, other folks can very easily extend what you’ve got and make the fixes themselves. Hunting out RCS style patches in drupal discussion forums is just really problematic. At this point I’ve got quite a number of local fixes, so module upgrade and maintenance is tricky. The only saving grace is that most of those fixes are on modules that are effectively abandoned so I shouldn’t have to worry about an update coming down the pipe.
The Drupal community is soldiering on even with bad developer infrastructure. I just wonder how much further along they’d be with better developer infrastructure.
The Ruby language has this great feature called Mixins. It lets you add methods to existing classes. Take this example from Ruby on Rails (which uses mixins heavily):
time = 2.days.ago
Yes, that’s valid code and does what you think. The result is a DateTime object. It was accomplished by adding methods the Numeric and to DateTime. If you come from a strongly locked down language background, this sort of thing horrifies you. If you don’t, you think it’s awesome. Remember, this isn’t inheritance, it’s actually changing the fundamental classes. This makes it much easier to retrofit on existing code. The python folks call it Monkey Patching, which makes it sounds kind of dirty. I like Mixins better.
While Ruby has been my language of choice for personal time hacking, I’m doing a lot of Java recently due to working on Android things. This past weekend I remembered one of the things I dislike about strongly typed languages: type gymnastics.
If you’ve got a time as milliseconds in Java and you want it in a string you’ve got to first convert it to a Calendar, then to a Date, then give that Date to a DateFormat. You’d think that Calendar.toString() might actually give you something useful, but it doesn’t. Oh, and also realize that every one of these objects has it’s own internal notion of TimeZone, quietly gotten from the system, so if you are trying to do something in UTC, you have to manually force that on them all. This is the crux of type gymnatics, long changes of type conversion operations because to get from A to B (in my case A:long, B:string) you’ve got to go through C, D, and E in the right order. These conversions are error prone, and clumsy, and largely produce some part of your namespace called “util” that is largely static methods to convert between one thing and another.
This is because the authors of A never thought you’d have to get to B. What’s so interesting about B? C is really nice this time of year, wouldn’t you just like to stay there instead?
The real problem is that original authors of software rarely really understand what their software will be used for, and the more immutable languages don’t let you fix things after the fact. In Java this means that any project ends up with a “utils” package which is used to do conversions between types that can’t natively be converted. All that code is just boring boiler plate, which is where you are most often going to make a hard to find mistake. Nothing generates errors like boredom.
I was recently forced into a pair programming exercise at work because we’d gotten to a critical bring up part of the code where nothing was really able to be done in parallel. Given that we are all noobs on this source base, there also wasn’t really anyone that should just go take the lead on it either. Given that 1 member of my team is actually in the same office as I am, we decided to try pair programming through it, because what else were we going to do. Jeremy brought in his laptop, and he mostly drove while I navigated as he was writing code. The results were impressive. In 2 days we got from a server that wouldn’t start, to one that was responding to half the nfs commands.
When first presented with Pair Programming most developers / managers have the same response: I’m going to have 2 people to do 1 person’s job? That’s just crazy inefficient. I admit, that I had my doubts, but as there is a decade of success behind this technique I decided it was worth trying. The generic “it’s actually more efficient” statement didn’t sit well with me because there was not explanation behind it. The why it works is actually really interesting, and I think it also explains the types of problems it is good for and the ones it is not.
Anyone that’s developed software has run into programmers rut at some point. This isn’t the same thing as writers block, it’s not the inability to create something, it’s having something not quite work and looping for hours to try to figure out why. Typically it’s solved by going away from the code for a while (often overnight) and the solution is obvious in the morning. When tackling a complex problem, you start building a model in your head that matches the software you are writing. Sometimes you validate that model as you go, but often you don’t. After hours working with that same piece of software you’ve made hundreds of assumptions on the model, any of which might be wrong. But once it’s fixated in your head, tearing it back down to validate each and every step seems defeatist. There is “just one more thing” that you could try and it will get you past this block. How many times have you said that to yourself… just one more thing. These “just one more thing” loops can easily become 4 hours in a shot.
When you walk away and come back, assuming your brain was focused elsewhere at the time, you’ve got to rebuild that model. It’s not actually an exact copy of the model before, that’s why it takes time to get rolling on a complex software task. And, as often as not you make slightly different assumptions this time, and low and behold you easily see where you were wrong. Problem averted, and we move on.
But in pair programming, you don’t have 1 model, you have 2. At a superficial level, those are the same model, that’s the architecture of your project. But on a deep level, the level of actually assigning variables and doing test conditions in the code, those models are different. Those differences are why we enforce code conventions on software, because left to our own devices those differences in mental models would spill into the editors in somewhat surprising ways, making the software itself completely incomprehensible. Look at someone’s collection of private scripts they’ve written to automate small tasks, stuff they never intended to be shared, and you’ll see what I mean.
With only one person at the keyboard, and 2 mental models of the code in effect, you’ll get a nice amount back and forth when the 2 models don’t line up. It’s kind of like unit testing for your brain. During this exercise there was a lot of “wait, why are you doing that? … isn’t that supposed to be this other value? … are you sure that value is actually initialized in the called?” I have no idea how many times I was right or wrong vs. Jeremy, it doesn’t matter. What mattered is that we were constantly checking each other. I mentally noted at least a dozen times where left alone, I would have been stuck for hours. While not perfect (we had one rut that got us stuck for 2 hours because we’d both made the same bad assumption in our model), it seemed like we eliminated 90% of our ruts by having the second mental model.
And that’s where the efficiency comes from. On anything other than rote code, software development is not continuous output. It’s some number of hours hours stuck in a rut, then an hour of speedy implementation, then a new rut, then a burst…. rinse, wash, repeat. It’s a set of fits and starts that as developers we convince ourselves was a much smoother process because we felt busy, or just because it’s the only way to do it. But it turns out those fits are actually huge inefficiencies in the process. They are probably one of the primary causes behind the observation that “great developers” produce 10 – 100x more output than average developers: great developers figured out how to pop out of ruts faster (either consciously or subconsciously). Pair programming gives you a simple tool to get some of that efficiency with your existing team and developers, making everyone a bit greater in the process.
Actually, the amount of refraction changes with air temperature, pressure, and the elevation of the observer (see Chapter 16). A change of temperature from winter to summer can shift the times of sunrise and sunset by about 20 seconds in mid-northern and mid-southern latitudes. Similarly, observing sunrise or sunset over a range of barometric pressures leads to a variation of a dozen seconds in the times.
It turns out that something as “simple” as calculating Sunrise is anything but. After you’ve worked out all the geometric positions of the planets, you then have to run your simulation backwards due to the ~8 minute light delay, and then you’ve got to take the pesky atmosphere into account, as it changes the apparent position of everything over the course of the sky. The effect is non uniform, which is why the Sun on the horizon looks squashed.
Working out all this math (with the help of my trusty copy of Astronomical Algorithms), and putting it into code for Where is Io, remains a taxing mental exercise, but one I am immensely enjoying.
One of the things that most excited me out the Google I/O event a couple weeks back was Google TV. It’s a set top box that brings a lot of web content to the TV. But what really excites me about it is that it’s an Android platform, that will have access to the market place. Having this announce come out a couple days after I pushed my first Android app out got me even more excited about the platform.
In my house I’ve got the following devices: a thermostat that’s attached to my home network, with a web interface that lets me adjust the temperature and programs; a TED 5000 energy monitor which is on my home network; a set of weather station sensors that I’m collecting data from on my home server. Each of these have some web interfaces, non consolidated, to get data, and small little screens on the respective devices to go and see what’s going on. And in my living room I’ve got a 42″ TV, with brilliant color.
I want all these various home sensors and actuators to show up on my TV, and for me to be able to control them from there. I keep looking at my logitech harmony remote and really thinking that I should be able to use channel up / down to adjust the temperature in my house when we’re hanging out on the couch watching TV. Not that many months ago, intrigued by how the Netflix Instant Bluray disc worked, I started looking into the Bluray Java spec, and realized that if I had to I could probably build a disc for my PS3 that would do most of this, but it would be pretty custom, and the dev / test cycle would burn through a lot of bluray media. I tried to download the Popbox SDK to see if they’d give me what I want, but they’ve made it impossible for me to actually do that.
Google TV is going to give me a set top box in my living room that will let me get access to a wide range of content, which will be great, but also let me publish my own code to it. As a creator of software, having that application channel, even for only my own use, is just incredible. The fact that it will share a lot of characteristics with my phone makes it all the better.
I really can’t wait until Logitech gets it’s box out there, and I’ve got something to experiment with. Having my livingroom TV be the nerve center of my home is a concept that seems so natural, and I’m surprised has taken this long to bring us this kind of tech.
I just pushed Where is Io out to the Android market for the low low price of free. The application presents a “spirograph” view of the 4 large moons of Jupiter over the next 96 hours, including an indicator on the current position. There are details provided on each of the objects in the system. Jupiter is just starting to come up in the early mornings, so over the next few months it should be handy.
You can download it directly here:
Or check out the Where is Io page for more screen shots and information (screen shots skipped for this post, because I just put some up in the last post).
It will be a couple of weeks before the next release, as I’ve got a real world building project that has to get done, but rest assured this is just the beginning.
I’ve made some more progress on what will be my first Android market application – “Where is Io”. I’ve learned a lot about sqlite performance on the phone, which isn’t bad as long as you limit the number of database opens you do. I’m also trying to make the interface more self explanatory to even those with less astronomy knowledge. Here are the current screen shots:
I’m not going to explain anything else on the interface, but I would love questions / comments in the blog if this seems confusing. My “must do” task list probably puts this at about 2 weeks away from publish into the market. Fortunately, Jupiter is only just coming out of the Sun now (with a missing belt!) so as long as I get this out in the next month or so it will be useful to folks.
There have been a series of posts about Git in the last week over at The Reinvigorated Programmer. It’s fascinating to watch someone come to terms with Git that’s also a brilliant writer, and gets to the heart of the challenges so quickly. If you’ve ever struggled getting over that hump with Git, I encourage you to read the three posts, in order, and see if it helps you on your journey.
Act 1: Git is a Harrier Jump Jet. And not in a good way
Act 2: Still hatin’ on git: now with added Actual Reasons!
Act 3: You could have invented git (and maybe you already have!)
Last Wednesday, at the kind invitation of the folks from Eclipse, I had the opportunity to sit with more august company – Justin Erenkrantz (Apache), Mårten Mickos (Eucalyptus), and Jason van Zyl (Maven/Sonatype) – on a panel charged with debating the future of open source. Among the questions posed to us was this: is the future of open source going to be based on communities such as Apache and Eclipse or will it be based on companies that sell open source?
My reply? Neither. It’s Github.
Stephen O’Grady does a great job of articulating why github is fundamentally changing the nature of open source development. It meshes well with my own thoughts on the matter.
|
|
