Cloud Development

WordPress on HHVM

Duct Tape, fixer of all things!
HHVM Blog: “As of WordPress 3.9, and HHVM 2.0 the following changes aren’t necessary as WP have updated their codebase to play nice with HHVM, and HHVM has updated itself to support more PHP stuff.”

I know it’s not in style to learn PHP, but it suits the old man C developer in me. I found myself reading about HHVM and Hack which lead me to think WordPress on HHVM might be kind of cool. One little Google search and what do you know, someone else had the same thought, and made it work. Not only did they make it work, but it looks like the HHVM and WordPress folks worked together to make it happen. Even better.

Maybe one of these days I’ll have time to get an HHVM based WordPress installation up an running.

Cloud Development Uncategorized


Dave Winer: “But all that has changed with the ability to access cloud storage from apps written in JavaScript that run in the browser. Software that used to require a central server, and was easy to attack, and had to scale for all sizes of use-cases, now can run in the browser, with little if any loss of power.”

Dave is excited he can host a JavaScript on a server and pull it to the browser to execute because it affords him the ability to do simple applications without the need of web services. I can understand his excitement. It’s less expensive than running a GIGANTOR set of servers to host your services and answer requests thrown at them from the client. Point taken. It’s a step in the right direction, but I still think services are necessary for all but the smallest of apps because browsers still don’t make great hosts for applications.

Bringing in the Harvest
I think designing services first is the more appropriate thing to do. Don’t think about the UI first. UI’s are a dime a dozen and should be lowest common denominator (browser), up to native, high performance, best of breed (platform specific; iOS, Android, etc.) Because mobile is so important today you can’t leave that out of any discussion about web based services. Most web apps I’ve run on my phone are pretty horrible performance wise, but I can run them. If I have a choice to get a native mobile client I always opt for it because of that.

Dave accused me of calling him stupid.

Far from it, Dave. I know you’re not stupid, I just have a different idea than you, that’s all. A differing of opinion, and that’s ok. I think you’ll be very happy with your new model and out of that we’ll see some great browser apps.

I’ve talked about it before. I’d like to see the browser evolve way beyond what it is today if this is the new “OS” for the web based world. It must if we expect to create beautiful, highly usable, fully functional applications like we did on the desktop before the invention of the browser.

When the browser can evolve to a faceless shell that is language agnostic and allows us to control it like a native application controls the desktop environment, man, then we’ll have something special, until that time it will provide the lowest common denominator gateway to the web.

Web Next

Can you imagine the explosion of high quality code and components that would flow out of a world where we’re not limited to the confines of the browser and JavaScript? It would be industry changing.

I’d love to see the browser community embrace the idea of a full CLI implementation and create a way to hit and endpoint URL that pulls a fully built application to the desktop that’s hosted by an “invisible” browser. [UPDATE: This part, about pulling a full app plays nicely with what Dave is talking about.] The browser should serve as the new OS giving the developer full access to a virtualized machine.

We’ll get there, some day.

Business Cloud Social

Path + WordPress

Engadget: “App developers can now ask for permission to use Path’s sharing API, which they’ll get if Path sees such apps as a logical fit. To get the ball rolling, the social network has already granted access to 13 partners that include WordPress…”

I’ve enabled posting to Path, lets see if this works.

Cloud Social

My RSS Wish

UPDATE: On second thought, this isn’t what I really want. What I want is a Twitter style feed, or as Dave Winer calls it, a River of News, which predates Twitter. I don’t need a complex sync mechanism, or a read/unread count. What I really want is a central place to see my river of news with a simple bookmark. Nothing is marked as read. When I open it in another app it takes me to my last bookmarked location. Super simple.

My original thought is below.

Guilty. That’s right, I’m guilty of the same desire as everyone else when it comes to RSS. I want my feed to be available on all devices (easy), I want it to aggregate to one location (less easy) and I want it to be in sync when I move devices (darn.)

Most people think of RSS as Google Reader. It’s not. Google Reader was the gorilla that made RSS its own, killed off and industry, and left us hanging. RSS is so simple it’s elegant. It’s nothing more than a format for syndicating news. Simple, right? Google Reader went so far beyond that no other RSS reader has come close. Not Feedly, not Digg, no one company has managed to do more than offer a simple reader that syncs. It’s a great start, but I digress.

Yes, RSS is simple, but in this ever connected world, social media world we want it all and we want it now! So, to do that, people took a the idea of a distributed network format and put it all in a central location. A single point of failure, can you say Google Reader? Fine. You want it all in one spot, I get it. How do we make that happen and not rely on a single vendor to provide us with a service?

