Monday, February 25, 2013
Why not a web book vs. a chromebook
My key point is this: Google's Chromebook experiment has it right on how people spend their time on light weight laptops but wrong on what to do about it. In short, as assumed by the Chromebook team, people on light weight laptops do spend the vast majority of their time interacting with and publishing "web" content.
However, is the solution to just push everything into the browser? I'll note that much like with my mobile devices, I opt for native web clients on my macbook air when they're available. They're faster, and I have more control over each service.
I think the Chromebook would be more interesting if it more clearly recognized this fact. Perhaps Go could become the default native client language.
Friday, February 22, 2013
The pixelated cloud
First off, I think Google is dreaming here, but it's an intentional act of dreaming as indicated in this article shared by +Tracy L. Crawford. What currently boils down to a $1200–1500 high-end web browser is not a mass market machine. Instead, it's meant to evoke in the minds of people who can do something about it the kind of scenario where the Pixel makes sense. In a nutshell, I think that scenario is as follows:
- Most of your processing power lives elsewhere. Google engineers using the Pixel are compiling on linux workstations back at the office. They're accessing Gmail and internal Google+ hosted by Google.
- You're not hampered by legacy software compatibility needs, in particular the need for seamless Microsoft Office compatibility. It's amazing how embedded office is in the infrastructure of even new phenomena like eBooks or electronic publishing. Microsoft Word is effectively still the standard of exchange for a large part of the content production industry.
Saturday, January 15, 2011
My new cloud computer
I have the 11" macbook air. It came Friday. It's expensive. It's something I said I would never get. I like it a lot.
Why'd I get it?
- I need a light computer to carry around.
- Its solid state drives are nearly indestructible
- It offers a lot of ways to connect to cloud services, not just a web browser
- It maintains the apple/unix compatibility I've been accustomed to for the last decade
We'll see how it plays out.
Sunday, January 9, 2011
Devices and platforms
I would like devices that plugged into platforms and just worked.
All of the talk of software as a service or infrastructure as a utility is just hogwash unless I can do that. The truth of the matter is that, at many levels, software is not sufficiently standardized to be offered as a service. Further, infrastructure is optimized as a stack around a presumed application model. There is currently a war going on around what will be the application model of choice that extends all the way down to devices.
You cannot just plug devices into networks anymore. This is a step backward.
Thursday, December 16, 2010
The era of network provider gadgets, the new railroad trusts
I'm highly networked. I have cell data plans for 3 out of 4 direct family members. We have a cable modem with somewhere on the order of 10 consumption devices on 2 subnets connected to it (this is no joke and may be an underestimate).
My thirst for new network gadgets is slackening. It's not that I don't find them useful. Rather, I don't like the fact that they're tied to particular providers.
- iPad 3G: ATT
- Kindle 3G: Sprint
- Cr-48: Verizon
- Android Phones: the cell provider who sells them to you
Isn't this what brought about the break up of the old ATT monopoly? Why is my equipment tied to my network provider? Why is my access to resources then also shaped by my provider often retroactively after I've already bought in?
Just so you know, my bottom line: I'd be willing to put up with traffic shaping if my device allowed me to hop around between providers.
Friday, December 3, 2010
My ongoing app engine dilemma
So, I'm not a professional developer or software engineer. I've never made my living entirely by writing code, though writing code has often been critical to many of my deliverables. The key difference for me and why I don't call myself a developer has been that it's never been entirely about the code for me, it's always been about the value the code can deliver.
Developers care more about the code as a deliverable in and of itself.
Now, with that preamble, I can properly state the dilemma I face with Google's app engine. For those unfamiliar with app engine, think of it as a way to write glue code for services in the cloud. For instance, say you want to create a service where multiple authors can contribute tweets to a twitter account but you want one person to have editorial approval. You can build that app in app engine (and also, apparently, in google apps script which might be thought of as a kissing cousin).
Google handles hosting your app and making sure it has the necessary server resources.
The way I've stated it, that sound pretty cool. You can essentially write web apps without having to manage web infrastructure.
Well, the problem comes in the constraints. App engine apps can only run for a limited period. Want to do serious number crunching and analysis? That's not really what app engine is meant for, and the time constraints it places on programs likely won't permit it. You have to think about some other way to do your analysis than running it on app engine.
Therein lies the rub for the non-developer. It's relatively easy to think of how to solve these problems in a case where one program does it all. Indeed, that's how I do all my cloud computing now. I run it all on a mac mini computer with a cron job that fires off every 10 minutes, harvests cloud resources, analyzes them, and then posts the result to a server.
It's harder to think of how to split it all up among multiple resources. I can do it conceptually. It's at implementation time that I get stuck. Too many little threads to pull together, and I retreat to the way I know how to make it work.
Sunday, August 29, 2010
Thoughts on the Summer of Android
For me, the summer of Android, when I really discovered Google's mobile operating system, started at Google I/O:
- Froyo, the new Android version was launched.
- We were given the additional conference gift of the Sprint EVO 4G, then arguably the most advanced Android phone available.
Like Saul on the road from Tarsus to Damascus, my eyes were opened within a day of possessing the EVO. Since, I've purchased the Droid x for myself (an upgrade from my original Droid) and have been following all telephony, not just mobile, closely. The summer has seen a tidal wave of telephony developments from Google and its partners.
Here are my summary observations about where we stand today, the weekend before summer informally ends:
- The ability to make calls from Gmail when combined with Google Voice is simply game changing. Suddenly, I have the best, free telephone routing system (Google Voice) liberated from the need for a physical device. At this juncture, I don't need separate POTS (plain old telephone service), and I only really need mobile for when I'm out of contact with a land-based network.
- It's easy to see the day when everyone in the phone business will just be a data network provider. Coverage and speed for price will be the defining characteristics.
- Since I now view mobile connectivity as a supplement to and not a substitute for land connectivity, I'm most concerned with net neutrality for land-based networks and trunk lines. That's where most connectivity is playing out for me now. It turns out mobile is a specific use case where I want to access specific things. In other words, I can see how prioritization might make sense in the mobile scenario.
- The biggest value in my mobile phone is my ability to connect back to "web-based" services that add context to my current situation, for instance, all Google location-aware services.
- The next biggest value in my mobile phone is the ability to connect to my "social graph" (i.e., the network people I'm connected to via some electronic service) in all of its forms. Android-facebook integration is useful in this regard, but the real ace in the hole is the contacts manager, and I think eventually, profiles. By the way, since I've had to resort to various Google Reader hacks to follow aspects of my social graph, I'll throw that in there too.
- The third biggest value in my phone is my ability to use it to access reference information in all forms, be it electronic books or the web.
Note how making voice phone calls is not listed as a separate item. I do this infrequently and would tend to include it as part of connecting with my social graph. I should point out that this is a giant change from where I was at the time of the ATT breakup in 1984. Then, I was excited by the new plethora of voice-related communication options. Simply put, times have changed. Text has replaced voice in most applications.
Tuesday, May 4, 2010
Blogging is the original cloud application
Back in the old days of blogging you had to do something like rent a server and install Movable Type. That was a chore. I still remember when Sixapart went to the paid typepad service. I bought in, mainly because I just wanted to create blogs at will without having to worry about the server.
I had typepad before I had gmail, and I had had to have my gmail account for two years before I decided it was was useful. Typepad went to work immediately. I wanted my information on the web, and typepad let me outsource all of the infrastructure for doing so.
Another thing, almost immediately after starting blogging, I went looking for a dedicated blogging editor. I wanted something that could manage my online writings all in one place. I needed something beyond my browser's limited capacity to handle my sometimes multiple identities at a given service.
Oddly, now that I've moved to content production on the mobile web (mainly through my iPad), I'm finding I want apps even more for all the cloud services I use. That's mainly because, even with html5, mobile browsers just don't seem to pack the required punch. Part of it is also the usual browser issue. I don't really have control of my identity with a browser the way I do with an app.
So, I was happy to see that Mars Edit, the blogging software I use came along with a nice upgrade for the Mac version. I was also happy to hear that the author is working on moving the app to the iPad.
Saturday, April 10, 2010
Getting an iPad for Dad, Part 2
So, I have to fess up. I wound up getting an iPad for me after a few days. The reason was simple: the 10–12 hour battery life plus the ability to get editing and web work done. Not tied to the laptop anymore.
However, since getting Dad's iPad and then mine, the story has also become more complicated:
- Some people are experiencing wifi problems. This thing is simply not worth it without a wifi connection. Its whole value derives from serving as a network device.
- Some apps are well connected to the cloud (i.e., seamlessly integrated with Internet-based services) and some aren't. Productivity apps like Apple's iWork suite are particularly deficient in this regard.
- There are platform wars breaking out. While Apple's snub of Adobe flash is getting a lot of attention, the more significant issue is between Apple and Google. Put simply, Apple does devices but not the cloud; google does the cloud but not devices; they can't figure out how to divide up the producer surplus across users who want to do both.
This last point, though worrisome to many (including myself), really just serves to point up the ground breaking nature of devices like the iPad. There's enough at stake now for leading rivals to throw aside the obvious benefits of working together and go to war.
The iPad heralds an era of light weight, network-centric devices that fulfill the promise of mobile productivity many are questing after.