Jason Miller Design

July 2011 Macbook Air is $949 and iMac is $899

Fri, 15 Jul 2011 02:17:30 -0500

Through some crafty google searching, I just happened on this particularly interesting result:

Does this mean we're going to see a price drop for both these computers? If so, I'm going to be out a ton of cash this month!

Basic AJAX: Using XMLHttpRequest

Tue, 31 May 2011 22:58:02 -0500

So, XMLHttpRequest is a feature in JavaScript that lets a page make HTTP requests to a web server on the same domain (note: there are ways to make requests to subdomains, they are not covered here).

First, you get an instance of it:

var xhr = new XMLHttpRequest();

You need some way to be notified when the HTTP request is done loading and the data is ready.

It's very similar to the listen() method in chat.botApi.

To listen for the end of the request, you create a function and assign it as the readyState Change Handler:

xhr.onreadystatechange = function() {

// your stuff here

};

You need to check that the request has ended, cause that function gets called 3 or 4 times depending on the browser, to indicate the various request states (sending, waiting, receiving, done - with done being readyState 4)

So, in your handler, check the readyState:

xhr.onreadystatechange = function() {

if (this.readyState===4) {

// huzzah, the data is here!

alert(xhr.responseText);

}

};

Once you have that, you open a connection to the server, with the request type (GET or POST, same as for a action), the URL you want to reach, and Boolean true.

(the last param, true, means asynchronous, which allows the browser and page to do other stuff while the request is loading. It's important, and you should never use false for that value, if you do browser makers will come to your house and change it. And they won't tell you.)

So that part goes like this:

xhr.open("GET", "/path/to/file.html", true);

Finally, you need to submit the request to the server. That part is easy, it only takes one parameter - the POST variables (exactly like fields in a )

if you want to send an HTTP post to your server, for a form or whatever, you need to URL-encode all the parameters and send it as a string

if you're just making a GET request, leave it blank, like so:

xhr.send();

... and we're done!

Let me know if this helps you out, or if you would be interested in more articles covering JavaScript basics!

Smallest JSONp Implementation

Wed, 06 Apr 2011 12:28:12 -0500

Here's a tiny chunk of JavaScript I wrote while experimenting with writing an insanely small web chat client. I think this might be the worlds smallest JSONp implementation that doesn't suck.

/** Pico JSONp: */ function jsonp(u,cb){var a=jsonp._c=(jsonp._c||0)+1,b='picojsonp_'+a,c=document,d=c.body,s=c.createElement('script');window[b]=function() {d.removeChild(s);cb.apply(cb,arguments);cb=c=d=s=null;};s.src=u.replace('{callback}',b);d.appendChild(s);} /** Example usage: */ jsonp('http://example.com/timeline.json?callback={callback}', function(response) { console.log(response); });

What is a Top Tweet?

Fri, 01 Apr 2011 13:25:20 -0500

I posted an article to the amoebaOS Twitter account today, and I noticed later that it had been marked as a "Top Tweet". It left me wondering what exactly constitutes a "Top Tweet", given that the only re-tweets were from my other accounts (come on, everyone does it).

Does anyone have a theory? Or is this another mysterious algorithm to lump in with Google Search?

The FSF is Out of Control

Fri, 01 Apr 2011 08:37:38 -0500

I understand the need for open-source software. Especially when it comes to re-usable code libraries. But seriously? Asking a client-side application to "open up" just proves they don't have sufficient skill available to assess JavaScript-based applications. It would take a very naive developer to assert that the bulk of Gmail's functionality lies within its JavaScript front-end, considering it is not a thick-client (aka thin server) application.

The article to which I am referring is here:

http://www.fsf.org/blogs/community/gmail-jstrap/

Honestly, every time I see a statement from the FSF regarding JavaScript (or any other browser tech), it just deteriorates my opinion of the organisation further.

Delete HTML5 Web SQL Databases

Thu, 31 Mar 2011 14:41:02 -0500

I've been spending a lot of time in Chrome's new "Clear Browsing Data" UI, and I wanted to make sure other people don't fall into the same trap.

While window.openDatabase and friends are fast and efficient for client-side storage, the API is underwhelming. For all the complexity of SQL, something like deleting a created database is still not possible. That sucks, and I would certainly consider it an oversight in the API design, not a feature as SQLite fans tend to portray it.