A wonderful boquet of flowers.First we need an open standard for centralized RSS (man, that sounds wrong.) This way people writing tools can push and pull data to and from a service. I’ll bet Digg and Feedly have their own implementations of such a thing, that are nothing alike, but do what they need. Pulling together the feeds is the easy part, that’s been solved. It’s the availability on all devices and sync that’s a bit more difficult. That’s where the standard, or open, format or API, comes in. Sure, we have the browser, but it’s not exactly all that useful on all platforms. I’d like to host my own RSS aggregator service, on my hardware, and have the ability to tell that service I’ve read something and make sure the last item is bookmarked so I can pickup where I left off, possibly on another device. Yeah, I want the ability to use Reeder, or NetNewsWire, or the browser.

That’s the bottom line. Think self hosted WordPress, but for RSS reading. Sure, you can use one of the many new services springing up, that’s great, but I’d like to host it myself and make sure it works with other services to make it mine. If there were an open implementation of a centralized RSS aggregator we wouldn’t have to worry about a single vendor destroying an ecosystem and abandoning it. We’d be able to rely on each other for help and benefit from a community of like minded people. The other upside to an open solution would be the ability to extend it to make it exactly what you want! Meaning you could implement code to give you your favorite Google Reader feature and share it with the world.


The Advantage of App.Net

Steve Streza: One other cool benefit of using for the backend is that the data specification is publicly available. This means other developers could build apps that recognize your journal. So, if the developer of your favorite camera app adds support for Ohai journals, they could save those photos into your journal. Then, the next time you open Ohai, those photos are available. Other developers could build journaling apps for other platforms like Android, or even write competitive apps for iPhone. You as the user would not have to export your data and re-import it; it would just all appear when you logged in. It’s a wonderful deal for customers to have no lock-in at all, with open data standards for interoperability.”

Ohai, Steve’s new app, is an app for keeping track of life moments. Similar to Vesper, from Q Branch, but this application has storage in the magical cloud. Not only does it make use of cloud technologies it’s using App.Net to do it. I think this is important because most people think of App.Net as a Twitter clone. It’s way more than that. It’s a set of API’s and infrastructure that allow people to build deeply connected applications. App.Net, the social network, is one example of the infrastructure and API’s. Ohai is another. Steve even points out that others could create other applications that can have access to the data. Why? Well, it’s your data. You decide who gets to see it.

Very cool app.

Business Cloud Technology

Parse: It was good while it lasted

AHHHHHH!Parse: “Some of the world’s best brands trust us with their entire mobile presence, and a growing number of the world’s brightest independent developers trust us with their next big thing. We couldn’t be happier.”

Parse is one of those companies I was really excited about. Our connected world is about services, not websites or mobile, but services. The backend; the logic and data it contains are the important bits of the puzzle. They’re also the most difficult to create and maintain. Parse built something that allowed developers to create small scale services without the need to build the backend. It was a genius idea and one that opened the doors for indie developers to create great services.

How much trust will the “world’s brightest independent developers” have in Parse now that it’s part of one of the most untrustworthy companies in the world?

I guess I can’t bag on these guys too much. If Facebook offered me a pile of cash for my product, I’d take the money and run.

Cloud Weblogging

Teehan+Lax on Medium

Medium LogoTeehan+Lax Weblog: “There weren’t many traces of our prototype in Medium, but that was pretty understandable—it had evolved into a very different product. Ev explained that he felt there was a need for meaningful writing on the Web. There wasn’t a place for people who wanted to write something more substantive than a tweet. Blogs, while better for long-form, required a certain savviness to get up-and-running. Successful ones required constant care and feeding and typically focussed on a single subject matter. New ones lacked an audience. He went on to say that people sometimes just have one thing to say about a subject, not something every day or week. This is what Medium would solve for.”

Teehan+Lax is a world class design shop, very talented, and Ev Williams is a visionary, put the two together and you get a great experience, you get Medium.

Weblogs are a dime a dozen, like this one, and most of them are pretty bad, like this one. Medium is a new form. It gives real writers a place to create. I like that. I’ve been reading random articles, from random authors, on Medium for a few weeks now and I really enjoy it. I like the writing and I like the design.

I will never have a place on Medium, and that’s ok. It’s a place for real writers and as a reader I very much enjoy it.


RSS Rivers

Dave Winer: “But there is another kind of aggregator, river of news, and its needs are pretty simple, compared to the Google Reader approach which requires synchronization among different clients. If I had the time here’s the software I would write.”

