...more recent posts
Obviously I haven't been blogging here in quite some time. I think that is going to change, and the changes I've gone through professionally, which I think largely mirror trends in the industry in general, should become clear.
I used to be proficient on the "server side" of the web equation (hence the blog title), meaning I mostly focused on the server: linux admin, Apache, MySQL, PHP (plus email, dns, and everything else that happens on the server.) I still do all that, but things don't change very much or very quickly inside that technology stack. The other side of the equation is the stuff that happens on the client side (i.e., in the browser.) Way back in the day this didn't matter much. The web browser just rendered the HTML encoded web pages that you sent it. Javascript existed, but you couldn't really count on any particular client having it enabled. But times have changed.
Nowadays, for most websites, a ton of stuff happens in the browser. Instead of just sending already baked HTML to the browser for it to render into a web page, you send it some HTML, along with programming code which is then executed in the browser in order to complete the HTML page. The programming code is written in javascript, which all browsers can execute, and which you can count on clients not having turned off (since so little of the web would work if you tried to surf without javascript enabled.) This results in the kind of interactive web pages we have all become accustomed to. You can click on interface elements on a page, and things happen (menus open, new content is fetched from distant servers, slide shows launch, etc...) without having to reload the whole page from the server. Going from a web of static pages to a web of dynamic interactive pages is largely the result of moving code from the server side to the client side of the equation. Web sites become less like "pages" of content and more like traditional desktop "applications".
HTML5 is a not very strictly defined term used to cover a lot of this new(-ish) technology. It means not only the latest version of the HTML standard (the latest HTML tags you can use to mark up the content of your pages thus creating the visual layout,) but also CSS for styling (fonts, colors, etc., and increasingly animations,) and javascript. HTML5 is sort of the catchall term for the technologies underlying this transition from static web pages to dynamic web apps. (Yeah, of course, this is a quick post and not completely accurate, but hopefully gets the general flavor.)
In any case, if I succeed in starting up the blog again, most of the posts are going to be about the client side. Especially Jquery which is (again, not completely accurate, but for our purposes...) a dialect of javascript that makes it easy to write javascript code that works the same in all browsers. I doubt this will all be very interesting. Mainly it will just be a place for me to put links which I think I might need at a later time. But occasionally I'll try to say something more high level about the state of the web and possible futures I see.
TideSDK looks incredible: "Create multi-platform desktop apps
with HTML5, CSS3 and JavaScript" (and PHP, Python, or Ruby.) Can't wait to dig into this.
Could have used this years ago, but at least I know about it now: mod_xsendfile
mod_xsendfile is a small Apache2 module that processes X-SENDFILE headers registered by the original output handler.
If it encounters the presence of such header it will discard all output and send the file specified by that header instead using Apache internals including all optimizations like caching-headers and sendfile or mmap if configured.
It is useful for processing script-output of e.g. php, perl or any cgi.
HTML email boilerplate. Should probably incorporate this.
Maybe I should change the name of this blog to WOW and then start every post with wow.
Wow. HTML5 bookmarkable infinite scroll example. Infinite scroll itself is cool, although it's not terribly new - basically instead of forward and back buttons (or previous and next) to page through content (like a blog), infinite scroll just loads new content in the background using asynchronous calls to the server as you scroll. So, for instance, as you get close to the bottom of the page some javascript calls the server, asks for more posts, and then they magically appear so you can keep scrolling. This way you can read a whole blog on one page, but you don't have to load the whole thing in at once (and you don't have to load a ton of content yo don't need in the case that you don't scroll all the way back which would probably be the usual case).
The cool thing in the example here is the use of the HTML5 History API - specifically replaceState - so that the URL changes as you scroll, thus making any point on the infinite page bookmarkable.
Wow. Hype is a key frame based animation creation program that outputs pure HTML5 and javascript. My mind is blown. Check out the gallery of examples.
Just received an Eye-Fi Pro X2 SD card for the new camera. The Eye-Fi card has Wi-Fi along with 8GB of storage. Totally cool. At home if I shoot pictures they are automatically uploaded to my computer as I shoot. Away from my computer I can upload straight from the camera through any open Wi-Fi network to a whole bunch of photo sharing sites (flickr, picasa, etc...) plus there is support for FTP so you could send them to any server on the internet (although, to be geeky about it: FTP? Really? Holy outdated insecure protocols.) And evidently there are free apps so that I can upload directly to iPhone and iPad (and Android too.)
Packaging and set up are very nice and straight forward. Great product so far! Highly recommended.
I first blogged about this tech way back in April 2006. Took them a long time to come to market, and me a long time to get on board. Here we are 5 years later and my mind is still blown. How did they get Wi-Fi in that tiny package?
Facebook's Open Compute Project. Basically, they've put all their custom server and datacenter specifications on line for anyone to use. Very impressive.
w00t. I successfully hacked jquery.markitup (1.1.9) to display it's preview (routed through previewParserPath) in a div rather than in an iframe (i.e., this is on the same page as the markitup textarea - so with previewInWindow not set.)
My problem was that my markitup'd textarea is on the same page where the content will be displayed (a textarea at the bottom of a column of comments.) With an iframe the previewed post does not get the styling of the parent page where it will be displayed when posted, so the preview doesn't necessarily match how the comment will look when posted. By displaying the preview in a div on the page I automatically get the correct styling (I just make the preview div have the same class as the divs holding the real comments.)
Sure, I could alter the script outputting the preview (the script at previewParserPath) to have the same styling as the comment page itself. But this is for a CMS where I don't know ahead of time what the styling of a page will be (since the styles are user changeable.) And I don't want the preview script to have to connect to the database and figure it out since this script gets hit *a lot* (on every enter key press in every comment textarea.)
I don't think anyone reads this blog, but if someone finds this through google I'd be happy to share my modifications.
It's true, xmlhttprequest posts are encoded as UTF-8, so a utf8_decode() is necessary if that's not the appropriate encoding. Will writing this here make me remember this? Who knows...