The only way to really delete a Web SQL Database (in Chrome, at least), is to clear all client-side storage mechanisms through the Clear Browsing Data interface (Command+Shift+Delete).

The main problem with this limitation is that it's possible (and very easy) to screw up Web SQL DBs. For example, calling openDatabase numerous times on a single page results in this lovely mess in Web Inspector:

How useful is that? Oh and if you were wondering, all those identically named databases also contain tables named "undefined" with no results that fail to open.

Not that I fault Chrome - it's obviously a very early stage in the development of this API, and they are taking a risk in order to push the web forward faster than the W3C can be bothered to make simple decisions (are they making any these days?).

I'm putting out a call for solutions here - can anyone come up with a way to actually delete (drop?) a WebkitSQLite database in Chrome?

Your Computer has More Web Browsers Than you Think

Fri, 04 Mar 2011 09:31:19 -0600

I'm going to be posting the screenshots I take of amoebaOS running in strange situations here. I'm starting this off now, because I thought this one, in particular, was interesting:

amoebaOS running in Coda Books
amoebaOS running in OS X Dashboard
amoebaOS running in OS X Dashboard
COB Wars running in OS X Dashboard

Undeniably Awesome: The .app TLD

Wed, 09 Feb 2011 01:14:50 -0600

Why don't we already have this?

It's the most obvious TLD I can think of, and an excellent way to differentiate between websites and webapps! Apparently there are 125 TLDs on the suggestion list for when the process is formalized in a month or two, perhaps someone has already suggested it (not that I'm aware, but it's possible).

Can you picture the simplicity? Imagine telling your users "Just type minipng.app into your browser"...

Webapp Or Website? Does Anyone Care?

Wed, 09 Feb 2011 00:46:17 -0600

In case you hate reading, the answer is yes. Users care because they want everything to happen as fast as possible.

I think the world needs to better understand what differentiates a webapp from a website, because internet users are directly affected by that difference every single day. Is Twitter.com a web app? Yes. Is this website a web app? No. Is Gmail a web app? That one is debatable, but yes.

What even defines an online resource as being an "app" instead of a "site"? I think the most definitive answer is that web apps transfer presentation separately from data, and do not employ a strict request- response technique for doing so.

Your users called, they want their time back.

Users care about speed, functionality (therein usefulness) and ease-of use. As developers, we can draw rather direct parallels to the technical aspects of web development from these general requirements. For speed, and since this is the web, we're talking almost exclusively about speed of data transfer (requests take much longer to transfer than to execute on the server). Functionality is created by selecting the most effective set of features for an application (more is not always better). Ease-of-use is important in webapps because we are still collectively helping computer users to adopt a new way of thinking about applications - if a user's first web-based application experience is horrible, they will most likely avoid using web-based software in the future.

So.. why classify "apps" and "sites" based on what the data looks like?

Users care about speed, and we know speed is most affected by data transfer time, so that's where we can draw a clear line between the "old" and "new" approaches. A website transfers data and formatting via a single request, which is optimal when loading new pages is the primary means of retrieving new data. A webapp transfers formatting and presentation information as part of an initial download process, much like downloading a desktop application. Once this information has been stored, data is then downloaded in a serialized format - optimized for speed in a situation where page loads don't occur. Examining the data being transfered makes it easy to determine which paradigm something is optimized for. Simply look to sites like Facebook and Twitter, where you can see an evolution in the direction of "webapp" for no reason other than to provide a better experience to users.

Doesn't that mean everything should be an app?

You're not getting the point - that would be premature optimization at its finest. If you are establishing a web presence for a business, where your needs are little more than an online business card or simple e-commerce site, don't build an app. Your time would be better spent working with the client to optimize their site for Search Engines or creating PPC landing pages. However, it would certainly be beneficial to apply lessons learned from the world of webapps to your website - things like HTML5's ApplicationCache and AJAX history can go a long way to improve user experience. A general rule-of-thumb is this: if your project is web-based, data- driven and is its own product, a webapp would be a wise choice.

So, there you have it. Apps, both web and native, have an initial download followed by speedy data transfer. Sites throw everything into a pile and download formatting intermixed with data.

The FSF Condemns Efficient JavaScript

Wed, 01 Dec 2010 22:05:53 -0600

Sometimes the FSF is just annoying.

http://www.gnu.org/philosophy/javascript-trap.html

Do they really think JavaScript can be "closed"? I feel like that whole article would never have been written had the author google'd "JavaScript De-Obfuscator"...