Radio UserLandMost of the links I tap, or click on, these days originate on Twitter. What Dave has always been a proponent of is an RSS feed in the style of Twitter. In fact I’m pretty certain Radio, one of Dave’s products, presented feeds in that very format. The mailbox style “you have 2.3 million unread feeds” is not necessarily the best way to view things. It leaves me feeling like I need to read everything to get caught up. I don’t feel this need in Twitter. I just scan tweets quickly and send links to Pocket for reading later. Why not do that with RSS feeds? I wish I had the time, I’d build it.

Business Cloud Social

The real Communication Network

Matt Gemmell: “The interesting part, though, is what you won’t be used to from Twitter. There are no ads, anywhere. Because it’s a paid service, there’s no spam at all; I’ve certainly never seen any. There’s an active and happy developer community, which ADN actually financially rewards. There’s a rich, modern, relentlessly improved API. And again because it’s a paid service, there’s a commensurately (and vanishingly) low number of Bieber fans, teenagers, illiterates, and sociopaths.”

I joined App.Net back in August and since that time a nice community has sprung up. There are a number of apps available to make the experience better and those numbers grow every day. Unlike Twitter developers are encouraged to develop unique and exciting applications, they even pay for the right to access the API. Imagine that, an entire social where the users actually pay to be a part of it. What a concept.

App.Net is creating the communications platform Twitter abandoned in favor of becoming an advertising company. The Twitter like experience is just one of many different types of applications being built on this platform.

If you’re interested, drop me a line and I’ll pass on an invite for a free account.

Apple Cloud Development

iCloud vs. Dropbox

Dave Winer tweeted something today that got me thinking, so instead of tweeting back and forth with him about it I thought I’d jot my thoughts here. Twitter is pretty horrible for discussions.

In response I pointed out that Dropbox and iCloud are different because Dropbox is a file syncing service and iCloud goes beyond that. If you’re a Mac or iOS developer you can sync portions of files to iCloud along with your application settings. Apple created this as an extension of their ecosystem. As a developer you can have automagic syncing for your applications, if you choose.

Of course I misunderstood Dave’s point. His concern is lock in.

Ah, now I see what he’s referring to. Apple has created a walled garden for applications built on their platform. It’s absolutely true. Another concern of Dave’s is the inability of iCloud to share your files outside of applications.

Once again, Dave is absolutely correct. There is no way to get at your content in iCloud if you’re not using an app that implements iCloud API’s. Oh, there is support for Windows, did you know that?

iCloud for DevelopersHere’s the deal. With iCloud Apple allows you to open your document, stored in iCloud, in your local application, make changes, and those changes can/will be sync’d back to your other devices. Here’s the difference as I see it. Dropbox is an extension of the filesystem on my local computer, iCloud is an extension of my application. Subtle, yes.

I’m having a difficult time getting to the difference because it is so subtle. Imagine if you have a Pages document open on your Mac and on your iOS device. You’re making changes on the Mac and you walk away. Those changes will get pushed to your iOS devices without saving the document. As far as I know you cannot do this with Dropbox. Dropbox will sync an entire file, not portions of a file.

Minor difference, but a difference none the less.

How about this. Dropbox allows me to see all my content via the web and my local filesystem has a copy of the documents. It’s absolutely perfect in that way. What about editing? Can you go to, log in, and edit a binary Visio drawing? No, you cannot. With iCloud we get this feature via apps. Again, it’s avery subtle difference, but it’s something Apple is very fond of.

I’d imagine once Apple can solve these types of issues we’ll see a more open iCloud, until then, if you’d like a great file syncing solution Dropbox is a better choice than iCloud. If you’re after great integration iCloud may be your best bet, although some applications have done a great job using Dropbox as their syncing solution.

In the end syncing of files across multiple computers is a very difficult problem to solve and Apple is just beginning to address the problem. Dropbox has created a very elegant full file syncing solution. Both are useful.

Oh, one more question. I almost forgot to ask this. If Apples’ iCloud is a lock in, which I will not argue, how is being tied to Dropbox not lock in? I would consider it lock in. To me what’s freed us from lock in are open protocols, like HTML, or RSS. They are part of the fabric of the internet and completely open. I can modify HTML with any application that can read, write, and modify simple text. Definitely no lock in. If Dropbox created an open protocol for syncing of files, that could be implemented by anyone, and their client application, as well as anyone else’s, could communicate with any server that implemented that protocol, I’d say it wasn’t lock in.

A stretch? Maybe. But we are, after all, talking about subtle differences.