Signs of experience

[jducoeur]

When you run your program for the first time in two months:

• A beginner has no idea whether it will run or not.


• A journeyman engineer will assume that of *course* it will run properly. It's just code, after all, and I haven't touched it, so duh -- nothing has changed, so why wouldn't it work right?


• An experienced systems engineer holds his breath and prays when he says "run", because he knows the 75 different forms of bit rot that can set in in the span of eight weeks. (OS updates; remotely-fetched libraries that have disappeared out from under you; forgetting the correct procedure to start the program; IDE "fixes"; or simply the machine deciding to be ornery.)

Knock on wood, it looks like Querki has not suffered any bit rot while I've been off dealing with the house. *Whew*. Now I finally get to get back to work. I believe step one is the very beginnings of identity management; there will likely be a post over on the development blog about that soon, since I spent yesterday puzzling the first pieces out...

Comments

[laurion]

Hmm. I'd probably fall between journeyman and experienced then. I'd have discarded the idea of OS updates, given that it is a web platform, and thinking that I'd need to worry about runtime environment updates, but then again, not knowing how it taps into the lower libraries, yeah. Are you actually using remotely-fetched libraries? I've seen other projects doing that too, but it hasn't yet made sense to me as to why you would. Forgetting the correct procedure is solvable by creating a bash script that does the procedure so you only need to remember one thing instead of (n), etc. But that, I suppose, leaves at least 70 other things that can happen. *grin* I suppose this is why systems like OpenCloud and ESX and even Amazon EC2 have become popular. By abstracting away hardware and abstracting in the ability to seamlessly migrate and spin up new VMs, there are a few more sources of problems that can be managed by intermediary layers.

[jducoeur]

I'd have discarded the idea of OS updates, given that it is a web platform

Well, remember that this is the development machine for Querki itself. It runs the Web, it doesn't run *on* the Web.

Are you actually using remotely-fetched libraries? I've seen other projects doing that too, but it hasn't yet made sense to me as to why you would.

For the time being, yes -- it's actually very common for the open source world these days. Mind, "remotely-fetched" doesn't mean that it gets downloaded every time; rather, the build environment maintains a local cache of the libraries, but keeps an eye open for updates.

For a small project like this, that works well most of the time -- getting quick notifications about bug fixes and things like that. But I've gotten bitten once or twice by, eg, using a snapshot version of a library (because I need alpha-level features) that disappears off the repository when I'm not looking.

I suppose this is why systems like OpenCloud and ESX and even Amazon EC2 have become popular.

True, although those can introduce their own forms of bit rot -- eg, procedures and APIs that change without you noticing them.

I *am* actually thinking of moving Querki over to CloudBees for its hosting (indeed, that's been part of the plan for quite a while now) -- that has some notable advantages, but I haven't gotten around to it yet. When I do, I'll have to think about whether to switch to using them for the development environment as well...