This is my first tablet, and hopeful I'll be able to writ some neat maps for it.  I've already had a great idea that nobody seems to be implementing in the android store atm.

So maybe I will at a future date?

• PUT /article/:articleID/favorite/:userID
• DELETE /article/:articleID/favorite/:userID

I decided that POST didn't make sense, as you couldn't really favorite a story more than once at a time, and of course DELETE makes sense here.  Adding them as a relation between the article and the user seems to make sense in this URI scheme as well.

So, all in all, I'm proud of myself.  Despite it being such a tiny, simplistic thing.

So, Mark Zuckerberg posted a photo today of his desk.. and I couldn't help but notice that his Facebook is different from mine.  Some key things to note:

• Instead of a tiny search bar at the top, there is now a very very large white bar.  This bar contains text in it, so I'm presuming it might be the new way to post data to Facebook, replacing the comparatively clunky share box we use today.
• Instead of three icons (Adds, Notifications, Inbox) on the top bar, there is a single icon.  Perhaps these have been combined into one?
• The icon appears squarer than the others.  Maybe its a Facebook icon, since the logo is clearly removed in this version?
• To the right of this large search box seems to be something else, but I can't make it out - and unfortunately I can't just do a CSI-esque "enhance" on the image.

So maybe this is a sneak peak at what is to come in the future?  Despite that, however, it should be noted that the changes seen here on Mark's computer may never hit production servers.  This is simply some speculation on some noticeable changes.

Source: Photograph Uploaded by Mark Zuckerberg

The idea is that the application would read through the code and find all the structures, classes, etc and would combine them in such a way that it could be read as a single line-by-line piece of code, with a UI that shows the separation between elements.  Possibly using indentation to show the differences between scopes, possibly with a collapsable block that specifies what the variables in that scope are set to.

A good version would, of course, automatically change the values of these variables based on the code.

Even if the movie was terrible, there would clearly be such a massive amount of fans rating the thing that it'd probably hit four stars.. but two and a half?  Not even a full three?  What was going on here?

A quick glance at the "customer reviews" told me everything I needed to know.  The full copy included some software called  "Ultraviolet," the main cause of over 200 1 star reviews.

Ultraviolet is another feeble, doomed attempt by some dinosaur brain Hollywood execs to restrict the use of your legally bought digital purchase. Ultraviolet is NOT a digital copy that resides on a device of your choice to be used on a device of your choice. It is a streaming service, for which you have to sign up and maintain an account, at the expense of your bandwidth, compatible with some but not all mobile devices. If you're willing to wait another 4 weeks, order this disc set from Amazon's UK website you can do this with your current US account). Not only are you getting a REAL digital copy, but the Blu-ray disc is region free too!! Price + shipping is the same as the price in USD with free shipping.

- John Dettingmeijer

So, that wrapped up that mystery.  Horrible software is murdering ratings.  A damn shame.

Late August, I went to my friend's house in Toledo.  There, we picked some pears.  I took home some for myself and placed them in my fridge, unfortunately never stopping to think to eat them.

Late September, I place a Sunkist can I had not had time to finish beside the pears, leaving it for later.

October 1st, I pull the pears out of the fridge, giving them up to inspection by Rebecca.  They look as if they haven't aged, possibly frozen by sitting beside the freezer inside the fridge.  I pull out the sunkist and set it on top of the fridge to deal with later.  Rebecca declares that the pears, although not yet rotten, would be as soon as they thawed as their cellular structure would not be able to survive being frozen and thawed.

Later that evening, I accidentally take a swig of the sunkist left on top of the fridge.  It has a delicious taste of pear to it, despite its flatness it does not taste bad.  It is delicious, but sickly sweet.  But amazingly delicious.

Now that I've learned this, what should I do about it?

However, you rarely see all of these accepted in a single place - and for very good reason: Its gorram difficult to implement so many different APIs and systems, and have to deal with tracking each of them.

Clearly, the Web needs a way to deal with this - and having a Federated Payment Protocol would solve it.

Think about it: A vendor website would easily communicate with a payment processor through this protocol.  They wouldn't have to know who the Payment Processor is, or even care for that matter.  The vendor would issue a request to the payment processor.  The processor would be in charge of authenticating the user, and would send back their "terms" (out of the requested amount, *this* much will be dispersed and *this* much will be taken as a processing fee).  The vendor will agree, disagree, or change the payment amount based on what the processor sent.  The processor would then submit this change to the user, if the user accepted the processor would send the new details and the vendor would accept or deny.  The processor would send the money through whatever system they need to, notifying the vendor how long it should take, and if its a short enough time the vendor can hold the user until the payment has cleared (or if it is a trusted source not hold at all) and provide the promised goods or services, after confirming the transaction with their receiving service.

