Amazon has opened their KDK Beta program. Amazon also published a KDK FAQ. As suspected, it’s Java ME based with a custom API for the Kindle:
[It will] provide UI components, JSON and XML parsers, HTTP and HTTPS networking, secure storage, and other features. Other APIs like audio and dictionary access will be available in a future release of the KDK.
Development will be possible in an Java environment, but it appears that Eclipse will be supported more directly.
There’s been a lot of talk about how the iPad will be used by people that aren’t experts in computers. This article makes a good case that Grandmas and Technophobes will love the iPad:
The darndest thing happened in the last five days and I was fortunate to be privy to it. Apple has gotten people excited about computing. But this time, it’s not nerds or geeks and certainly not IT industry analysts. It’s everyone else. I had a curious set of three conversations this week. One with a grandma, one with a technophobe and the third with a self-proclaimed luddite.
And this article explains the difference in computing habits between the Gen Xers that came of age during the PC revolution and the generation before and after us.
The reason I’m starting to think the Old World is ultimately doomed is because we are bracketed on both sides by the New World, and those people being born today, post-iPhone and post-iPad, will never know (and probably not care) about how things used to work. Just as nobody today cares about floppies, and nobody has to care about manual transmissions if they don’t want to.
Both of these articles make a great case, and although, I need a regular computer to do development, I would like everything else to migrate to an iPad.
I started to use Macs again after ten years when I got a digital camera. I read the instructions for the Windows software it came with and then just plugged it into a Mac I inherited — it just worked. Since then, I’ve used a Mac for everything except my job (.NET SDK development).
Which brings me to my first problem with the iPad — how do I connect my digital camera? Steve Jobs talked about how great the iPad would be for photos, but how do they get on the iPad to begin with? Undoubtedly, this will be solved, but it’s a problem that will make the iPad useless for a lot of people if this is their only computer.
Secondly, I don’t take a lot of pictures and almost no video and I have about 10-15 GB of photos (and 20-25 GB of music). 64 GB is just completely inadequate if this is going to be the only place to store them. For the iPhone, synching gives me downsampled photos and music if I want to save space, but I can’t do that to my primary copy. I’m sure iPads will get to bigger sizes, but I’m also sure that we’ll need more too.
Even if the iPad had a terabyte, I really need some off device storage — iPads can be lost, which would be bad, but not as bad as losing all of my data. It’s unclear how the iPad can be backed up if it’s your only computer.
I know that these problems will be solved eventually, but right now — it’s not really possible for the iPad to work without a host computer — if it’s like the iPhone, it depends on synching too much.
I’m not sure what the solution will be, but I have a Time Capsule — if the iPad had Time Machine, and if the Time Capsule could suck the images off my digital camera (perhaps using the iPad as the UI), then I’d be most of the way there.
Amazon has no hope of competing with Apple to be the best general computing tablet platform, so trying to match the iPad feature for feature will drive up their cost and still leave them with an inferior product. The two other stable competitive positions are either to go cheap or to go niche.
In his 1980 classic Competitive Strategy: Techniques for Analysing Industries and Competitors, Porter simplifies the scheme by reducing it down to the three best strategies. They are cost leadership, differentiation, and market segmentation (or focus). Market segmentation is narrow in scope while both cost leadership and differentiation are relatively broad in market scope.
This will be hard for Amazon because, before the iPad, they were clearly the differentiated premium market-leader, but now that market has been subsumed. The only hope for Kindle is to become the cost-leader and to let third-party developers turn the Kindle into cheap niche devices.
Once the KDK is available, we’ll see the top end come down to about $400. Amazon can do this because they’re set to make money from their free 3G, in the form of subscription applications. I’m sure a significant component of the $489 price is to offset the expected 3G use that isn’t offset by book sales.
This strategy is more in line with Amazon’s online retail strategy. They currently compete on price and let third-party stores focus on niche markets. Even though Porter cautions against trying to have two strategies, it can be overcome if different business units focus on each strategy independently — what could be more independent than a third-party.
The speculation on the KDK is that it’s going to be Java based, and I hope that’s right. We know for sure that it runs Linux, and that there’s a JVM and obfuscated jars on the device. According to what I’ve read, there’s no perl or python or anything like that on it, so the only options will be C/C++ or Java. For the sake of the ecosystem, Amazon will need to pick Java and probably will run third-party code in a some kind of sandboxed environment.
To me the best thing about it being Java based is that I will finally have a JVM that I care about targeting. One of my big problems with Java is that there’s no place the JVM runs where something else doesn’t run better or that I just like more. For web apps, I prefer python based frameworks, and for Windows apps, you have to use .NET or Win32 with C/C++. On a Mac, Objective C is the obvious choice. Java is a good choice on a lot of mobile devices, but I haven’t cared about them, until now.
And the main reason I want a JVM to target is because it gives me a practical reason to use clojure. I know it might not work out, and of course, I’ll be writing Java at first to learn the API, but I’m hoping I can transition to clojure eventually, or at least use a hybrid.
In 2008, Rich Hickey came to speak in Northampton, and I prepared by learning and blogging about clojure for the 20 days preceding it. Since then, I’ve been on a lookout for a JVM that I wanted to target. The closest I’ve come is the Google AppEngine, but I still liked python and Django style better. It may turn out that the KDK just works better with Java, but clojure has shown that it’s pretty good at driving OO frameworks like Swing, so I think it will work just fine.
Amazon, clearly feeling the heat from the Apple device coming out in two days, is making some moves with Kindle. In the space of a few weeks, they have altered the publisher/Amazon split, announced an SDK, and are offering a money-back guarantee for frequent book buyers [links via daringfireball.net].
Amazon has a real chance to win the hearts of developers because of few key differences between their offering and Apple’s.
Subscription apps + good enough for business will be a big win for developers. Business apps don’t go for $0.99 — the equivalent might turn out to be $5/month for something simple, and businesses won’t blink. Better than the up-front price is that you get a predictable income stream that isn’t subject to the whim of the top 25 lists.
This isn’t to say that Kindle will beat Apple in any quantifiable way (number of apps, number of downloads, number of customers, etc), but I think that the kinds of stories of real businesses being built on the Kindle store will be quite different from the lottery that the iPhone app market appears to be.
Last week, Amazon announced that they will be releasing an SDK for creating Kindle Apps. I know that three days before the big Apple Tablet/Slate/Canvas announcement, I’m supposed to be getting ready to tabletize my app, but the idea of developing for the Kindle
Given that the beta isn’t out yet — there isn’t a lot of information about the KDK yet. However, there have been some successful hacks of the Kindle and Amazon was forced by the GPL to publish their modifications, so we do know some things:
The brevity of the developer guidelines is welcome, but I hope they elaborate on them in the near future.
I took part in a Western MA Developers podcast last week. It was a lot of fun and definitely captures the spirit of how our conversations usually go. We cover a broad range of topics including the bug tracker market, refunds in software, whether to be Rich or King in a venture, and a philosophical discussion of Rich Hickey’s Time is the new Memory concept.
Ben Fry, the creator of Processing and the author of Visualizing Data is coming to speak in Northampton. The event is sponsored by Atalasoft and Snowtide.
When: May 5th @ 6:30
Where: Snowtide Offices, 243 King St (Potpourri Mall, just across from Stop and Shop) Northampton, MA
I’ll post more details soon.
My colleague, Rick, is playing around with F#. He made this ant colony in F# that’s based on Rich’s clojure one. If you know clojure, and you want to see what F# is all about, you might want to take a look.
Last night was our Clojure event with Rich Hickey. BTW, if you were there, regular meeting of the Western Mass Developers Group are every other Thursday at Panera Bread in Hadley (7pm) — most of the time, we just sit around and talk — very informal — hope to see you there.
Back to the presentation — hopefully the slides/video/etc will be up somewhere soon — Rich focussed on the concurrency features of Clojure (Vars, Refs, and Agents). First he showed us the state of concurrency support in Java/C# today (locking) and identified the problem as having direct references to mutable objects. Clojure offers only immutable atoms and datastructures so that’s how he addresses one part of the problem. However, since the mutability is how the world works, Clojure models change as a change to what a reference points to. So, if you view the world through refs, it will appear to change. Then he introduced the controlled ways in which refs can change.
1. Vars are essentially thread local variables. They are a reference whose changes can only be seen in a single thread — each thread gets an independent and isolated view of the variable. Like thread-local variables — they are a very simple way to take code that looks like it’s manipulating global state and give each thread its own isolated copy.
2. Refs are mutable references to immutable objects. They can only be changed inside a transaction and all changes to all refs in a transaction appear to have happened at the time the transaction ends (to other threads). Inside the transaction, the changes are immediate. When two transactions are open and change the same ref, the second one to finish is automatically retried (so you should have no side-effects inside of transactions). All Refs read inside of a transaction will return the value that they had at the start of the transaction (so are consistent with each other).
3. Agents (which I have explained before) are for asynchronous changes to a reference. Each agent hold a value and you send actions to it to change the value. Only one action will happen to an agent at a time and you can read the current state of the agent any time. Rich spent a little time to caution us against any comparison to Erlang’s actors. They are a different concept with different tradeoffs. Agents have the advantage that they can be read from any thread conveniently (just dereference) whereas actors require sending a message to read (which is asynchronous). Clearly, Erlang’s benefit is location transparency (for distributed code) — which is what it was designed for. Rich hinted that Clojure might have an Actor concept, but it would not be unified with Agents.
What was new to me with agents is that there are two types of message sending mechanisms — send and send-off (which appear to be undocumented right now) — Rich used send-off which dedicates a thread to the agent (rather than run the action from a thread-pool). This is how you have to do it if agents block at all (which ants do because they have a small sleep).
Then, he showed us an ant simulation — I think he will make the code available. In short, there is a square world of cells, each one holds a Ref to what is in the cell (food, ant, pheromones, home base). Ants are represented by agents, which are sent a behave message. Behave picks a random action for the ant to do (move, turn, pick up food, drop food) and then mutates the world of cells in a transaction, then it sends itself another behave action. There is an agent responsible for painting the world, and another which evaporates pheromones in the background.
Anyway, the demo was impressive — since painting makes a copy of the world in a transaction, it has a completely consistent view of the world. Refs make sure that all changes to them are in transactions, so you have language support for where you need cooperation (contrasted to locking, which is not enforced). Agents also help you model the real world in a way that a coordinated single-looped simulation (calling behave on ants in a loop, then paint over and over again) could not.
And clojure’s agent mutating mechanism (sending a function to it), means that agents don’t have to have any knowledge of the messages that might be sent to it (again contrasted to Erlang Actors). Finally, various messages can take different times to complete and that would be represented in the simulation — some ants might complete several small actions in the time it took another to complete one (which would not be the case in a behave loop).
I’ll have more on this when the slides, code, etc are available.