Recovering your submitted form data in Chrome
Have you ever submitted form on a website after filling in a lot of text (maybe a comment), only to get an error on the other side? And when you hit back, your nice long response is gone? There's a (sort of easy) way of retrieving it, if you don't stray from the landing page after you submit the form -- at least in Chrome.
1) Wrench icon > Tools > Developer Tools
2) Network tab
3) Click on the network request with the same name as the current page (that matches the URL)
4) Click the Headers tab in the right section of the developer tools
5) Scroll down to the section "Form Data" (you may need to Expand this section by clicking the > arrow)
6) Copy and paste your previous response into somewhere safe (Notepad?) while you attempt to resubmit the form or frame your amazing writing for later.
I'm pretty sure you can do the same thing with Firefox, but it would require you to install Firebug.
Quasi-turn-based game design: movement
I'm fiddling around with building an online browser-based game right now, but am having some trouble trying to figure out how and when different units should move (since they can move at different speeds). The game is turn-based, i.e. actions happen in fixed time intervals, but it has real-time elements, since each unit is on its own clock -- actions that happen every 5 minutes for one unit don't necessarily coincide with actions for another unit that also has a 5-minute tick interval. In my mind, these are the requirements:
- No unit should move multiple tiles in a single turn -- in a given turn/tick/whatever, they move at most one tile.
- Some units can move faster than others -- namely, cavalry can move 3x as fast as infantry, for example.
- Units that have varying movements speeds could have the same attack speed -- just because they move faster, doesn't mean they do everything else faster.
- The speed of units can change dynamically -- if they are Haste'd by magic spell, or Slow'd by a bog, then...they do what you'd expect.
So far I've come up with three strategies for how one might implement these in a game.
Easy way to generate “release notes” on GitHub
Assuming you're using tags with your git repository on GitHub, it's rather easy to generate something resembling "release notes"; or at least, a list of descriptions of all changes between two tags. That's pretty much the same thing, right? Anyway, if you go to "/compare/tag1...tag2" under a project on GitHub, it'll show you everything that changed between those two tags. Here's an example: Radiant's changes between 0.9.0 and 0.9.1. Neat, huh? If not used as the actual release notes, it can at least help you remember all that changed between two releases when you handcraft a list yourself.
This feature was announced March 1, 2010, but it's hard to find unless you know you're looking for "compare view" 
. It's also sort of hard to find -- you have to go to the Source tab, then Branch List, then hit the Compare button on a random branch, and then, finally, you can input a start and end tag in the upper right. Easy to find, no?
How we got here: Web App Stores
The recent sudden popularity in web "app stores" is taking off with a rate normally associated with fads, but in some respects is actually to be expected. Still, it bears an interesting similarity with one of the oldest types of websites that the average consumer has seen: directories.
Grandparent of Ruby and Java: Eiffel and friends
I'm curious about the effort involved in writing a new programming language, and hence have been doing a little research (including watching Guy Steele's now-famous and amusing Growing a Language lecture). I know I want to target the NekoVM (primarily one of the targets of haxe, for now), but what languages should I base it on? One of the languages I've heard a good deal about about, mainly based on its design-by-contract principles, is Eiffel.
(even if you're not interested in building a new language, learning about programming languages and their design decisions increases our understanding of them and, hopefully, our proficiency with them)
Banks and OAuth support
For fun, I decided to ping all of my financial companies (Bank Of America, CapitalOne, Chase, EmigrantDirect, INGDirect, Vanguard) about their plans for OAuth support. I don't know how many of you use the wonderful service known as Mint, but I like it a lot. Unfortunately, a part of me died when I gave them my username/password for my banking sites. And INGDirect is secure enough that Mint can't even interface with them! Sorta cool.
Anyway, here's what the institutions said:
Web server output generation design patterns
There are several styles of content generation that I know of so far...I'm reviewing them because I'm looking to see if there could be something better.
Flat-file
Example: plain ol' PHP
PHP, at its simplest, doesn't have any separation at all -- you can, if you choose, have all the programming/form-processing logic in the same file that renders the output to the browser. While simple, if you're creating a full website, this can be cumbersome and confusing.
Design pattern/flow for building a website
So here's how I normally do things:
- Do as much of the models as possible in this first pass, skipping validation but including schema stuff
- Stick a couple things into the controllers that I think I'll need
- Build out some of the views, giving them some basic styles
- Revisit the models to add validation, helper methods
- Build out the rest of the views, give them real styles
- Muse about specs, then give up before starting
- Put more stuff into the controllers
- Iterate on random components until you're done
Needless to say, I'm getting to the point where my lack of organization kills my mini-projects before I hit step 4, sometimes even sooner than that. So I'm going to try a slightly more...conventional (or widely suggested, at least) approach:
- Create controllers with just enough information so that your pages will display. No setting variables yet or other logic!
- Fill out the views with as much HTML and fake data as you need. Site have a sign-in page? Leave a link to "force sign-in" the user that simply sets them to an authenticated state. All it should do is set a session variable
- Spec out the models. Don't check for validation yet, just check for core functionality, i.e. there is a User table, the first user has a name of Foo and email of [email protected], etc.
- Fill out your model code so that the specs pass -- this includes migrations with sample data (these can be removed in a later migration).
- Spec out your controllers/views.
- Fill out your controllers/views so they pass specs.
- Do the rest of the little things that need doing, like validation, error messaging, authentication, styling, etc.
- Revel in having finished a project.
Hopefully I'll get further than step 3 this way! I'm going to try to focus more on content/frontend instead of getting bogged down in the backend, and I want to actually write specs.
Any comments/suggestions?
XSLT is a giant pain
Some of you may be aware that XML+XSLT 1.0 can be rendered directly by modern browsers (even IE6!), which led me to thinking that it may be a good idea to give it a try and see how good or bad it was.
Starting new projects
So I know I'm not the only dev who does this, but I tend to start a lot of projects -- and not finish them. I'm coming up with a checklist of things that I want to make sure I do before getting involved in any new projects.
Read on for some of the initial questions you should ask yourself, and what to do next.