Extremely positive attitude. My website is beebo.org.
A few thousand words on the Mountain Lion document model, the auto save model, how it differs from previous versions of OS X, and so on. Does this really need to be so complicated? I very much prefer the way Sublime Text handles this problem: a document is continuously auto-saved to some secret location, with the changes only written to disk when you explicitly hit save. As soon as you make some changes to a document, the “unsaved” indicator in the tab changed to “unsaved”, but if you quit the editor at this point: (a) there’s no prompt to get you to save “unsaved” changes; and (b) if you restart the editor, you get everything back the way it was before you quit, including the “unsaved” indicator. (It doesn’t save the undo stack, I just noticed, so it’s not perfect, but it’s so much better than the confusing muddle of Mountain Lion.)
Some tips from a booklet that came with my packet of Sugru. I was hoping this would be online, so I could just throw the booklet out (the suggestion that you clean you hands by wiping them with tissue paper is excellent—water and soap is surprisingly and frustratingly ineffective), but it’s not, and so I’m typing it out here…
Master Your Craft
In case you didn’t know…
Those mobile specific URLs—m.*
, mobile.*
and the like—they’ve
got to go. There’s just too many mobile-specific URLs popping up on
Twitter and similar, and since for some reason the browser detection
only only pushes people from desktop to mobile, if you’re actually on
a desktop browser, you end up stuck there. A poor user experience,
and it doesn’t sell many ads, either. People are just going to have
to do that shit right—the same URL (i.e. resource) for everyone, and
content negotiation (or “responsive design”) thereafter. (Set a
cookie summarising what’s in the User-Agent header, if necessary.)
It’s not that hard!
A brief note; something I discovered recently found surprising: JavaScript compilers, which these days end up essentially compiling the same source code into machine code multiple times (the same function might sometimes take ints and sometimes take floats, for example), do it by going back to the source code and re-parsing the source. In particular, they don’t start from an intermediate representation like an AST or bytecode. This applies both the v8 and Firefox. (Actually it’s not clear that Firefox actually operates this way, but Eich says that it could.) I wonder if they have essentially two versions of the parser, one for unverified source code (better debugging information, but slower) and another for source code known to be syntactically correct? And what does this mean for Parrot?