This solves a few key issues:

• Vendors have to trust that they are receiving the money for their services.
• Credit Card details would never have to be provided to the vendor, as the service would be directly through their credit company's payment service.
• Vendors would not have to implement different APIs for different payment methods.
• "Credit Card Fraud" liability would be the burden of the Credit Company, of whom authenticated the user.  A vendor would no longer be required to make sure a person is who they say they are.
• Banks could offer their own payment services ("Debit."  Possibly with No Fee, resulting in a reduction of prices from vendors, hopefully).

No, I'm talking about reliability.  Something Google has had for a very long time, and one of the many reasons I'm such a Google fanatic.

Until recently, at least as far as I can remember, Google products that existed did not see the end of the tunnel very often.  (The question and answer service excluded).

Recently, however, Google has been trying to expand into many markets.  From what I can take away, Google wants to be the hub of information exchange on the Internet.  After all, knowing all of that powers their search - and their search powers their ads.

Recently though, several Google services have announced that they will be discontinued.  Among these: Wave, PowerMeter, and Health.

PowerMeter and Health did not see large enough adoption for Google to continue putting forth the funds for them.  To me, this is disappointing.  Being able to get this information so easily and readily through Google was really exciting.  After all: Google has the technological know-how to keep my data secure and provide at least decent user interfaces to said data.  In fact, I used Google Health - although since I don't have many issues it was currently just to store my insurance information.

Now though, these services will be disappearing.  Who is to say that other less-mainstream services won't disappear in the future?  Buzz? Voice?  Google+?  Well, there's no way that last one could disappear... right?

If I'm going to rely on Google to provide a service, I'm going to need the security of knowing that the service is going to continue to exist.  I might be asking a bit much as a free user, but its still a very important consideration.

If Google loses this trust; this security; this reliability - won't it hinder future adoption of Google's services?

Think about it.  How much has email changed in the last twenty years?  Not a lot, if any.  The most revolutionary features are GMail's labels and Gmail/Outlook's server-side email rules/filter settings.  To me, this is ridiculous.  I was born in 1991, played around on the internet when it was on dialup, and had a free Juno account when I was old enough.

Since then I'd moved through Yahoo, Hotmail, and finally rested on Gmail.  But all-in-all, everything is still pretty much the same.  It was because of this that Gabor's idea to scrap IMAP really intrigued me.  I wanted this.  Google and Microsoft had both come up with newer, proprietary synchronization standards, and creating a new, open protocol would be the way to usher in a new age of compatibility and extensible feature sets.

Since this initial bit of intrigue, I've spent some time working on protocol documentation whenever I can get a bit motivated and have some spare time to do so.  I continue to push my creativity and find new things to throw in to the protocol, ideas that wouldn't have to be there when the first part hits, but that its extensibility would make possible.  Ideas such as receiving push notifications from web services, that could also be synced to mobile devices through the protocol, or using OpenID as a base and creating a new single-login/password system that uses your email address., or even ideas such as being able to query an email server for a person's contact information, and store/update it in a syncable address book.

Once we leave the defining bounds of IMAP and proprietary protocols like Exchange, we can really start work on building something terrific that would allow a flood of innovation that email has never seen before.

Unfortunately, my voice is small - and is very largely unheard.  I can't even get Gabor, the original creator of this idea to @mention me on twitter regarding it anymore, and so I've been stuck working on it by myself.

So yes, this is a call to action, and I do so hope that you'll oblige me.  I need help revolutionizing email.  I can't do it all on my own, and the protocol being open is the important part.  I need other people's ideas, not just my own.  I need their thoughts and their knowledge.  I'm only a college student after all, and as much as I'd like to do this all by myself and use it as my claim to fame - I'd much rather just be a person that helped start and organize it and get things moving.

So please, join me in discussing my ideas, submitting your own, and if you feel like it even work on defining the protocol!

Please join the discussion on 'MSAP' at Google Groups.

Thank you for your time, and I look forward to hearing your thoughts and ideas.

So it thrills me to no end that there is now a Node.JS executable for Windows.

Of course, things kind of suck when you don't have the super simple power of NPM, but that's life for ya.

I understand the basics of Node.JS (If you've ever touched JavaScript, its hard NOT to); but some fine details such as templating elude me.  Maybe you're not supposed to template?  Maybe you're just supposed to serve up some static HTML that then queries the Node.JS server for the information it needs?  Oh.. now there's a thought.. program a single frontend that just talks back and forth with the backend.  Kind of like Google+, actually.

Is that what I'm supposed to do?  God I love this language.