About that cunning plan

[prog]

Before I could figure out how to properly address the issue of going broke, I had to see when our latest fundraising schedule predicted that I would be able to write myself a paycheck. daerr and I played with the spreadsheet some more tonight, making two different, new versions that are based around a schedule of small, gradual investments rather than one really big one up front.

I now am confident that the best choice for me involves picking up a short-term, low-stress programming contract, something telecommutey. I have done these before, even relatively recently (crunching up voter-reg records for 2004 Ohio, sigh), and know that I can complete such work without giving up everything else that I'm doing. It's still enough of a time sacrifice that I wouldn't want to make a habit out of it, but that's the whole point; if Volity's cunning plan works - and I think it will - then I shouldn't have to do more than one or two of these.

So, it's http://jobs.perl.org for me. And updating my resume. (And if any of you have work that an expert Perl and web hacker can accomplish, given a deadline but a completely flexible schedule, please let me know.)

---

I'm going to have to make a more detailed post in the devblog about this: we also had a great conversation about some concerns I have been having with how we're doing things vis-a-vis Gamut, based on both user and developer feedback, and my own observations about how the webby world has been working lately.

Upshot the first: I am suddenly keenly interested in making an variation of Gamut that runs as a Java applet, within the Web browser. The applet would really only need to be the SVG pane; everything else can be accomplished with AJAXified HTML. We can do this using tech and know-how we have now; it will just take time, and it will be so worth it.

I am increasingly convinced that, wherever reasonable, (things that run in a Web browser) > (things that you have to download, install, and run separately).

Upshot the second: Actually, nothing new, but we really need to press ahead with SVG UI development libraries now. And by now I mean now.

Comments

[radtea.livejournal.com]

I am increasingly convinced that, wherever reasonable, (things that run in a Web browser) > (things that you have to download, install, and run separately)

I fully agree, but strongly disagree that Java is the best way to do this. In my (now fairly dated) experience the Java-inna-browser environment is even worse than the JavaScript/HTML environment. JVMs are like snowflakes--no two of them are alike. And there are a lot more JVMs, especially counting incompatible versions of the same JVM, than there are major Web browsers.

So unless you really need the power of Java on the client side I'd seriously investigate the possibility of going all AJAXy, although admittedly that has risks of its own.

[prog.livejournal.com]

Until SVG works in-browser as cleanly as HTML, we do in fact need the power of Java. We'd use it solely to drive the SVG pane that displays the game interface... everything else would in fact be AJAX.

I note that, in fact, the major browser are chipping their way towards SVG compliance. We will wait for them to catch up, and the applet will serve until then.