First Slice of Cake finished

[jducoeur]

This month has been a somewhat tough one emotionally. This is largely because, about four weeks after I started, I now have a program that prints, "Hello, Mark Waks!" (plus, as of this morning, the last time I logged in).

Mind, I haven't exactly been quiet for the past month. The program:

• Uses Apache Tomcat to serve that string out via a servlet;


• Has a JSON-based Ajax interface to allow the static webpage to fetch the data from the servlet;


• Integrates the MooTools Javascript toolkit to signal when the page is ready (and will use it for lots of UI shortly);


• Runs inside of Facebook as an application, and fetches the user's data via the Facebook APIs;


• Uses Hiberate to generate all of the data-manipulation code, and to talk to a MySQL database on the back end;


• Implements the Ecology pattern that I'm so fond of as a program-lifecycle and discovery model, and has a bunch of specialty classes to make JSON and Hibernate and such all play together nice and transparently, and allows me to extend the program API trivially;


• and has automated functional tests that use Selenium to open the browser, navigate through FB to the app, and check the results. (No unit tests, admittedly, but that's intentional -- I've always focused more on functional tests than unit tests.)

So basically, I have a program that does nothing -- but does it *really* well.

This is all more or less according to plan. One of the precepts of at least some forms of Agile Development is the "slice of cake" model. You do your work in slices, and each is pretty thin, representing just a single bit of functionality, but each slice should cut all the way across the system, doing it all correctly. That first slice is always the hardest, because it requires you to set up the bulk of your infrastructure. With that done, it becomes much easier to add each feature as a proper little increment.

Realistically, I knew this was all going to take a while. I've never even touched most of those technologies before, so there has been a great deal of self-education in the past month, to get to the point where I can get each one up and running. It's taken about a week longer than intended, mostly because the documentation for this stack is rather less well-organized than the Microsoft stuff I'm used to. (And yes, that comment is as scathing as it sounds, but it's probably inevitable given how much open source I'm using here.)

None of which makes me any more content about having so little to show for a month's work. But with any luck, by the end of next month I'll have made quite a lot more progress...

Comments

[metahacker.livejournal.com]

Hello World it ain't! Sounds like you have your whole pipe in place, end to end, with testing, and all ("all") you need to do is start filling it with content. Which, in your case, is actually smarts, but close enough.

So congrats!

[jducoeur]

Thanks!

[learnedax.livejournal.com]

Hmm. While I think it's good that you have that infrastructure in place, and it's absolutely a valid approach to get that all set up first, I think it's not what I would normally call agile.

Agile is indeed about taking tiny little slices of the project... but making the first slice weighted with all the infrastructure isn't really doing that. Sure, you need to design your system so that at every step it's modular and extensible, but you explicitly shouldn't write heavy components in advance of necessity. It's tricky to write features before you lay down the infrastructure, but the idea of agile is that you can't know in advance what that infrastructure should really be like, so you keep it as light as you can as long as you can...

[jducoeur]

Well, this *is* keeping it light -- most of the details aren't in place yet. But pretty much all of this is going to be necessary for the very next step (starting a conversation), so I chose to get it all in place while it was still in the trivial "toy" state, to minimize my variables.

Some of those bits may not look critical from the outside, but they really are: they're all involved with not writing any throwaway code. For instance, the JSON API is bound up in the client/server architecture, which is designed around static pages that are chatting directly with the server for content.

So while it's one step shy of true XP, it's not too far off: I expect all of these components to be essential by the end of the week...

[alexx-kay.livejournal.com]

None of which makes me any more content about having so little to show for a month's work.

But you managed to *do* a solid month's work on that infrastructure, so congratulations! I've never been able to maintain that sort of focus for more than a few days at most, which is why I've never gone into game development on my own.

[jducoeur]

Thanks. Over the years, I seem to have developed the necessary discipline. The situation at Zingdom may have pushed me over the top: since I not only had to be disciplined for myself, but had to manage that last project, it taught me a lot about how to manage without making myself nuts. (I also discovered that I am most comfortable when the buck largely stops on my desk.)

Really, though, it's not all *that* different from writing a LARP. In both cases, I have to set myself clear goals and sensible timelines, and make a point of doing a consistent amount of work a day. The scale's rather larger, but the principles seem to be pretty similar...

[cellio]

The next slice of cake will come more easily because of the work you've done here. Congrats!

[doubleplus.livejournal.com]

Congrats! And sympathy about docs for open source stuff -- I presume it's because everyone wants to work on the parts that are cool and fun, and the parts that are necessary to make the cool stuff work, and documentation is rarely cool and fun.

[jducoeur]

Actually, I'm coming to the conclusion that it's even subtler. People do *write* the documentation, and some individual bits are even decent. But the really unglamorous job, that's so vital but so neglected, is *organizing* the documentation, and making the pieces fit together.

In that respect, the Microsoft stuff isn't fabulous but it isn't terrible: once you grok how it works, it's not too hard to find what you're looking for. But because the open-source stuff (a) tends to be extremely flexible, so it can be mixed and matched in so many ways, and (b) comes from so many different vendors, it's much harder to organize. And nobody really has the commercial motivation to do a really good job of it.

So for example, there is some documentation for Tomcat. And there is some (really pretty good) documentation for Hibernate. And there is some documentation for JNDI. But there are precious few pages describing how to use them together, and even those tend to become obsolete very quickly. I eventually found a single page on the subject that was more or less up-to-date -- but that (like most such pages) advocated a very specific configuration, which didn't quite match mine, and didn't provide quite enough explanation of the underlying principles to help get me past the differences. (With the result that I'm still using a raw JDBC connection, without the JNDI layer that I clearly am going to need to fit in eventually.)

Admittedly, this is harder because I'm trying to absorb so much so fast: this is all from a completely standing start two months ago, and I'm not willing to spend six months on self-education. So I've learned a very shallow amount about a very broad swathe of the stack fairly quickly. That'll improve with time, as I internalize more of this. But I am winding up with a remarkably large stack of bookmarks I need to juggle, to understand all these pieces...