SparqEE's Cell is a just launched Kickstarter project to build a GSM data module ready to integrate with Arduino, Raspberry Pi, or any other embedded hardware kit. In addition to the cellular board they are also offering SIM cards with discount data service; a first in the projects I've looked at.

Chris Higgins, one of the SparqEE founders, graciously agreed to answer a few questions about the project and their vision for how the Cell will be used. Enjoy!

Josh: Hi Chris. Before we talk about the Kickstarter project and Cell, could you tell me a bit about your company. Where did the name come from and where are you located?

Chris: SparqEE is a Southern California company that is “of the people, by the people, for the people,” if I may borrow those words from President Lincoln. We created SparqEE to make great technology that helps the world but also to change the game - in our society, money is horded by few when it’s the workers who drive companies - SparqEE shares all equity with our team. Anyone who wants to be involved and works hard will get a slice of the pie.

My 7 years in the defense industry was very demoralizing because even though I always delivered, successfully ran projects, attained patents, and innovated continuously, my income was fixed. But now with SparqEE, the harder we work the more benefits we reap.

Josh: How did you found it and find your co-conspirators?

Chris: It started back in 2009 when I was running a transportation based R&D project, I met my co-founder when meeting with the University of California, Riverside’s Center for Environmental Research and Technology (CE-CERT) team. We immediately recognized each other’s talent, had a phone conversation and talked about working together, and then in early 2010 made it official and started SparqEE.

Both co-founders are electrical engineers with a heavy background in programming, hardware, and networking so we wanted to write that into our name with “Spark” being related to electricity, the blood of technology.

Now our team has expanded and includes people we’ve worked with in the past, people we’ve met at MeetUp events, others from CoFoundersLabs – good people are everywhere, you just have to look and get involved!

Josh: What other products have you created? What other products will you create?

Chris: As for what we’ve created already and what we’re focusing on, it's vehicle telematics. We already have some history making a device for Raytheon and Oregon DOT but will be expanding that line greatly – we’ve got some fun stuff coming out for the car buffs out there! We are bootstrapping a few different directions but Telematics is one we’d definitely like to focus on.

Josh: Tell me about the Cell, your Kickstarter project. What can it let me do that I can't do with a typical Arduino?

Chris: The CELLv1.0 actually easily plugs into an Arduino, Raspberry Pi, or other breakout board – just take a look at the available shields. So right out of the box you can send messages over the cellular network.

If you take it one step further and look into the very minimal selection of cellular dev kits out there, you’ll soon realize the real reason for launching this Kickstarter.

On face value, the CELLv1.0 hardware is simply much more compact and less expensive than any other option currently on the market, but it’s the other facets that are the real differentiator, the entire ecosystem SparqEE has setup is where the value is:

• Price: definitely an important aspect as we're driving down the price of not only starter kits in the cellular arena but in production systems too. The CELLv1.0 is definitely the least expensive dev kit currently on the market.
• Servers: We're offering our servers for use by the community so that users don't need to know anything about the server-side, all they see is the CELLv1.0 attached to their Arduino or Raspberry Pi, then the reception of that data at their internet enabled device.
• SIM: With the CELLv1.0 users can use their own SIM straight from their smartphone, a prepaid one, or the SIMs we set up for this Kickstarter which are actually one of the most beneficial pieces of this project and for the community at large.
  

With M2M (machine to machine) applications and anything cellular really, the providers are one of the biggest hurdles. Since our goal is to make cellular as ubiquitous as Bluetooth and WiFi we needed to take care of everything, including the providers. So we put together a SIM card offering that works anywhere in the world, is the easiest to setup, no minimums, and is the lowest cost I've ever seen - check out www.SparqEE.com/products/SparqSIM for more info.

Josh: I see that some of the reward levels include Dev Points. What are dev points and what can I do with them?

Chris: If you take a look the Kickstarter project under the section titled “Reward Levels” we list a number of possible breakout boards, such as GPS, accelerometer, and relay, as well as shields for the Arduino and Raspberry Pi. Then, we assign a number of “Dev Points” to each one – so essentially you just add up the number of dev points for the rewards you want and select that purchase level.

Josh: Why did you go with dev points instead of traditional Kickstarter rewards?

Chris: Kickstarter rewards always seem to have way too many options and variations. The “Dev Points” is our attempt at simplifying the choices. Since our project offers a number of optional breakout boards and shields, we wanted people to easily be able to select whatever they wanted without having a million reward levels for every combination – as an example, if someone wants a relay board and accel board, all they have to select is 2 dev points under the rewards and that’s it!

Josh: Does this really work with Arduino out of the box? Can I use the regular Arduino IDE with it?

Chris: Yes, definitely. As we progress we’ll be having simple and quick explanations and examples showing you just how to connect all the hardware and the code to use. For the Arduino, if you get the Arduino shield along with the CELLv1.0 simply plug CELLv1.0 into the shield and then onto the Arduino, plug-in power, open up the Arduino IDE and you’re off – right out of the box without any extra components!

Josh: I'm confused by why there is a separate cellular board and jumper board. What is the advantage of making it two pieces?

Chris: The Jumper board is mainly for development and not meant for production systems (although you could use it for that). The main point of making it a two piece is to allow people to affix the small Cellular board to any product whether development or production.

To give a bit of insight into the cellular industry – the certifications are very stringent and expensive (~$30k), so by creating and certifying the small Cellular board, it allows others to use this module in their final products without having to go through the whole recertification process.

Josh: What do you think people will do with the Cell once they get it?

Chris: People have already been writing in to tell us about what they're going to do with the CELLv1.0 from tracking their bike for theft protection to real-time updates while racing. Others have mentioned plugging this into their BeagleBoard and thus expanding the capabilities of yet another very useful development platform.

Some ideas we came up with at SparqEE were a vehicle tracker and engine kill switch, a device that could open doors, turn on lights, and control temperature at a remote cabin or beach-house, and even early warning systems looking for heat signatures of forest fires or earthquake monitoring.

The possibilities really are endless with this component, but my favorite idea is to make a remote quadcopter to hold my Canon 60D. I really like photography and videography and with the CELLv1.0 I could fly across the city and snap pictures or take video of anything, anywhere.

The SparqEE CELLv1.0 steps in wherever there is a project that is simply out of reach using Bluetooth and WiFi.

Josh: SIMs for GSM data aren't cheap. Typically you need a full plan like the kind you'd have on your cell phone, right?

Chris: Yes and no. You do need a SIM card with a plan, similar to your cell phone, and they are typically expensive but we’ve solved this one too. With the CELLv1.0 you can use the SIM straight from your phone, a prepaid one, or the SIM card offering we put together for this project. We’re able to provide SIMs that work anywhere in the world, are the easiest to setup, no minimums, and are the lowest cost we’ve ever seen! - Check out www.SparqEE.com/products/SparqSIM for more info.

Josh: How are you able to make your own SIM cards be so cheap? Is there a monthly fee in addition or is it just cents per kb?

Chris: There are no additional monthly, yearly, or whatever other fees. We do have to charge once for the SIM card itself and activation, which comes out to less than $10, but past that there’s nothing more than the cost for data or SMS usage that you need. What you see on our page is really the extent of the costs.

As for how we’re able to offer these plans and prices, it’s because people believe in SparqEE and Kickstarter and want to see M2M flourish as much as Bluetooth and WiFi have. With affordable SIM cards, a whole new range of applications is enabled.

Josh: When will the SparqEE SIMs be available?

Chris: Since we’ve garnished so much positive feedback for our SIM offering itself, we’re working to get it up and running for the Kickstarter launch so people that need SIMs will be able to get them with their CELLv1.0.

Josh: The page mentions integrating the Cell into a product. Does that mean I could order a bunch of the boards from you for a discount? When will that be available?

Chris: Our first objective is to deliver to our supporters through Kickstarter – if you believe in our goals and support us through Kickstarter, our first priority is you. Only after the Kickstarter rewards and ecosystem are delivered and setup will we offer units for sale. At that point we imagine people would be able to order either the Jumper or Cellular boards or both, but as far as price is concerned we’re comfortable saying that if you pick up a CELLv1.0 and some dev points through Kickstarter you’re getting a great deal, a deal that won’t exist later. We appreciate the Kickstarter community and the early funding they’re providing.

Josh: Why did you choose to go with a Kickstarter instead of other funding routes?

Chris: I doubt you’ll be surprised to hear that investors aren’t all that interested in spending money to help the technological community nor thin margins. Kickstarter is a great way to get initial seed for an idea, a little bit of PR, giving you maybe just enough to be noticed if you need another round. But in our case, we believe Kickstarter will provide enough capital infusion to actually allow us to bootstrap our next iterations, circumventing the investors entirely.

Josh: When can we expect a followup project from you guys? Cell 2.0 maybe? Anything else on tap?

Chris: We’ll have follow-up projects coming up right after the CELLv1.0, maybe not on Kickstarter, but we’ve got ourselves a roadmap which includes using the CELLv1.0 on 2 other projects. People can "Like" our Facebook to get our updates! But really, we don’t imagine that the CELLv1.0 will need to be upgraded for tens of years – 2G is only just being phased out by AT&T by 2017 so 3G support will last for a great while and the CELLv1.0 will still dominate in both the 2G and 3G spaces.

Josh: What's the one question I should have asked you but didn't?

Chris: How about how we came up with the idea for the CELLv1.0? We were working on the Keychain Tracker project and thought it would be easy to get a small, inexpensive cellular module, SIM and integrate it – we were dead wrong. So, we saw that the industry needed someone to come in and minimize the pain for everybody out there and help make cellular technology and SIMs, or what amounts to relationships with cellular providers, more readily available. Thus the Kickstarter project was born.

Thank you Chris. Good luck to the whole SparqEE crew. Go check out the Kickstarter project and the SIM pricing now.

When I started this blog I had hoped to post once or twice a week. If you're one of my few remaining readers you know that this hasn't happened. My new position at Palm has kept me so busy that I haven't had time to work on the big long educational posts like Typography 101. I've also been debating if I should have any Palm or JavaScript specific content, or just keep this as a pure design blog.

So... I've come to a resolution: it's my blog and it represents me; all of the facets of my professional life. I'm going to just blog away on all topics, keep the posting flow higher, and not put off things until they are perfect. They never will be. I'll deal.

So.. look for a lot more posting from now on. I'll be sure to tag everything appropriately so you can easily filter out Palm, Java, trip reports, or anything else you desire. Thank you, gentle readers.

The Last Rocket

I first met Shaun Inman at a conference two years ago where he showed me an iOS game he was working on. Since then his NES style platformer The Last Rocket has become a hit on iOS, as well as contributing to several Lundam Dares. Shaun and his friends are in the final days of a Kickstarter project to build six retro styled games in six months. I asked Shaun to tell me a bit about the project and the motives behind it.

As of this writing Retro Game Crunch is only 60% funded with 8 days left. If you pledge now you will get to contribute to the design and plot, then receive an awesome finished game each month along with a variety of bonus goodies.

Josh Hi Shaun. Thanks for joining me. Before we get into the Retro Game Crunch can you tell me a bit about yourself? Where did you go to school? Where do you live now? What did you do before you got into game building?

Shaun Thanks for having me Josh! I'm an independent game designer and developer. I graduated from the Savannah College of Art and Design's Graphic Design program. I currently live in Chattanooga, Tennessee. Before I got into game design, I primarily designed and developed the web apps Mint and Fever.

Josh What drew you into game building? And how did you decide on retro vs more modern art styles and genres?

Shaun I've always played games. When I wasn't playing them I was reading about them. When I wasn't reading about them I was day-dreaming about them. One day I realized that I had cobbled together enough skills in the three core disciplines of game design: graphic design, programming, and music, to tackle creating my own game. When I use the word "retro" I'm referring to limited palette, resolution, and sound channels, and a focus on one or two gameplay mechanics. The limitations reduce distraction and force a designer to zero in on what makes their game fun and unique.

Josh What was the inspiration for the Retro Game Crunch?

Shaun Retro Game Crunch was inspired by other game jams like Ludum Dare. The thematic and time constraints promote the same kind of focus as the retro aesthetic. Usually at the end of these jams, you go back to your other projects. After the most recent Ludum Dare, Rusty, Matt, and I didn't want to abandon the momentum we had built up with Super Clew Land. So we kept working on it for another month. We think the resulting Super Clew Land Complete turned out great and decided we wanted to do it (at least) six more times!

Josh I'm a huge fan of the NES/SNES era Final Fantasies. I've always felt the are the perfect blend of story, graphics, music, and level grinding. Any chance we will see any RPGs from this game crunch or are you sticking with platformer styles, or even branching out to other styles?

Shaun We'll definitely be branching out. We love platformers as much the next guy but we're very conscious of not making the games too same-y. Rusty and I both love the 16-bit Final Fantasies too and would love to make an RPG. It's a tall order for 30 days but if a theme presents itself that would best be served by an RPG we might just have to go for it.

Josh Have you ever collaborated with others before on a game? How do you think these games will be different from your solo efforts?

Shaun Before Super Clew Land, Matt and I worked together on Flip's Escape and an unreleased iOS game. Neven Mrgan, Alex Ogle, and I created Millinaut during a previous Ludum Dare. Seeing what we were able to accomplish in such a short time made me crave collaboration—which is crazy because I've been working solo for more than seven years!

Josh After the six games are done what are your plans for them? Will they be ported to other platforms? Print up t-shirts? Start a Saturday morning cartoon?

Shaun Ha! We haven't really decided what to do with the games after they're in backer's hands. If any of the games seem well-suited for touch input we'd love to port them to iOS. I'd also love to have Ashley Davis, who did the illustrations for the posters, do illustrations of each character we create. An extended poster series? Who knows!

Josh I loved the Last Rocket. It has such a fun style. Any chance we'd see a sequel?

Shaun Maybe. I've already developed a plot and new gameplay elements. I just need to find the time to develop it!

Josh When we first met you showed me a prototype you were working on. In the game the character could switch from Game Boy era graphics to Super Nintendo. Whatever happened to that?

Shaun Mimeo and the Kleptopus King was a ridiculously ambitious project for my first real game. The tech demo was cool but couldn't support a full game (it was just too inefficient). I'd love to pick up the idea again once I'm a little more experienced. And maybe with a bigger team. Four resolutions means four times the graphic, music, and level assets!

Josh It seems that retro game building has gone from a hobby to your full time job. After the Crunch is over do you think you will stick with making games or you will be sick of it?

Shaun I'm looking at Retro Game Crunch as a learning and growing experience. I doubt I'll be sick of it. Rusty, Matt, and I survived the first crunch and are eager to start again. We'll probably weather the six months just fine!

update

Shaun let me know they just added something new. If you pledge Retro Game Crunch now you will also get a Bonus Jam Pack with Mac/Windows versions of several games by their indie-coder friends, including Fathom, Escape, and Midas.

One last update before the auction begins. I'm labeling everything and checking that all the devices charge. No bum-devices here. I can't vouch for the never been opened vintage PalmOS devices but everything that is open will charge.

New Items

I've received a few more items. Another 32GB ATT TouchPad, including a TouchStone charger. Plus some one of a kind Palm and HP Tshirts that were given out to staff for the original TouchPad launch event. Oh, and webOS Nation sent us some rad coffee mugs. Even if you don't use a webOS device anymore you can still show your webOS pride. Many thanks to all of our donors.

Shipping

A note on shipping. When you check out after the auction ends you should be able to include extra for shipping. It is 10$ for a single item, or 5$ if you get multiple items (I don't think anything is so big that it will cost too much more). If you live outside the US just mail me to work out exact postage.

We'll see you Sunday morning with the link to the auction to check out all the merch. Remember to join the mailing list so you get the link. Thanks again.

Javascript has always had properties but recently support for property accessors and mutators was added, or rather it is finally supported in enough browsers that we can reliably use it. Property accessors and mutators are what we would call in the Java world "getters and setters". The cool thing about the new JavaScript version is that you don't call the getX method. Rather you can set a property the way you always have, as a variable assignment, but the accessor method is called underneath.

This is a very powerful feature, and yet my research indicates that they are rarely used in practice. In fact I can find almost no reference to them beyond how the syntax works. Where are the cool crazy things you can do with them? They seem incredibly useful.

Here's how the syntax works

var foo = { 
    x:0, 
    get value() { return this._x; }, 
    set value(x) { console.log("set to " + x); this.x = x; }
}
var foo = new Foo();
foo.x = 5; // prints 'setting x to 5'

The ability to invoke a method whenever a property is set seems very powerful. For example, you could bind the width of a rectangle to the value of a slider. Whenever the slider changes the rectangle would move, no extra update code required. I think the new property system would also let us have proxy methods, meaning we replace a setter or getter with a new implementation that does something special then calls the old implementation.

Then we could add after an object is created:

• A listener to be called when a property changes.
• A filter on a property to veto certain value changes. ex: restrict value to 0->1. veto anything else.
• Bind any two variables together. If x changes then y is updated to reflect the new value
• Bind the value of a slider to an object on screen, modified with an equation. ex: rect.width = slider.value * 3;

The new property syntax can also be used to create synthetic properties. A synthetic property is one that has no direct underlying storage. Rather the value is calculated on the fly, or delegated to alternate storage. For example, you could have a rectangle object with x and y as true properties. Then add a position property which is a short hand that maps to the x and y underneath:

rect.x = 10;
rect.y = 20;
// pos is a synthetic property. really sets x and y underneath
rect.pos = [10,20]; // pos is a synthetic property, really gets value from x and y
console.log("the rect is at " + rect.pos);

This could let us create more convenient APIs for certain domains like event handling.

onDrag(mouse) { 
    //set rectangle's position to the mouse's position 
    rect.pos = mouse.pos; 
    //set rect's position to the mouse's position plus an offset 
    rect.pos = mouse.pos.plus(30,40);
}

I don't think we can do operator overloading, or else this would be possible: rect.pos = mouse.pos + [30,40];

We could also do structure swizzling like this:

color.bgra = color.rgba;

Or modify colors stored as RGB using synthetic HSV properties, like this:

color.rgba = #ff00ff00;
color.hue += 30;
color.saturation = 0.5;

So my real question is: Why is no one using this stuff? Where are the cool demos by language gurus who know far more about JavaScript than me. Am I just missing the magic website that talks about it?

Please send feedback and comments to my twitter account @joshmarinacci instead of on the blog. Thanks!

Jesse is one week old today. An amazing week it has been.

In general I don't post personal things to this blog. A few years ago I consciously decided to keep personal communication on Facebook and restrict my professional online life to this blog and Twitter. That's why I'll ignore FaceBook friend requests from people I don't regularly know in real life and limit search/info/photo access to friends of friends.  However, I'm making an exception today for one simple reason: having a child is life changing, both personal and professional.

I'm currently on vacation for two weeks to spend time with my new son, and it's true.  My life is changing. I know it sounds cliche, but we have cliches for a reason. That a child would change my life is something I always knew, but didn't understand until now. As I Tweeted a few days ago: now that I've spent hours up all night coaxing a fussy baby to sleep, I finally feel like a father. Life will never be the same again.

That doesn't mean I won't be the GUI nerd I've always been; I'll just focus on different things. For obvious reasons my interest has focused on ebooks and games, especially apps targeted at young children.  I've been involved in the development of the TouchPad for close to a year, and I know the potential of tablet technology to revolutionize how we teach, train, and entertain children.  We have so many great apps prepping for launch, I really couldn't be happier.  I think you'll be happy too.

That's all for today's lazy Sunday post. Time to wake Jesse up for lunch and clean the house (it's amazing how messy a house can get with a baby around).

Welcome to the world Jesse. We've got great stuff to show you.

I'm on the plane home from Mobile World Congress. It's been a heck of a couple of weeks. I've gotten some new coworkers, a new boss, announced our new products, showed off the new devices in Barcelona, and spread the word of webOS itself to anyone who will listen. I've got several blogs coming about what we've announced, some fun new demos, app speculation, and updates on my open source projects.

But first.. I rest. I've been traveling for two weeks straight and need some sleep. In the meantime I'd like to share with you photos of something far more important: the revolution in Egypt. You really must read this post from Peter Turnley, an amazing photographer who ventured to Cairo in the midst of the protests to shoot some amazing photos both before and after the president's capitulation. You won't regret it.

The Problem

The Solution

if(canvas.width != canvas.clientWidth) { canvas.width = canvas.clientWidth; }

• Do nothing. Don't adjust the canvas size or scaling at all.
• Resize the canvas but don't mess with scaling. This essentially turns the canvas into a resizable rectangle, leaving it up to the content to adjust as desired.
• Uniformly scale the content to fit.

2010 is here and I still don't have my flying car or moon rocket, much less a spaceship en route to Jupiter for some serious monolith research. Sadly, I'll have to be satisfied with some baseless and random speculation on the year to come. Take these predictions with a boulder of salt and me out on them in December.

2009 was a big year for technology. A fairly bright spot in an otherwise dismal economy. From a design perspective we've seen the further growth in next-gen UI technologies like Flash, Silverlight, and HTML 5; and a greater focus on design in the app development process. We've also seen major growth of alternatives to the WIMP (window, icon, menu, pointdevice) user interface that has dominated computing for the past 30 years. Touch screens, ePaper, accelerometers, and embedded cameras are mainstream technologies and have started working their way into every gadget we buy.

The next year should be an exciting one, but with mostly evolutionary improvement of technologies we have today. I predict nothing out of the blue. (Of course, if something was truly out of the blue we, by definition, wouldn't be able to predict it). Anyway: on with the show!

I've broken my predictions up into three categories: software, hardware, and misc. Each prediction has a percent indicating the likely-hood it will come true. Next December we'll revisit these and see how I did.

Software in 2010

Software is moving to the cloud. The UI of any given app might be implemented in HTML & Javascript in a webbrowser, or through an RIA toolkit like Java, Flash, or Sliverlight. (and occasionally a native toolkit like iTunes). But the trend is clear, all software comes from the internet and a significant portion of their features are implemented on the server side. This is a long term trend and won't be reversed. Given this trend, here are the effects I think we'll see in 2010:

Social Networking sites become useful. 80%

We've had Facebook, Twitter, LinkedIn, and other social networking sites for a few years now. I think the industry is starting to coalesce into a set of useful offerings now that we've had enough time to figure out what all of this stuff is actually good for. This means both companies and individuals will start to see real value from these services.

The downside is that privacy sinks to an all time low and our public & private lives heavily bleed into each other. I've taken the step of fully separating my personal and professional identities. I now use Facebook only for personal friends that I know in real life, and push my professional life through Twitter, LinkedIn, and this blog. Fortunately the social networking tools have improved enough to make this a relatively painless process. However, given that each service has a different audience I'm often conflicted about what to post where.

OpenID finally takes off: 70%

OpenID is an open standard which lets you log into a website using your username from another website. It promises to free us having to remember a million different logins. Since Google, Yahoo, and others now expose their user databases through OpenID I predict a huge increase in websites using it. The era of a universal login might soon be upon us.

Downside: the era of a universal trackable login might soon be upon us.

Cloud enabled netbooks ship: 70%

You will be able to buy a small laptop who's entire software catalog is purchased through an online store in the device. It will probably run Chrome OS, Android, or an Ubuntu variant. All apps will be HTML in the browser or written in a crossplatform RIA toolkit like Java or Flash. If your netbook dies, you just buy a new one and click a button to reinstall everything from the cloud.

We'll have several shipping toolkits that let you target all of the major smartphone OSes: 80%

This means a write-once run everywhere cross-device toolset for smartphones that is actually shipping (not tech demos), and supports iPhone, WebOS (Palm), Android, and Blackberry.

We are pretty much there already. Adobe has promised a version of Flash in 2010 that will let you build apps on WebOS (Palm), BlackBerry, and the iPhone; and some Android phones ship with Flash support. PhoneGap lets you target every device with a WebKit derived browser, which is pretty much everything. Silverlight is being ported to other platforms and MonoTouch lets you write C# code that targets the iPhone. 2010 will see all of these toolkits mature, with several prominent app makers adopting them for all of their apps except games.

Windows Mobile and older JavaME based feature phones aren't on the list above because developers won't care about them. Sad but true. WinMo is dead unless Microsoft does something truly amazing with Windows Mobile 7 (and I sincerely hope they do). Older JavaME based phones have the numbers (2 billion +) but those phones (and their associated cellphone contracts) don't encourage users to buy apps, so they don't matter to developers. If you can't ship apps to them then they don't count.

Hardware in 2010

Hardware improvements shouldn't be surprising: everything will be smaller, faster, and cheaper. Moore's Law will not be repealed. The focus on power efficiency means the world is going mobile. The biggest shift we will see in 2010 is the general purpose 'personal computer' losing sales to more specialized devices. eBook readers, smartphones, tablets, and set-top boxes will continue to chip away at the market share of desktop and laptop computers.

Someone will create a TV attached device worth owning: 30%

Everyone has some sort of a TV attached device these days. It makes sense, the TV is the largest screen in most homes so why not do something more with it than just playing video. I want a device which will play media, play games, check mail, browse the web, and let me install my own apps; all displayed in gorgeous 1080p. The potential is huge!

Sadly the market is terribly fractured with no standards and a bunch of half finished solutions. The AppleTV has devolved into an iTunes Store front-end. The Wii, XBox, and Playstation all do games well, but their video and content services are weak. The cable companies have semi-decent DVRs, but don't have stores with downloadable apps or access to internet content. The most compelling options today are actually home-brew Linux boxes running MythTV.

I really hope someone can pull the pieces together into a single solution, but I don't have high hopes. It may take an iPhone-like dark horse entrant to change the power structure of this market.

Pico-projectors for Smart-phones become popular: 20%

The concept seems good on paper: a tiny projector that fits in your pocket, attaches to your cellphone, and projects a 4 foot image on a wall or T-shirt. Sounds like science fiction! It seems like a great idea, but in practice the images are too dim and shakey to be useful. It will remain a novelty that most people don't need or want

Tablet computers will be popular this year: 100%

I'm planning a much longer post on tablets for next week so I'll just summarize here. Both the hardware and software have converged to make a useful tablet computer possible. The key will be building a device that doesn't try to be a full featured desktop computer in a tablet form factor. Any successful tablet computer will be more like a large iPod Touch rather than a flat laptop. It will be the next step along the road of making computing ubiquitous and invisible. After all, what is a tablet but a computer where everything has been made invisible except the display.

Given the Apple rumors and pre-announcements from several vendors I expect several tablets to be on sale next year. If they can figure out one or two killer features (most likely relating to media consumption and social networking) then I think they will be very popular.

My specific prediction regarding the Apple tablet: it will be a large iPod Touch running the same OS and managed though iTunes. There will probably be a few extensions to the Cocoa Touch APIs and new UI guidelines for the larger form factor. The basic apps will be retooled for the larger screen but little change in functionality. iTunes will add a book and magazine store. But that's it. No revolutionary form factor or display technology. Just a large iPod Touch. And it will sell millions. The time is just right.

An ebook reader using something other than eInk ships: 50%

Ebook readers are all the rage right now, and with good reason. They represent the future of paper, but the display technology is still very limited. Virtually all of the ebook readers on the market use the same physical display technology: an electrosensitive fluid from eInk. Refresh rate and contrast is horrible, but it's a good enough start to create a market for better products. A slew of competing technologies are under development and success of the Kindle will ensure they get funding, so there's a good chance one of them will ship in 2010.

Smartphones won't improve significantly, but over half of all phones sold in the US will be smartphones: 80%

The iPhone, Android devices, the Palm Pre, and new BlackBerries have solidified what a 'smartphone' is: a general purpose touch-centric device with user installable applications. A year from now I don't expect this to look any different. We'll have some new devices with more memory and faster CPUs, but the landscape will be pretty much the same.

As a side effect of this market stability I expect smartphones to make huge inroads into the general cellphone market. Thanks to Apple's ads the average consumer now understands the benefits of a smartphone with installable apps, and carriers love to sell data plans. I expect over half of all new phones sold next December to be smartphones. AT&T's network will continue to strain under the usage.

Land line phone service falls by half: 80%

This has been a long time coming. I've personally had only a cellphone for the past decade. Thanks to competition from wireless carriers, Skype, and VoIP solutions I expect the retreat from landlines to reach 50% by the end of 2010.

On The Edge

Voice recognition becomes a significant user interface: 20%

Voice recognition will continue to be a technology that's just around the corner but still never arrives. Any growth will come from 411 style services that let you speak a question and receive a webpage answer. Google is pushing heavily in this area with their Google Voice service. I still don't think we'll have true voice command (KITT style) until we have much stronger AI. But that's just around the corner. :)

Self driving cars: 0.001%

The potential is huge, but the chances of me being able to buy a self driving car this year is almost certainly none.

However, we are likely to see some interesting advancements on the way to self driving cars. Some luxury cars can now parallel park themselves and the DARPA challenges have been successful. I suspect we'll see more closed course demonstrations of cars doing things that would simply be impossible for a human driver to accomplish. Things like drifting and spinning become trivial when you can control each wheel's drive and breaking separately. Since most drivers don't have eight feet, the computer will have a leg up on humans.

YouTube, Twitter, and Facebook combine into a single time wasting website: YouTwitFace

Likelyhood: 92.6%

Happy New Year!

When redesigning Amino I had a few core goals. These goals are in place to guide the product and ensure we created something genuinely useful, and not become "yet another gfx lib".

Goals

Amino 2 must be:

• Simple: the api must be simple and easy to understand
• Responsive: the goal is to hit a consistent fps for all graphics on screen. 60fps on desktop and 30fps on mobile. This should be very doable with modern devices. The UI must always be responsive, even at the cost of accuracy or graphics complexity.
• Rich: complex effects and animation should be possible(shadows, gradients, real world textures, animation) while still hitting a consistent FPS.
• Speedable: we should be able to add speed improvements, including hardware acceleration, purely in the implementation. Speedups shouldn't affect the API. Existing apps just get faster over time.
• Subsettable: You should be able to use just the parts you need.
• Portable: Nothing of the underlying graphics implementation should be exposed. (we aren't there yet).
• Flexible: for lots of tasks you can just compose nodes together, but sometimes you may want to dig down to the lower levels. This should be possible, as long as you realize your code might not be as portable anymore.

Structure

With these goals in mind, here is the basic structure:

A Node is an object in the tree with a draw function. Anything which draws or affects drawing is a subclass of Node. This means all shapes, groups, transforms, imageviews, etc. Nodes also track their dirty state, and if they contain a given point (used for input processing). All nodes have parents (except the top most node)

A Parent is simple a node that implements the Parent interface. Currently only Group and Transform are parents.

A Scene is a tree of Nodes (a non-cyclical directed graph).

Everything is done on a single GUI thread. Touching nodes or trying to draw off the GUI thread is an error.

Resources (images, gradients, colors, textures) are immutable, to enable transparent caching.

Amino's internal system handles repaints, animation, and input events for you. you just create the tree of nodes and you are off to the races. By letting Amino handle these things we can ensure a consistent framerate and the best performance possible.

All events are generated by the system (usually by wrapping native events) and passed to your handlers through the event bus. You can listen to either a particular kind of event on a particular object, or all of that kind of event throughout the system. For example: Give me all mouse press events or Tell me when this node is clicked. Events will be automatically transformed into local coordinates when you click on transformed objects, and they are passed along with the target node of the event.

A quick note on cross platform support. My goal is to make the Java and JavaScript APIs identical. Wherever possible this is true. However, due to the difference between the languages (namely that JavaScript uses prototype based inheritance) there will be minor differences. In general the same code should work under both with only minor syntactic changes.

Example

The following code creates two colored rectangles with method chaining. Then it creates a square that spins and slides back and forth across the screen. I've included both Java and Javascript versions so you can see the minor differences.

Javascript

var runner = new Runner();
runner.setCanvas(document.getElementById("canvas")); var g = new Group();
g.add(new Rect().setWidth(100).setHeight(50).setFill("green")) .add(new Rect().setWidth(50).setHeight(50).setY(100).setFill("yellow"))
; var r = new Rect().set(-25,-25,50,50).setFill("white"); var t = new Transform(r).setTranslateX(100).setTranslateY(100);
g.add(t);
runner.addAnim(new Anim(t,"rotation",0,90,1).setLoop(true).setAutoReverse(false));
runner.addAnim(new Anim(t,"translateX",100,500,4).setLoop(true).setAutoReverse(true));
runner.addAnim(new Anim(t,"translateY",100,150,0.5).setLoop(true).setAutoReverse(true)); runner.root = g;
runner.start();

Java

final Core runner = new Core();
runner.setSize(600,400);
runner.setBackground(Color.BLACK); Group g = new Group();
g.add(new Rect().setWidth(100).setHeight(50).setFill(Color.GREEN)) .add(new Rect().setWidth(50).setHeight(50).setFill(Color.YELLOW).setY(100))
; Rect r = new Rect().set(-25, -25, 50, 50);
r.setFill(Color.WHITE);
Transform t = new Transform(r).setTranslateX(100).setTranslateY(100);
g.add(t);
runner.addAnim(new PropAnim(t,"rotation",0,90,1).setLoop(true).setAutoReverse(false));
runner.addAnim(new PropAnim(t,"translateX",100,500,4).setLoop(true).setAutoReverse(true));
runner.addAnim(new PropAnim(t,"translateY",100,150,0.5).setLoop(true).setAutoReverse(true)); runner.root = g;
runner.start();

Download

Amino 2 is still very much a work in progress, but so far I'm happy with the design. I've made several TouchPad apps already with decent performance, and the API really simplifies Java2D coding. Next I'm working on more graphics primitives, buffered effects, and a simple path API.

You can download a daily build here. Please join the Amino Dev List to provide feedback or contribute to the project.

Thanks!

The Good

The Bad

Wires

During SXSW this year I had the great fortune to see the keynote given by Stephen Wolfram. If you’ve not heard of him before, he’s the guy who created Mathematica, and more recently Wolfram Alpha, an online cloud brain. He’s an insanely smart guy with the huge ambition to change how we think.

When Stephen started, back in the early 1980s, he was interested in physics but wasn’t very good at integral calculus. Being an awesome nerd he wrote a program to do the integration for him. This eventually became Mathematica. He has felt for decades that with better tools we can think better, and think better thoughts. He didn’t write Mathematica because he loves math. He wrote it to get beyond math. To let the human specify the goals and have the computer figure out how to do it.

After a decade of building and selling Mathematica he spent the next decade doing science again. Among other things this resulted in his massive tome: A New Kind Of Science, and the creation of Wolfram Alpha, a program that systematizes knowledge to let you ask ask questions about anything.

In 1983 he invented/discovered a one dimensional cellular autonomy called Rule 30, (which he still has the code printed on his business cards). Rule 30 creates lots of complexity from a very simple equation. Even if one runs just a tiny program it can end up making interesting complexity from very little. He feels there is no distinction between emergent complexity and brain like intelligence. IE: we don't need a brain like AI, the typical Strong AI claim. Rather, with emergent complexity we can augment human cognition to answer ever more difficult questions.

The end result of all of this is the Wolfram Language, which they are just started to release now in SDK form. By combining this language with the tools in Mathematica and the power of a data collecting cloud; they have created something qualitatively different. Essentially a super-brain in the cloud.

The Wolfram Language is a 'knowledge based language’ as he calls it. Most programming languages stay close to the operation of the machine. Most features are pushed into libraries or other programs. The Wolfram Language takes the opposite approach. It has as much as possible built in; that is the language itself does as much as possible. It automates as much as possible for the programmer.

After explaining the philosophy Stephen did a few demos. He was using the Wolfram tool, which is a desktop app that constantly communicates with the cloud servers. In a few keystrokes he created 60k random numbers, then applied a much of statistical tests like mean, numerical value, and skewness. Essentially Mathematica. Then he drew his live Facebook friend network as a nicely laid out node graph. Next he captured a live camera image from his laptop, partitioned it blocks of size 50, applies some filters, compressed the result to a single final image and tweeted the result. He did all of this through the interactive tool with just a few commands. It really is a union of textual, visual, and the network.

For his next trick, Mr. Wolfram asked the cloud for a time series of air temperatures from Austin for the past year then drew it as a graph. Again, he used only a few commands and all data was pulled from the Wolfram Cloud brain. Next he asked for the countries which border Ukraine, calculated the lengths of the borders, and made a chart. Next he asked the system for a list of all Former Soviet Republics, grabbed the flag image for each, then used a ‘nearest’ function to see which flag is closest to the French flag. This ‘nearest’ function is interesting because it isn’t a single function. Rather the computer will automatically select the best algorithm from an exhaustive collection. It seems almost magical. He did a similar demo using images of hand written numbers and the ‘classify’ function to create a machine learning classifier for new hand drawn numbers.

He’s right. The Wolfram Language really does have everything built in. The cloud has factual data for almost everything. The contents of wikipedia, many other public databases, and Wolfram’s own scientific databases are built in. The natural language parser makes it easier to work with. It knows that NYC probably means New York City, and can ask the human for clarification if needed. His overall goal is maximum automation. You define what you want the language to do and then it’s up the language to figure out how to do it. It’s taken 25 years to make this language possible, and easy to learn and guess. He claims they’ve invented new algorithms that are only possible because of this system.

Since all of the Wolfram Language is backed by the cloud they can do some interesting things. You can write a function and then publish it to their cloud service. The function becomes a JSON or XML web service, instantly live, with a unique URL. All data conversion and hosting is transparently handled for you. All symbolic computation is backed by their cloud. You can also publish a function as a web form. Function parameters become form input elements. As an example he created a simple function which takes the names of two cities and returns a map containing them. Published as a form shows the user two text fields to ask for the city names. Type in two cities and press enter, an image of a map is returned. These aren’t just plain text fields, though. They contain are backed by the full natural language understanding of the cloud. You get auto-completion and validation automatically. And it works perfectly on mobile devices.

Everything I saw was sort of mind blowing if we consider what this system will do after a few more iterations. The challenge, at least in my mind, is how to sell it. It’s tricky to sell a general purpose super-brain. Telling people "It can do anything" doesn't usually drive sales. They seem to be aware of this, however, as they now have a bunch of products specific to different industry verticals like physical sciences and healthcare. They don’t sell the super-brain itself, but specific tools backed by the brain. They also announced an SDK that will let developers write web and mobile apps that use the NLP parser and cloud brain as services. They want it to be as easy to put into an app as a Google Maps. What will developers make with the SDK? They don’t know yet, but it sure will be exciting.

The upshot of all this? The future looks bright. It’s also inspired me to write a new version of my Amino Shell with improved features. Stay tuned.

For some reason the concept of Genetic Programming got stuck in my head the other evening. At midnight, after spending about four hours reading up on the topic around the web, I came away disappointed. The concept of evolving code the way genes do is fascinating but the results in the field seem to be very narrow and limiting. Thus began this rant.

This article called Genetic Programming: A Novel Failure probably sums up my thoughts best. Genetic programming is only a slight variation on solution searching algorithms. Based on my reading, most work in the field has focused on how to make systems converge on a solution more quickly, i.e.: improving efficiency. This seems wrong, or at best premature.

We live in the 21st century. We have more CPU cycles than we know what do with. Where are the systems that are wide but shallow? The ones that are really non-determinstic and will generate truly surprising results? We should be wasting cycles exploring new possibilities, not generating new solutions for known problems.

The free ebook, A Field Guide to Genetic Programming, is a great primer in the topic. I read through most of it the other night. My biggest frustration is that almost all genetic programing systems focus on evolving syntax trees, usually some form of Lisp or it's semantic equivalent. I see why people would do this. Lisp code is easy to manipulate programmatically, so evolving it should be simple as well. There are other kinds of systems using different gene encoding, such as image arrays and direct byte code. However, these appear to be far in the minority. The Field Guide has a chapter on the topic, listing several alternate systems. The fact that these systems receive a single slender chapter while the rest of the book covers syntax trees gives you an idea of how under-explored the topic is.

When I first heard of genetic programming I imagined having a sequence of simple instructions that could be mutated. The instructions would be extremely simple and limited, perhaps more simple than most assembly languages. Evolving syntax trees certainly does let you make progress quicker, but the generated solutions will be limited to the underlying tree language. Our genetic beasties will never evolve novel flow control systems, or invent a crazy kind of memory register. ASTs are great if we want to produce a human readable program as the result, but it still feels limiting.

I would like to see a system that is as open ended as possible. Create a system of small instructions of uniform length that can only manipulate basic storage and do simple math. Then give them as much freedom as possible. Let them live in a wide fitness landscape. A digital environment with a huge number of potential ecological niches. Ideally we could take this to the next step and give our digital creations physical bodies so that they may evolve targeting real world constraints. Evolving a robot's brain seems far more interesting than figuring out how to gain 10 milliseconds trading stocks. Of course we lose rapid iterations by running them in the real world, so it my be better to run them in a simulation of the real world at many times normal speed. I imagine we could build self driving cars this way, starting with bots that play racing games then upgrade them to working with real world footage from actual self driving cars.

Am I wrong? Is there cutting edge genetic programming that is truly open ended? What successes have they made?

Please send feedback and comments to my twitter account @joshmarinacci instead of on the blog. Thanks!

I recently wrote an amusing rant on programming languages called "An open letter to language designers: Kill your sacred cows." It was, um, not well received. If you read some of the comments on Reddit and Hacker News you see that most people think I'm an idiot, a novice, or know nothing about programming languages. *sigh*. Maybe I am.

Most people got hung up on my first point: don't store source code as plain text on disk. I thought it was innovative but relatively uncontroversial. Surely, one day we won't store source as ASCII text files, so let's start thinking about it now. I mean, surely the Starship Enterprise's OS wasn't written in plain text files with VIM. Surely! I guess I underestimated the Internet.

Perhaps Not

So why did I not spark any real discussion? First I must blame myself for writing in the form of a rant. I thought the obnoxious insults would be amusing jokes, very tongue in cheek. Alas, tone is very hard to convey on the Internet through prose. That is completely my fault. I think I made an even bigger error, though. I talked about some interesting ideas (or rather, what *not* to do) but I didn't give any solutions or go in-depth with my justifications. That is why I have written the essay you are reading now: to explore just the first point and see if it makes sense.

Engineering is about tradeoffs. Cheap, fast, and correct: pick any two. So it is with source code stored as something other than ASCII text. Any modification will require changes in the surrounding ecosystem of tools. Version control. Continuous build systems. Diff tools. IDEs. The question is whether the benefits outweigh the negatives plus the cost of change. In this essay I hope to prove to you that the benefits could outweigh the costs; or at least close enough that it is worth exploring.

What is a codebase?

A codebase is fundamentally a large graph structure. If you look at the typical Java code base you have a bunch of classes with varying visibility organized into packages. The classes contain fields and methods which are composed of statements and expressions. A big tree. Since classes can call each other in varying ways, not to mention other libraries on the class path, we get a potentially circular structure. A codebase also has non-code resources like images, as well as some semi-code structures like XML config files (I'll leave out the build infrastructure for now). So we get a big complex graph that grows bigger and more complex over time.

A good IDE will create this codebase graph in memory. This graph is what gives you things like cheap refactoring and code completion. But when you quit your IDE what does it do? It serializes the entire graph as code split across multiple files and directories. When you restart the IDE it must regenerate this entire graph in memory. Though it wastes some CPU, this system would be fine if everything from the in-memory graph was preserved and restored perfectly without any data loss. Sadly it does not. The source code can't preserve developer settings. This is stored elsewhere. It can't store a history of what the developer actually did at what time. This is stored elsewhere or not at all. I think there is fundamentally something wrong with the fact that we are converting our complex graph into a lossy data store.

Source Code Is Lossy?

Yes, I think source code is lossy. A source file must meet two opposing demands. It must be human readable and writable with as little annoyance as possible. It must also be parseable into a graph structure (the Abstract Syntax Tree or AST) by the compiler without any ambiguity. These twin demands are sometimes in conflict, and when they are the compiler usually wins. Let me give you a simple example. Nested block comments.

In your typical C derived language like Java you can have block comments delimited by /* and */. You can also use single line comments that begin with // and finish at the end of the line. This basic system is a few decades old and has the unfortunate side effect that block comments cannot be nested. The following code is probably clear to a human but will choke the compiler.

some live code
/*
first commented out code
     /* second commented out code */
more first commented out code
*/
more live code

I know what this means but it is impossible for the compiler. Of course, the compiler could start counting open and closing delimiters to figure it out, but then it might choke on a */ stored inside a string. Or the human could nest the single line comments with the help of an IDE. All of these are solvable problems with a more advanced compiler or improved syntax, but they further complicate the language definition and impose more mental cost on the human doing the coding.

The Alternative

Now consider an IDE and compiler that work directly on the graph. I select some code in my editor and click the 'comment' button. It marks that section of the graph as being in a comment. Now I select a larger chunk of code, containing the first chunk, and mark it as a comment. Internally the IDE has no problem with this. It's just another few layers in the tree graph. It can let me move in and out of the code chunks with no ambiguity because it is operating directly on the graph. If the IDE can store this graph to disk as a graph then the compiler can also do its thing with no ambiguity. If we first serialize to human readable source code then parts of the graph are lost and ambiguity results.

This sounds like a trivial example, and quite frankly it is. That's the point. This is a simple case that is hard for the current system but trivial for a graph based system. How much more work must the compiler do to handle harder problems? Here's a few examples of things that become trivial with a graph system.

• A version control system that loaded up a graph instead of text files could calculate perfect diffs. It would actually know that you renamed class A to class B because the IDE recorded that history. Instead, today it must reverse engineer this information by noticing one file is gone and another one appeared. If you renamed several classes between commits then the diff tool could get confused. With a graph the diffs would be perfect.
• With perfect diffs the version control system could visualize them in a way that is far more useful. Rather than a bunch of text diffs it could say: "class A was renamed to B. Class D was renamed to G. Class E was deleted. Methods X, Y, and Z were moved up to superclass R. The contents of methods Q and R were modified. Click to see details."
• Renaming and refactoring is trivial. We already know this because the IDE does it using an internal graph. What if other tools could do that. You could write a script that would perform complex modifications to entire code bases with ease. (James Gosling once experimented with such as system called JackPot).
• As with comments, multi-line strings become trivial. Just paste it in. The IDE will properly insert it into the graph. The language definition doesn't have to care and the compiler will work perfectly.
• Variable interpolation in strings is a function of the IDE rather than the language. The IDE can store "for ${foo} justice" as ("for " + foo + " justice") in the internal graph. This is passed to the compiler so it doesn't have to worry about escaping rules. Any sort of text escaping becomes trivial to deal with.

• Since the parsing step is gone we no longer need to worry about delimiters like {} and (). We can still use them in the IDE to make the code more comprehensible to humans, but some programmers might prefer indentation to delimiters. The IDE will take care of it, showing them if you wish or hiding them. It makes no difference to the underlying graph or the compiler. Here's a great example of an IDE built by Kirill Osenkov with very creative ways to visualize code blocks.

  

New Things

Once we have fully committed to storing the graph directly rather than the lossy plain text phase, other things become possible. We can store many forms of metadata directly in the graph rather than splitting it out into separate classes or storing it outside the code repo. Now the IDE can focus on making life better for the developer. Here are a few things I'd like to see.

• A better interface for creating regexes. Define your regex in a special editor embedded into the main code editor. This editor not only provides docs and syntax highlighting, it can store example data along with the regex. Are you parsing credit card numbers? Type in 20 example strings showing the many ways it could go wrong. The editor shows you how they pass or fail. It also stores it with the source to be executed as unit tests by the continuous build system.
• Inline docs would be editable with a proper WYSIWYG interface. No more having to remember the particular markup syntax used by this language. (Though you could still switch to raw markdown, html, etc. if you chose). Images in docs would become more common as well. You could also select a snippet of live code and mark it as being an example for the docs above. Then your example code will never be out of date.
• Inline unit tests. Why must our unit tests be in a separate hierarchy run with separate commands. If it is good to keep docs near the code then it seems logical to keep the tests with the code as well. The IDE could give me a list of tests relevant to the current block of code I'm looking at. I can see the history of these test and if they currently fail. I can create a new test for the current code without creating new classes and files. The easier we make it to create tests the more we will be created.

• Edit and store non-code resources inline. Icons, vector artwork, animation interpolators, hex values for colors. This would all be stored as part of the source and edited inline using the appropriate interface. Colors can be edited with a color picker instead of remembering hex codes. Animation can be edited with a bezier curve instead of guessing at values. The icon would actually be shown visually instead of just a file path. All of these things can be done today, but they become easier and more standardized if we work directly on the graph instead of plain text. Here is an editor called Field that shows some of the possibilities.

• Once we get away from the file being the atomic unit of code, then we can start to arrange our code visually in other ways; ways that might be more useful to the human rather than the compiler. Chris Granger just posted a video for a cool new IDE concept called the Light Table.

Conclusion

I hope I have shown you that there is a wide world of new coding ideas being explored, most of them not related to the language definition but rather to how we human programmers interact with the code. Certainly there are costs associated with such a change, but I think the costs could be dealt with if the benefits are worth it, and I clearly believe they are. We can update version control systems to work with a graph instead of text diffs. We can define a standard for storing the graph on disk so that any IDE can work with it. We can create libraries for manipulating the graph, enabling others to easily create new tools. Those are all solvable problems if we decide we want to.

Ultimately my disappointment with new programming languages, and the impetus for my original essay, is that we live in the twenty first century but we still code like it's the 1970s. I want to see our field move forward by leaps and bounds, not incremental improvements to C, Smalltalk, and Lisp. The challenges our industry faces will be easier to deal with if we aren't wedded to our current notions of how coding is done. 100 core parallelization. Code scaling from non-smartphones to global computing networks. 3D interfaces built from scene graphs and real time imagery. Ubiquitous computing and latency driven design. We have lot coming, and coming soon, but our language researchers are acting like compilers and languages are a solved problem with only a few tweaks needed. And if we, the real world programmers, are afraid to try anything too radical then perhaps the researchers are right.

But I don't think so. The challenges coming this century are huge. We should invent new tools to solve them.

I’m happy to announce Electron 0.2. We’ve done a lot of work to improve the compiler and library tools. The biggest news is Windows and Linux support. Also, you don’t need to pre-install the regular Arduino IDE anymore. Electron will auto-download it’s own copy of the required toolchain. Here’s the details:

• Initial Windows and Linux support!
• You don’t need to modify settings.js anymore. Electron will auto detect your Arduino/Sketchbook dir.
• You don’t need the regular Arduino IDE installed anymore. The appropriate toolchain will be auto-downloaded for you the first time you compile something.
• User installed libs work now. Note that user installed libs take a priority over libs installed by the IDE.
• the serial port will be automatically closed and reopened when you upload a sketch. If this crashes your computer please let me know. I might need to increase the timeouts.
• Preliminary support for auto-detecting which board you are using by the USB VID/PID. Special thanks to PixnBits for that.
• Set the serial port speed
• Sketch rename works now
• download progress is shown in the browser (partially)
• tons of under the hood fixes
• auto scroll the console

The arduino-data project was also updated with new boards an libraries:

• New boards: TinyLily and Gamebuino
• More networking libs: CmdMessenger, OneWire, PS2Keyboard, SerialControl, SSoftware2Mobile, Webduino
• More specs on various boards
• The rest of the built in libraries: Ethernet, Firmata, GSM, LiquidCrystal, SD, SoftwareSerial, TFT, WiFi
• Support library sub-dependencies

Thanks to contributors:

• Dan O’Donovan / Dan-Emutex
• Nick Oliver / PixnBits
• Sean McCarthy / seandmcarthy
• trosper

You can get the latest code on the github project.Please test this with every board and OS you have. File bugs in the issue tracker.

I’ve registered a domain for Electron, electron.pw, though don’t bother going there yet. I haven’t built the website. If anyone is a talented webdev who’d like to help with that job, please contact me.

I’ve you’d a sneak peek of the next version of Electron, check out the mockup here. It’s got a new library picker, a proper tree based file picker, and resizable panes. It still needs a lot of work before it can go live, but this will give you an idea of where we are going.

Thank you, and keep on testing.

I've been posting little teasers of the CNC machine I'm working on.  It's time to reveal a bit more.

In my spare time I have been working on a tiny two axis CNC machine that will be powerful enough to move a pen around like a plotter. Future versions will be larger and handle more powerful tools, but this is a good start to work out the kinks.  

So here she is in all her glory:

She's a two axis CNC. The X axis is the lower level and the Y axis is the upper, set at 90 degrees. A future version will have a Z axis as well. The structure is made of aluminum extrusion from Open Beam. This version uses about 4 meters.  You can see the nice ABS brackets on the corners, also from OpenBeam.  

Each axis consists of a structure sitting on sliders created from roller skater bearings. For movement I'm using standard stepper motors from Spark Fun powered by EasyDriver boards.  The steppers convert rotation into linear motion through the long threadscrews. While you can spend a great deal on threadscrews, these are just standard steel all thread from the hardware store (~3 USD). Everything is bolted together with Open Beam screws, which are standard M3 6mm screws and matching nuts.

Electronics

Stepper motors have to be powered and controlled by a driver board. I'm using the open source EasyDriver from SparkFun.  There are more powerful motors and boards available, but these will suffice for version 1.  They are cheap, effective, and very simple to wire up as you can see in this photo:

Each stepper motor has it's own driver board.  The four wires go into the four motor pins of the board, labeled A1, A2, B1, and B2.  These aren't actually labeled on the motors themselves so I had to test and label them by hand.  Each board also has power and ground.  They receive more than 5V since the motors usually need more. In my case I've connected them directly to a 9V battery. This would never be enough power in production, but it's okay for testing and very portable.  I'll dive more into the EasyDriver's later, but for now just know that they can take almost any power you can throw at them and convert it safely to run your motors. 

Finally the drivers have ground, step, and direction pins connected to the Arduino, which you can see in this photo:

The Arduino code toggles the two step pins over and over, occasionally changing the direction.  That's all there is to the electronics.  Arduino and the EasyDriver make it very simple.

Now let's look at the mechanicals:

Hardware

The beams are aluminum extrusions from Open Beam. In addition to being open hardware (the schematics are available to make your own) it has a few nifty features.  Take a look at this end cut:

There is one channel per side. Each channel takes a metric M3 nut or screw.  Hex nuts are the perfect size to slide in easily and not rotate. Because these are standard sizes you can buy screws from other vendors, such as these black anodized 16mm screws I got from Amazon.

I've cut most of the extrusion by hand using a hacksaw and plastic miter (the kind used for cutting wood). Eventually I bought a cheap 6" power saw from Harbor Freight that uses cutoff disks. The final cuts are smoother than a hacksaw can produce and are done in a quarter the time. It's good enough for 60 USD but eventually I will probably upgrade to a proper miter saw with a metal cutting blade.

Brackets

The extrusions are put together using injection molded ABS plastic brackets, also from Open Beam.  I mostly use angle brackets with a few Ts thrown in.

The stepper motors are attached with Open Beam stepper brackets. These are designed to accept any NEMA 17 stepper motor and come with matching brackets for the other end.

But here is the genius part: Open Beam sells an adapter which accepts #608 roller skate bearings, which look like this:

These brackets make building a lead screw very easy. I chose a 5/16 inch all thread screw at my local department store (~3 USD). It fits inside of a roller skate bearing perfectly.  The blue stuff in the photo is the skate bearing.

Speaking of skate bearings, they are completely awesome. But that will have to wait until tomorrow.

Next Time

I'll go into the bearings and shaft coupler tomorrow, two of the most critical parts of a CNC machine. Oh, and one more question. What should I name this contraption?

I mentioned a few days ago that I updated my Canvas Deep Dive ebook and dropped the price to free. But wait, there's more! I've also completely open sourced the book. My goal with Deep Dive was always to disseminate information as widely as possible. There is no better way to do that than giving it to the world.

The source to the book is now on GitHub here.
I've created a separate repo for the example code here.
The compiled web version of the book is here.

There are several reasons I think Canvas Deep Dive is different than the other canvas resources out there. First, it is comprehensive. Starting from chapter one the reader learns what canvas is, how it works, and the basic functions for drawing shapes. From there it moves on through charts, animation, pixel manipulation, WebGL with ThreeJS, WebAudio and finally a quick introduction to the experimental webcam API. Along the way the reader is walked through hands on exercises that ensure they understand the concepts.

Second: the book is interactive. Any text in a gray box has a glossary definition. The first chapter shows off interactive code snippets. Any number in red text can be dragged to change the value and the graphics are redrawn so the reader will directly see how this code changes the output. The hands on labs have inline demos so you can compare your code with the expected result.

Now that the source to the book is out there I need your help to make it better. Any contributions are welcome, from correcting spelling mistakes to writing new chapters. When the changes are committed the entire book will be rebuilt by my Hudson server here. Periodically I will be uploading new versions of the book as app to the iPad and TouchPad app stores. I'd also like help supporting Android tablets (I'm not much of an Android developer, I'm afraid). All pull requests are welcome.

Together we can make this the best way to learn HTML Canvas.

Thanks.

Software Libraries are good. They allow abstraction and encapsulation; which encourages reuse. They also allow the library to be written by one person and used by another. This is reuse at the programmer level, not just the system level. A library can be written by a person who has domain expertise but used by someone else who has less or no expertise in that domain. For example: an XML parser. The implementer knows the XML spec inside and out, but the user of the lib needs only a basic understanding of XML in order to use the lib.

Now that we've established that libraries are good (regardless of whether are are implemented as classes, packages, DLLs, etc.), how can we extend them? Traditionally libraries are very limited in how they can influence the experience of the programmer. The coder simply has new functions to call. A more advanced case is component driven GUI builders where the lib exposes more information so that the IDE can make the library easier to use. Annotating of types in a map component could enhance the GUI builder draw markers, use a dummy tile set, and set positions. This is all standard stuff. Could libraries do more? How could the library author further influence the experience of the library user?

Let's do a quick brainstorm:

• Extend the language with new operators and syntax specific to the library. A physics library could import operator overloads to enable more math like syntax when dealing with physical units and vectors.
• Tests that verify aspects of the code that calls the library. This could automate the advice that would be in the documentation, such as "don't pass null to certain functions" or "this function returns an object that you must dispose of".
• If the lib is used from within an IDE, the lib can insert new documentation into the searchable index of docs.
• The lib could come with example code and reusable annotated code snippets that would only be applied to projects using the lib.
• The lib could insert a new package manager into the compiler toolchain. No more messing with Maven POMs.
• The lib can provide the compiler with new code optimizers for the particular tasks. An imaging analysis library could instruct the compiler on how to better use SIMD instructions when available.

Obviously modifying the environment of the programmer is a dangerous activity so we would need very strict scoping on the changes. A library which extends the language applies only in the parts of the code that actually import the library. Changes are scoped to the code which asks for them.

Fundamentally a library is a thing created by one programmer for use by another programmer (or the same programmer at a future date). We should extend the concept of a library to apply to the entire programming experience, not just adding objects and methods. This would allow all environment extensions to be managed in a standard way that is more understandable, flexible, and scoped. I would never need to set up a makefile again. I could simply import in my main.foo code the package manager, repos, code chunks and syntax that I want to use for this project. The library extensions to the compiler handle everything else automatically.

Clearly there are challenges with such an approach. We would have to define all of the various ways a library could modify your environment. How would compiler hooks actually work? Annotation processors? A function to modify the AST a different stages of compilation? Would it imply a particular back end like LLVM? I don't have the answers. There clearly are challenges to be solved, but I think the approach is a step forward from today where we have many different components of our programming environment that are dependent on each other but don't actually know about each other. Having a way to organize this mess, even if imperfect, would certainly help us make better software.

Today we are talking with Rusty Moyher, another member for the Retro Game Crunch team. You can read the previous interview with Shaun Inman here. There's still a few days left to help push the Retro Game Crunch to the finish line. Pledge now!

Josh Before we talk about the Crunch, could you tell me a little bit about yourself? Where did you go to school? What did you do before you started making games?

Rusty Sure! I got started making games pretty early. In 1993 my family received a hand-me-down computer, an old black and white Macintosh Plus. I discovered, with a program called Hypercard, I could make rudimentary games. They were far from amazing, but I had a blast making them.

Gradually I became more interested in film and started making my own movies. At Sacramento State I earned a B.A. in English because I thought it would help me write better screenplays. But it turns out you get better at writing by simply writing more.

Josh What did you do at Apple?

Rusty Fixed computers. Produced a couple internal videos too.

Josh The Kickstarter site says you are also a filmmaker. What films have you made?

Rusty Most recently, For America. It's a grindhouse flick about a man being evicted from his home by the evil banks. Naturally, it turns into a punch out.

Josh Do you think there is a lot of overlap between film and game creation? Do your skills in one cross over to the other?

Rusty I’ve spent the better part of 10 years writing, producing and directing independent films. I’ve always had a passion for creating and sharing experiences with people. My background as a writer, director and editor colors everything I do. Games are not movies (and they shouldn’t be), but both are designed as an experience.

Josh How did you come up with the idea of doing one game every 30 days for six months rather than a more traditional schedule? What are the advantages to doing it so quickly?

Rusty I've found a healthy amount of focus and pressure help me make better decisions. 30 days should give us just enough time to focus on the gameplay and then polish it for release. The idea came from making Super Clew Land. We felt 30 days was just about the right.

Josh Tell me about Bloop. What is it and where did the idea come from?

Rusty Bloop is like a Twister / Hungry Hungry Hippos love child. Two to four players tap tiles on iPad as quickly as possible. The tiles shrink and hence begin to collide. It's a hilarious party game.

The original idea for Bloop came from frustration. I was working on a more complicated iPad game. It was just too much for players to set up easily. I want a simple experience people could just play without needing to learn or set up anything.

Josh I saw it was nominated for Indiecade 2012. There's a lot of interesting stuff nominated this year. Did you expect to get recognition for Bloop?

Rusty No way! I was blown away and honored to have Bloop among so many other amazing games.

Josh Have you collaborated with others on previous games?

Rusty I’m only just discovering the Voltronian power from combining the strength of a couple like-minded Indies. Last month I made the original version of Super Clew Land with Shaun Inman and Matt Grimm. It’s been such a blast, we haven't stopped collaborating.

Josh What ideas do you have for game styles in the Retro Crunch? Can we expect platformers or other styles, or something completely new?

Rusty No way of knowing yet! Everyone who backs our Kickstarter gets to submit and vote on themes. When all the votes come in, a winning theme is declared. Then we design a game based on the theme. Only then will we discover the style of the game.

Josh What is the one existing game you wish you had created?

Rusty I would love to have worked with the team behind Super Metroid or Final Fantasy VI.

Josh What's the one question I should have asked you and didn't?

Rusty Do you have even more amazing games planned for the future? You bet. :)

Thanks Rusty

I'm not sure I'll ever be ready to tell everything about my time at Palm. Certainly not now. Perhaps in a novel or an 8bit video game, one day. I don't know. I really enjoyed my time there and made wonderful friends. It was also two straight years of frustration. For now I suggest you read The Verge's excellent in-depth article on the 31 months from Palm's 2009 CES debut to the end of the platform (and possible rebirth?). After you read it come back to compare notes. Below are some inaccuracies or clarifications based on my own recollection of events. Think of it as directors commentary if the director was forced to sit in the back and watch through a 3 inch screen.

Caution Ahead

A note to the reader. Before you continue there are three things you must keep in mind:

• I am now an employee at Nokia. The comments below reflect entirely my own opinion, not of Nokia or my team. Also note that I am not working in the Windows Phone division (or any product division for that matter) and have no insight into product plans.
• The comments below reflect entirely my own opinion. This is based on my recollection of events and personal speculation. Others have different recollections. These are mine.
• I wrote the following comments while reading The Verge's article. The thoughts are spontaneous, passionate, off the cuff, and unedited. Please adjust your expectations accordingly.

Commentary

Prima (2008). I never got a chance to see Prima. I wish I did. Sounds ugly. I was able to get my hands on a Foleo, though. Insert another epic yarn about a brilliant but doomed product. I do know that Prima was Java based, and closer to JavaME than JavaSE. It had major performance issues because it was built on some wonky embedded JVM they got from a small company (I don't know who) rather than a proper JITed VM like HotSpot and JavaSE Embedded (though that wasn't a shipping product from Sun at the time these decisions were being made).

Prima's JVM at CES 2009. Yes, it was still there running some system services. Those lasted until around the time of WebOS 2.0, towards the end of 2010 as I recall. There were always references to it in the open source code dumps which is why people kept asking me if webOS supported Java. It never did in any way that a developer could actually use. That JVM also sucked up way too much memory, making a lot of system services dog slow.

CES 2009 This is the event which sold me on Palm. When I met Ben and Dion in Sweden to discuss working for Palm later that year this was the event I watched and analyzed to see if I truly wanted to work for Palm. The polish and practice was really amazing. If you haven't seen it you should watch it. It even made up for the truly horrible TV ads Palm later aired.

The de-Mercerization to create Blowfish: I don't know the details of exactly how Blowfish was built. Engineering was very closed off to us (Developer Relations). It was like pulling teeth to get information about them. I learned a whole lot by searching JIRA bugs and watching commit logs, however. Blowfish turned into a classic Fred Brooks "Second System Effect" death march. The release stretched on and on. Things which worked previously were broken and never fixed. Testing started to fall by the way side. Quality declined and the release kept slipping. In the end we missed an entire product cycle. This probably doomed us more than anything else.

2010 This when I joined. The Droid campaign had already screwed Palm (or Palm let itself be screwed by placing so much fait in a a carrier). Verizon promised to support the Pre Plus but it turns out that support didn't extend to the actual employees in the retail store. In the US, at least, a phone lives or dies by the retail staff in the carrier stores. Nothing else matters. Not price. Not features. Not apps. If the retail staff doesn't like you... you die.

Anyway. I'd been at Palm for only a few months when the HP deal was announced. I still feel it was the best decision. The smart phone game of the early 2000s changed forever after the iPhone. It was now a rich man's game. Palm was against companies literally 10 times it's size. To create a viable smart phone platform today you have to be prepared to spend about a billion dollars a year. Palm was simply too small. HP had the size and the cash, and a desire to not just be a Windows OEM forever. It was by far the best option. (All other options would simply have liquidated us). But the best laid plans of mice and men…

Leo: Well…. We will never really know what happened inside Mr. Apotheker's mind when he decided to cancel all webOS hardware. Did he not have the stomach for a billion dollar a year run rate? Did he never really want to be in the consumer business? Was his talk of "doubling down" a lie all along? We will never know. It was clear then and now that he never believed in the webOS vision. Perhaps if Hurd had not left history would have gone differently. At the very least the TouchPad would have had the chance to develop into the strong product it could have been. We were, for a brief time, the #2 tablet in the US.

Greg Simon: It really hit me hard when Greg Simon left. He was the only one who was getting my graphics bugs fixed! We had no hard specs for what our Canvas and CSS graphics output should be so I made it my personal mission to write tests for every missing feature of the spec and then push to have them implemented. For a long time Greg was the only guy who could help me. He's the one who implemented CSS gradients for me.

TouchPad hardware: One thing I don't see mentioned is that the hardware design for the touchpad came from HP. It was designed before the acquisition and originally ran Android. That's why you'll occasionally hear rumors of a touchpad the shipped with Android on it. That's also why the specs were a bit anemic when it shipped over a year later.

So ultimately the question is why did the TouchPad fail in the market place? The software was definitely buggy, but we made pretty rapid improvements in the update releases. The iPhone was buggy when it launched but got better very quickly. The hardware specs were considered anemic, but really it should have been flying with a dual core 1.2ghz proc. The immature software held it back. My only real complaint about the hardware was the weight and the lack of a camera. The 7" Opal / TouchPad Go would have solved the camera issue but it was still too heavy. The other big issue was the price. It should have gone out the door at 399 or lower, even if we would have lost money for a while. We didn't have a comparable product to the iPad, so we shouldn't have priced it as such.

So why did it fail in the market place? Actually, I question that assertion. Clearly we weren't selling as well as the iPad but based on anecdotal evidence we were selling more than any Android tablet. One Best Buy employee told me the iPad sold about 10 units a day a his store while the TouchPad sold two a day. The other tablets (Android and BlackBerry) were lucky to sell one a week each. While Samsung may have shipped millions of tablets they later admitted that most of them were never actually sold to end customers. We were the #2 tablet even before the fire sale. A weak #2, but still #2. Not bad for a 1.0 product. If we continued working on the software, pushing out consistent updates, and shipped the Opal then we would have gone into the Christmas season with a strong momentum.

I will say this for both Apple, Google, and Microsoft. They go in big and they don't give up. They take the long view; steadily improving their products over months and years. Spending heavily on advertising then giving a product only six weeks in the market is *not* long term thinking. If HP was only going for a quick buck then webOS would never have survived, whether or not Leo was at the helm. This is a game for the rich and patient man.

So then why was the TouchPad canceled? As I said, we will never know. Perhaps the sales projections weren't realistic. But we do know that the *way* it was killed was designed to be irreversible. The press release announcing cancelation took everyone by surprise, including our partners. AT&T refused to carry the Pre 3 just before it was scheduled to go on sale. The Opal was canceled just days before it would have gone into production for a release in late September. Once you scupper a supply chain that way it takes at least a year to rebuild. The damage was irreversible. Even if Leo had been fired a week later and Meg reversed the decision, it still was too late. And it was that supply chain which cost most of the two billion dollar write down HP had to take later. I sometimes wonder if it would have been cheaper to build the TouchPad Go anyway and still sell it for 99$ like the TouchPad. In any case, the decision was made and it was immediately final.

Of note: when Meg Whitman was asked in an all-hands meeting how the board could have voted for such a decision, she said the board was "informed" of the plan, not consulted. No vote was required or taken.

Post cancelation stasis: my biggest memory of that period is when we were scheduled to go on a three stop tour of Asia (Australia, Singapore, and Bejing) to excite developers about products that now would never ship. In the end we made the trip because Richard Kerris (head of devrel) felt it was important to meet our developers on their own terms and be honest with them. It was both an interesting and awkward experience. I'm glad we did it.

Meg Whitman. During my final months at HP, Meg was refreshingly honest. She took her time to make the decision, but honestly we had plenty of time after the hardware cancellation. A few months either way would make no difference, and she had bigger fish to fry (like the PC division). In the end I think she made the best decisions possible under the circumstances. I wish her and the rest of HP well. I do not envy the work ahead of her.

Sam Greenblat & Martin Risau: I ramped down my travel after my son was born so I only came into the office twice after the cancelation. I only met each briefly. They both seemed smart and competent but had different visions of what Open webOS would be. It doesn't surprise me that there were conflicts.

Other tidbits:

• There was other hardware in the works beyond the TouchPad Go. I saw prototypes of many products including a transforming tablet / netbook combo with an ingenious sliding hinge and super thin keyboard. I really hope someone makes it one day.
• On "competing for #3" Yes it would have cost us billions of dollars over a bunch of years, but I think we would have been #2, not #3. It has been nearly a year since the TouchPad launched and Android tablets are still failures. I think there is a lesson in here for us: without a carrier and contract pushing them, Android devices don't sell themselves.
• WebKit: Using WebKit for the GUI was pure genius. Forking Webkit so you couldn't take advantage of community improvements was pure stupidity.

Oh. and the Palm V is still the best PalmOS device ever. It was the perfect size to fit in a shirt pocket, had a beautiful and unique shape, and was made of good metal materials. And the battery would last forever. It was an iPod Touch ten years early.

Post Mortem

I am still very proud of what we created, especially my teammates in Developer Relations. The TouchPad launched essentially on schedule and had a solid over the air update. We opened the catalog with 10k webOS apps and 600 specifically for the TouchPad. That put us ahead of the number of Android Tablet apps at the same time, even though we shipped 6 months later. We continued to increase the number of apps in the catalog even after the hardware was canceled. We ran fun developer contests and promotions. Our developer community was always been passionate and appreciative, even in the times when we weren't allowed to say much. I'm glad we were able to open source Enyo in a way that lets those developers take their apps to other platforms.

Post Post Mortem

It has been nearly a year since the webOS hardware was canceled. A year that has afforded me some perspective. I left HP not because I didn't enjoy my time there. My reasons were more personal. After seven years of being a technical evangelist for Java, JavaFX, the JavaStore, and then webOS; I was simply tired. Tired of putting emotion and energy into platforms. Tired of the travel and speaking engagements. Tired of the constant product deadlines. Combined with having a (now) one year old child I realized I needed a break.

My current position requires little travel, has a flexible schedule, and lets me work on interesting things not tied to any particular platform. Best of all a specifically *can't* talk about what I'm working on. Perhaps one day I will return to platform evangelism. I still enjoy it. But for now I'm in a nice peaceful place.

Thank you for taking the time to read my tiny part of this epic tale. One day it will truly be the stuff of valley legend.

Yesterday Apple updated their Apple TV product, taking it into a new direction with a 99$ TV dongle that does only content streaming. Apple has long described Apple TV as a 'hobby' because they haven't figured out the right way to create a compelling TV product. Since they've spent millions of dollars building up a new data center in North Carolina to support the streaming catalog of the new Apple TV, then presumably they think they've got it figured out now.

I actually think Apple is wrong. I think Apple TV is a failure and will continue to be a failure for one simple reason: it goes against the design philosophy of every one of their successful products.

Now, yes, I realize thems fight'n words; but hear me out.

At it's core Apple is a software company that makes money by selling hardware. Mac OSX is an amazing operating system that they monetize by selling high end laptops & desktops. iTunes and the iPod OS are great pieces of software that they monetize by selling iPods. iOS is a great mobile operating system that they monetize by selling high margin iPhones and iPod Touches.

The Apple TV

And then there's the Apple TV. It is a piece of hardware that does very little. When originally launched, the Apple TV streamed music, videos, and photos from your desktop; but there are plenty of cheaper alternatives that are just as good. If you hack the Apple TV you can install your own software to make it do all sorts of cool things, but as a stock device directly from Apple it doesn't do much. Apple updated it with a new interface that added the ability to buy music and video directly from Apple's catalog. In other words, they added nothing except the ability to pay them more money.

Yesterday Apple updated the Apple TV once again to do the exact same thing in but a smaller, cheaper package. In some ways it does less since the hard drive is gone and it's likely harder to jailbreak into a useful product. It is now purely a 99$ catalog for the iTunes Store. I'm sure in Apple's mind this is a win. It can do exactly what the previous version did for less than half the price. Surely that's a win, right?

I don't think so.

Monetizing Software Through Hardware

Apple is a software company that monetizes their software through hardware. The Apple TV is a hardware product that is monetized through a streaming media service. It's fundamentally a different kind of product. Services has never been Apple's strong point (cough *MobileMe*), and this product is just a 99$ access device to their catalog service. It still could be successful thanks to their focus on user experience, but I think it will remain a failure because of another point.

Most people don't want another streaming media service on their TV. I love Hulu Plus and I happily pay 10$/mo to get it, but I watch Hulu on my laptop. I don't own a TV, and that makes me a rarity. Most people have very nice large TVs and already pay upwards of 40$/mo for TV service. They don't really want something which costs extra to do what they already are paying for, no matter how small and cute the box is. Apple TV doesn't provide anything new. It competes with something consumers are already quite happy with but doesn't offer everything the existing product provides. This doesn't sound like a recipe for success unless they can get all of the networks on board to massively beef up their content. Even then I'm not sure it will work because most people really like an all you can eat plan for TV. They don't want to pay by the show.

A Good Apple TV

Now that I've denigrated the Apple TV, lets talk about what would be a compelling product: an Apple TV with apps. Essentially an iPod Touch for your TV.

The modern flat screen TV is the largest and most expensive display in most homes, and yet it's wasted. All we do with them is play video. These displays could do so much more with the right input devices and, most importantly, a good app ecosystem. Here's just a short list of apps that would really add value to a flat screen TV:

• specialty photo slideshows. Turn your TV into an art gallery
• music driven lava lamp display to run during music sessions
• an interactive billboard to combine fun graphics with a live Twitter stream
• widgets: weather, stocks, rss news feed, world clocks, and your calendar
• zen space: a underwater simulation with soothing sound and lights
• games (duh!)
• Video conferencing

I actually think Sony and Microsoft are far closer to creating this vision than Apple is. Both of them have network connectivity, downloadable apps, and are releasing unique forward looking input devices. Microsoft's Kinect in particular shows promise. With the right software your TV becomes this portal to the world that brings interactive content and apps to your living through purely through an intuitive gestural interface.

That vision is far more forward looking and interesting than Apple's; where all they've sold you is pricey a catalog for their own store. And in my mind, that's a big fat fail.

A round up of interesting stuff I've been collecting lately. An interview with Philippe Starck, vintage ads, UI design tips, and electronic comics.

Philippe Starck

Last fall Engadget did a short interview with legendary designer Philippe Starck. Wonderful insights on the world of design and creation.

Also check out the bonus round of word association with Philippe.

eComics

The most interesting ebook applications to come out of the iPad hoopla is actually the comic book readers. Most readers seem to treat ebooks just like books and focus on recreating the experience of reading a printed book, complete with faded paper and page curls. Only the comic book apps seem to be exploring new forms of interaction, stealing liberally from cinema. Kicker Studio has a great overview of the cinematic reading of electronic comics.

UI Design Tips

Flyosity has a great article on Crafting Subtle & Realistic User Interfaces. Starting from the basics of light it goes through using borders, gradients, and highlights to create the illusion of depth.

Advertising Through the Ages

A great Flickr set of ads from the fifties. I just love the style from that era.

The Evolution of Print Advertising. What it says on the tin: a brief history of ads from the 1760s to the present. I love how in the 70s even banks used psychadelic imagery.

The twit-o-sphere came alive last week with the news that Adobe is canceling their Flash for Mobile products. I even briefly joined in.  Many see this as evidence that the open web has won (it has), or a justified comeuppance for Adobe's historical slights to Apple (it might be), or perhaps vindication of Steve Jobs' rant anti-Flash (it was), and maybe even that Microsoft was really to blame (it's a stretch).  Lost in all this, I wonder, is the effect this actually has on Adobe beyond their short term problems.

Lets step back a minute and consider what Adobe actually does.  They have some enterprise backend products for document management and (amazingly still used) a server side platform in Cold Fusion.  They have some cloud products (Acrobat.com) built on the the Flash platform. Then there is Flex, an enterprise application platform designed to steal Java developers from Sun, as well as a mobile advertising and analytics platform (Omniture). And of course Flash for mobile.

Oh yeah. And they also make Photoshop, Illustrator, Fireworks, and a bunch of other industry leading graphics and content creation tools so pervasive that some have called them the Adobe tax.

This really sounds like two different companies, doesn't it?  I'm not exactly sure when, but at some point Adobe strayed from focusing on high quality content creation tools for designers and artists. They entered the "platform space": trying to be an enterprise company, a software as a service company, and own the mobile content market.  That's a whole lot for any company to do, especially one who traditionally focused on content creation tools.  In the end I think it just became too much for one company to do, and it takes away from the thing they are good at: killer tools for designers.  If killing of mobile flash lets them focus on their core competency then this is a good thing for everyone.

Adobe is known for tools used by professionals to create content. The Flash designer tool is used by professionals to create animated interactive content. Currently, the format of the final output is a SWF file. Do the purchasers of this tool care? Not really. Flash designers want to create content that is viewable by the most people. The audience wants great content accessible from the most devices. Neither of these two groups of people gives one whit about the actual format of the bits.  Flash, the runtime, was simply an end to a means.  With HTML 5 technologies becoming viable for interactive animated content, the Flash designer tool can simply output a new binary blob to be uploaded onto web servers.  The designers won't care, the audience won't care.  Everyone will get on with making/viewing their content and Flash Designer CS 22 will sell millions of copies.  This really isn't a big deal.

Well, except for one group of people who really truly do care about mobile Flash: the makers of iPad competitors. Apple's refusal to allow Flash onto the Safari mobile browser created a market opening for a device that *would* play Flash.  While it was never a big factor for webOS, it was a flagship feature for the BlackBerry Playbook and various Android Tablets.  They've now lost a checkbox in their feature war with the iPad.

No matter. The world will move on.  The mobile web is built on HTML 5 standards. And in 5 years the mobile web will simply be the web; which may foretell the end of the desktop Flash plugin as well, but the end result is the same. Adobe will continue to sell world class content creation tools. Tools which output whatever format the world actually wants. And now, finally, the world wants HTML 5.

Long Live the Web. Long Live Adobe.

Teach them well and let them lead the way

The Status Quo

Last summer I released Leonardo, a cross platform vector drawing tool. Later in the year I released an alpha of Amino, the new Java UI toolkit I wrote in the process of building Leonardo. Since then I've released updates for both, but haven't quite reached a 1.0 for Amino. It's time for some changes: Amino 2 and Amino.js.

Overall I've been pretty pleased with most of Amino. It is reasonably fast, pretty skinnable, and has a very clean API with generics, an event bus, and isolated models. The underlying graphics stack, however, is a mess. Originally I planned to build a second graphics stack on top of JOGL, but it's never worked properly (you can still see the disabled code in the repo). Amino has a basic component tree structure built on a Java2D wrapper but for a modern UI toolkit we need more. We need a real scene graph. Something that has animation and transforms built right in. A library fully isolating the app from the underlying graphics, with framerate and buffering control. Without a real scenegraph Amino will never work well on top of JOGL.

Modern Graphics Research

You have may noticed a slowdown in Amino and Leo commits. That's because I've spent the last few months researching modern hardware acceleration and teaching myself OpenGL Pixel Shaders. (Oh, and traveling around the world, announcing new products, and getting ready for my first baby to arrive in May). After all of the research I've come to a few surprising conclusions (surprising to me, at least).

First, on modern GPUs memory usage and bandwidth are the bottle necks, not drawing speed. In the realm of 2D graphics, at least, our biggest headache is managing the data structures and shipping them up to the GPU. The pixel shader units themselves are far faster than what we need. It's often much better to send a tiny amount of information over the bus and use an inefficient algorithm in a pixel shader, rather than do it on the CPU and upload a texture.

Two: OpenGL sucks for traditional 2D drawing tasks. Sure, it's great at compositing, but the actual line and polygon routines are primitive if you want antialiased shapes and smooth compositing. There's a whole lot of stuff we have to rewrite by hand on the CPU or re-implement with shaders.

Three: on platforms without accessible GPUs we can do lots of tricks to speed up apparent drawing speed. Reponsiveness and consistency matter more than raw drawing speed. And if a GPU is available, then we can efficiently cache portions of the drawing as textures and use the GPU for compositing. All of this is hard to do in a reusable way without a real scene graph to build apps on.

Four: Web and mobile apps need a scenegraph as well. For a long time I've mainly thought of web apps as UIs built with static images and text. However, in the last year HTML Canvas has come a long way. Games with sustained 60fps are quite possible in recent builds of Chrome, and mobile devices are catching up as well. (I'm amazed with what I've been able to do on the upcoming TouchPad). So, if we are going to put high powered UIs on web technology, then we need a real scene graph.

Amino 2: The New Plan

I've decided to start a new branch called Amino 2. The current Amino will be split into two parts:

• Amino Core, the scenegraph, event bus, and common utility classes
• Amino UI, the UI controls and CSS skinning layer

Amino Core will have multiple implementations. First, a scenegraph for desktop Java apps that will use a mixture of Java2D and JOGL. Eventually it may be possible to do full anti-aliased shape and clip rendering with pure shaders, but this is still an open area of research. For now we will do the shape rasterization in software with the existing mature Java2D stack, then do compositing, fills, and effects on the GPU with shaders. Over time we may shift more to the GPU. With a scenegraph this will be transparent to the app developer, which is a very good thing.

Announcing Amino.js

Amino GFX will also have a second implementation built in JavaScript and HTML Canvas. I'm calling this Amino.js. It will let you build a scene graph of shapes and images, complete with declarative animations and special effects, all drawn efficiently into the a canvas on your page. Amino.js will not have the CSS and UI controls layer, because that stuff is already well provided my many existing JavaScript libraries. There's no point in making new stuff where it's not needed

I've also considered making a pure in memory version of the scenegraph without any Java2D dependencies, or porting it to a pure C++ lib on SDL or OpenGL. However, these requires a lot of research into rasterization algorithms so I'm not going to work on them unless someone really wants it.

Next Steps

That's it for today. I've built a prototype of Amino.js and over the next few weeks I'll show you more of the API and walk through it's construction. I hope you'll find it interesting to watch as the pieces come together, and any code contributions will be very welcome. Come back next week for some code samples and I'll dive into a puzzle game prototype called Osmosis. Here's a few quick demos to whet your appetite.

Animated bar chart

draggable scene nodes

Simple particles at 60fps

Oh, and I forgot to mention that Amino2 and Amino.js will again be fully free and open source. BSD for the win!

The Web is amazing for answering questions. Suppose you want to answer a question like, "what does the .JPG file extension mean", then the answer is just an internet search away. Millions of answers. However, if you stray from the common path just a tiny bit things get hairy. What if you want to get a list of all file extensions? This is harder to find. Occasionally you might find a PDF listing them, but if you are asking for all file extensions then you probably want to do something with that list. This means you want the list in some computable form. A database or at least a JSON file. Now you are in the world of ‘public’ data. You are in a world of pain.

Searching for “list of file extensions” will take you to the Wikipedia page, which is open but not computable friendly. Every other link you find will be spam. An endless parade of sites which each claim they are the central repository of file extension data. They all have two things in common:

• They are filled with horrible spam like ‘scan your computer to speed it up’ and ‘best stock images on the web’ and ‘get your free credit report now’.
• They let you add new extensions but don’t let you download a complete list of the existing ones.

What I want is basic facts about the world; facts which are generated by the public and really should belong to the public. And I want these facts in a computable form. So far I cannot find such a source for file extensions. These public facts, as they exist on the internet, have morphed into a spam trap: vending tiny bits of knowledge in exchange for eyeball traffic. These sites take a public resource and capture all value from it, providing nothing in return but more virus scanner downloads. That they also provide so little useful information is the reason I have not linked to them (though they are obviously a search away if you care).

The closest I can find to a computable file extension list is the mime type database inside of Linux distros. This brings up a second point. Every operating system, and presumably web browser, needs a list of all file extensions, or at least a reasonable subset. Yet each vendor maintains their own list. Again, these are public facts that should be shared, much as the code which processes them is shared.

File Extensions are not the only public facts which suffer the fate of spam capture. I think this hints at a larger problem. If humanity is to enable global computing, then we need a global knowledge base to work from. A knowledge base that belongs to everyone, not just a few small companies, and especially not the spammers.

Wikipedia and it’s various data offshoots would seem to be the logical source of global computable data, yet the results are dismal. After a decade of asking, Wikipedia’s articles still aren’t computable in any real sense. You can do basic full text search and download articles in (often malformed) wikimarkup. That’s it. Want to get the list of all elements in the periodic table? Not in computable form from Wikipedia. Want to get a list of all mammals? Not from them. Each of these datasets can actually be found on the web, unlike the list of file extensions, but not in a central place and not in the same format. The data offshoots of Wikipedia have even bigger problems, which I will address in a followup blog.

So how do we fix this? Honestly, I don’t know. Many of these datasets do require work to build and maintain and those maintainers need to recoup their costs (though many of them are already paid for with public funds). If this was source code I’d just say it should be a project on GitHub. I think that's what we need.

We need a GitHub for data. A place we can all share and fork common data resources, beholden to no one and computable by everyone.

Building and populating a GitHub for data, at least for these smaller and well defined data sets, doesn't seem like a huge technical problem. Why doesn’t it exist yet? What am I missing?

or: "Why I won't work for a social network."

I've had a lot of ideas involving social networking floating around in my head for the past few months. They were finally crystalized into a solid conclusion this week: I don't want to work for a social networking company. There are really two distinct but related problems with social networking companies, and combined they form a deal killer for me.

First: they are free. With the possible exception of dating sites, social networking services are free. They do everything in their power to get as many people to sign up as possible. Due to the network effect they really can't charge admission. It's not worth money to join the network until lots of other people are already on it. Combined with the economics of VC funding, the cost of joining is always driven to free. You should always be nervous when someone offers you something for free.

If a service is free then one of three things will happen. The service might charge in the future. This is a valid strategy but likely to piss off lots of current users. Next, the company could simply run out of money one day and shut down. Many great sites have simply died due to a lack of a viable business model. And finally, the site could remain free but make money doing something else; which, in the social networking world, means advertising.

Facebook doesn't charge you money because you aren't the customer. The advertisers who buy your eyeballs are the real customer. This creates an inherent conflict of interest. They serve the advertisers over the users. The users still matter somewhat since without users there would be nothing to sell, but there is a constant tension between the two. Still, this wouldn't be so bad if it weren't for the second problem: scarcity

Fundamentally social networks are selling the users' time, and time is the ultimate scarce resource. The only way for a social network to grow is by getting more users or getting more time out of their existing users. There are only twenty four hours in a day and only a certain number of people on the planet. Recent polls indicate that social networks are reaching saturation in developed nations. Most of the people who want to use a social network are already doing so, or will in the next year or two. Without new users social networks must maximize the time they get from each individual user. This is where things really start to get bad.

To further their growth Facebook has an incentive to optimize the number of ads you see per page, and the number of pages you see per day. They constantly look for ways to bring you back to the site and spend more time interacting with it. I call this the Zyngafication of content, after its most famous implementor. I stopped playing Cafe World when I ran the numbers and realized there is no strategy. You can't design a particular cafe or food item that will maximize profit. The most profitable food in the game was (as I recall) a 3 minute appetizer. The point values of foods are weighed to maximize the number of minutes you have to actually spend playing the game per day. Their incentive structure is designed to suck up as much of your time as possible.

Long term this can't be sustainable. As free services try to maximize their profit the number of ads per page will increase, and the number sneaky ways they get you to stay on the site longer will only grow. The user experience will suffer and eventually users will leave. What we need is a system that treats our most valuable resource, time, as something to be conserved instead of wasted. I suspect this is fundamentally incompatible with an advertising driven model. And I don't want to work for a company who's business model requires reducing the user experience.

So this brings up a fundamental question: Would you pay to use Facebook if it let you accomplish things more efficiently instead of less? What about photo sharing? Is there a viable model for paid social networks and services?

The past two years have been a hell of a fun ride, but alas it must come to an end. It is with sadness but no regret that I must announce Friday will be my last day at HP / Palm. This was a very difficult decision to make. I have enjoyed my time here and after seeing the webOS roadmap I'm very excited for it's future, but it is time for me to do something else.

I am extremely proud of what the webOS Developer Relations team was able to accomplish. We kept the community together through several big platform changes and managed to launch the TouchPad with more native tablet apps than Android had after six months. Even after the webOS hardware was canceled we still managed to grow the app catalog to more than a thousand apps. Recent numbers indicate that our USA Today app has twice the number of downloads as all Android tablets put together. I'm proud of what we built with fewer resources than our gigantic competitors.

Sadly, webOS is a failure as a retail product, at least in it's current incarnation. There are many reasons for it's failure ranging from poor marketing to the ravings of a lunatic. Perhaps one day I will write more on the topic, but for now I will let the past be past. webOS has a new future as Open webOS, but one that I must cheer from the sidelines. It is time for me to make some changes in my own life.

I have spent the last seven years championing underdog platforms. Starting with desktop Java and Swing, then NetBeans, the JavaFX platform, and the JavaStore. Finally I spent the last two years doing my best to make webOS a success. I'm proud of the work I've done and the platforms I've helped, but quite frankly I'm damn tired. It's a lot of fun to champion something you are passionate about, but also exhausting. And since Jesse arrived I no longer want to be a platform evangelist; traveling to conferences and staying up late for weeks to ship a product. My life is simply different now.

So March 12th I will be taking a research position at Nokia. I will get to play with cool future stuff and stay involved with the industry, but at a much slower pace. I simply need a break for a few years. This doesn't mean I will disappear. Rather I plan to increase my blogging, but on a wide range of topics in more long form essays.

I do plan to stay involved with webOS. Now that I'm no longer an HP employee I can actually sell my own apps in the app catalog. I will also keep working with Enyo and the Open webOS builds; and making sure Amino and Leo support them. I love my TouchPad and will continue to use it until they pry it from my cold dead hands.

I want to mention my incredible fellow Developer Relations crew members, some of who were laid off today. And my eternal gratitude to the amazing webOS community. You made all of our hard work worth it.

Today the other shoe dropped. Fortunately it was a soft slipper, not the steel toed boot to the head I had feared. HP is open sourcing webOS.

What does this mean? Well, I honestly don't know yet. There is a huge amount of planning to be done, but it could be the start of something great. We will have to see. It will be a busy Christmas, that's for sure.

In the meantime I'm working on a few other projects that I hope to share with you soon. Stay tuned. Thanks!

- josh

I've always wanted a magic wordprocessor. Something that helps me organize my thoughts and build ideas organically, rather than spend all of my time worrying about formatting. Something for the internet / cloud age. Given that Microsoft Word hasn't fundamentally changed in over a decade (or possibly two), we aren't likely to get such software from them. Instead, I decided to play around with some ideas using my new favorite programming tool: OMeta.

OMeta

OMeta's story starts with compilers. Compilers are built of many phases: lexing, parsing, applying optimizations, then generating machine code. OMeta's creator, Alessandro Warth, realized that these are all essentially the same thing, pattern matching. The only difference is whether you are matching a stream of characters, tokens, or parts of a tree. Alex created a single language that lets you match over objects (ie: anything) to implement all parts of the compiler using a single tool.

OMeta is that single tool: a domain specific programming language for creating pattern matchers. More properly, it is a language extension that can be laid on top of an existing host language. I am using OmetaJS, an extension to JavaScript. The wonderful thing about OMeta is that it's easier to use and extend than dedicated parser generators like Antlr or Yacc because you always have the host language available to do whatever computation you need.

Editor Demo

As my first experiment with OMeta, and new wordprocessors, I created a simple Markdown editor. You type raw text into the left side of the screen and see your properly styled text on the right side. But this editor has a trick up it's sleeve. You can type simple math expressions inside curly braces the editor will evaluate it for you.

Play with the editor here

Here's what the OMeta code looks like:

ometa Foo {
    //white space
    toEOL = (~seq('\n') char)*:t '\n' -> t.join(""),
    
    //headers
    h1 = "#"   ' ' toEOL:t -> tag("h1",t),
    h2 = "##"  ' ' toEOL:t -> tag("h2",t),
    h3 = "###" ' ' toEOL:t -> tag("h3",t),

    
    //paragraph
    paraend   = seq('\n\n'),
    para      = (expr|strong|em| (~paraend char))+:t -> tag("p",t.join("")),
    text   =      (~seq('\n\n') char)*:t      -> t.join(""),
    strong = "**" (~seq('**')   char)*:t "**" -> tag("strong",t.join("")),
    em     = "*"  (~seq('*')    char)*:t "*"  -> tag("em",t.join("")),
    expr    = "{"  exp:t "}"  -> tag("b",t),
    
    //code block
    codeblock = fromTo("```\n", "```\n"):t -> tag("pre",tag("code",esc(t))),
    
    //inline expressions
    num = :n -> parseInt(n),
    term = num,
    expadd = term:a "+" term:b -> (a+b),
    expmul = term:a "*" term:b -> (a*b),
    expsub = term:a "-" term:b -> (a-b),
    expdiv = term:a "/" term:b -> (a/b),
    exp = (expmul|expdiv|expadd|expsub):e -> (" "+e+"") ,
    
    //pull it all together
    line = space* (h3|h2|h1|codeblock|para):t space* -> t,
    top = line*,
    
    END
};

This editor only understands simple two term arithmetic but it could easily be expanded with variables and more complex functions.

Richard Kerris leaving HP for "an opportunity outside"

Hot on the heels of my Canvas talk at OSCON (which went very well. Much thanks to everyone who attended), I've put up a post on the developer blog about the great new Canvas stuff in webOS 3.0.  Most importantly, speed has been doubled for certain drawing operations! I'm very proud of the graphics team here at Palm.

You can read the full description of the changes here.

- Josh

Vacation and travel is over and I'm happy to say things are moving again. I'm feeling refreshed and I have a lot to share with you in 2012; starting with the new book I'm writing for O'Reilly! Read on, MacDuff.

The Book

I've been working on a new book for O'Reilly, tentatively titled Building Mobile Apps in Java. I mentioned it briefly on Twitter but haven't gone into the details before. It will show you how to use GWT and PhoneGap to build mobile apps. With these two open source technologies you can code in Java but target pretty much any mobile platform such as iOS, Android, and webOS.

The book will cover the technical aspects of using GWT & PhoneGap. It will also dive into how to design for mobile. Navigation and performance varies greatly across devices, so it's an important topic. Oh, and the last chapter will show you how to make a mobile platform game with real physics. Tons of fun.

Building Mobile Apps in Java will be an eBook about 60 pages long, available every where O'Reilly publishes their ebooks. Look for it in February or early March.

Open Source and Speaking

For 2012 I want to spend some time doing more actual design work. I'm planning a new hand built wordpress theme for my blog, including proper phone and tablet support. I also have a few art side projects that you'll get to see later in the year.

And speaking of design, I have new significant releases of Amino and Leonardo Sketch coming. If you are in the Portland area come to the January PDX-UX meeting. I will be presenting how to do wire framing with Leonardo Sketch. I'll give a brief overview of Leo and show off some of the great export and collaboration features.

I will also be doing a 5 minute Ignite talk in Portland on February 9th about the future of ebooks and what a Hogwarts Textbook would look like.

Onward!

Finally, I plan to post both more and less on this blog. I used to do short posts on small topics or collections of links. I found social networks better for that thing so I'll do that on Twitter and Google Plus from now on. From now on I want to use the blog for more long form content such as my well read HTML Canvas Deep dive. Look for more long essays on canvas, app stores, and technology trends this year.

2012 is finally here!

It would be an understatement to say that the last year has been busy. With having a baby, launching and then 'unlaunching' the HP TouchPad, lots of conferences, and pushing out several open source project releases it's just been one heck of a crazy time. Throughout it all I've tried to continue blogging, though not as consistently as I would like. I thought it would be interesting to review the blog stats for the year and see what was actually the most popular posts rather than what I thought they were. The results may surprise you. They certainly surprised me.

Traffic has grown for Josh On Design in general. At the beginning of 2011 I was averaging around 20-30 hits per day. For December the daily average is around 180. So that's quite a significant jump. However it doesn't account for the nearly 50k hits of the entire year. A good portion of that came in two spikes at the end of September and the middle of October. See the anomaly in this chart:

Those two spikes represent when I was linked by heavily trafficked news sites: Reddit and YCombinator's Hacker News. These links are attributed to one piece of content: the notes and exercises from my HTML 5 Canvas Deep Dive workshop that I presented at OSCON in July. In fact, the canvas article accounts for nearly half of all hits I've gotten for the entire year. So, lesson number one: quality deep technical content is greatly appreciated.

The #2 hit is the main page of my blog, which doesn't really tell us anything. #3 is my post about refactoring Amino with 1700 hits. Note that even though this is #3 it's still only 3.69% of the total for the year. What this tells me is that my blog has a very long tail. Only the canvas deep dive is significantly more popular that the rest of the site.

#4 four is a post about my App Bundler project which lets you easily build native Java exes for a variety of platforms. #5 and #6 are more posts about Amino.. This surprises me because Amino doesn't seem to be used very much in practice and the mailing list traffic is minimal, yet posts about it seem to be popular. Perhaps it's a big hit with my Twitter followers.

With 898 hits Typography 101 is the seventh most popular post. This is the first one that doesn't surprise me. I figure reference material will generally pick up a lot of hits over time as people find it through Google. The two articles Future of Desktops and Design of the Workstation OS and Why 2014 won't be like 1984 are rant essays about the industry. I'm not surprised that they were in the top ten since controversial topics seem to always get hits. Finally UI Design Assets and Tools rounds out the top ten with 676 hits for the year.

Overall I'm happy with the blog traffic. Considering I haven't had much time to work on it, especially since Jesse was born, I think it's doing pretty well. I expect traffic to rise significantly early next year when my O'Reilly eBook is published (which reminds me that I've got more editing to do).

I'm officially on vacation today and will be offline for the next three weeks. I've got much needed baby time awaiting. I'll see you in 2012!

You may be a new programmer, or a web designer, or just someone who's heard the word 'RegEx', and asked: What is a Regex? How do I use it? And why does it hurt my brain? Well, relax. The doctor is in. Here's two aspirin and some water.

What is it doctor?

Oh, it's two parts hydrogen and one part oxygen; but that's not important right now. We're here to talk about RegEx. RegEx is short for Regular Expressions, but that's also not important right now. Regexs are just patterns for matching bits of text. Whenever you hear RegEx, just think: pattern. In fact, I'll stop using the word regex right now, since it mainly sounds like the kind of medicine you'll need after trying to write a complex regex.

What are these patterns they good for?

Patterns are mainly used for three things: to see if some text contains the pattern (matching), to replace part of the text with other text (replacement), and pulling out portions of the text for later use (extraction). Patterns contain a combination of regular letters and special symbols like ., *, ^, $, \w and \d. Most programming languages use pattern matching with a subset of the Perl syntax. My examples will use JavaScript, but the same pattern syntax should work in Java, Python, Ruby, Perl, and many other languages.

Matching

Suppose you want to know if the text "Sally has an apple and a banana." contains the word 'apple'. You would do it with the pattern 'apple'.

var text = "Sally has an apple and a banana.";
if(text.match(/apple/)) { console.log("It matches!");
}

Now suppose you want to know if the text begins with the word 'apple'. You'd change the pattern to '^apple'. The ^ is a special symbol meaning 'the start of the text'. So this will only match if the 'a' of apple is right after the start of the text. Call it the same way as before.

var text = "Sally has an apple and a banana.";
if(text.match(/^apple/)) { //this won't be called because the text doesn't start with apple console.log("It matches!");
}

Besides the ^ symbol for 'start of text', here's some other symbols are important to know (there are far more than this, but these are the most important).

$ = end of the text
\s = any whitespace (spaces, tabs, newlines)
\S = anything *but* whitespace
\d = any number (0-9)
\w = any word (upper & lower case letters, numbers, and the underscore _)
. = anything (letter, number, symbol, whitespace)

If you want to match the same letter multiple times you can do this with a quantifier. For example, to match the letter q one or more times put the '+' symbol after the letter.

var text = "ppqqp";
if(text.match(/q+/)) console.log("there's at least one q");

For zero or more times use the '*' symbol.

var text = "ppqqp";
if(text.match(/q*/)) console.log("there's zero or more q's");

You can also group letters with parenthesis:

var text = "ppqqp";
if(text.match(/(pq)+/)) console.log("found at least one 'pq' match");

So, to recap:

. = any x+ = match 'x' one or more times
x* = match 'x' zero or more times ex: match foo zero or more times, followed by bar one or more time = (foo)*(bar)+
x|y = match x or y

Replacing text

Now that you can match text, you can replace it. Replace every instance of 'ells' with 'ines'.

var text = "Sally sells seashells"
var text2 = text.replace(/Sally/,"Billy"); //turns into "Billy sells seashells"
var text2 = text.replace(/ells/,"ines"); //turns into "Sally sines seashines"

Modifiers

Most pattern apis have a few modifiers to change how the search is executed. Here's the important ones:

Make the search case insensitive: text.match(/pattern/i)

Normally the patterns are case sensitive, meaning the pattern 'apple' won't match the word 'Apple'. Add the i parameter to match() to make it case insensitive.

Make the search multiple lines: text.match(/pattern/m)

Normally a pattern will only match the first line of the text. It will stop at the newline character '\n'. With the m parameter it will treat newlines as whitespace and let you search the entire string.

Make a replace global: text.replace(/foo/bar/g)

Normally the replace() function will only replace the first match. If you want to replace every match in the string use the g parameter. This means you could replace every copy of 'he' to 'she' in an entire book with a single replace() call.

Substring Extraction

Another major use for patterns is string extraction. When you do a match, every group of parenthesis becomes a submatch, which you can use individually. Suppose you have a text string with a date in it and you want to get the year and month and day parts out of it. You could do it like this:</p

var text = "I was born on 08-31-1975 and I'm a Virgo."
var parts = text.match("(\d\d)-(\d\d)-(\d\d\d\d)");
//pull out the matched parts
var month = parts[1]; //08
var day = parts[2]; //31
var year = parts[3]; //1975
//parts[0] would give you the entire match, eg: 08-31-1975

The Cheet Sheet

The standard pattern syntax in most languages is expansive and complex, so I'll only list the ones that are actually useful. For a full list refer to the documentation for the programming language you are working with.

Match anywhere in the text: "Sally sells seashells".match(/ells/) (matches both sells and seashells)
Match beginning of text: "Sally sells seashells".match(/^Sally/)
Match end of text: "Sally sells seashells".match(/ells$/) (matches only the seashells at the end)

any word at least three letters long \w\w\w
anything .
anything followed by any letter .\w
the letter q followed by any letter q\w
the letter q followed by any white space q\s
the letter q one or more time q+
the letter q zero or more times q*

any number \d
any number with exactly two digits: \d\d
any number at least two digits long: \d+
any decimal number \d+\.\d+ //ex: 5.0
any number with an optional decimal \d+(\.\d+)* //ex: 5.0 or 5
match the numbers in this date string: 2011-04-08 (\d\d\d\d)-(\d\d)-(\d\d)
also be able to match this date string: 2001-4-8 (\d\d\d\d)-(\d+)-(\d+)

Conclusion

Patterns are a very complex subject so I've just tried to give you the basics. While complex, they are also incredibly powerful and useful. As you learn them you'll find you use them more and more for all sorts of cool things. For a more in-depth tutorial read the Mozilla JavaScript Regular Expression guide.

PS: Found a bug in the above code? Want to suggest more examples of useful regex's? Want to just shoot the breeze? I've turned off comments due to 99% of it being spam, so please tweet your suggestions to me instead: @joshmarinacci. Thanks for understanding!

After over a year of living with my custom built blog system I'd finally had enough last weekend. Time for something new. Something less buggy. Something extensible. So I took a day and rewrote it from scratch.

The new blog system is still custom, and still based on Node, but now backed by a real database ReThinkDB. Also, having many more months of Node and JS experience means I have a better idea of what I'm actually doing now. The new system integrate pages and posts into a single system, automatically tracks traffic, and calculate the sidebar links based on which content is the most popular. All with a single DB query, actually.

In any case, the internals probably aren't very interesting to you. More interesting is the new design, hopefully a bit cleaner and easier to read. I chose new colors and fonts, restyled a few things, and built a new custom layout from scratch. Of particular importance to me is that the pages scale properly on all device screens, from the lowly smart phone, through varying tablets, to the gargantuan widescreen desktop computer. If you resize you're browser you'll see the fonts and margins shift to always provide the optimum experience.

I just turned the new blog on tonight, so If you notice any broken links or JavaScript errors, please contact me on Twitter, G+, email, etc. Thanks, and have a great weekend.

Yes, the future is now, and not just because I bought a 2TB hard drive for less than 150$. Bionic hands, self driving cars, and printable solar cells...

Bluetooth has a use?!

While it hasn't been widely known, because I am not widely known :), I haven't been a big fan of Bluetooth devices. Due to their short range they end up simply replacing 6 foot wires, at an increased device cost and the extra hassle of having one more thing to charge (plus interference with endless other devices). But here's something that might change my mind..a a bluetooth hand!

This prosthetic hand lets you tweak settings via Bluetooth. It can handle up to a 200lb load, which clearly puts it into the six million dollar man range. Hmm. Perhaps that wireless technology is good after all.

Autonomous Audi TT

James Gosling, inventor of Java and my former co-worker at Sun, has been helping some Stanford students work on an autonomous car. Along with Audi, they've announced a TT-S that will attempt to drive the Pike's Peak International Hill Climb. (PS, it's partly running Java and Solaris).

eBooks as eJournalism?

Imagine the world two years from now when the tablet form factor is successful and we are all eReading. Monday Note tackles the question. Less overhead, easier access, newer long form formats emerge. The ebook as a form of journalism. The future might be Awesome!

Paper Solar Cells

They say that the key to making something cheap is to find a way to build it using microchip technology. Then you get to free ride on Moore's law and have someone else fab it for you. Flash memory followed this trend. So did accelerometers. They were once mechanical devices the size of a soda can. Once they could be made using CPU fabbing techniques the price and size dropped precipitously, and now they are being embedded in virtually everything.

So what's the next step beyond microchip tech... paper. If you can make something printable on paper then you can make it cheap. Amazingly cheap. And what's what may happen with solar cells. MIT has demonstrated a solar cell technology using essentially a fancy inkjet printer. The efficiency isn't great, but if it's a factor of a hundred cheaper than ridge cells no one will care.

40+ Vintage Posters to Inspire Your Next Designs Color Palette

From The Design Cublicle: [link]

I'm always looking for design inspiration, especially trends from previous eras. This link has forty really cool retro (or at least retro-looking) posters that pop with great colors. The Nerd eyeglass pattern is one of my favorites.

10 Tips for Creating Compelling Web Copy

From the Web Design Ledger: [link]

Part of creating a good experience for your users is the language you use on your website and in your documentation. Your text must engage the reader and keep them entertained as well as informed. And most of all you must not waste your user's time. After all, user is just short for future customer, and customers don't want you to take them for granted.

Complete Beginner’s Guide to Interaction Design

From UX Booth [link]The title says it all!

Yahoo! Design Pattern Library

Yahoo: [link]

Found via the aforementioned guide to interaction design. A catalog of different design patterns from accordion to the convention of labeling stuff with Your.

Branching is Fun

From Mr. Doob [link]

Not at all design related, but I'm a sucker for cool visualizations and graphics effects.

And for when you really must think outside the box

[found via Peta Pixel]

outside the box from joseph Pelling on Vimeo.

It's been a while since I've written anything, especially anything other than the topics of Amino and Leonardo. While I rarely talk about my personal life on this site, I feel I should let you all know what's been going on, and how the next few months look.

Of Death and Life

The last couple of months have been a bit rough. My wife had two deaths in her family only five days apart. We've spent most of the last two months with family and traveling to California. At the same time Jen and I are experiencing the joys of having our first child. Our son, Jesse Paul, is due May 27th. The name 'Jesse' is from the biblical father of David, which means "Gift from God". 'Paul' is from my uncle who passed away last year. Uncle Paul taught me to program as a child and had a huge influence on me and my career, and so is very special to me.

Onward

Now that we are home, with no more travel in sight for my wife at least, life should return to normal. There's more travel for me, however. In a week I'll fly down to Sunnyvale to spend a week with my team at Palm HQ and prepare for our big event on February 9th. This is going to be huge. I can't wait for you to see what we've got in store. After the event I'll be home for a day and then fly to Barcelona to talk about our new products at Mobile World Congress. If you are going to be at MWC, give me a shout for some drinks.

After MWC I'll have some time at home before doing a series of smaller events (which I'll talk about later), and then be home for Jesse's birth.

Coding

I haven't done as much work on my side projects as I wanted, and things will slow down even more once Jesse is born, but I'm still making progress. Here's a rough roadmap:

Leonardo, the open source drawing program. I've been slowly polishing the UI and adding features. Object effects are high on the list (dropshadow, blur, emboss, etc.) as are a full set of gradients and texture fills. I'm hoping for another release by the end of February which will also include more path features like transforms, rotation, and converting shapes to paths. The big UI overhaul and sharing features will have to wait for later.

Amino 1.0: a full UI toolkit. I've continued to fill in missing features and controls, including the new Table and Tree/TreeTable views. I've got a few more bugs and memory leaks to fix before I'll call Amino 1.0 final and finished, but I think it's close.

Amino 2.0. I've started working on Amino 2.0 in a branch. Amino 2 is an almost complete rewrite, including a new cross platform stack that will support Java2D, JOGL with shaders, and potentially HTML canvas. It will be much more modular; strictly separating a super fast 2.5d graphics API, a flexible scenegraph, and then the current Amino GUI widgets and CSS on top. If you've seen this screenshot of playing a high def video through a realtime pixel shader, then you've seen the potential of this approach. The new design will make Amino more flexible and easier to evolve. I don't have a timetable for when it will be done, but I plan to open the repo for contributions very soon. For developers the APIs won't change much, but the under the hood changes will be huge.

So, in short, Amino and Leonardo have a strong future, just a bit slower than originally planned. I also have great new things coming with webOS and I can't wait to teach you how to use some of the cool new stuff. So bear with me. The future looks both bright and busy

The call for proposals for OSCON 2013 just went out. OSCON is the one conference I try to speak at every year because the topics are so diverse and interesting. And being just up the road in Portland doesn't hurt either. However, I'm having trouble deciding what to submit. Too many things interest me. So I thought I'd consult the wisdom of the crowd. What do you want to see?

I plan to submit an update to my 3 hour HTML Canvas workshop since it is still a very relevant technology. It has been my most popular session, however, I don't just want to rehash what I did the last two years. What new things would you like to see? A game engine? Graphing algorithms? UI toolkits? More on Audio and Input?

Even if you don't plan to attend OSCON, the Canvas talk may still be relevant to you. The content from these sessions has turned into my popular open source ebook HTML Canvas Deep Dive. The book accounts for 75% of the hits on my blog, making it the most popular thing I've written by far. Any updates for OSCON 2013 will go into a new edition of the book.

I'm also open to other topics that fall within my area of expertise. The internet of things? Arduino hacking? Mobile app design? Usability? I'll even consider some Java stuff if that's what you want. What are your burning topics for 2013?

With all of the hoopla last week about the innovative features in the new iBooks 2 I thought it would be instructive to see what could be done with pure HTML 5. I put together a little demo which adapts to screen sizes and has simple interactive content. Here's what it looks like:

View the live demo here. I highly suggest you load it up on an iPad as well. Try rotating the screen (or make the browser window narrow if you are on a desktop.) Keep in mind this is just a prototype. It's not skinned or made to look pretty at all.

You can spin the little sphere tree by dragging with your mouse. If you view this on a tablet it will respond to touch events as well. You can click on the photo to see a large fullscreen version. The footer will stay fixed to the bottom. The inline photo and canvas will resize and move to the left edge if you switch to portrait mode.

My goal for this effort is use pure semantic HTML. If we want to scale this up to a full book then the markup needs to be as close to pure text as possible. I'm using only divs with paragraphs and headers for all textual content. The interactive stuff is canvas or img tags. All interaction is standardized and put into reusable javascript files except for the actual dot tree itself (though it does use reusable components). I had to add a little hack to make the canvas resize properly, but that is also reusable. The footer and general layout is pure CSS.

I think the prototype turned out pretty well. It would be easy scale up to a full book with one page per chapter. Table of contents, index, and glossary would have to be written by hand unless we have some automated tool to do it, though I think such tools already exist.

So far I haven't found much that the new iBooks 2 format does that couldn't be done with plain HTML. They did add nice columns and shaped floats, but that is part of the CSS 3 specs and could be implemented in the renderer quite easily. (And shaped floats have been hacked into CSS2 for over a decade!)

I do like the look of iBooks Author. It's a very nice visual tool that should let people create books without any programming experience. The new terms of service are a different issue, but after thinking about it I've decided I don't care. iBooks Author is a tool for formatting content to be sold in the iBookstore. It really has no purpose other than that so the terms of use don't make much difference. Amazon has their own tools for their own store as well, and I expect them to get better with the advent of the Kindle Fire.

While I would love to see a beautiful visual editor like iBooks Author that formats content for all possible bookstores I don't really expect Apple to build it for me. Such a solution will have to come from a third party. Fortunately third parties now know that Apple won't compete with them to build such a tool, so I expect we'll see something like it soon.

Anyway, back to my HTML 5 prototype. Anything else you'd like to see it do?

Please send feedback and comments to my twitter account @joshmarinacci instead of on the blog. Thanks!

How to Hide Wires in the Wall

If you are like me, and the fact that you are reading this suggests a certain kinship, then you have many electronic devices scattered around your house; each with their own wires for communication and power. Wires are wondrous. They form the basis of our information economy. Unfortunately, in a shared space like a living room, they are also atrociously ugly. For your consideration: my living room.

Okay. So that doesn't look quite so bad. However, here is what the couch is hiding.

Even worse.

Background

My wife and I have been TV-less for several years, mostly watching Hulu on our laptops. When we re-designed the house after Jesse was born I decided it was time for a TV. We still watch Hulu and Netflix, but now streamed through a tiny Roku box.

After several months of work, nestled in between getting webOS 3.0 out the door and prepping the nursery for the pending arrival of my first child, I am happy to announce the release of Amino 1.0. I have been eagerly following the development of HTML 5 Canvas support in the major browsers as well as ensuring the HP TouchPad will have great support for it. Amino is a great way to use the power of Canvas is modern mobile and web applications.

What is Amino?

Amino is a small scene graph library for both JavaScript and Java, letting you embed smooth animated graphics in webpages with the Canvas tag and in desktop Java applications with a custom JComponent. Amino provides a simple API to do common tasks, while still being extensible. For example, to create a rectangle that loops back and forth in a webpage, just do this:

//setup
var runner = new Runner();
runner.setCanvas(document.getElementById('canvas')); //create a rect filled with red and a black 5px border
var r = new Rect() .set(10,20,50,50) .setFill("red) .setStroke("black") .setStrokeWidth(5);
runner.setRoot(r); //animate r.x from 0 -> 300 over 5.5 seconds, and repeat
runner.addAnim(new PropAnim(r, "x", 0, 300, 5.5).setLoop(true)); //kick off the animation
runner.start();

See the results on the Amino homepage here

What can it do?

Amino can draw basic shapes (rects, circles, paths) and animate them using properties (width goes from 10 to 20 over 3.2 seconds) and callbacks. It also can buffer images to speed up common operations, manage varying framerates on different devices, and do Photoshop like image filtering (brightness, contrast, adjustment). And finally, Amino supports keyboard and mouse events on nodes within the scene, not just for DOM elements. In short, it's a portable scene graph for making interactive applications. Amino handles the hard work of processing input and scheduling the drawing to ensure a fast consistent framerate.

How about some examples?

I'm glad you asked. I've put together a couple of examples to show the variety of things you could do with Amino.

PlanetRover is a simple multilevel sidescroller game with jumping and collision detection.

Big Fish, Little Fish is a page from a hypothetical children's ebook, showing how text can be enriched with animation, images, and custom fonts.

This LineChart component is a super easy way to render graphical data in the browser with a minimal api.

These examples and more are available on the Amino Gallery Page.

How do I get it? What's the License

Amino is fully open source with the BSD license. You can download the source and binaries from here, or link directly to amino-1.0b.js from here in your app with a script tag.

If you'd like to contribute, or just want to let us know the cool stuff you are doing with Amino, please join the developer list or send an email to joshua at marinacci dot org

So I been thinking. Design comes in waves. First it was page curls and drop shadows. Then came glossy buttons and wet floors, followed by shiny badges and rough textures. Today 'flat' is the leading trend in UI design. It certainly defines the look of Web ’13. Even Apple has jumped on the bandwagon. But what comes next? Where do we go from here? Whither 2014?

The problem with flat is that we can’t make flat flatter. Flat may be perfection but once you hit 10 you’ve got no where to go. We need one more; and I think I've found it: plaid.

I know plaid may seem to be a controversial choice, but it actually has a lot of things going for it. Plaid is more than just what you get when half of your stripes turn left. Plaid can meet or beat Flat on every level. Plaid has skillz.

Plaid Hides the Chrome

One of the core principles of Flat UI design is to make the interface controls subdued so that content will be highlighted. Plaid has this in spades. Take a look at this room.

Subdued UI Controls, from Oxford Design Studio

The plaid design elegantly highlights the non-plaid potted fern in center. A plaid elephant could be hiding in this room and you’d never know it. Plaid is a highly effective way to hide your design.

Plaid Makes a Statement

Flat minimalist UIs are bold. They make a statement. They say: "Hey, here’s my content. Deal with it.” Nothing makes a statement more than plaid. No one’s going to mess with you and your herd of sheep when you're dressed like this.

Plaid means serious business

Plaid is Timeless

Plaid is timeless. It’s here to stay. In the fashion world some designs go in and out of style but plaid has survived. Endless flirtations with polka dots and checker patterns have come and gone, but plaid is still with us. It has a classic design that continues to survive.

These guys wouldn’t look out of place at a modern rave.
image from Reconstructing History

Plaid isn’t Skeuomorphic

FlatUI aims to be authentic. There is nothing more authentic than plaid. While it does originate in real world materials, plaid is not skeuomorphic like other patterns such as leopard print and zebra stripe.

This zebra is highly skeuomorphic

Plaid is Classy

Plaid is classy. Who wears plaid? Lots of awesome people. One in particular stands out. Who? James Bond, that’s who.

From The Suits of James Bond, possibly the most awesome site in The Internets.

And who didn’t wear plaid? The enemies of James Bond.

See this guy? This guy didn’t wear plaid. Here he is in his minimalist black and white ensemble sipping his presumably flat cappuccino. No plaid to be seen.

Hugo Drax, non-plaid wearer and supervillan

I don’t have to tell you how it turned out when these two met.

"Well plaid, Mr. Bond. Well plaid."

That’s "Sir Plaid" to You

Plaid has a deliciously colorful history. Originally used for straining curds into cheese, this illustrious pattern was little known outside of dairy production until the Great Plaid Revolt of 1763 when members of the Scottish House of Commons disagreed over the proper pronunciation of 'tartan'. Overzealous British soldiers in residence attempted to quell the violence with an ample dose of additional violence, resulting in the death of thousands. (see illustration).

History lesson from the Modern Tartan Shopping Guide

The book is done!

I am happy to announce that I have finished writing my new book for O'Reilly on GWT and PhoneGap. Well, not completely finished; my final draft is submitted but O'Reilly's talented team still has to work their technical magic to get it prepped for sale.

Oh yeah, and I got a cool animal as well!

The book is called Building Mobile Applications with Java. It will be about 70 pages long and be ready for purchase in March. The book shows you how to write code in Java, compile it into JavaScript with GWT, then bundle it up as an installable mobile app with PhoneGap. Since PhoneGap was recently donated to Apache the final title may use PhoneGap's new name: Cordova.

The book covers everything you need to get started with GWT and PhoneGap, including how to use the native SDKs for iOS, webOS, and Android. Then we dive into customizing the interface for mobile devices and using open source libraries to access device features. I also cover app UI design and optimization. Finally the book ends with a video game project where we use HTML Canvas to build a tilting physics game with a cartoon blob hero.

I am quite proud of the book though I often find the process of long form writing painful. The first 90% is super fun but the second 90% seems to take forever! I hope you enjoy the results. The book will soon be available for order on O'Reillys website and wherever ebooks are sold.

thanks!

I've heard a lot of noise recently about these new fangled smartphones and tablets not replacing 'real computers', especially since the announcement of many new tablet products, including the HP TouchPad. That they are just expensive FaceBook machines. I've also heard people say that there's no room in the market for more devices: iOS and Android will take up the market and leave nothing for anyone else. It'll be just like the PC wars again!

Well... no. We definitely are going to see a huge shift in the industry over the next couple of years, but there will not be just one or two OSes controlling the market. And laptops won't be obliterated by tablets any more than TV destroyed the movies and radio. We won't see Mac vs PC again, or desktops vs Apple IIs. 2014 won't be like 1984.

First a disclaimer. These are my opinions, not the opinions of my team or employer. I work in Developer Relations. I have no knowledge of long term HP strategy, nor do I have any influence on it. This is simply the ramblings of an long time computing observer.

Tablets are no substitute for 'real' computers

Let's tackle these issues separately. First the claims: 'tablets suck for real work', or 'I would never use one. They are too limiting', or 'They are only for content consumption'. What are we talking about?

By tablet computers I mean things like the TouchPad or the iPad. These are devices which run a non-general purpose OS. There is no exposed filesystem. Apps are sandboxed and safe. A PC is a desktop or laptop running a general purpose OS like Windows, Mac OSX, or full Linux distros. Regardless of the form factor (touch vs keyboard), these are fundamentally different kinds of devices. Now the claims:

Tablets are too limited compared to a real computer. Yes the current generation of hardware is limiting, but it's going to get better; and fast. My top of the line computer less than 10 years ago had a 400mhz processor with 64MB of RAM, no GPU, and 8 GB of slow disk storage. Pretty much all tablet computers far exceed this already, and will soon support printing, directly controlling hardware in your house, and be first class citizens of the network (assuming Apple ever lets you jettison iTunes from your 'real' computer). They will all get better, and quickly. Especially when there is competition.

Tablets suck for real work: Yes, they are primarily designed for content consumption and tasks that require typing a paragraph or less. But guess what: that's a lot of stuff. In fact that's what 90% of people do 90% of the time on their computers. Most people don't write more than a paragraph at a time on their real computers. Most people surf the web, check Facebook, place games, pay their bills, and write a few short emails. A tablet device that can do 90% of what they need with less fuss and less cost is a big deal. A really big deal. Half of people could never learn to drive before the automatic transmission was invented. Yes, it's that big of a deal.

'I would never use one. They are too limiting'. That's very true. If you get nothing else from this essay, I hope you remember one thing:

They aren't built for you!

These things are built for the 90% of people who don't need everything a full PC does. By definition, if you are reading this blog, then these things aren't built for you. You are a programmer or writer or artist. You need a 'real' computer. In 10 years (probably far less), you will own a tablet computer, but it won't be your only computer.

In ten years I will still have a laptop with a real keyboard, possibly a disk drive, and most certainly an exposed filesystem with regular installable apps. It will still have a command line. (bash4eva!) I'll certainly use a tablet computer as well, but it won't be my only computer. However, for 90% of people, the tablet will do everything they need. It's built for them, not us.

OS Wars

Now that we have the audience for a tablet out of the way, lets look at the OS wars. There's a lot of talk that we'll have just iOS and Android. That they have an insurmountable lead. That the market wants one boutique option and one mass market indistinguishable option, just like MacOS and Windows.

I really don't think this is the case. I don't think any OS will have more than 25% market share in 10 years. Despite the similarities, the mobile OS market is very different than the PC market. Why? Well, let's compare the world of 1984 with the world of 2011.

• Hardware: In 80s and early 90s you bought a PC in a computer store or maybe a department store like Sears. In 2011 you buy a phone in a cellphone carrier store, or on the web. You buy a tablet computer in a cellphone store or a mass market retailer like Target. These stores really didn't exist 30 years ago. Getting distribution for a device is very different now.
• Apps: In 1984 you bought apps on floppy disks, wrapped in boxes, sitting on a shelf in a computer store. Or maybe Sears and Toys'R'Us (for games at least). There were no 'app stores'. Today, mobile apps are almost always bought in a store provided by the mobile platform itself. It doesn't matter if a retail location wants to carry your apps or not. No one has to fight over physical shelf space. The economics are fundamentally different.
• Advertising: In 1984 computers were mainly advertised in computer magazines and newspapers. Remember those? Those things that no one my age reads anymore? (I'm 35 by the way.) Now we read and shop online. Or on our phones. Or get recommendations from friends on Twitter. And mobile devices are advertised on television. Advertising has changed. People find out about products in fundamentally different ways.
• Compatibility: In 1984 software compatibility mattered. Software was hard to write, required huge lead times, couldn't be easily updated, and speed was of the utmost importance. Only the biggest apps would be on more than one platform, so getting apps on your OS was a big deal. IBM went to a lot of trouble making OS/2 Warp work with Windows 3.1 apps, for the sake of compatibility. Apple created expensive Apple II plugin boards for the Mac, all for the sake of app compatibility.
  
  Today most of the apps we run are backed by platform independent web services. Only the client app is different. And even that is easier thanks to open standards, modern programming languages, and the web. webOS has smaller market share than iOS and Android, but we still have Facebook, AngryBirds, and about 2 million Twitter apps. And you can view all the same websites. Compatibility simply isn't an issue anymore.

The economics of mobile operating systems are fundamentally different than the desktop wars of olde. To say we are in for a repeat of Mac vs Win is like saying the two world wars were identical because they both involved Germany and had the word 'World' in their names. Well the world has changed.

I think there will not be any single OS winner. Instead it will be more like cars. Many different models and vendors to cater to different tastes. They each have their own colors, addons, and spare parts; but they all drive on the same roads (the internet) and all take the same gas (webservices). 2014 simply won't be like 1984. And that's a very good thing.

Last week I flew down to California for orientation at Nokia. My return flight was supposed to leave Wednesday afternoon, but due to weather and United's bungled computer merge with Continental, I ended up stuck at SFO for a day and a half.

But my loss is your gain! Whoo hoo! Armed with my trusty laptop I fixed some long standing bugs in Leo Sketch and finished up the 1.1 release.

New in this release are:

• let you end a path without closing it by just clicking the 'end' button.
• gradients autoscale to fit the shape they are in
• the Arrow tool is restored
• HTML export supports multiple pages
• Any shape can be turned into a link that jumps to another page in the document
• dynamic bitmap font export for Amino
• text wrapping *yay!*
• many more export improvements and bug fixes

Download here

This week at OSCON gave an updated version of my 3 hour Canvas tutorial. I think the session was well received. It was one of only a few tutorials that was completely sold out, 200 seats taken. But if you couldn't be one of those two hundred I don't want you to miss out.

I turned the content from last year's tutorial into an interactive eBook for the iPad and TouchPad. I did this partly to experiment with ebooks and partly to learn how to publish an app in the various stores. In thanks to my webOS fans I sold the TouchPad version for 99c while the iPad app costs 4.99$. It was a fun experiment but I have decided my real goal is not to make money, but rather to spread knowledge as widely as possible. So I have decided to make it all free as in beer and speech.

Yes, HTML Canvas Deep Dive is now 100% free

I have dropped the price of the existing apps to 0 (the TouchPad store may not yet reflect this). I have also published the book as a set of pages on the web so you can easily read and link to the book without installing an app. Note that the apps don't yet have the new content, just the webpage.

read it now

Even better, there is a bunch of new content I created for this year's OSCON. We now have new chapters on WebGL, WebAudio, and getUserMedia (webcam), as well as fixes for various existing chapters. Deep Dive is now over 20k word!

But, I need your help.

First, please spread the word about my book. I want it to be the definitive introduction to Canvas.

Second, I would love some help both with programming and design. I have created iOS and webOS versions of the book, but I need some help supporting Android, WinPhone / Win8RT, and PlayBook 2.0. I would also like some help from a web designer to improve the layout and font selection, especially on mobile devices.

Finally, please read the book and give me feedback. If you find spelling errors, code bugs, or an unclear description, please let me know. If you are interested in contributing new chapters I'd love that as well.

Working on this project has really been a labor of love. Thank you for your support.

Installing Node on a Raspberry PI used to be a whole lot of pain. Compiling an codebase that big on the Pi really taxes the system, plus the usual dependency challenges of native C code. Fortunately, the good chaps at nodejs.org have started automatically building Node for Linux arm Raspberry Pi. This makes life so much easier. Now we can install node in less that five minutes. Here’s how.

First, make sure you have the latest raspbian on your Pi. If you need to update it run.

sudo apt-get upgrade; 
sudo apt-get update

Node and NPM

Now install Node itself

wget http://nodejs.org/dist/v0.10.2/node-v0.10.2-linux-arm-pi.tar.gz
tar -xvzf node-v0.10.2-linux-arm-pi.tar.gz
node-v0.10.2-linux-arm-pi/bin/node --version

You should see:

v0.10.2

Now set the NODE_JS_HOME variable to the directory where you un-tarred Node, and add the bin dir to your PATH using whatever system you prefer (bash profile script, command line vars, etc); In my .bash_profile I have:

NODE_JS_HOME=/home/pi/node-v0.10.2-linux-arm-pi 
PATH=$PATH:$NODE_JS_HOME/bin 

Now you should be able to run node from any directory. NPM, the node package manager, comes bundled with Node now, so you already have it:

npm —version

prints

1.2.15

Native code

If you are just working with pure javascript modules then you are done. If you need to use or develop native modules then you need a compiler and node’s native build tool, node-gyp. The compilers should already be installed with Raspbian. Check using:

gcc —version

Install node-gyp with:

npm install -g node-gyp

Now any native module should be compilable.

That’s it. Node in 5 minutes.

As regular readers know I have recently jumped into Arduino and hardware hacking full-time. One of the things which fascinates me is the idea of monitoring our environment. I mean not only the global environment but also our own local spaces. Sensors and computation are incredibly cheap. Network access is almost ubiquitous. This means we can easily monitor our world and learn interesting things by analyzing simple data points over time.

Being an engineer I started by picking out some books to read. First up is an amazingly thin but info-packed tome from Maker Press: Environmental Monitoring with Arduino: Building Simple Devices to Collect Data About the World Around Us by Emily Gertz and Patrick Di Justo. As the name would suggest, it is exactly the book I was looking for.

Before I continue I must warn you, reading this book will make you spend a lot of money. You will find yourself spending hours checking out cool sensors and outputs on websites like Adafruit, SparkFun, and Emartee. Tracking your environment with simple sensors is simply too intriguing. I apologize in advance for the new habit you will form.

Though short (81 pages by my count), Environmental Monitoring with Arduino contains a lot of information. It starts with a chapter called "The World's Shortest Electronics Primer" introducing Arduino, basic electronics, and then runs through an LED blinking tutorial. From here you jump straight into your first sensing application: a noise monitor with an LED bar graph.

The book is organized in mostly alternating chapters. Each chapter either introduces a new piece of hardware or a project using that hardware. The chapters cover how to measure electromagnetic interference, water purity, humidity / temperature / dew point, and finally atomic radiation as used by individuals in the wake of the Fukushima disaster.

The components required to build most of the projects in the book are surprisingly cheap. For example, Emartee's mini sound sensor, a tiny board containing a microphone and the support circuitry, is only seven dollars.

The only really pricey component is the Geiger counter from Goldmine that costs $137. Of course it uses a special beta and gamma ray sensitive mueller tube from Russia so it's actually fairly cheap. Most components are under $10.

While I love the book there are a few things that could be improved. Each chapter contains a few paragraphs explaining what we are measuring and how it works (water conductivity was especially interesting), but I'd like to learn more about the science behind each effect. This probably isn't possible in a book of this size, so links to external websites would be greatly appreciated.

I'd also like an appendix with links to learn more about Arduino and environmental sensing, as well as a list of sites to buy cheap components that are easy to work with.

Finally, there is no information on the authors. Most books include a short bio or an introduction by the authors to explain who they are and why you should listen to them. This book contains no biographical information at all beyond the authors' names.

Go - No Go?

A definite go.

If you are new to environmental monitoring this book is a great place to start, even if you know nothing about electronics and Arduino. And for the price ($7.99 for the print copy and half that for ebook) it's a steal. You can get it on:

• Amazon in print
• Amazon as Kindle book
• O'Reilly print or ebook

I finally watched Code Rush this weekend, a documentary about open sourcing mozilla and the sale of Netscape to AOL in the late 90s. There is no doubt that Netscape created the web as we know it. The web changed everything. But I wonder about Mozilla itself. Did open sourcing Mozilla really make a difference to it's success?

I know that Firefox has been a great force for good, encouraging competition and pushing the web forward. However, Firefox only became what it is today when the Mozilla foundation decided to stop the end-all-be-all Communicator effort and instead focus on creating a single product: the world's best browser. Firefox, while open source, is primarily developed by Mozilla.org. Mozilla is a company. They may be a non-profit company, but they have income from search deals that they use to pay staff. Did being open source make a difference? Couldn't a closed source Mozilla do the same thing?

I've been thinking about this all weekend and I'm still not sure. On the one hand being open source built up a community of interest around it, a rallying point for the open source world, even if most of the actual coding came from paid employees. On the other hand, Firefox's userbase is somewhere around 20% of the internet. That means most Firefox users don't know or care what open source is. They use it because it's a good browser.

In the end I think open sourcing ended up being a benefit. Not because it allowed tons of Mozilla forks and variations. I can't think of any high profile Mozilla forks, actually. No, I think the real value was that it freed the Mozilla code base from Netscape Inc. It was insurance. No matter what happened to Netscape the code would always be free, with the option to one day create a non-profit around the code in case the community didn't like what Netscape did with it. And in the end, after AOL bought the company, that's exactly what happened.

So, perhaps my real question is: did the people making the decision to open source the Mozilla code base have this in mind when they did it, or is it a fortunate accident of history? Perhaps we will never know.

By what standard should we measure if code is "beautiful"? I argue it should be not lines or speed, but rather conciseness and clarity. Can someone who is not familiar with the language still understand what the algorithm does? Can someone not familiar with the task still get a feel for how it works? This metric favors shorter code over longer, but not at the expense of readability. Beautiful code should be as close to expressing the underlying algorithm as possible. How close is the actual code to the most straight forward pseudo code?

Some will argue that an elegant implementation is useless if it is too slow; but what if the elegant version is only 5% slower? Is that a good tradeoff? Almost certainly. What if it's 10x slower but only runs for 1% of the time? Then the trade off might be worth it. It depends. Certainly it's good to start with the clear and concise version and only move to a more complex implementation if the speed profiling warrants it. This is what I like to call concise computing.

Complexity

Concise code is easier to read, easier to write, and much, much, much easier to maintain. Fewer lines of code means fewer places for bugs to hide. But let me take it from another angle:

If you open up the typical programming library, especially older ones, you will find a bunch of complex code; often difficult to understand. This is the case even if the underlying task should be straight forward. Why should code be like this?

I think there are two reasons: first, the programming language used to write the library wasn't expressive enough to write the implementation in a way that looks like the algorithm. If a task is naturally described using objects then a language with out direct object support will be at a disadvantage. If the task is really about matching patterns, then a language without matching will necessarily represent the algorithm in a less elegant way. And of course once written we try not to rewrite our code for fear of breaking things. Code is instant legacy.

The other reason for complex libraries is speed. While I can describe sound synthesis using pure math... math is expensive to compute. A set of pre-calculated wavetables will be far faster than raw cosine functions. Changing an algorithm to be fast often makes the code hard to understand. But is this really a good excuse?

Our software doesn't have to be fast. It has to be fast enough. But enough depends entirely on context and it changes over time as hardware evolves. Math.sin() used to be hugely expensive. When John Carmack wrote Doom he would massively change code to save a few divides. The code was amazing but came at a cost of obscuring the underlying algorithm and being hard to maintain. It doesn't have to be like that anymore.

Ometa

I did not invent concise computing (though I haven't heard the specific term before). It has been a computing goal for over fifty years. The sweet spot for any implementation has shifted over the years as hardware changes, but I think the time has come for most of our coding to move in the direction of conciseness. We have such an excess of CPU power, even in our mobile devices, that in almost every case the concise version wins over a fast but complex one. However, let me stop with the theoretical discussion and give you a concrete example of what I'm saying.

I recently discovered a language called OMeta. OMeta is actually a extension to let you write DSLs in a general purpose host language. My preferred version is OMeta/JS, which extends JavaScript, but there are implementations for SmallTalk, C#, and others. OMeta really exemplifies my thoughts on concise computing.

Alex Warth, the creator of OMeta, realized many computing tasks, especially writing parsers and compliers, are just different forms of matching. So why not bake it into the language in a way that is convenient but still lets you get at the power of the host language, and treat the parsers as objects that can be extended in various ways. Here's what a simple calculator looks like:

SimpleCalc <: Ometa {
   exp = number | sub | add,
   sub = exp:a "-" exp:b =<  (a-b),
   add = exp:a "+" exp:b =< (a+b),
}

result = new SimpleCalc().matchAll("6+7);  //result is set to 13

Even if you don't know anything about OMeta you can follow what is going on. This says that exp is a number or a pattern called sub or add. Then it defines sub and add with recursive definitions back to exp. The => part says that the matched expression goes to a small Javascript expression, in this case the part that does the actual math.

This code looks a lot like your typical BNF grammar. The magic here is that everything after the => part is regular Javascript. Instead of (a+b) it could be console.log("doing an add"), or call some other function to add in base 16 math, or generate C fucntions. Normally I would have to break out to a special library with weird syntax, or write in a completely different language. OMeta lets us implement algorithms that are naturally expressed with matching, but still remain in our general purpose host language, not some special matching only parser. This is concise computing.

OMeta was created as part of Alex Warth's graduate thesis. You should definitely check it out. For an academic paper it is highly readable. Alex continued his work at VPRI, a research group set up by Alan Kay. Yes, that Alan Kay. Though Alex's OMeta is an excellent improvement the original idea goes back to Meta II, a meta-compiler created back in 1962!!! The battle for concise computing is far from recent.

A PNG Parser in OMeta

Most public uses of OMeta show small examples like the calculator above or language compilers, which is probably it's most obvious application. (I myself am working on my own cross-language system with OMeta which I'll detail in a future blog post). Earlier this month I showed you a markdown word processor with embedded arithmetic expressions built in OMeta. However, today I want to show you a different kind of task: parsing a binary data PNG file in JavaScript.

PNG is a fairly simple data format yet many parsers are surprisingly complex. As documented in Wikipedia, PNG consists of a header followed by a series of chunks. Each chunk has a length, type, and payload. Most of the chunks contain metadata about the image. Only one, IDAT, contains a bitmap. The example below does not decompress the actual image data (which requires a DEFLATE decompressor) , but rather parses and validates all of the metadata chunks; the most likely use for an external parser.

Parsing binary data in Javascript has always required hacks because JS has no native binary types. Fortunately, the W3C and Khronos recently remedied this situation with Typed Arrays, a new data type built to support textures and vertices for WebGL. Using typed arrays we can fetch a PNG file from a server and convert it into a large buffer; like this:

function fetchBinary() {
    var req = new XMLHttpRequest();
    req.open("GET","icon.png",true);
    req.responseType = "arraybuffer";
    req.onload = function(e) {
        console.log("loaded");
        var buf = req.response;
        if(buf) {
            var byteArray = new Uint8Array(buf);
            console.log("got " + byteArray.byteLength + " bytes");
            var arr = [];
            for(var i=0; i<byteArray.byteLength; i++) {
                arr.push(byteArray[i]);
            }
            processOmeta(arr);
        }
    }
    req.send(null);
}

The Uint8Array is an array of unsigned bytes (8 bit long 'words'). With this array in hand we can parse the entire structure in less than 20 lines of Ometa. Again, even if you don't know how Ometa works you can get a vague idea of what the program does by reading it.

ometa BinaryParser <: Parser {
    //entire PNG stream
    start  = [header:h (chunk+):c number*:n] -> [h,c,n],
   
    //chunk definition
    chunk  = int4:len str4:t apply(t,len):d byte4:crc
        -> [#chunk, [#type, t], [#length, len], [#data, d], [#crc, crc]],
   
    //chunk types
    IHDR :len  = int4:w int4:h byte:dep byte:type byte:comp byte:filter byte:inter
        -> {type:"IHDR", data:{width:w, height:h, bitdepth:dep, colortype:type, compression:comp, filter:filter, interlace:inter}},
    gAMA :len  = int4:g                  -> {type:"gAMA",value:g},
    pHYs :len  = int4:x int4:y byte:u    -> {type:"pHYs", x:x, y:y, units:u},
    tEXt :len  = repeat('byte',len):d    -> {type:"tEXt", data:toAscii(d)},
    tIME :len  = int2:y byte:mo byte:day byte:hr byte:min byte:sec
        -> {type:"tIME", year:y, month:mo, day:day, hour:hr, minute:min, second:sec},
    IDAT :len  = repeat('byte',len):d    -> {type:"IDAT", data:"omitted"},
    IEND :len  = repeat('byte',len):d    -> {type:"IEND"},
   
    //useful definitions
    byte    = number,
    header  = 137 80 78 71 13 10 26 10    -> "PNG HEADER",        //mandatory header
    int2    = byte:a byte:b               -> bytesToInt2(a,b),    //2 bytes to a 16bit integer
    int4    = byte:a byte:b byte:c byte:d -> bytesToInt(a,b,c,d), //4 bytes to 32bit integer
    str4    = byte:a byte:b byte:c byte:d -> toAscii([a,b,c,d]),  //4 byte string
    byte4   = repeat('byte',4):d -> d,
   
   
       
    END
}

This parser returns a JSON structure that we can loop through to find any chunk we care about.

chunk: {"type":"IHDR","data":{"width":33,"height":36,"bitdepth":8,"colortype":2,"compression":0,"filter":0,"interlace":0}}
chunk: {"type":"gAMA","value":55555}
chunk: {"type":"pHYs","x":2835,"y":2835,"units":1}
chunk: {"type":"tEXt","data":"Software0x0 QuickTime 6.5.2 (Mac OS X)0x0 "}
chunk: {"type":"tIME","year":2005,"month":4,"day":5,"hour":17,"minute":6,"second":20}
chunk: {"type":"IDAT","data":"omitted"}
chunk: {"type":"IEND"}

In a sense the code above is not really an algorithm, but rather a definition of the PNG format. A runnable specification. For an even more impressive example, the OMeta guys created a TCP/IP parser which uses the actual ASCII art header definitions from the RFC as the parser code itself.

More

What I've shown you today is merely a hint of what concise computing could be. Imagine an entire operating system from boot to GUI, complete with apps, written in less than 20k lines of code? It sounds crazy yet that is what VPRI has done.

By writing the most clear and concise code possible we can make our software more maintainable and longer lived. Next time I'll show you the same principle applied to audio synthesis. Feel free to ask questions and continue the discussion.

Lately I've been experimenting with Functional Reactive Programming, or FRP. There are several good libraries to use FRP with Javascript. I chose Bacon.js. I'm finding FRP to be very useful but hard to understand.

The way FRP is explained often leads to confusion. Most people know what the P is, and the F seems fairly understandable, but the R causes confusion. Examples usually talk about the difference between expressions and statements. Rather than c = a + b setting a value right now, it is an expression which defines that c is always a plus b. It defines a relationship. In another life I would have called this a binding expression. I suppose expressions get to the heart of what FRP is but it doesn't really explain why it's useful. Let me try another way.

FRP is this: working with streams of values that change over time.

Perhaps an example would help. Imagine moving a mouse over your browser. It produces a stream of x and y values. Rather than using a callback for every mouse move, we can work with the mouse events as a single object over time: an event stream. Suppose we want to know when the mouse moves past a line on the screen at 100px. In regular code we could do this:

$("body").on('mousemove', function(e) {
     if(e.pageX > 100) {
          console.log("we are over 100");
     }
};

With FRP we would create a stream based on mouse move, then filter it to only have X values over 100, like this:

$("body").toEventStream('mousemove')
     .filter(function(v) { return v > 100; })
     .onValue(function(v) {
          console.log("we are over 100: " + v);
     });

This is roughly the same amount of code so it doesn't seem like a big improvement. Trust me, it is. We have separated the action, printing a message, from the source of the stream and any filter operations. We can also add more operations to the stream if we want, and abstract the filters out further.

//create a stream of clicks
var clicked = $('body').asEventStream('click');
//look for clicks for no longer than 300ms
clicked.bufferWithTimeOrCount(300, 2)
     .filter(function(x) {
          return x.length == 2;
          })
     .onValue(function(x) {
          console.log("double clicked: ", x);
     });

var isTwoValues = function(x) { return (x.length == 2); }
var log = function(str) {
     return function(obj) {
          console.log(str,obj);
     }
}

clicked.bufferWithTimeOrCount(300,2)
     .filter(isTwoValues)
     .onValue(log("double clicked");

clicked.bufferWithTimeOrCount(600,2)
     .filter(isOneValue)
     .filter(function(x) return (x[0] == true); }) 
           //x[0] = true if it's a mouse down. false if it's a mouse up
     .onValue(log("hold"));

mouse_move
    .filter(mouse_down.toProperty())
    .diff(null, function(a,b) {
            if(a) {
                return {
                    dx: Math.abs(b.pageX-a.pageX),
                    dy: Math.abs(b.pageY-a.pageY),
                    dt: b.timeStamp - a.timeStamp
                }
            } else {
                return { dx:0, dy:0, dt: 0 }
            }
    })

    //the five most recent samples
    .slidingWindow(5,5)
    //calculate the sum of the samples and velocity
    .map(function(v) {
            var tx = 0; var ty = 0; var tt = 0;
            for(i in v) {
                tx += v[i].dx;
                ty += v[i].dy;
                tt += v[i].dt;
            }
            var txy = Math.sqrt(tx*tx + ty*ty);
            return txy/tt*1000;
    })

    .filter(greaterThan(2000))
    .onValue(log("current velocity in pixels per second =, > 2000"));

Hi. My name is Josh Marinacci. You might remember me from the webOS Developer Relations team. Despite what happened under HP, webOS is still my favorite operating system. It still has the best features of any OS and an amazing group of dedicated, passionate fans. I deeply cherish the two years I spent traveling the world telling everyone about the magic of webOS.

However, I’m not here to talk to you about webOS. I want to tell you about my brother in law, Kevin Hill. Two years he was diagnosed with stage 4 melanoma. If you know anything about melanoma, then you know this was 100% terminal just a few years ago. Kevin and my sister Rachel have traveled the country joining every experimental trial to beat this. You can read about their amazing story on their site: The Hill Family Fighters.

The Hill Family

Kevin and Rachel have had amazing success but recently hit a roadblock: the scan a few weeks ago showed a spot on his brain. It’s a testament to his strength that he has continued to work remotely as a sysadmin through all of this (even using his TouchPad from the hospital), but the time has come to slow down. We have not given up hope that he can beat it, but this latest development means he must finally quit work and focus on staying alive.

It will be 90 days before his long term disability kicks in. That's 90 days without income, and just 50% of his salary after that. My sister works part time as a brilliant children’s photographer, but spends most days taking care of Kevin and their two little children, Jude and Evie. We’ve calculated that they need at least ten thousand dollars to Bridge the Gap and get them to the end of the year. This is where you come in.

I am auctioning off my entire collection of webOS devices and swag to help them cover the bills and fight the cancer.

I will be holding an online auction selling everything I have. There will be devices like Pre2s and Pre3s. Limited edition posters and beer steins. My personal water bottle that saved my life in Atlanta (it still bears the dents). In addition some of my former Palm co-workers are donating their own devices and swag. And the highlight is an ultra-rare Palm Foleo with tech support from one of the original hardware engineers.

With your help we can Bridge the Gap for the Hill family. Please add your name to my mailing list. I will send you a note soon when I have a final date for the auction. This list is just for the auction and will be destroyed afterward. Even if you aren’t interested in buying anything I could really use your help getting the word out. Let’s hit the forums, the blogs, and the news sites. The webOS community is the best I’ve ever worked with and I need your help one last time.

Thank you.

Sincerely,
  Josh

Sign up to be notified about the auction

Ten years from now 90% of people will use something like a tablet or smartphone as their primary computing interface. And the remaining 10% will use a desktop OS on something called a workstation.

Workstations vs Tablets

Why and Who?

What do they need?

• Scalability
• Efficiency
• Reliability
• Customization

Next Steps

• IDEs are some of the most sophisticated applications available thanks to highly advanced UIs (code completion, class generation, syntax highlighting), heavy integration with other tools (put a web server *inside* of your IDE?), and yet are almost all completely free.
• Only nerds complain that OpenID and OAuth suck for desktop applications. Why?
• File systems let you track files, not documents, and yet documents are usually what we care about. Can we do better?
• iTunes might be the most widely used pro app in the world, even if it's recently jumped the shark.

Hi. My name is Josh Marinacci. You might remember me from the webOS Developer Relations team. Despite what happened under HP, webOS is still my favorite operating system. It still has the best features of any OS and an amazing group of dedicated, passionate fans. I deeply cherish the two years I spent traveling the world telling everyone about the magic of webOS.

However, I’m not here to talk to you about webOS. I want to tell you about my brother in law, Kevin Hill. Two years he was diagnosed with stage 4 melanoma. If you know anything about melanoma, then you know this was 100% terminal just a few years ago. Kevin and my sister Rachel have traveled the country joining every experimental trial to beat this. You can read about their amazing story on their site: The Hill Family Fighters.

The Hill Family

Kevin and Rachel have had amazing success but recently hit a roadblock: the scan a few weeks ago showed a spot on his brain. It’s a testament to his strength that he has continued to work remotely as a sysadmin through all of this (even using his TouchPad from the hospital), but the time has come to slow down. We have not given up hope that he can beat it, but this latest development means he must finally quit work and focus on staying alive.

It will be 90 days before his long term disability kicks in. That's 90 days without income, and just 50% of his salary after that. My sister works part time as a brilliant children’s photographer, but spends most days taking care of Kevin and their two little children, Jude and Evie. We’ve calculated that they need at least ten thousand dollars to Bridge the Gap and get them to the end of the year. This is where you come in.

I am auctioning off my entire collection of webOS devices and swag to help them cover the bills and fight the cancer.

I will be holding an online auction selling everything I have. There will be devices like Pre2s and Pre3s. Limited edition posters and beer steins. My personal water bottle that saved my life in Atlanta (it still bears the dents). In addition some of my former Palm co-workers are donating their own devices and swag. And the highlight is an ultra-rare Palm Foleo with tech support from one of the original hardware engineers.

With your help we can Bridge the Gap for the Hill family. Please add your name to my mailing list. [link] I will send you a note when I have a final date for the auction and when it starts. This list is just for the auction and will be destroyed afterward. Even if you aren’t interested in buying anything I could really use your help getting the word out. Let’s hit the forums, the blogs, and the news sites. The webOS community is the best I’ve ever worked with and I need your help one last time.

Thank you.

Sincerely,
  Josh

I am not entirely sure what to say.  It has taken me two hours to write the following few paragraphs.

Though I never worked at Apple nor had a chance to meet him, I owe my career to Steve Jobs. At the tender age of 8 I learned to program on an Apple IIe and have been hooked ever since. I've used Mac OS X since the first public beta on my tangerine iBook. I used a string of iPods and iPhones before joining Palm to compete with Apple. Steve's products changed desktop computing, music, movies, cellphones, and almost everything else in our modern world, and I thank him as a happy user of those products.

However, I think most of all I thank him for making the world understand the value of design and usability It's not just an add on. It's the most important part of a product. I've spent my professional career helping developers build better software thanks to his vision and singular focus. Not only would I not have this career without him, but my entire field (developer evangelism) likely wouldn't even exist.

So thank you Steve. Thank you for teaching us that our job is to make the world better for everyone.

Building my own CNC machine has been quite an educational experience. I've got a better idea of what I'm up against now, and have plans for moving forward.

Lessons Learned so Far

First. Hardware is hard. Much harder than software. I expected programming or wiring the electronics to be the difficult part, but thanks to good docs and helpful Arduino libraries I was able to get basic movement going pretty quick. The biggest challenge has been the mechanical construction of machine. I've gone through several iterations of the pen mount, sliders, and lead screw attachments but there is still much more to do. Software is so much easier to modify and test out new ideas. Creating a new slider took several hours to design, build, and test.

I have also learned how much of hardware success is based on component sourcing. Throughout this project I have added to a growing list of good online shops to getting interesting pieces; and how to repurpose unexpected materials like plumbers tape. I also learned that Amazon Prime is your friend. I honestly don't know how Fedex can make any money off of them.

Improvements

So far I'm happy with the progress I've made on my CNC machine. I can now make a pen move in the X and Y directions with a fair amount of repeatability. The machine is a good test of ideas but not reliable enough to actually use yet. The biggest issue is tightness. Everything in the CNC machine has some slack in it. Each component of slack multiplies to make the pen slide all over the place; and a sliding pen means bad drawings. So that will be the main driver of the next version: making it super tight.

The other night I designed a new slider. It still uses roller skate bearings but applies them to the support beam from three sides instead of two. It also uses more rollers spaced further apart. The new sliders greatly improve stiffness without adding too much friction.

To remove the stickiness of then pen I realized I need a way to press the pen into the paper but still have some slack. This calls for a spring. After reading work that others have done I devised a new holder using two ballpoint pens. They are, interestingly enough, identical pens but with different brands on the side. Most likely from the same swag manufacturer. If you attend conferences you likely have tons of these guys lying around.

By combining two pen barrels and putting a spring at the top I can get the pen to sort of float in the middle but pressed against the bottom end. The spring pushes it against the paper but lets it slide up when needed. It acts sort of like a tiny shock absorber. Good enough for this version.

On the electronics side I finally mounted the various boards on a sheet of plastic. Using my Dremel drill press I set them up on inexpensive spacers from the Robot Shop. I also gave the steppers proper four pin connectors from Adafruit since I'm always plugging and unplugging them. The drivers still have some breadboarding to get rid of, but things are improving. I also added a real power switch for the motor current instead of having to constantly unplug the wall wart.

On the software side I wrote some new Arduino sketches using the excellent open source library AccelStepper. It handles acceleration and multiple steppers with ease. Now the motors sound like engines powering up.

NES Controller

Oh yeah; my teaser from before. The NES Controller.

I found two original NES controllers at our local electronics recycling shop for five bucks each. I love these things. These two are probably over 20 years old and they still work perfectly. Nintendo designed them to be bullet proof. (Sadly their design of the cartridge connector was not so well thought out).

The controllers use a simple serial protocol over their five pins. You can hook them up directly to an Arduino using jumper wires but I found an NES breakout board (Robot Shop) to give it that nice finished look. The software side is easy using the NESpad library. Note that this code is a few years old and won't compile out of the box. I suggest using my fork of the lib which is patched to compile with Arduino 1.0 and higher.

Name

Every good project needs a name. I'm tired of saying "my CNC drawing machine thingy" over and over. Thus I dub thee "Clyde" after the orange ghost of Pacman fame. Apparently his other names are (translated from Japanese) are "stupid", "slow guy", and "pokey". Fortunately Clyde is easier to pronounce than Guzuta and Otoboke. He may be slow but he tries really hard and gets the job done.

Next Steps

I'm going to take a week off from Clyde during my parents' visit. Instead we will play with Jesse and finish up some house projects. When I return I will build a new machine over twice the size of the current one: 40cm x 60cm x 10cm. This is big enough to do some real work while still able to fit on my desktop. My latest extrusion order from OpenBeam is enough to build the new machine with plenty left over for reinforcement and experimentation. Have a good weekend!

I love the Arduino platform. I have official boards and lots of derivatives. I love how it makes hardware hacking so accessible. But there’s one thing I hate: the IDE. It’s ugly. It’s ancient. It has to go.

Sure, I know why the IDE is so old and ugly. It’s a hacked up derivative of an older IDE, written in a now-deprecated UI toolkit. Fundamentally, the Arduino guys know hardware and micro-controllers. They aren’t desktop app developers. I suppose we should be happy with what we have. But I’m not.

My previous attempt

About two years ago I created a new IDE built in the same UI toolkit as the original (Java/Swing for those who are interested). It worked roughly the same but looked better. It had a proper text editor (syntax highlighting, line numbers), better serial port and board management, and a few inline docs, but basically worked the same; just some UI improvements.

I posted my new IDE on the Arduino forums and got almost no response. Pondering this for the past two years I realize this forum was the wrong place to launch a new IDE. The people there are experts. They are happy enough with their current tools that they don’t want to switch. They are experts. They don’t need all of the improvements that a better IDE could provide, like inline documentation and auto-library-installs. They are also more likely to simply use a general purpose IDE. I’ve done this myself and it works okay, but I’m still not satisfied. Arduino is special. It deserves better.

As the Arduino platform grows it needs a better out of the box experience. We have more and more novices hacking for the first time. We need an IDE that is truly top notch. Something that is custom built for Arduino, and the tasks that you do with it.

Some have asked me, “What do you want to do that the existing IDE doesn’t already?”. That’s a good question. If we are going to seriously invest in something new then we need some good reasons. Let’s start with the basics: installing libraries and boards.

Library management

Right now you find a library somewhere on the web, download the zip file, and unzip it into your ‘libraries’ directory. You do all of this outside the IDE even though you will be using it inside the IDE. Next you need some docs. There is no standard for the docs, but there’s probably something to read on the website you got the lib from. At least there are some examples. Oh, but they are buried deep inside a menu.

Now suppose it’s a month later and you are working on a new sketch. Do you remember all of the libraries you have installed? How do you search for them? Do you have the right versions? Do they work with all of your Arduino boards or just some of them.

It’s the year 2014. Why can’t the IDE just already know about the libraries out there. It should let you search for them by name or keyword. It should let you search through the example code. Once you find the library you need it should install it for you automatically. Where does it go on disk? Who cares?! That’s the IDEs problem. Finding and installing a library should be a single button click (or maybe two clicks if we are picky).

Board management

The many Arduino boards are listed in a nested menu, derived from the boards.txt file. This text file is only updated when the IDE itself updates, which isn’t very often, and the list isn’t comprehensive anyway. If the board you need isn’t listed then you have to add it manually, outside the IDE, duplicating the effort of other developers everywhere. Why can’t the IDE just fetch a list of all boards from the internet somewhere; a list updated by the actual vendors of those boards, so it’s always up to date.

This list of boards actually contains quite a bit of useful information, like how much RAM is in that board. However, this information isn’t actually shown anywhere. It’s only shown to the compiler. The IDE should give you full specs on your chosen board right on screen so you can refer to it whenever you want. Furthermore, the IDE should have extra board info like the number of pins, the input and output voltages, and if we are being generous an actual pinout diagram! All of this information is available on the web, just not in your IDE.

The IDE should just do all of this for you. Choose your board from a gigantic list downloaded from the internet. This list includes detailed specs on every known board, updated as new boards are made. You can refer to the board specs in a side pane, and even correlate the pins in your sketch with the pins on the board reference. This isn’t rocket science folks!

So you can see, there’s good reasons for a new IDE. This is before I’ve gotten to forward looking features like a built in Firmata client or data analysis tools. It’s time. Let’s build this.

Now for something completely different

Two years ago I tried by recreating the IDE in the same form. Now I want to do something different. I’ve started a new IDE completely from scratch, written in NodeJS and HTML. While it does use web rendering it won’t be a cloud based IDE. It will still run locally as an app, but using newer GUI technology than Java Swing. Don’t worry, you’ll have a proper app icon and everything. You won’t know it’s NodeJS underneath. It’ll just be a nice looking GUI.

Since it’s a back to basics effort I’m calling this new tool Electron, the fundamental particle of electronics.

So far I have basic editing, compiling, and uploading working for an Uno. I’ve also built a system for getting installing libraries and board definitions from the Internet using a git repo. This separate repo will contain a JSON file for every known library and board. Currently it has the basics from boards.txt and a few libs that I use, but more will come online soon. If you want to help, adding to this data repo is the easiest way to start. Pull requests welcome.

Electron IDE repo

Arduino Data repo

Here’s a rough screenshot. The GUI will greatly change between now and the 1.0 release, so just think of this as a guideline of the final look.

If you are a Node/HTML hacker please get in touch. There’s tons of work to do. Even if you are just an Arduino user you can help by providing feature requests and testing, testing, testing.

Thank you. Let’s bring Arduino development into the 21st century.

One of the benefits of my job at Nokia is the ability to do indepth research on new technologies. If you follow me on G+ then you know I've been playing with 3D printers for the past few months. As part of my research I prepared a detailed overview of the 3D printing industry that goes into the technologies, the companies involved, and some speculation about what the future holds; as well as a nice glossary of terms. Nokia has kindly let me share my report with the world. Enjoy!

3D Printing Industry Overview

I recently got a 3D printer and boy are my arms tired!

A bit tongue-in-cheek, but yes 3D printers can be a pain to set up. While I love the concept of 3D printing, the industry is currently in the pre-Model-T phase. There are hundreds of models, mostly incompatible, and they require a lot of futzing and tweaking to get them working properly.

The good news is that 3D printers are getting better very quickly. In the two years I've followed the technology prices have dropped in half and quality has doubled. Exciting stuff, but until a month ago I hadn't actually jumped into the 3D printing market myself. That all changed when I saw the Printrbot Simple.

Printrbot Simple, $300 kit

The Simple is a $300 from Printrbot. While most of their printers now come pre-assembled, the Simple is still available as a kit, and for an amazing price. I knew going in that it would likely have limitations, but I can honestly say it was more than worth the price. The prints aren't perfect, but they are pretty good. It's been a great introduction to 3D printing and I expect to make lots of things over the coming months.

Calibration object at 3mm, gray PLA, Printrbot Simple

The Simple is cheap through clever engineering and the fact that you have to assemble it yourself. For an extra $100 they will pre-assemble and calibrate it for you, but if you are serious about 3D printing I think you should build it yourself. It was an amazing learning exercise and gave me a crash course in mechanical engineering.

All that said, I ran into some hiccups during the initial assembly and calibration. I only got decent prints after a few days of futzing. I expect lots of people will be opening Printrbot Simple kits Christmas morning, so I thought I'd spare those happy new Simple owners (perhaps you are one of them) my headaches by writing a new getting started guide. Behold!

Getting Started with the Printrbot Simple

read for moar

This guide started out as my notes while building the kit, but after photos and forum feedback turned into an epic four thousand word epic tutorial. Did I mention it was epic? I didn't plan to write that much; it just kept going. And you, gentle reader, are the benefactor.

I've tried to not just cover initial setup, but also teach basic 3D printing terminology. When you start getting into 3D printing as a hobby you will immediately come up against terms like E value, PLA, and hot end. Needless to say these can be confusing to the new enthusiast. I've also included a trouble shooting section to cover the most likely print failures you will face. With pictures. Lots and lots of pictures. Oh, and the source for the whole thing is on github.

Dubai and Dubluck

I love symbol fonts. My new favorite is Font Awesome, an open source font with over 300 icons. Symbol fonts are great because they are pure vectors. They scale with everything else in your page and look pixel perfect on any DPI display, retina or otherwise.

However, sometimes I really just need an image. While working on an iOS application I wanted to use an image for a button. Finding decent iOS icons can be tricky, but Font Awesome matches the new iOS 7 look pretty well. Of course Font Awesome is a vector font and I need an PNG? What to do.. What to do..?

Well, I could have used Photoshop to rasterize that one glyph, but that's kind of a pain. Especially if I have to go through the whole process for multiple glyphs. What I want is a rasterizer that will generate an image for every glyph in a font. I hoped someone had already done this for Font Awesome, but I couldn't find one. Sometimes you've just got to do it yourself.

So this is my font slicer.

Please Click to view the demo.

The FontSlicer is a pure HTML5 app with everything done client side. I first tried to find a NodeJS server side rasterizer but in the end just went with HTML5 Canvas.

The really cool part is that you don't download a single image. Instead it renders a small PNG image for each glyph in memory using `Canvas.toDataURL` then streams them into a zip file that you download. This is thanks to the handy JSZip JavaScript library. Because everything is client side nothing is actually downloaded from the server after the page loads. I thought that was pretty nifty.

or, an epic post in which Josh declares his boredom of smartphones, creates a new world order, and redirects this site towards evil purposes.

I Am Tiredman

I am tired of smartphones. It's true. They are done. Baked. And boring. It's not that I don't like mine. It's just that I don't see anything interesting in them anymore. I'm happy to use one, but as a career target for innovation I feel they are done. Before you jump all over me about how I could possibly feel this way when I work for a smartphone company please allow me to explain.

I've spent the last seven years championing underdog platforms. First it was Swing, then JavaFX, then webOS. Throughout it all I saw the progression of smartphones from promising niche technology (my Treo 300 -> Treo 680) to ubiquitous consumer product. This really is a good thing. We now have the ability to check our email, take pictures, listen to music, and design killer apps for a class of tiny devices with immense computing power on a miserly power budget. Simply astounding! The future is now, people, the future is now.

So why am I bored? Because we are basically done. We know what a smartphone is now. There will certainly be innovation in the next ten years, but the iPhone 9x won't look too much different than the iPhone 4s. It will be a slab with a touch screen running apps. We know roughly what it will be. It won't be some new form factor that will blow away the competition (Google Glass is interesting but it won't take the place of smartphones. It's … something else).

This type of thing has happened before. In the early days of automobiles there were all sorts of crazy designs that we could never drive today. Some used levers to steer. Some actually used reigns like the horse and buggy. Eventually things settled down by the 30s resulting is the classic design of a car. A car of today would not look unrecognizable to a person from the 30s. The only huge advance was the automatic transmission, doubling the number of people who could successfully drive a car. We achieved the final form of the car. Everything after that has been incremental improvements. Great improvements of course, but incremental. That's where we are with smart phones, or in many ways "Personal Computing". With the advent of a smartphone now anyone can use a computer to be productive. Good job old chaps. Well done, I say good sir. Well done. Indeed.

So now what?

The Big Picture

The winding down of HP's webOS business and my new non-product position at Nokia has afforded me the time and vantage point to look at the big picture. I'm no longer involved in the phone OS wars. My favorite phone is now 'all of them'. I actually have a Lumia 800, iPhone 4S, Galaxy Nexus, Pre3, and the legendary Meego N9. Finally I've had a chance to catch my breath and get some perspective. Along the way I've noticed a few trends that I think will shape the next 10 to 20 years (limiting myself to computing technology).

We are turning atoms into bits.

Replacing atoms with bits is incredibly powerful. We can lower costs, increase reliability, and expand access to technology that was previously only available to the few. At it's best, turning atoms into bits not only improves the efficiency of existing things but makes new things possible.

Take for example quad-copters. These small cheap flying vehicles really came out of no-where, or at least it seems that way. They are cheap and surprisingly good. They are made possible by the decades long development of cheap sensors and open source software. An autonomous flying vehicle used to need lots of mechanical parts for navigation as well as an physical shape that would be aerodynamically stable. Additional stability implied additional size, weight, and cost. A non-stable vehicle is unthinkable because no human could react fast enough to pilot it.

The magic of drones is that they are controlled by a computer system fast enough to keep up with an unstable system. This removes the constraints of aerodynamic stability resulting is a drastic cost and weight reduction. Bits replaced atoms. Now that quad-copters are accessible we can think about doing truly new things with them, like hovering servers and taco delivering robots. A big enough change in efficiency allows a qualitative change, not just quantitative. Quad-copters are just the beginning. I expect we will finally get our flying cars this way.

Bits can replacing and controlling atoms creating so many new opportunities. I am very excited by the possibility of 3D printers and home CNC machines. For a few hundred dollars you can build a machine that will carve wood, drill precise holes, create circuit boards, and draw pretty much anything. For a few hundred more you can have an additive 3D printer.

This is a trend that is just starting to pick up steam. I can't wait to see where it leads. If we can really build it. Which brings me to my next point.

We are tracking our atoms with bits

Tracking and controlling our atoms is part of the next big thing. Yes, we've been doing this in some form since the dawn of the industrial revolution but I have never see the technology become so democratized. Take a look at Kickstarter. Count the number of projects that are trying to let people build their own contraptions, program their own hardware, and monitor their own world. I think we can take Kickstarter as a leading indicator. We are nearing a big change of some sort centered around sensors and actuators.

Sensors and actuators are the interface between software and hardware. I'll talk more about this in the future, but suffice it to say: programming physical objects is like a breath of fresh air. Software feels more real when it does something beyond calculating math more efficiently.

We can't dream big anymore

I realize this sounds like the opposite of what I've just previously said, but please hear me out.I feel like we are a very risk averse culture now. Children can't run on the playground at school anymore for fear of lawsuits (yes, I am serious). In the 50s we dreamed of space colonies, now we can't leave low earth orbit. The original Empire State Building was constructed in 13 months. Today you can't even file the paperwork for the site that quickly. We know how to make expensive buildings but not grand ones. Can you imagine anyone commissioning a building as elegant as Grand Central Station today? I wonder if we just can't dream big anymore.

The smartest engineers of my generation are currently spending their collective brainpower trying to get people to watch more advertisements instead of building the next world changing technology. This is just sad to me. Where will the next Steve Jobs come from if we are just making companies to be sold to Google and Facebook?

I'm a futurist. I'm obsessed with old visions of the future, especially the 1950s. I love the positive view of the future we used to have. How did we stop dreaming? Where are my floating cities and intelligent androids? Where are my replacement kidneys and synthetic eyeballs?

I'm clearly not the only person thinking along these lines.

Next Steps

Many of my interests are converging and I feel like I'm at an inflection point in my career, so it's time to change this site to fit.

I can't talk about my job at Nokia, but I can assure you it's not to build new phone apps. But I can tell you that I'm a software guy. I'd love all hardware to be emulated. It's turtles all the way down. But the realness of controlling physical atoms is intoxicating. During my week at OSCON I filled up on talks about home automation, Arduino, and embedded computation.

• Connecting iOS to the open source world with Arduino
• Arduino Hacking 101: Importing the Universe
• Arduino & Handbag: Create Android Accessories Without Android Code
• Building a Home Automation Server
• The Yocto Project: Professional Tools for Embedded Linux
• Bonescript: Simplified Physical Computing with Node.JS

I've been doing this blog for three years now. I've focused mainly on software and user interface design. It's time for some changes.

First, I have released my book HTML Canvas Deep Dive as open source. I suspect I won't be able to maintain as much as I like, so the best way to have it live is to give it to the world. It's cur currently in GitHub awaiting pull requests.

• Read the book
• github project

Next: Physical computing. I have several projects on my plate around physical computing. I've been doing more with Arduino and ARM chips lately. I've also purchased some stepper motors and a set of extrusions from Open Beam to build my own CNC machine. I'll be blogging as I do this, so look for more posts around building actual real physical things, from the point of view of a software guy learning about hardware. It should be enlightening.

And finally. I can't make the world dream big again. But I do know people who are dreaming big. My mission, which I have chosen to accept, is to bring their stories to you. I am starting a new series of long form innoviews with innovators. (get it? inno-views? inno… ah, never mind). I haven't decided if these will be recorded or written, but I hope to bring out not just what these people are working on but why they do what they do. What drives them to push the boundaries? And what do *they* see as the important challenges ahead?

My blog posts will continue to be about design, and thus the name of this blog, but more on the design of physical things, their interaction with computation, and the design of things by innovative people with a vision of the future they want to see.

I hope you will enjoy the next three years even more than the last.

After 5 amazing years at Sun I have decided not to move on to Oracle. Instead I will be joining Palm as a developer advocate for the WebOS. The WebOS is an open platform with an exciting future on a variety of Palm devices, which I'll talk about in great detail soon. For now though, I want to talk about Sun, why I'm leaving, and the future of Java & JavaFX.

I joined Sun in 2005 to work on the Windows L&F for the Swing team. Since then I've been on several different teams, always working with some incredible engineers. First the Swing team, then the NetBeans team to work on the GUI builder, then the JavaFX team to work on the designer, samples & docs, and general development. Finally I've spent the last year working on the desktop client for the Java Store, written in JavaFX.

I didn't start working with Swing at Sun, though. I've actually been doing Java GUI stuff since before there even was a Swing toolkit. In 1995 I learned Java at the recommendation of my favorite TA, Ian Smith. He was convinced that Java was the future of OO languages, not C++. Shortly after I began writing AWT graphics hacks, creating the world's first (to my knowledge) Java ray tracer in 1996. I then spent my last year at Georgia Tech working for Scott Hudson on an experimental GUI toolkit called SubArctic. (the demos should still work, actually). That work led to my one year internship at Xerox PARC where I got to work with Studio RED and met Marc Weiser (who foresaw of today's smartphone and embedded computing revolution). I even got to have dinner with Alan Kay when he was at Disney. (FYI: Alan Kay is the man who invented everything in the 1970s, including the iPad).

After PARC I worked in a few startups doing interface architecture and view engines until the dot-com bust. As required by law, all programmers in Atlanta must work at least one of the following: Home Depot, CNN, Cox, Verizon, Coke. I worked for Home Depot & Verizon, then joined Docucorp; doing various client & server side UIs for each. Finally, while at Docucorp, I started blogging on Java.net and wrote Swing Hacks with Chris Adamson. It was Swing Hacks which eventually led to the Sun position, and to where I am today.

So, from 1995 until the present I've spent my professional career working on Java GUIs of some sort. Now that it's the year 2010 (freakshow!) I've decided to start working with something completely different: HTML, JavaScript, and CSS on the WebOS. The Oracle transition seems like a good time to make the change.

Don't think that I'm leaving Java and JavaFX behind. I'm proud of the work we have done, from making UIs easier to code, to reinventing JavaDocs. JavaFX is a great technology with a bright future now that it will have Oracle's financial and marketing support. Now I'll just be involved with them from the other side, as a user and application programmer. I still plan to work on Leonardo, my wireframing tool in the Java Store. I've also got another release of MaiTai ready to ship when JavaFX 1.3 & Prism are out. The JavaStore is going to be a big part of desktop computing, and I look forward to buying lots of great apps through it.

Finally I want to thank my incredible colleagues at Sun. Rich, Jasper, and Amy: you've done a great job designing a GUI toolkit for the 21st century. Jeff, Jeet & Nandini. I've greatly enjoyed working in your teams. And most of all, I feel incredibly fortunate to have worked with the inventor of Java (and the Java Store), James Gosling. I still have your signed dollar on the wall of my office.

When I was in college there were five companies I dreamed about working for. Sun was one of those companies. All my wishes for a bright Java future.

This entry is my first Innovator Interview, Terence Tam, creator of the amazing Open Beam aluminum system launched on KickStarter. I first discovered Open Beam while doing research for my CNC machine. After being so happy with the product I contacted Terence for an interview. He graciously took time out of his busy schedule to speak with me about OpenBeam, how an engineer cooks a turkey, and lessons learned from running a KickStarter project. I think you will enjoy reading is as much as I enjoyed talking with him.

JM: Why don't you introduce yourself and talk about what OpenBeam is.

TT: Okay so, my name is Terence Tam and I am a mechanical design engineer. I have a day job working at a company that builds optical microscopes for biological sciences research.  I came up with OpenBeam in my spare time.

Prototype Quad-Robot.  Richard DeLeon, Metrix:Create Space

OpenBeam is an extruded aluminum construction system. In the industry it's called a T-slot extrusion and the name comes from the four T shaped slots that run down the sides of the beam. The thing that makes Open Beam different than most of our competitors is that it is an open source system. We publish all the mechanical CAD files, publish the engineer prints and publish all of the specifications, which is why it's called OpenBeam.

JM: So someone could make their own beam on their own out of some other material if they wanted to?

TT: Well, yeah, there could be someone using Kickstarter money for Tangi-beam out there, but more importantly the CAD files for all of the connectors are are freely available. You actually could print a set of them on a Rep-Rap if you like. It's probably not going to be cost effective for you to do so because we injection mold them and we run the mold in pretty high quantities which brings the cost down. So that brings me to the other part of what makes OpenBeam unique. Because it’s open source and crowd funded, I do not have investors to answer to. I designed the system for the lowest cost possible. I did this by injection molding the joining plates and use standard metric nuts instead of proprietary nuts.

JM: Is that common among other systems? To have special dimensions that require special parts?

TT: As far as I know pretty much everyone requires you to buy a special nut from them. And that's actually where most companies make their money. They sell the beam at ten dollars per meter which is a pretty common price, but then charge 30 cents a nut, and with each joint needing 3-5 nuts, this adds up quickly.

JM: Woah. So that's the razors and blades model.

TT: Exactly.

JM: Had you used some other extrusion before and then decide to go your own route?

TT: Yeah. I used 80/20 quite a bit early on in my tech career. I used to mentor for FIRST robotics (Dean Kamens For Inspiration and Recognition of Science and Technology program,) where mentors partner up with kids and we have six and a half weeks to build a robot. We used a lot of 80/20 for our competition robots. It's a nice system. It's a little heavy for competition use so we’d end up drilling a lot of holes in the extrusions where we didn’t need the material to take the weight off. But it is a very flexible system. I mean, with a team of kids we can give them a bunch of Allen keys and nuts and bolts and in four hours they can build a frame and start driving around, so it's definitely a very powerful system. For work we use 80/20 for some framing for prototyping and such. We've switched to OpenBeam at work, obviously.

JM: It's always good to eat your own dog food.

TT: Right. Definitely I use OpenBean for work projects and personal projects.

Kaloss Crate.  Matt Westervelt, Metrix:Create Space

JM: So do you have rack in your kitchen made out of OpenBeam?

TT: Um… that hasn't passed the girlfriend acceptance test yet but I use it a lot in my garage for storage. I have some robotics projects that are using it and some 3D printer projects. At work mostly I use it for framework for building test equipment.

JM: Now you said there is a 3D printer project. I notice you just posted on one of your several blogs about something called, what was it, lemon drop?

TT: Lemon Curry. Lemon Curry is actually a Rep Rap project. As far as I can tell there isn't an official Lemon Curry machine yet; it's still just a collection of links. But it's really a mission to build a DLP projector based resin printer. The common Rep Raps are all extrusion based or fused filament fabrication (FFF) machines where you have a spaghetti of resin passing through what is essentially a hot glue gun and depositing it using either an XY bot or a Rep-Rap style bot.

JM: And that's why a lot of the things I've seen produced that way, they sort of have these striated lines in them?

TT: Right, if you look closely at them you can see layers where the spaghetti has melted and re-soldered. You can see the different layers. In a DLP resin type machine your building material is actually a photo polymer, which is a kind of plastic that is tuned to harden into solid plastic at a very specific wave length of light. So there are resins that will harden at about 405nm and 385nm (UV range). At 405nm you can actually use visible light to hit the resin and it will cure. So the machine that I'm building takes the solid geometry and slices it and instead of trying to extrude with an XY print head, it's taking the cross sections and projecting it with a DLP project onto a vat of resin, and the part is pulled out of this vat.

JM: So it's doing an entire layer at a time, then?

TT: Yes and potentially it can build faster and you can hit higher accuracy with it. We are currently looking at using 100 micron in XYZ steps, at 100 microns the projector I'm using is 1024x768 so that 104x76.8 mm build space and you can hit 0.1 mm resolution. Each pixel cures a 0.1x0.1 mm area on the resin. So it's a pretty high resolution machine and the biggest advantage over a FFF machine is there won't be any delamination problems. In an FFF build, because of the way the layers are laid out the part is actually really strong in X and Y but if you flex it in the Z axis you can actually shear layers off. In a resin printer because of the way the curing process works the entire object cures in a solid block so there aren't layers that you can delaminate at a later time.

JM: So how close are you having your first print?

TT: I want to do this right. What I mean by "doing this right" is, I'm using OpenBeam, of course, and I'm using Open Rail as my linear bearing.  I'm developing a lower cost linear bearing carriage for Open Rail. The reason for doing this is, well, I love what the Open Rail guys have done but I think for 3D printer applications the V-groove bearings are a little bit expensive and, frankly, probably a overkill. So I'm trying to develop an injected molded part and I'm prototyping it by machining it out of production representative materials. I can test the plastic's self-lubrication properties. I'm probably four to six weeks away from my first print.

JM: So this would be a different carriage but it would still attach to the Open Rail?

TT: Yes, this would be a different slider carriage.  My design would be modular so people can adapt it for Maker Slide and Open Rail, and of course Open Rail + OpenBeam combinations. There are couple of dimensions I'm going for. Specifically if you are going to use the OpenBeam NEMA 17 motor mount you can put one of the OpenBeams on each side and that spans a 75mm gap. I'm designing it so that on a 75mm gap, if you put the Open Rail extrusions on the sides the carriage will slide right over that. You can put matching brackets on the other side, you can use a 608 bearing adapter to mount a tensioner pulley and so for about twenty five dollars total worth of hardware you now have a linear rail system. (My goal is to keep the carriage under ten dollars.)

JM: That would be great. When I first started looking into CNC machines I found the linear rail system was always the most expensive part.

TT: Right, and if we can drop the price on that and drop the price on the 3D printer electronics (and I know some guys at Metrix:Create Space working on that problem,) we can drop the price of a 3D printer significantly.

H-Bot Prototype.  Gavin Smith, Robots and Dinosaurs

JM: I'm curious, what drove you to decide to make your own company and launch a new product? Was it just that you wanted it to exist? I mean, lots of people came up against these problems but they didn't decide to start a company around it?

TT: Well, I think when you are building an open source hardware project like this you really need some sort of continuity. This can't be just a flash in the pan project on KickStarter. For all of the guys who've backed me on KickStarter, it would be a real shame if I tomorrow I decided "you know what I'm tired of this, I don't want to do this anymore". I kind of got the feeling that's what MakerBeam did. If you look at their history and you look at their fulfillment, yeah they fulfilled their KickStarter rewards but today if you want to buy MakerBeam the only place you can buy it is through Spark Fun in the

US. And you can only buy it in either a small or large kit. You can't buy individual components. It's a very restrictive purchasing model. So it's really unfair to all of the guys who have backed them because now they have a bunch of parts and can't get more. There's nothing worse than not being able to get more and build stuff. So at the beginning of the KickStarter I decided that I would spin up a company to do this, to handle fulfillment and ongoing support.

Now, truth be told, yeah the extra income source is nice, but I've actually reinvested everything back into my company. I setup the project in such a way that when I bought my first lot of extrusions I would have a lot of additional material left over. If people needed extra material they could order it from me and I could ship it to them. We have a web store up and running now at openbeamusa.com.

JM: So you planned this as a business from the beginning; something that would be sustainable?

TT: Right. I designed this to be sustainable. Someone else is handling fulfillment for me so when my day job becomes too busy I'm not delaying orders by three or four weeks before I can ship them. Someone else is doing the packaging and shipping. I decided to be a very hands off when it comes to day to day operations  My time with OpenBeam right now is spent on building the infrastructure and growing the community. I'm working on a forum right now. I'm working on getting open designs out there around OpenBeam so that people can reference them and design around them.

JM: The KickStarter ended fairly recently, right? May or June?

TT: It ended in late April, early May.

JM: When did your web store open?

TT: I never really announced it to the world but at the end of June it was running. For the first eight weeks I was more concerned about fulfilling the existing KickStarter pledges. With the exception of the trebuchet kits, which we are still building, tuning and

documenting, we've shipped all of our orders from KickStarter. The majority of them shipped in June with a few in July. We actually shipped earlier than the original schedule.

JM: I seem to recall you had some issues with actually figuring out how to mail heavy pieces of metal through the postal service.

TT: *laughs* Yeah. Actually it was FedEx.  We had all the orders ready to go but I didn't feel too confident, I guess.  So I randomly grabbed five orders and shipped them first. I was actually more concerned about the billing and the database merging and making sure that all the waivers are generated correctly, so I wouldn't be hit with a six digit FedEx bill. And then the reports came in like  "hey man, you shipped me an empty tube!" or "hey man, I got the extrusions and nothing else!". We later found out the tubes had been breaking open in shipping and FedEx had been sealing them back up for us.

JM: Well, that's a good thing to learn.

TT: So our backers received the orders fully sealed but all of the stuff on the inside was gone! So we put a ship hold into effect. We re-engineered the package. We actually did a bunch of drop testing. FedEx has a standard test. It's something like 6 drops from one meter onto a steel plate.  We engineered our packages to survive that at a minimum. Our package can withstand about twelve drops from eight feet onto concrete. We have this on high speed camera. We looked at the footage and documented everything. FedEx is in the process of certifying our packaging right now so we can get a discounted insurance rate from them. All of this is to put us in a better position so that when we put out a package we know that our customers will receive it in good condition.

It's funny. For most people who do a KickStarter, shipping and handling is probably the last thing on their mind. You go through such a long process to bring a project to life, but that last piece is so critical. The first thing that your customers will see is your packaging. If there is any damages when they open it all the hard work is washed down the drain. I wish I had paid more attention earlier on to my packaging. That's one of my regrets about the way that my KickStarter went. It's not bad right now, it does the job, but it could have been better.

JM:  I have to say all of the extrusion I ordered arrived in perfect shape. The metal caps on the end are sturdy. I had to get out my big pliers to open it.

TT: But the metal caps are about a buck fifty per package and that's not including the cost of the tubes. And it's a one time use cap. Once we pound that cap in there's no way to get it back out. Someone once ordered something, asked to upgrade the shipping to air freight, and asked me to toss in an extra screwdriver.  I was like, "Umm.. no. You've seen how we package these things." It's pretty much a destructive process to get anything out so… It does the job, but it's kind of a pain in the butt sometimes.

JM: It sounds like you've really designed this to be a coherent business that has a bright future. Are you planning to start ramping up production? Do you have advertising? Are you going to start working with retailers or resellers?

TT: Right now I'm more focused on the international backers. The reason for that is the challenges of shipping internationally are about five times bigger than shipping domestically. Domestically, if someone has heard about OpenBeam already, they know where to get it. The URL is molded into every plastic piece that we sell. Our existing infrastructure, although not great, will handle domestic orders just fine. Twenty percent of our KickStarter backers were international though. They come from all over the European Union. They come from Australia, New Zealand, the Pacific Rim region. I think I've got a couple of guys in Russia. Supporting these guys is important too, but it can't be a hundred bucks in shipping for fifty bucks in parts. So we are very actively trying to spin up international distributors. Solarbotics actually just became our first international distributor. If you are Canadian, SolarBotics.com actually carries OpenBeam components now. We are talking to someone in New Zealand and Australia. We are hoping to have Hong Kong coming on line as a distribution point. They will service Singapore and probably some of the other international orders until the EU guys have spun up.

So that's where my focus has been. I'd like to do some more advertising in the US. I'm actually kind of on a budget crunch right now so I'm not sure if running an ad is going to be the best way to do this, but I do a lot of "community outreach". So whenever I'm traveling, like in about three or four weeks I have to go to the Twin Cities Minnesota area for a wedding, I always see if there's a local hacker space. I bring an OpenBeam kit and I offer to buy them pizza. That's how I've been selling Open Beam in the US. And it works. I mean, not to sound cocky, but the product sells itself.  The guys who are into building things, they are my target audience; and they screw a couple of parts together and then they get it.

JM: I took some to our local maker space here and the guys were very excited to play around with it.

JM: So, after you get all of your shipping stuff worked out what do you think is the next step? Do you want to introduce kits? Bullk pricing? New brackets?

TT: So there's a couple of exciting things going on. We've actually partnered up with MicroRax and we're going to be offering pre-cut lengths and pre-cut construction kits. MicroRax will also have the ability to do custom length cut extrusions too. With that I can then offer a kitting service to 3D printer builders. There are a couple of plans out there for Rep Rap machines that use extrusions. I can actually offer a kitting service to guys who are designing 3D printers and my dealer pricing is very competitive, and the total cost of ownership is probably lower than Misumi when you factor in the bracket and fastener costs.

I plan to offer my design in a kit form as well. That competition will help lower 3D printer pricing across the board. I have a couple of friends at Metrix that are working on cheaper 3D printer electronics, so that's pretty cool. We are going to be releasing kits in conjunction with them. With the pre-cut kits, I'm probably going to be shipping some kits out for review and hopefully getting some interest and business that way.

Camera rig with iPod teleprompter.  Matt Westervelt, Metrix:Create Space

JM: I notice that you have a couple of other blogs. There's one for yourself and one for TamLabs, though it looks like you haven't updated them in a while. I'm guessing you've been very busy lately.

TT: *laughs*. Yeah.. So I have a personal blog at terencetam.com.  I think the last update is "okay guys! the KickStarter is going live!"

JM: And then you just fell off the face of the earth.

TT: Yup. I like to cook and I like to take pictures, so that's pretty much my outlet for documenting recipes and photos I've shot.

JM: Now did I see in the blog a turkey with wires hooked up to it?

TT: *laugh*. Yes you did. So there's actually a fun story behind that. That was the first time I had to cook for my current girlfriend's, actually soon to be fiancée's, parents. They tasked us with providing the turkey for the Thanksgiving dinner; for both of her grandmothers and her parents and a couple of aunts and uncles. Well, if you ask an engineer to cook a turkey on a barbecue that's what you're going to get. It's a couple of thermocouples monitoring the cooking process. We did a couple of test runs and we ate a lot of smoked turkey in the week leading up to Thanksgiving making sure that we got it down.

JM: So you had all of your trials beforehand. What was the final result?

TT: I thought it was a little bit over cooked to be honest, but they loved it. They said it was one of the moistest turkeys they've ever had. It would have been preferable to have two smaller birds instead of one big bird, that said... the thermocouples are accurate to three degrees centigrade so by monitoring the temperature you can pull it out the moment it's done. There's only about a fifteen degree range for white meat before it turns really, really dry, so that was why we had all the instrumenting and monitoring. It was a really cold winter day in Chicago so I kept the fire going, smoked it over apple wood, and it turned out okay.

JM: Well they liked it, that's all that matters.

TT: Yeah, they liked it! Exactly!

JM: Were you happy with your KickStarter experience? Do you think you would do another one?

TT: Yes. I am definitely looking into another KickStarter, probably one for the linear bearing block once I have it designed. There are some minor issues with KickStarter in how it handles data and the tools. After my last rewards ship out I will be doing a series of blog articles on my post mortem. I'll probably email the KickStarter team a link to it with some of the constructive criticisms of their websites. But overall it has been really positive.  The cool thing, and maybe it's because I'm in the open hardware / technology category, everybody has been really, really great and really understanding. When I had problems with shipping everybody was like "yeah hey. No worries. We understand. Delays happen. We'd rather that you sort this out before you take orders on the web-store". Not one person complained about the communications or the delays.

JM: Perhaps we are all just so used to dealing with beta software.

TT: Yeah. Certainly when you read some comments on the more consumer product oriented stuff, like the iPhone docks, you hear a lot more people complaining about "oh they slipped their dead line… This is bogus. The guys took their money and ran." I had none of that. I'm really thankful to my backers for that.

JM: When you launch your next product, why are you thinking of going with KickStarter rather than just making a run at trying to sell it?

TT: Well.  If you think about the percentage that they take, the 5% off the top of the project, it's some of the cheapest advertising you can buy. Open Beam raised over $100k. KickStarter took 5% of it, so just over $5k and another $5k or so went to Amazon credit card processing fees. For me to run a single run of ads in Make Magazine, that itself is going to cost $1500. Essentially for $5,000 I got a product that was publicized around the world. I look at the countries and continents that my backers are coming from and I say to myself, “holy crap.” Even on a $20k advertising budget I wouldn't know how to reach some of these guys. That alone is worth it to me.

The other thing that's nice with open hardware is that it takes a lot of the risk out of the picture. Especially with open hardware, where I'm publishing my drawings, my cad files, all the specifications, etc….

JM: I imagine you still have to have a lot of capital to do that initial order.

TT: Yeah, there's a bunch of capital involved and the same time my only protection is to move fast and keep innovating, and be reasonable about the prices I charge.

JM: I've been very happy with the beam. I'm heading forward on my own 3D printer.

TT: I'm really happy to hear that.

JM: What do you think people are going to build with OpenBeam? It sounds like robots are on the table and certainly 3D printers. What else do you think people would want to do with it?

TT: Just today I got an enquiry from someone building a Magic card sorting robot. I thought that was pretty cool.

JM: A magic card… oh the Magic the Gathering cards?

TT: Yeah. *laughs* There's a couple of guys in Spain working on a structured 3D light scanner and another gentleman is building his own hologram studio with OpenBeam. I'm hoping that he'll share some photos of what he has done.

JM: I'd love to see a project gallery on the site.

TT: Yeah. I'm working on that too. There's some pretty cool projects in the works, definitely. There's a school in Marin County that just bought a bunch of OpenBeam so I'm guessing their students will be building a bunch of robots.  The cool thing about being a construction system like this is you do get a lot of creative folks. Watching what they come up with is quite a reward.

JM: Awesome.  Thank you Terence!

If you saw my tweet about porting Chrome to the Roku, I'm afraid it was, indeed, an April Fools joke. I didn't actually rewrite Chrome in a TV scripting language. However, I did build something cool.

When you build software you have to map between two things. First is the representation that you develop with: your code, your graphics in photoshop, your CSS.. whatever it is. It's the thing you actually manipulate. Then you have the actual visual representation of the thing you are building: the app running on a real device, the page in the browser, the executing game.. whatever it is you are actually making. I believe software improves if we can minimize the distance between those two representations.

I suggest you watch Bret Victor's amazing presentation on the topic. It's long (1hr) but completely worth it. I have been a believer in this philosophy of minimizing editing distance for some time, but Bret explains it better than I ever could.

But back to the Roku

The Roku is very easy to develop for, but it still requires writing some code, turning it into an app, and installing it into the device. While not hard, it can be annoying. It also increases the distance between the editing and viewing representations. So, I decided to build a Roku power-up in Leonardo Sketch.

If you are new to my blog: Leo Sketch is an open source vector drawing tool I've been working on for a while. It can export to SVG, PNG, PDF, and JavaScript. The Roku power-up will export your current drawing into a Roku app, then compile and launch it. It is just a static image on the screen at this point, but it's a good start. In the future you will be able to add behavior and animation to the graphics. The Chrome April Fools hack was just a screenshot of Mac Chrome I had lying around, exported to the Roku through this plugin.

Leo Sketch Power Ups

Now you might be wondering what a Leo Sketch 'power up' is. It's a new kind of plugin system I'm working on, currently only available in an experimental branch. (the 'powerup' branch, if you want to try it out). Powerups are like plugins except they only have an effect when you explicitly activate them. This solves a lot of problems with traditional plugins, plus it enables a few new interesting things. I'll cover powerups more in a future blog. For now, just know that they will be awesome, and Leo Sketch will soon be exporting to far more than static image files.

Stay tuned.

When working on big projects I often create little projects to support the larger effort. Sometimes these little projects turn into something great on their own. It's time for me to tell you about one of them: AppBundler.

AppBundler is a small tool which packages up Java (client side) apps with a minimum of fuss. From a single app description it can generate Mac OSX .app bundles, Windows .EXE files, JNLPs (Java Web Start), double clickable jars; and as of yesterday evening: webOS apps! I started the project to support Leonardo Sketch but I think it's time for AppBundler to stand on it's own.

Packaging Java apps has historically been an exercise in creative swearing. The JVM provides no packaging mechanism other than double clickable jars, which are limited and feel nothing like native apps. Mac and Windows have their own executable formats that involve native code, and Sun has never provided tools to support them. Java Web Start was supposed to solve this, but it never took off the way the creators hoped and has it's own idiosyncrasies. Long term we will have more a more environments with Java available but with different native package systems. Add in native libs, file extension registration, and other metadata; and now you've got a real problem. After hacking Ant files for years to deal with the issue I decided it was finally time to encode my build scripts and Java lore into a new tool that will solve the issue once and for all. Thus AppBundler was born.

How it works

You create a simple XML descriptor file for your application. It lists the jars that make up your app along with some metadata like the App name and main class. It can optionally include icons, file extensions, and links to native libraries.

<?xml version="1.0" encoding="UTF-8"?>
<app name="Amino Particles"> 
   <jar name="Amino2.jar"/> 
   <jar name="amino_sdl.jar"/> 
   <jar name="examples.jar" 
         main-class="com.joshondesign.amino.examples.Particles"/> 
   <property name="com.joshondesign.amino.impl" value="sdl"/> 
   <native name="sdl"/> 
</app> 

Then you run AppBundler on this file from the command line along with a list of directories where the jars can be found. In most apps you have a single directory with all of your jars, plus the app jar itself, so you usually only need to list two directories. You also specify which output format you want or --all for all of them. Here's what it looks like called from an ant script (command line would be the same).

 <java classpath="lib/AppBundler.jar;lib/XMLLib.jar" classname="com.joshondesign.appbundler.Bundler" fork="true"> 
<arg value="--file=myapp.xml"/> <arg value="--target=mac"/> <arg value="--outdir=dist/"/> <arg value="--jardir=lib/"/> <arg value="--jardir=build/jars/"/> </java> 

What it does

What about webOS?

How you can help.

Client Java Freedom

References:

• AppBundler download
• Leonardo Sketch (& AppBundler) developer mailing list
• Avian, embedded JVM
• JSmooth

Amino 1.1 is on it's way, and despite the small version number difference the changes will be big. We are dropping Java support and heavily refactoring the JavaScript version.

First things first. I'm dropping support for Java. I have gotten essentially no downloads or feature requests for the Java version of Amino which tells me that almost no one is using it. If you want to do desktop Java graphics then I suggest moving to JavaFX. It is well supported and received many excellent updates in the past six months; and it's open source now. If I had known JavaFX was going to reboot with a pure Java version with great hardware acceleration then I probably wouldn't have started Amino to begin with. Leo itself will stay on the older version of Amino until I can get it ported, but no new features will go into the Java port. I highly suggest you check out JavaFX 2.1, now in beta. It even has WebKit integration.

Second, I have done a big refactor to the JavaScript port. The API will change only slightly. The big changes are under the hood in the way it handles animation and multiple canvases (canvii?). Now you can have a single core Amino engine per page that supports multiple canvases. They will all repaint quickly with minimal tearing while being as efficient as possible. This is a must on mobile devices, and in ebooks where multiple canvases per page are common.

Other stuff of note:

• Bitmap Text: support the custom styled font output of Leonardo Sketch using dynamic bitmap sprites.
• Animate DOM elements as well as shapes on the canvas.
• Improvements to the animation api to support chaining, parallel animations, callbacks, and before/after actions.
• Split into three files: core, shapes, and bitmap effects. Now you can do cool animation without including the scripts you don't need.
• New API documentation.
• Simple integration with Three.js for 3D objects with 2D canvas
• Touch events for mobile devices.

Not everything is in the beta build yet, but it will be coming soon. Please try it out and give me feedback.

An open letter to language designers: please, for the good of humanity, kill your sacred cows. Yes, i know those calves look so cute with big brown eyes and soft leathery skin, but you know what? Veal is delicious!

Let me preface this by saying that I am not writing my own language. The world doesn't really want a new language, especially one from me. I made one a few years ago. While only a few dozen people were horribly maimed, I still consider it a failure and don't wish a repeat experience. The world does not want a new programming language, especially from me. But since you are hell bent on creating a new one, you might as well make it an improvement.

So open up your looking balls and point them right here. Our sacred cow wilderness safari begins now. Buckle up! It's going to be a long and awkward ride.

Lets start with the big cow, since it leads most of the ones that follow.

Cow #1: source code is ASCII text on disk.

You may think the storage of source code isn't really a language issue, but it is. A programming language isn't just the language anymore. It's the entire ecosystem around the language; including editors, libraries, source control systems, and app deployment. A language in isolation is so useless it might as well be LISP. I don't mean that to demean LISP, the badass godfather of languages. I mean it as: if you aren't thinking about a whole ecosystem then your language will mathematically reduce to LISP, so why are you bothering.

Back to the topic at hand. This is the 21st @#!% century!! Why, for the love of all things pure and functional, are we still storing our source code as ASCII text files on disk? One answer is "that's how we've always done it". Another is that our tools only work with text based code. So what?! I have a ten 1GHz devices sitting on my shelf unused and a 4 way multiprocessing laptop. Why are we being held back by the ideal of ASCII text? This cow must be shot now!

If we switch to using something other than text files, say XML or JSON or maybe a database, then many interesting things become possible. The IDE doesn't have to do a crappy job of divining the structure of your code. The structure is already saved. It's the only thing that's saved. The IDE can also store useful metadata along with the source and share it with other developers through the version control system, not through comments or emails. We could also store non-code resources, even non-text resources, right along with the code. Oh, and tabs vs spaces, style issues, etc. become moot. But more on that later.

Oh, and before you ask, putting your files in a directory structure and calling them 'packages' doesn't count. Think beyond the cow corral.

Cow #2: source code must be editable by plain text editors. IDEs should be optional and unnecessary.

Cowpatties! Unless you write your code exclusively with echo and cat, you are already using an IDE. A plain text editor is just an IDE with no useful features. We all use IDEs, the question is how much functionality does it provide you. When programmers say they shouldn't have to use an IDE, what they mean is they shouldn't be locked into using someone else's favorite IDE instead of the one they prefer. (I wouldn't mind being locked on a desert island with IntellJ, for example but I'd commit suicide if I was stranded with Eclipse).

Rejecting an required IDE is an issue of having specs and multiple implementations, not the concept of IDEs in general. I don't draw graphics in a text editor, I use Photoshop. The problem is that Photoshop has a closed file format that must be reverse engineered by Gimp. To go without an IDE is to go without 20 years worth of UI improvements. We are building a 21st century language here. Assume an IDE and plan for it. Cow dead. Yummers!

Cow #3. Less syntax is good.

No. While technically a language can express everything using just a nested tree structure (ala LISP) that doesn't mean it's a good idea. Syntax matters. Programming languages are user interfaces *for programmers*, not the computer. They let the programmers express what they want it the most convenient way possible and have the compiler talk to the computer. Certainly syntax can be too cumbersome or verbose, but that is about giving the programmer more to remember. Minimal syntax isn't the answer. The more specific the programmer can be the better. We want to give as much information as possible to the compiler so it can generate efficient binary code (where 'efficient' varies depending on the problem domain).

Minimal syntax is seductive because we like the idea of being concise and typing nothing extra. This is all very well and good. But the solution isn't to remove syntax, but rather make it optional. If the compiler can figure out what the programmer means without extra parenthesis and semicolons, then great, but let us add it back in if we want clarity. Make typing our variables optional for when we are hacking, but let us be more strict when we get to production. The syntax needs to scale with our needs, not yours. Oh, and what do you think of my nice leather wallet?

Cow #4. Holy wars: Whitespace. Indenting. Bracing. Tabs vs Spaces.

Irrelevant. Completely irrelevant. This is a style issue that can be enforced (or not) by the IDE. As long as it saves the source in a canonical format you can edit the code in any style you want. If you want to hide braces, do it. The IDE will handle the details for you. If you want to use square brackets instead of parenthesis, do it. The IDE will convert it. A funky syntax for escaping multiline text? Who cares. I can paste it into the IDE and it will deal with it. If you want to use dingbats symbols instead of keywords, do it. The IDE will handle it. (hmm. that's not a bad idea, actually. Have to think about it some more).

These are holy wars that matter unreasonably much to us but have not practical difference in the real world. Simply specify the semantic meaning and let the dev choose what they wish. Having good defaults matters, of course, but don't allow your cool new language to get trapped in the tar pit of programmer holy wars. Leave that for the cows.

Cow #5. What the world needs is a better type system.

No. The world doesn't care about yet another cool type system. You won't get programmer adoption by emphasizing how awesome your types are. No one will say: "Woah! Check out the type system on that one!". What the world needs is good modules. An escape from classpath hell. The ability to add a new module and know it will work without modification and without breaking something else. Let the compiler rewrite anything inside a module without affecting the outside. Fix versioning. These are those hard problems that need to be solved, not type systems. My code won't get magically faster and bug free through your awesome type system. Another cow bites the dust.

Cow #6. We must not let programmers extend the syntax because they might do bad things.

So?! We are adults. Let us shoot ourselves if we really want to. Let us override the syntax of the entire language if it would help us solve real world problems. Just make sure the changes are cleanly scoped, then let us have at it. The amazing success of JavaScript has been because it was so flexible that real world programmers could try different things and see what works, in the real world (seeing a common theme here?). Usage of JavaScript has evolved tremendously in the past decade, so much so that you could say the language itself has evolved (even if the syntax changes have actually been minimal).

So, no. Your language doesn't need to provide X. The language should programmers build it themselves. One more cow down the drain. Get your swim fins.

Cow #7. Compiled vs Interpreted. Static vs Dynamic.

Nobody cares. All languages are compiled at some point, the question is when. All languages live somewhere between the platonic ideals of static and dynamic. If we can get useful work done then we don't care where your language fits mathematically.

Cow #8. Garbage collection is bad.

No. Garbage collection is good. It has increased programmer productivity tremendously and eliminated an entire class of bugs (and security exploits). The problem is garbage collection isn't perfect. So grow your hair long enough to escape from your ivory tower and fix the GC, don't eliminate it.

GC systems often have bad nondeterministic performance, especially in interactive applications. They treat all objects the same. They provide the programmer with no-insight into what is actually going to happen. So improve the GC. Let us give it more hints about what we actually want. Why should the GC system treat my cached textures the same as a throwaway string. This is also a place where better IDE integration would help. If you make it easy for me to see where GC might be a problem then I, the programmer with the knowledge of what I'm actually trying to accomplish here, can provide the compiler with better information. Research modern infoviz. Get out of your pure text mindset.

We can rebuild this GC cow. We have the technology.

In memoriam

I hope I've provided a bit of guidance before you go off to your language shack in the woods and come back with type safe encapsulated 'genius'. Once again, you really shouldn't be building a new one language anyway, we have more than we need. Please, please. please, don't make a new language. Since you are determined to not heed my warnings, the least you can do is not injure the world further.

And please kill a few cows on your way out.

Below is a screenshot of a debugging app I've been working on called SideHatch. It essentially lets you open up your Amino app from the side and poke around at the innards.

In the screenshot you can see the two main tools: the Translator and the Inspector. The Translator shows all strings in your application that have been translated, broken down by category and locale. From here you can update translations and switch locales on the fly. The app will automatically refresh itself to show the changes without a restart.

The Inspector puts an overlay into every window showing the bounds of every control in your scene. Then you can move the mouse around to get info on particular components, like it's dimensions and translation. In the screenshot the indicator is telling me that the button I've hovered over doesn't have a translation yet.

SideHatch is currently in the 'translation' branch of the repo if you are interested in playing with it.

This is a short video (~6min) where Tim Berners Lee (Mr. Web himself) talks about the successes of open data. Take special note of the end section where the Open Street Map project is used to help relief efforts in Haiti after the earthquake.

Watch it now!

I hate smartphone lock screens. Not the concept itself, but the many implementations. Everything I’ve seen is too minimal or too complex. This is prime real estate we are talking about. Surely we can do better. Since it’s been on my mind a lot lately I thought it would be fun to redesign the lock screen starting with first principles. Note: I’m a researcher at Nokia by day. This blog and the opinions on it have nothing to do with my work at Nokia. All ideas are my own and do not reflect anything Nokia is working on. This post also does not reflect a desire on my part to actually build a new lock screen for any OS. This is purely a design exercise to explore the space and see if we can do better.

android image from xda-developers.com. (i know it’s a modified rom, but it illustrates the point)

At the beginning

What really is a lock screen for after all? It’s original purpose was to protect the phone from unwanted input, either by accidentally pressing buttons or an intruder reading your email. While this is still the primary purpose; the lock screen, by virtue of being the easiest place to access on a phone, is where we put lots of extra information like the time or recent calls. In recent years phones, especially Android phones, have created an explosion of new widgets and dashboards on the lock screen. It’s getting out of hand and still doesn’t use the available space as well as it could. We need to start over from first principles.

Fundamentally a lock screen dashboard is about presenting status at a glance. This is the status of anything on the phone, from wifi and signal to time to location to incoming messages. Here’s a list of ‘status’ items I just thought up:

• current weather conditions
• battery / power charging
• currently playing music / other audio
• calendar
• todos
• alarms
• a running stopwatch
• location
• Facebook notifications and photos
• emails
• tweets
• SMS messages
• and of course the first thing to go on the lock screen: time and date

I’d also like to mention the following which aren’t statuses but which are commonly found on lock screens. I’ll talk about what to do with them later.

• quickly record a note
• quickly snap a photo
• contact info if lost. technically that last one isn’t status, but it sure would be useful. perhaps a remote request to put the phone into ‘lost mode’ which then shows that info on the lock screen.

Status at a Glance

So we have a long list of statuses. How should we present them? We can’t list them all, there wouldn’t be room. Should they be interactive? Animated?

First of all, I’d like to go back to our original definition of the lock screen: “status at a glance”. The 'at a glance' part is very important. The user’s only required interaction should be pressing the power button to toggle the screen. Too many lock screen widgets want you to interact with them. Anything which allows interaction violates the ‘at a glance’ principle, plus we get back to the purpose of the lock screen: to prevent accidental input. Anything which accepts input on the lock screen could be accidentally pressed.

Let’s break down the problem into chunks. The obvious solution is to list all of the items vertically. This would be too long for the screen, especially if you have a lot of social media notifications. We could scroll but that requires interaction and means you can’t see everything at a glance. Let’s start by removing unneeded things. The alarms are only present if you have an alarm. Most of the time we won’t have an alarm so we can hide it. The same applies to the stopwatch and music interface.

Next let’s focus on only the current items. This is about current status after all. That means the alarms should show you only the next upcoming alarm. The same with the calendar and todo items. These all have an inherent order and timeliness. By only showing what’s next we can help the user focus on what is important as well as reclaim a lot of screen space.

Notifications

Now, about those Facebook and Twitter notifications. I hate them, but some people like to have them. Let’s keep the noise down by only showing direct replies or posts from your most personal group. In Facebook this could be family or friends, or simply the 10 people with the most interaction between the two of you. Google + has circles to indicate importance. I’m not sure about Twitter. Followers only? The user could tweak these settings, of course, but good defaults are important.

Next, let’s collapse those notifications into a single line by platform. All Facebook notifications into a single line. All tweets in a different line, etc. The line shows the first notification and a count of total unread messages. This system works well for email and SMS messages as well. To keep it current let’s always show the most recent notification by default. Then if you view the screen, turn it off and more come in while you are away but before you actually log in to dismiss notifications, then you will still see new information when you turn on the phone again.

This presents a dilemma though. If you’ve got three new @replies on Twitter we have the information to show them all, but we don’t want to take up the screen space. There is a temptation to show the messages as some sort of scrolling list or carousel, but this would violate our ‘at a glance’ principle. What to do? What if we modify our rule slightly. It’s okay to allow interaction while locked as long the interaction is read only. The user can’t dismiss notifications or reply to messages as those would change fundamental state. We only allow simple navigations where the cost of accidental interaction is low. Accidentally swiping through a list of tweets in my pocket is not a big problem. Butt-dialing is.

So, with our new modified rule we can collapse the tweets into a single list item scrollable horizontally like a carousel control. This system works with anything that has multiple ‘current’ items: email, alarms, todos, calendar, etc. To preserve our principle of only allowing read-only interaction let’s reset the current item to the most recent whenever something new comes in, or after a timeout of 10 minutes.

Weather

Great, now we’ve shrunk or completely hidden most information, reclaiming much of our lock screen. Now let’s get into a few corner cases starting with the weather: The weather should always show your current location, unless you are flying to another city in which case you couldn’t get weather data anyway. It should indicate what location that weather is for and how long it has been since it grabbed the data. Further more, if the user has configured additional cities (home city, work city, family city) in the weather app, these should show up here using the same swiping mechanism as messages. Having a graphical view of weather would be nice but not essential. What is essential is a textual description of the weather, the temp, and whether it’s going to rain in the next few hours. We want to show information that is both current and relevant. That, my friends, is status.

Battery and charging are self explanatory. Show the current charge level of the battery both as time to dead and a percentage. Indicate if it is currently charging. If the charger is plugged in and it’s not charging then this counts as an exceptional condition that must be highlighted. The same for a near death charge.

Music and Location

Jen was working today, so I spent the day fixing bugs and coding new features in Leonardo. Today's awesome feature: HTML Canvas Export. Yes, oh yes! You can draw anything you want in Leonardo, then export it to JavaScript code that draws into Canvas. Why would you want such a feature. Lots of reasons:

• Maybe you need to draw vector graphics in a browser that supports Canvas, but not SVG.
• Maybe you want to learn Canvas and have some code to start with.
• Maybe you are just simply too lazy to draw your own damn pictures in code.

Whatever your reason, Leonardo will be there for you. Look for it in our next release!

Check out this demo output page.

Now that Apple has given us final specs and cost for the redesigned Mac Pro I’ve heard complaints that it is underpowered and non-expandable, especially for the price. The Pro comes with reasonably beefy CPUs but they will be out of date in a few years. The buyer can only expand the ram and disk, and not so much on the disk side given the lack of available space. So how can this be worth the $3000 entry price Apple is charging?

First we must realize that the Mac Pro isn’t for everyone. It really is for creative professionals who spend a lot of time in Logic, Aperture, Final Cut Pro, Maya, and other pro apps. These people need the maximum ram and processing power possible, and will pay for it. Expandability of storage isn’t a problem because they don’t care about internal storage anyway. Anyone who buys one of these will be using a stack of external drives or NAS. I can buy a 3TB drive at Costco for under 200 bucks! Thus the nice collection of Thunderbolt and USB ports on MacPro’s backside.

More importantly, however, the CPUs aren’t the real focus of the new Mac Pro. Apple is betting that the future of high speed computation is GPU computing. Apple is right.

I recently went to the International Super Computing conference when it was held here in Oregon. At least 50% of the talks were about how to restructure computing tasks to take advantage of GPUs. GPUs are the future of almost all high performance computing. GPUs are not as general purpose as a modern CPU, but if you can structure your problem in a way that a GPU can compute, then you can get a 5x to 10x performance boost for the same watt (or dollar). Intel and Nvidia are happy to sell you a stack of GPUs without video connectors. These cards exist purely for GPU computation. Daisy chained together a stack of GPUs will beat any traditional super computer.

Of course, with the GPUs doing the heavy lifting the challenge becomes how to get your data *to* the GPU quickly. That’s why Apple’s MacPro site spends so much time talking about the IO bus and memory bandwidth. Internal storage? CPU upgrades? Who cares! The MacPro is all about moving data in and out of beefy GPUs as fast as possible.

Apple has been working on this for a while. Initially they started shifting graphics work to the GPU with Quartz Extreme. This enabled the OSX compositing window manager to run smoothly on older hardware. Later Apple introduced full Mac support for OpenCL, a computation companion API to OpenGL. When you write some code in OpenCL the Mac can shift the computation dynamically between the CPU and the GPU. Powerful GPUs can make up for weak CPUs.

And this brings me to the Raspberry Pi, my favorite cheap ARM based mini-computer -- so cheap I’ve seen hard drives with Pi’s glued to the side of them as files servers. At 700mhz the Raspberry Pi’s CPU is anemic but the GPU is surprisingly powerful. Broadcom’s VideoCore IV not only supports OpenGL 2.0, meaning real shader support, it also has H264 video encoding and decoding in hardware. It can decode a 1080p video in real time on this 35$ computer. The CPU just has to stream the compressed video file to memory; the GPU will care of the rest.

The Pi’s GPU also has an interesting API called dispmanx. While it is extremely undocumented, I’ve learned that this API lets you set up an almost unlimited number of hardware layers in the GPU. You can have one layer with 3D content from OpenGL while a second layer plays video and a third shows images. Most importantly each of these layers can be resized and alpha blended entirely by the GPU. This means we can create a full compositing window manager like OSX and Window 7 have, all on our tiny 700mhz computer. These guys are already working on a port of the composited Wayland/Weston library to the RaspberryPI.

While the Raspberry Pi does not support OpenCL it is possible to use the GPU for accelerated JPG decompression and there is ongoing efforts to directly target the VideoCore’s internal APIs for SIMD processing.

All of this power comes from shifting computation from the general purpose CPU to the custom purpose GPU. This is a long term trend. Over time more and more work will be shifted. GPUs can’t do all computational tasks of course; but if you can transform your problem in to something the GPU can handle (preferably something highly parallel), then you’re golden. He who controls the GPU... controls the world! Now let’s get some cheese, Pinky.

I haven't posted about the iPad (or tablets in general) since before the iPad announcement. I thought this prudent given that we all knew what was announced but I hadn't actually tried using one in person. Last week I played with a couple at my friends company and my initial thoughts were confirmed: the iPad as existing product today is interesting but not amazing, but as an indicator of the future is amazing.

When I picked it up it seemed smaller than in the pictures, and a tad heavier. Very solid, though. The interface is essentially a large iPod touch with a few flourishes. This isn't a bad thing, though. The iPhone interface was clearly designed to scale to larger devices. And on the faster CPU of the iPad it absolutely flies. This is one advantage of controlling both the software and hardware. I am surprised that they didn't put more memory in it, however, given how cheap memory is. Perhaps it was the only way to meet their margins.

The screen is gorgeous. Viewing websites, news, facebook, mail, etc. is a very nice experience. Where it falls down is content creation, specifically typing. Steve called this a magical keyboard or some such during his introduction keynote.

This is a lie.

While it may be better than the iPhone keyboard, it still sucks. Maybe for someone who is a hunt and peck typist it would be about as fast as a real physical keyboard, but anyone who is a touch typist will be immediately frustrated (and I mean *immediately*!). Now...it's not their fault.. they've done the best possible with their screen real estate, but hard immovable glass is no substitute for real physical keys with edges, dimples, and movement. No comparison.

However, this doesn't matter..

Why? Because most people aren't touch typists. And most people aren't content creators. I fully recognize that I'm not the target market for this. One day the iPad and similar devices will replace the desktop computer for 90% of people. (When I say 'desktop' I mean general purpose computers running full desktop OSes, whether or not they are actual desktops or laptops).

For me the iPad is an expensive novelty. It would live in my living room table as a nice way to read email and news feeds in the morning while I drink my coffee. Then I'd go upstairs to my real computer. But most people aren't like me (or you, given that you are reading a technology blog right now, probably through an RSS reader). Most people use computers for content consumption and communication, not creation. And the iPad is 90% of what they want. Ten years from now 90% of computers will be something like an iPad. And the remaining 10% will be called workstations.

That said, for the target market I think the iPad will still be seen as too expensive and missing features. It will sell well but won't be the smashing success that the iPhone was. But that's fine... Apple's used to that. They will slowly and carefully add features, and lower the price, until they take over the world.

So what's missing for most people? I originally had a laundry list but after taking off things that don't really matter anymore in the 21st century (like CD drives), I came up with only three things:

1. the iPad must sync to a real computer for software updates and other data like address books
2. the iPad must sync to a real computer to get music
3. the iPad can't print

The first one is easy to solve. Sync over the network. Every smart phone not made by Apple can get software updates over the web (my new employer does a great job of it). I expect Apple to enable this in the next year. Mobile Me already does most of the job.

The second one is a bit harder due to the massive amount of data involved. Most people have gigs of MP3s. I expect Apple to solve it by either creating the media server edition of the Time Capsule or else offering music streaming from the cloud... Or both, they've sure got the resources.

The third was is already 90% solved. The iPad SDK has render to PDF support, which is most of printing. Combined with better network printing to kill off the need for printer drivers, you'd have it.

So that would be it: a laptop replacement for 90% of people. The future is here (90% of it anyway) and it's a pad. Now if only they didn't hate the pencil so much.

This is part 2 of my N part series on building a DIY CNC machine. If you missed it, here is part 1.

Bearings

One of the trickiest parts of building a CNC machine is the linear sliders. Each axis requires a rail to slide the carriage on. This is called a linear slider. The sliding mechanism must have very low friction but also be strong to support the weight of the other axis and the head (which could be as heavy as a router). The carriage must also grip the slider tightly to ensure it doesn't slip or turn. The accuracy of the final CNC machine is directly related to the quality and tolerances of the slider. Needless to say, professional slider mechanisms aren't cheap.

After researching what others have done I decided to build my linear sliders out of OpenBeam using #608 roller skate bearings. Skate bearings have a few advantages: they are produced in mass quantities so they are pretty cheap for the quality you are getting. They are also usually sealed to keep out road dirt, so they can handle any debris the CNC might produce. And, because they are a standard size, getting parts to fit them is fairly easy. Here's a quick look at two versions of my bearings.

Skate bearings typically start at 1 USD each in sets of eight and go up from there. However, if you can afford to buy a lot at once you can get them as cheap as 50 cents a piece. I purchased my bearings from Amazon as a pack of 100 for 50 USD. A CNC will end up using at least 20 bearings so it's worth going for the large pack.

To attach the bearings to the beam I used long M3 screws from my local hardware store, about 20mm. Of course the inner diameter of the bearings (the bore) is much bigger than the diameter of the screws, so I needed to fill in the space.

After playing around with a variety of spacers, sleeves, and bushings I found a combination that would work, as depicted in this photo:

This works and is what I used in the current version of the CNC machine, but it has a few disadvantages. The nylon parts are longer than the bearing is wide so I had to trim them by hand. Plus there is two of them needed for each bearing, which adds cost and assembly time. I also had to add some washers to prevent the screw head from going through the center and to give more space between the beam and the bearing. Not bad for a first try, but I need something better.

Some searching on Amazon turned up some better pieces:

This bearing assembly uses a slightly shorter screw, 16mm (also in cool anodized black). I also found spacers that the were the perfect length, no trimming required. The interior diameter is perfect for the screws. the outer diameter is a tight fit in the bearings but I can pop them in easily with pliers. Since they fit in with friction I don't need to worry about washers to hold the bearing on. To give more space I used some of my standard M3 nuts. Since I already have to buy tons of them they are cheaper than washers, and adjustable to boot. Score!

I'm learning that creative sourcing and constant redesign is the only way I will reach the 200 USD goal.

Shaft Coupler

The next big challenge for a CNC machine is attaching the lead screw to the stepper motor. I would think this would be easy. I would be wrong.

The lead screw needs to be attached to the stepper motor securely so it won't slip, but it also needs a bit of flexibility to absorb vibrations. The two shafts also must be perfectly concentrically aligned or else the carriage will bounce up and down. Doing all of this for a decent price is very hard. Commercial solutions run 30 USD per shaft coupler.

I found several people online who use rubber tubing with clamps. Unfortunately I found the tube around the stepper shaft was too loose. If I tightened it with the clamp then the shaft would never be concentric with the lead screw.

My next attempt is what you see in this photo:

I used two pieces of tubing, one nested inside the other. The smaller tube is shorter and only goes around the stepper shaft. The larger tube contains the smaller tube as well as the leadscrew. The small tube is tight enough that it doesn't need a clamp, so that reduces the complexity a bit. The larger tube still slips, so the clamp must remain.

The two shafts are now more concentric but still not perfect. It's a good start though. For my next attempt I will switch to aluminum tubing from a hobby store.

Pen Mount

I can't turn my CNC machine into a plotter without a pen of course. I started with a Sharpie rubber banded onto a piece of extrusion.

It almost works but not quite. The pen has no give. It is either pressing very hard against the paper or doesn't touch at all. When it presses hard it prevents the carriage from moving smoothly, so I get lots of skips and jumps. I'm still looking for a better solution that will add some spring.

That's it for now. Next time I'll show some of the improvements I'm making to the electronics side for V3.

I was in Sweden all of this past week for the OreDev conference. I had a wonderful time last year and made it first on my list to see again. The attendees are friendly and their technologies diverse, making it such a good learning environment. I was especially pleased to see they have added an entire track on User Experience. What follow's is OreDev's take on the future of user experience design, from the visualization technologies coming out of Microsoft Research, to a brief history of touch interfaces, to the latest rapid development technologies for mobile devices.

Interactive Visualizations

First up is Eric Stollnitz from Microsoft Research's Interactive Visual Media Group. This is the group responsible for the zooming PhotoSynth technology. They are continuing to pump out amazing imaging technology, some of which he demoed to us.

Eric showed us the Image Composite Editor which will stitch a multi-gigapixel panorama out of a hundred photos taken with a standard consumer digital camera. You just give it a directory full of images and it does the rest, arranging and blending the photos into a single final image. I especially liked how it would arrange the photos randomly and then move them into place as it does the analysis. This gives you a sense of what the app is doing. It uses realtime feedback as you change parameters to update the generated panorama using lower quality thumbnails. Once you've got settings that you like press the render button and let it run in the background, producing the final (very large) image. Future versions of this app may work with video footage as well.

The first thing he noted about their demos is that almost everything is now done with WPF, which is Microsoft's vector based UI toolkit for writing native Windows apps. It lets developers work at a higher level and produce apps that would be difficult to impossible using the older WinForms toolkit. In the Java world this parallels the relationship of JavaFX and Swing. The panorama stitching app was originally in older technology and they were able to have one intern completely rewrite it in WPF over the summer.

Eric demoed several apps using the DeepZoom technology that has been shown by MS for the past couple of years. It's interesting to see how this technology has evolved. Early demos simply focused on the amazing technical ability of zooming into insanely large images. Now that this is commonplace the focus has shifted to what useful things can be done with the technology, which is really far more exciting. Modern computers so much excess computing power, it's nice to see us doing interesting things with it.

My favorite DeepZoom app is called WorldWide Telescope. It combines beautiful large space images from various telescopes with user created content. You can 'tour' the galaxy with paths from different tour guides. In one example a seven year old kid first showed us his home in Toronto, followed by a tour of his favorite constellations. Another tour took us from earth, through the solar system, to the local galaxy structures, and finally to the edge of the known universe. The blending of multiple images into the same experience were simply amazing.

• Microsoft Research
• WorldWide Telescope
• DeepZoom Composer
• Image Composite Editor

Tap is the New Click

Next up was Dan Saffer of Kicker Studio. It turns out I've been reading his blog for months. I found it while Googling for touch interfaces on Bing.com.

Dan gave us a brief history of touch technology, an overview of the various options, and finally some design guides for using touch in new interfaces.

One of the most interesting challenges in designing touch interfaces is the fact that fingers are larger than a mouse pointer (significantly) and that your hand can be in the way of the screen. With clever design you can address these shortcomings, but it's not trivial.

One way to solve the size issue is with iceberg and adaptive touch points. A touch point is simply a place on the screen where a user can touch. It's what we'd think of as a button or clickable image in traditional user interfaces. An iceberg touch point is when the touchable area is larger (sometimes a lot larger) than the apparent visual bounds of the thing being touched. This focuses the user's attention in the center of the touch point, but allows for a lot of error.

An adaptive touch point is where the touch bounds adjust based on context. For example, in the iPhone keyboard if you type 't' then 'h', the OS can guess you are likely to type a vowel next (at least in English). The keyboard can adaptively expand the touch size of the vowels to make them easier to hit. This improves the error rate of touch keyboards significantly.

The final example Dan showed us was a visual remote control system his firm developed. It's a set top box for your TV that uses a camera and vision system to let you control the TV with just hand gestures. They developed a simple language of gestures for changing the volume, navigating menus, and turning the TV on and off. It was interesting to see how they reduced a complex task into a small set of simple gestures through very careful research and design. Great stuff.

Quote of the day: The best designs are those that dissolve into behavior.

• Kicker Studio Blog
• Designing Gestural Interfaces, by Dan Saffer, O'Reilly publishing.

Making web applications for iPhone

On Thursday I attended a talk by Michael Samarin on developing iPhone web applications without navigating Apple's app store or writing a single line of JavaScript (well, okay, he wrote 3 lines). He did everything with Dashcode, Apple's visual web design tool, and Java servlets in NetBeans.

Dashcode has improved a lot since I last used it. Originally for building dashboard widgets, it has turned into a general purpose web design tool with a drag and drop interface similar to their InterfaceBuilder tool for desktop apps. Most importantly it has tons of Javascript enabled widgets that emulate the native iPhone environment.

Michael built a simple app on stage that could navigate and play a directory of of video clips on his server using a JSON web feed from the servlet. Dashcode lets you bind Javascript UI controls to JSON fields, making a functional app with only about 3 lines of actual code. You can even add simple hardware accelerated 3D flip transitions using CSS. The server side component was a straight Java servlet which parses the directory structure on disk and generates the JSON feed.

Next he used some Applescript called from Java to build a web based remote control for the QuickTime player. It was simple to build and surprisingly responsive. Every bit as good as a native iPhone app without all of the headaches. Michael's company, Futurice, now often recommends web apps to their clients instead of native iPhone apps because development time is far shorter, cheaper, and can be updated instantly without going through Apple's approval process.

The rapid development time really lets his team focus on the user experience. While I still believe in plugin based rich clients for the web, I was very impressed with what's possible in pure JavaScript and CSS on the iPhone. They've got quite smooth stack.

Conclusion

I love OreDev because it exposes me to technology I wouldn't otherwise get to see. Ultimately great design doesn't depend on the technology you use, but how you use it. And if the talks presented here are any indication, the future looks bright for many technologies.

That's the highlights for me. I did my final presentation on JavaFX Friday followed by some fun demos for a local Java group. Both went quite well and is in prep for a new app I'll be launching in a couple of days. Now time for some sleep.

Another month has gone by with no update to Leonardo, or a real release of Amino. It's interesting how life changes. When I started this projects last summer I had no idea Jen and I would be having a baby in a month, nor did I truly have any notion how much my life would change. Everyone always says having children will change your life, but you never really understand it until you do it yourself, and our journey has just begun.

So, the upshot of all this rambling is that kids take time, and when you have to distribute a finite resource between multiple buckets, something has to get less. Sadly this time the short straw goes to my open source projects. It doesn't mean I won't work on them anymore, just at a slower pace. However, in order to feel at peace with myself I need to leave them in a state where they can still progress without my large time commitment. That's what this post is about.

I've spent the last year working on two main open source projects called Leonardo and Amino. Quick recap: Amino is a scene graph library for Java and JavaScript. Leonardo is a vector drawing program built on top of Amino. I want to get them both to a state where they are stable, useful, and can live on their own. Hopefully more of my job will be driving the community and integrating patches rather than directly coding everything. Every project reaches a point where it should stop being driven by a singular vision, and instead be driven by needs of actual users (the good projects anyway). Now is the that time. Time to focus on gaining adoption, growing a community, and making these projects rock-freaking-solid.

Concrete Plans

Amino

Amino basically works. Shapes are animated and drawn on screen, input events are properly transformed, and it's got pixel effects on both the Java and JavaScript sides. Speed, efficiency and features driven by actual use.

Amino finally has it's own website at GoAmino.org and I've set up auto-builds for both the Java and JavaScript versions. They also have a redesigned API doc template that you can see here. Last steps before a 1.0 release: bug fixes for Mobile Safari and FireFox, more demos, and a tutorial for integrating with Swing apps. (Oh, and if someone has a nice spring easing function, that would be swell). Target: next weekend.

Leonardo

It's basically done. It lets you draw vector art of shapes, images, and paths; and also create attractive presentations (which is just multiple pages of vector art). Now comes polish and adoption and export features. I suspect the value will really be in the export features so I need to know from you guys: what do you want?

In concrete terms I have a bunch of old bugs to fix and will finish the redesigned fill picker (colors, swatches, gradients, patterns, etc.) I also need your help updating the translations. Once that's done I'll clean up the website and cut a 1.0 release. Target: end of April.

Next Steps

In short, a lot of work for the next few weeks, but with luck (and hopefully some great feedback from you) , both Amino and Leonardo will be just fine.

I finally got tired of hacking Wordpress and decided it was time for a change. My site has always essentially been static. I don't need a database or the ability to switch themes and use plugins. I'm the only author and the content doesn't change more than once a day (usually once a week). So, I scrapped WordPress entirely and wrote my own blog in Node. It only took me about a day of real hacking to get it up and running.

The blog itself is a simple Node app with the Express toolkit. For markup I'm using Jade, a refreshingly clean template engine. The blog posts themselves are just HTML on disk with some adjacent JSON metadata. ie: the simplest thing that could possibly work. No databases are involved. Just in memory caching of on disk text files. When I want to post something I just drop in a new file and restart the node process (takes less than 1 second). I suppose I could write some sort of visual posting interface if I wanted to, but no need to complicate things rith now.

The style of the site is custom. I designed it to have a bit of a retro feel while remaining clean. You can see the tag chart in the sidebar borrows colors from the top header. The top font is Ostrich Sans from the League of Movable Type, using @fontface.

I originally chose to go with WordPress for my blog because of the many themes available, but finally decided they are all way too configurable or just plain crap. And the markup is always atrocious. I wanted something neat and clean, so I had to go custom.

I built the UI of the site on top of Twitter's Bootstrap CSS framework which gives me a nice clean grid to work with, consistent vertical spacing, and responsive behavior if you view it on a mobile device. Yes, there is no special mobile theme. You get the exact same content on all devices, but with a layout tuned to your needs. As a mobile developer I am adamant that we shouldn't have two versions of any site. Just make it adjust dynamically.

I hope you enjoy the new design. Please give me feedback on Twitter.

I'm working on a few submissions for OSCON, due in two days. I've got lots of ideas, but I don't know which ones to submit. Take a look at these and tweet me with your favorite. If you can't make it to OSCON I'll post the presentations and notes here for all to read.

Thx, Josh

Augmenting Human Cognition

In a hundred years we will have new bigger problems. We will need new, more productive brains to solve these problems. We need to raise the collective world IQ by at least 40 points. This can only be done by improving the human computer interface, as well as improving physical health and concentration. This session will examine what factors affect the quality and speed of human cognition and productivity; then suggest tools, both historic and futuristic, to improve our brains. The tools are jointly health related: disease, sleep, nutrition, and light; digital: creative tools, AI agents, high speed communication; and also physical augmentation: Google Glass, smart drugs, and additional cybernetic senses.

Awesome 3D Printing Tricks

The dream of 3D printing is for the user to download a design, hit print, and 30 minutes later a model pops out. What’s the fun in that? 3D printers are great because each print can be different. Let’s hack them. This session will show a few ‘unorthodox’ 3D printing techniques including mixing colors, doping with magnets and wires, freakish hybrid designs, and mason jars. Lots of mason jars.

The techniques will be demonstrated using the open source Printrbot Simple, though they are applicable to any filament based printer. No coding skills or previous experience with 3D printers is required, though some familiarity with the topic will help.

Cheap Data Dashboards with Node, Amino and the Raspberry PI

Thanks to the Raspberry Pi and cheap HDMI TV sets, you can build a nice data dashboard for your office or workplace for just a few hundred dollars. Though cheap, the Raspberry PI has a surprisingly powerful GPU. The key is Amino, an open source NodeJS library for hardware accelerated graphics. This session will show you how to build simple graphics with Amino, then build a few realtime data dashboards of Twitter feeds, continuous build servers, and RSS feeds; complete with gratuitous particle effects.

HTML Canvas Deep Dive 2014

Behind plain images, HTML Canvas is the number one technology for building graphics in web content. In previous years we have focused on 3D or games. This year we will tackle a more useful topic: data visualization. Raw data is almost useless. Data only becomes meaningful when visualized in ways that humans can understand. In this three hour workshop we will cover everything needed to draw and animate data in interesting ways. The workshop will be divided into sections cover both the basics and techniques specific to finding, parsing, and visualizing public data sets.

The first half of the workshop will cover the basics of HTML canvas, where it fits in with other graphics technologies, and how to draw basic graphics on screen. The second half will cover how to find, parse, and visualize a variety of public data sets. If time permits we will examine a few open source libraries designed specifically for data visualization. All topics we don’t have time to cover will be available in a free ebook to read.

Bluetooth Low Energy: State of the Union

In 2013 Bluetooth Low Energy, BLE, was difficult to work with. APIs were rare and buggy. Hackable shields were hard to find. Smartphones didn’t support it if they weren’t made by Apple, and even then it was limited. What a difference a year makes. Now in 2014 you can easily add BLE support to any Arduino, Raspberry PI, or other embedded system. Every major smartphone OS supports BLE and the APIs are finally stable. There are even special versions of Arduino built entirely around wiring sensors together with BLE. This session will introduce Bluetooth Low Energy, explain where it fits in the spectrum of wireless technologies, then dive into the many options today’s hackers have to add BLE to their own projects. Finally, we will assemble a simple smart watch on stage with open source components.

While I have many projects in progress right now, including Amino, Leonardo, getting the TouchPad out the door, and having my first baby (only a few weeks left!); every now and then I just get something into my head and have to code it out. Last night it was noise functions.

Since I've been using little bits of noise in my designs I thought it was high time to really learn how it works. Following code & articles from here and here I've managed to create a simple noise and turbulence generator in Java. With a few different settings you can get textures that range from completely random to something that looks like marble.

pure random grayscale noise

high turblence

medium turbulence + one sinewave

medium turbulence + three sinewaves

It's actually simpler than I thought. Noise is just a bitmap filled with random values from 0 to 1 (or a grayscale value between black and white). Turbulence is created by stacking multiple layers of noise, each stretched to different amounts. Add in a bit of linear smoothing and you get some quality texture. The marble effect is just a turblence texture merged with a sine wave.

Next up, making the noise repeat so we can have tileable textures. Then I might make a simple app to generate noise with various colors. If it all turns out okay I might make a plugin for Leonardo to create your own textures.

20th century advertising has taught us to associate quality artwork and polish with quality products. Given two apps that do the same thing, a potential customer will pick the one that looks and feels better. This means every great app needs great art. Since most developers aren't artists or designers by trade, I've assembled a list of resources that can help. Here are icons, fonts, sounds, color schemes, and other great art assets to help you make your app stand out from the crowd.

Color Schemes

Good use of color can really make your app stand out, but color can be tricky. The best color schemes often come from other people or real world objects. These sites have collections of color schemes created by people who work with color every day. They let you search by color, theme, and popularity.

COLOURlovers

COLOURlovers is a creative community where people from around the world create and share colors, palettes and patterns, discuss the latest trends and explore colorful articles... All in the spirit of love. (yes, they wrote that part)

Kuler

Kuler at Adobe is a Flash based color searching site.

For more on the topic of color see my Color 101 article.

Icons

Every great app needs great icons. Not only for the app itself but also within the application for buttons and indicators.

The great FXExperience blog has several free PNG icon collections that are generic and useful for lots of things. Most are small so they work well on mobile devices. Free icons for your JavaFX applications @ FX Experience

The Crystal Clear icon set by Everaldo is licensed under LGPL and includes icons for apps, actions, devices and mimetypes.

The Nuvola icon set contains 600 icons with a cute cartoon feel to them.

Icon sets for Gnome, under various licenses

Tango Icon Library: another very complete set of desktop icons.

Sounds

FreeSound.org

Free Sound has a huge collection of user contributed effects, clips, and just plain weird sounds. Great for building sampled music and effects in your games

Jamendo

Jamendo is a music site containing only Creative Commons licensed works. The perfect place to find your next soundtrack.

Imagery & Textures

Lost Garden

Lost Garden focuses on video game design. The author, Danc, has literally decades of experience in the field. You can easily lose hours reading through amazing essays on the site. Today, however, we are here for the free game graphics. Spanning both vector and bitmap, retro and modern styles, Lost Garden has game graphics for many uses

Open Graphic Design and Think Design blog

OpenGraphicDesign.com has tons of cool shapes and vector artwork. They are great as starting points in Illustrator

ThinkDesignBlog.com has free textures and vector shapes. Good for backgrounds and skinning. Plus tons of inspiration articles.

Photos

For photos your best source is images licensed under Creative Commons at Flickr. Conveniently they have a search option for just such photos.

Inspiration

Well Placed Pixels is a blog containing only one thing: screenshots of beautiful software.

The idea of computer vision has always fascinated me. The ability to get from a plain image to an understanding of it's contents seems magical. Though I understand a bit of the underlying math, to build my own computer vision system would take years of study. Fortunately, this book and an open source library come to the rescue.

Practical Computer Vision with SimpleCV, published by O'Reilly, is a wonderful book; with an emphasis on Practical. It explains a bit about how computer vision works then dives right in to building things using the open source computer vision library: SimpleCV. SimpleCV is a Python library (linking to an underlying C implementation, I think), and quite easy to use. Since the book examples are all in Python anyone with basic programming experience (Java, C#, JavaScript, Ruby) should have no trouble with the example code.

The first half of the book starts with an explanation of basic computer vision concepts then jumps right into build a simple time lapse photography app with a few lines of Python code. Next comes image manipulations such as cropping, color reduction, simple object detection, and histograms. This is enough to create a blue screen effect and parking detector.

The second half contains the real meat of the book: detecting features. SimpleCV can pick out different shapes, filter by colors, look for faces, and even scan barcodes. One of the examples looks at a table of change to calculate the monetary value using coin size. The final chapter covers some advanced techniques like optical flow and key point matching.

While I like the book overall I do have a few nits. First, I really wish it was printed in color. Several chapters have images which can't be easily distinguished when printed in black and white. Second, I wish it was longer. While the book does covert almost every feature of SimpleCV, I'd love to read some larger example apps that combine multiple techniques. All that said, the book was still a good read and informative. It will stay on my shelf for future imaging projects.

As you know, I've been doing a lot of ebook prototyping lately. Ever since the iBooks 2 announcement I've had this idea stuck in my head that we can make rich interactive ebooks using nothing but web technology. That lead to the toolkit I've been working on, now open sourced on github. As the first thing written with that toolkit I'm proud to announce my first interactive book: HTML Canvas, a Travelogue.

The book is an interactive guide to learning Canvas. It is not a comprehensive reference guide since there are plenty of those. It gives you an overview of the technology with deep dives into a few parts to let you explore what the technology can do. It does this through some hands on tutorial chapters where you build charts and a simple video game. It also has interactive code snippets that let you tweak variables to see how they react in real time. The entire book is written in HTML with the ebook toolkit. For the chapter navigation I used the new Enyo 2.0 beta with the Onyx theme. Animation is done with Amino, and for app packaging I've used PhoneGap.

Canvas is a technology that is still in flux, so I think an app based book is a perfect way of learning it. As the technology improves and changes I can continue to update the book with new examples and reference material. I like to call this concept an everbook. When you buy such a book you aren't just buying the static text itself. You are buying all future editions of that book, and can give feedback to the author to help shape the material. If the reader wants a deeper explanation of a particular topic or finds a bug in an example, then he can simply email the author with the request. The book is updated for free and everyone wins.

I will be releasing it for all of the tablet platforms over time, starting with webOS first and the iPad next. The retail price will be 4.99$, but as a thank you to the webOS community I am releasing it for a permanent price of 99 cents. And as of right now it is live in the TouchPad App Catalog and available for purchase. I love you guys and this is the best way I can think of giving back: developing tools and apps to keep webOS great. Please check it out and give me feedback. All bugs will get top priority.

Thank you.

- Josh

In today's post I'll dive into Amino's new buffering support. At then end we'll talk about new API docs for Amino, the roadmap, and request for help on a domain name.

A big part of making a scenegraph fast is using lots of little tricks to do as little work as possible. Most of these tricks are decades old, but they still work. What makes a scenegraph good is letting developers easily use these tricks without having to code up anything special.

Dirty rect tracking is one such trick, but I haven't implemented it in Amino yet so I'll cover that in a few weeks. Another common trick is using intermediate buffers to store effects that are expensive to compute, such as blurs, shadows, and Photoshop style adjustments. The beauty of buffers is that if you can pretty much do any crazy thing you can think of, as long as you can figure out how to draw it into a buffer first. A good third of Swing Hacks, the book Chris Adamson and I wrote, is just different clever ways of using buffers.

Given the importance of buffers I made this a central feature of Amino. But before I go any further, how about a demo!

Zoom Effect

First, an MP3 style Visualizer. I say MP3 style because it's not actually working with audio. I'm just generating random data then pushing it through a simple buffer effect: draw into buffer1, copy buffer1 into buffer2 with stretching, flip buffers and repeat. It's a simple technique but if you do it over and over the results are very cool.

MP3 Visualizer. Click to view

On a modern browser you should get a solid 60fps. BTW, a quick shout out to Internet Explorer 9. The guys at MS have done a top notch job. Amino runs beautifully there, no matter what I threw at it.

The Buffer API

Buffering is broken up into two parts. First is the actual Buffer object, which is a bitmap with a fixed width and height that you can draw into and can be drawn into other buffers or the screen. In the Java version of Amino this is a wrapper around BufferedImage. In the JavaScript version Amino creates an offscreen canvas object to use as a buffer.

The simplest use for a Buffer is in the BufferNode, which just draws its only child into the internal buffer for safe keeping. If the child hasn't changed on the next drawing pass then it will draw using the buffer instead. This is the simplest use case, but very important because you can draw a bunch of complex stuff and save it by simply wrapping it in a buffer. Here's a quick example:

//create a group with 100 child rects
var g = new Group();
for(var i=0; i<1000; i++) { g.add(new Rect().set(i,i,50,50));
} //wrap the group in a BufferNode
var b = new BufferNode(g);
runner.setRoot(b);

The code above creates a group with a thousand rectangles. This will probably be slow to draw, but by wrapping it in a buffer it's only drawn once and then saved for later. Now the rest of your scene can draw at full speed.

Real Time Photo Adjustments

The next big use of buffers is for special effects like Photoshop filters. As of today Amino now has effects for blur, shadow, and photo adjustment (saturation, brightness, contrast). Each of these effects uses one or more buffers internally to manipulate the pixels before drawing to the screen. Blurring is a big topic, so I'll cover that in it's own blog later. Today I'll cover the photo adjustment.

Adjusting the saturation, brightness, and contrast of an image is actually pretty simple. It's just basic math and a lot of copying:

• create two buffers.
• draw your photo into the buffer 1
• loop over every pixel in buffer 1
• pull out the red, green, and blue components of that pixel's color.
• calculate a new red, green, and blue using some math
• Set the same pixel in buffer 2 using the new calculated color

For brightness, saturation, and contrast the equations are:

new color = old color + brightness
new color = (old color - 0.5)*contrast + 0.5
//desaturation
new color = old.red*0.21 + old.green*0.71 + old.blue*0.07

I won't bore you with the details of actually extracting the components with hex math and stuffing it back into the new pixels (well, maybe I will in a later blog on canvas performance). The point is you can do lots of effects with simple math.

The challenge with code like above is that it still may be too slow for real time work. Remember, the goal of Amino is a rock solid 60fps on a desktop browser and 30fps on a mobile device. To keep our framerate promise we need a way to do some work without blocking the UI. That means background threads.

Background Threads, Sorta

On the Java side we can use real background threads to do compute intensive effects; though honestly Java is fast enough for most cases that it hasn't been necessary yet. Canvas is most browsers is slow enough that we can't process an entire large picture (say 512x512) in a single frame. Unfortunately, JavaScript doesn't really have threads, or at least not until the forthcoming Worker API is released. So on to our backup plan: cheat.

We are allowed to do some work on the GUI thread as long as we don't take too much time. The solution: break up the work into small chunks and distribute them across multiple frames. It won't be quite as 'realtime' but it still allows us to do these effects in browser without slowing down the UI.

Amino now has an internal class called WorkTile which defines a subset of the full image to be processed. Right now it's set to 32x32 pixels. Once the effect starts it will process one WorkTile at a time until it runs out of time for this frame (currently set to 1000/40 ms). When the next frame arrives it will draw a few more WorkTiles until it runs out of time. After enough frames the image will be completely processed and saved into the final buffer, and work is terminated. Volia, 'background' processing of images in a browser without blocking the UI.

Currently only BackgroundSaturationNode uses this new worker system but eventually all effects will use it. Here's a demo to change the saturation, brightness, and contrast of a satellite image from Venus. Click the image to go to the demo page.

Photo Adjustment. Click to run.

API Docs, Website, and Roadmap

Along with the buffering work I've recently written a new doc tool for Amino. I wanted something that would work on both Java and JavaScript code and didn't have the ugly legacy of classic javadoc. It's still a work in progress but I'm happy with the results so far. It's a new design where classes are grouped by category instead of package. Feedback is very welcome.

• Java API Docs
• JavaScript API Docs

I think Amino is getting close to a real beta release. It's pretty stable in the major browsers and on mobile devices that support canvas (I haven't tested Android yet, but TouchPad and iPad work great). I have a bit more work to do on events, fills, and animation but once those are done we'll be ready for a 1.0 release.

Now the big question: where to put all of this? I think Amino deserves it's own domain so I'd like your help picking one. Please tweet your suggestions to @joshmarinacci.

That's it for this week. Thanks guys. I think Amino is shaping up be a rockin' scenegraph library.

It's been a while since I've posted thanks to this spring's conference schedule. Part of my new job at Palm is working at our booth answering technical questions. This has kept me on the road, but certainly provided opportunities to talk about our technology and build interest in apps. Read on photos and stories from GDC and CTIA, including a clip of Shrek Cart.

CTIA in Las Vegas

I'll say this: Vegas is flashy, dry, and tiring. I was working the whole time so it wasn't as fun as I would have imagined. I suspect if I went on vacation there I'd have a very different experience (as my wife did last year with her friends). Still, it was interesting.

Probably the best part was getting to meet the Pre Central crew in person. @adora, her bf, and I had dinner in the Palms hotel (natch) with Dieter Bohn of the PreCentral PalmCast, along with co-casters from WMExperts and Android Central. I always enjoy good sushi, drink, and conversation.

The rest of the trip is punctuated by booth shifts, collecting a ton of business cards, and drinking lots of water. The CTIA floor is truly massive. Hopefully next year I'll get to spend more time wandering it. I will say this about Las Vegas: their indoor architecture is amazing. Next time I plan to take far more pictures.

Attendance at the booth was quite good. Most people knew about us and were excited to hear webOS devices are coming to AT&T. The ability to talk and surf at the same time can be handy, as long as you are careful.

GDC 2010 in San Franciscio

Next up is the Game Developer Conference, or GDC. As the name would suggest this is a developer centric event of the gaming variety, though there were certainly plenty of biz people too. I will say this: the gaming industry has a lot more fun with their booths than the enterprise software guys. I never saw anything like this in front of an Oracle booth.

You will optimize your SQL statements with fourth normal form.

The Palm Booth / Beacon

The Palm booth saw good attendance, and you certainly couldn't miss our sign. Rather than an endless parade of booth babes we went for a clean and soothing wood and smokey grey finish, topped off with a massive orange sign. It was way too bright to photograph without manual control SLR. If there wasn't a roof on the building you could have seen it from space.

While attendees flitted in and out we had presenters explaining phone features and playing some of the new games from our catalog. In the clip below you can see Cassie playing Shrek Cart against another phone over WiFi. At one point we had six people playing on the same course, each from their own phones. (yes, I captured this with my Palm Pre).

Touring the floor

I did get a chance to browse the floor between shifts. The crowd around StarCraft 2 was thicker than a zergling's skull. I'm not a gamer anymore, but I may have to pick it up when it's finally released in 2023.

StarCraft is finally threee deee

Your life in 3D

GDC isn't just for video games themselves. Much of vendors are showing their latest tools and supplies for making games. Thanks to Avatar motion capture and 3D were the major tech themes.

My first observation, 3D TVs are coming whether we like them or not. I tried on the glasses and sat down for a few minutes to watch a movie and some games. First impressions: 3D movies will still be a novelty at home. We've only just started to get films in 3D that really take advantage of the format, and while they are a truly experience in the movie theater (Coraline was simply stunning), I don't think it transitions well to the smaller screen and lesser technologies. Movies created for 3D will still fare reasonably well, but 2D content converted to 3D made my eyes hurt. Still too much of the 'shiny thing popping out at you' to make it interesting.

Video games, on the other hand, I think may be the killer app for 3D TV sets. The racing game I played was much more immersive and felt more engaging. Since the content is rendered realtime and already in 3D they don't have to add in the effect afterwards.

As for the glasses, they had the usual polarized paper specs in the booth for cost reasons. Not comfortable, but once classy Oakley style glasses hit in the next year I think the need to wear something special for 3D will become a non-issue.

Take that two dee screens!

All Motion Must Be Captured

As for motion capture, it's everywhere. Many different techniques, presumably for different costs and results. I get the impression that all games with 3D characters use this now.

Capture your motion, look cool in spandex

That's it for this week. I should have some exciting stuff to share with you soon. In the meantime here's a bonus pic I found on my phone, taken a week ago in downtown Eugene. Perhaps leading them to greener pastures?

Remember to tether the children well.

I’ve been using Node JS off and on for the past few years, ever since we used it in webOS, but I’ve really gotten to go deep recently. As part of my learning I’ve finally started digging into Streams, perhaps one of the coolest unknown features of Node.

If you don’t already know, Node JS is a server side framework built on JavaScript running in the V8 engine, the JS engine from Chrome, combined with libuv, a fast IO framework in C++. Node JS is single threaded, but this doesn’t cause a problem must most server side tasks are IO bound, or at least the ones people use Node for (you can bind to C++ code if you really need to).

Node does it’s magic by making almost all IO function calls asynchronous. When you call an IO function like readFile() you must also give it a callback function, or else attach some event handlers. The native side then performs the IO work, calling your code back when it’s done.

This callback system works reasonably well, but for complex IO operations you may end up with hard to under stand deeply nested code; known in the Node world as ‘callback hell’. There are some 3rd party utilities that can help, such as the ‘async’ module, but for pure IO another option is streams.

A stream is just what it sounds like from any other language. An array of data that you operate on as data arrives or is requested. Here’s a quick example. To copy a file you could do this:

var fs = require('fs');
fs.readFile('a.txt',function(err, data) {
     fs.writeFile('b.txt',data);
});

That will work okay, but all of the data has to be loaded into memory. For a large file you’ll be wasting massive amounts of memory and increase latency if you were trying to send that file on to a client. Instead you could do it with events:

var fs = require('fs');
var infile = fs.createReadStream('a.jpg');
var outfile = fs.createWriteStream('b.jpg');
infile.on('data',function(data) {
     outfile.write(data);
});
infile.on('close', function() {
     outfile.close();
});

Now we are processing the data in chunks, but that’s still a lot of boilerplate code to write. Streams can do this for you with the pipe function:

fs.createReadStream('a.jpg').pipe(fs.createWriteStream('b.jpg'));

All of the work will be done asynchronously and we have no extra variables floating around. Even better, the pipe function is smart enough to buffer properly. If the read or write stream is slow (network latency perhaps), then it will only read as much as needed at the time. You can pretty much just set it and forget it.

There’s one really cool thing about streams. Well, actually two. First, more and more Node APIs are starting to support streams. You can stream to or from a socket, or from an HTTP GET request to a POST on another server. You can add transform streams for compression or encryption. There’s even utility libraries which can perform regex transformations to your streams of data. It’s really quite handy.

The second cool thing, is that you can still use events with piped streams. Let’s get into some more useful examples:

I want to download a file from a web server. I can do it like this.

var fs = require('fs');
var http = require('http');

var req = http.get('http://foo.com/bigfile.tar.gz');
req.on('connect', function(res) {
     res.pipe(fs.createWriteStream('bigfile.tar.gz'));
});

That will stream the get request right into a file on disk.

Now suppose we want to uncompress the file as well. Easy peasy:

var req = http.get('http://foo.com/bigfile.tar.gz');
req.on('response', function(res) {
    res
        .pipe(zlib.createGunzip())
        .pipe(tar.Extract({path:'/tmp', strip: 1}))
});

Note that zlib is a built-in nodejs module, but tar is an open source one you’ll need to get with npm.

Now suppose you want to print the progress while it happens. We can get the file size from the http header, then add a listener for data events.

var req = http.get('http://foo.com/bigfile.tar.gz');
req.on('response', function(res) {
    var total = res.headers['content-length']; //total byte length
    var count = 0;
    res.on('data', function(data) {
        count += data.length;
        console.log(count/total*100);
        })
        .pipe(zlib.createGunzip())
        .pipe(tar.Extract({path:'/tmp', strip: 1}))
        .on('close',function() {
            console.log('finished downloading');
        });
});

Streams and pipes are really awesome. For more details and other libraries that can do cool things with Streams, check out this Streams Handbook.

Amino is my JavaScript graphics library I've been working on for a few years. Last year I started a big refactor to make it work nicely on the Raspberry Pi. Once we get X windows out of the way we can talk to the Pi's GPU using OpenGL ES. This makes things which were previously impossible, like 3d spinning globes, trivial on the Raspberry Pi.

For the talk I started by explaining how Node and Amino work on the Raspberry Pi, then shows some simple code to make a photo slideshow. (in this case, Beatles album covers).

Next we showed a 3D rotating text RSS headline viewer.

And finally, using the same GeoJSON code from the D3/Canvas workshop, a proper rotating 3D globe.

Hmm... Did you ever notice that the earth with just countries and no water looks a lot like the half constructed Death Start in Return of the Jedi?

Of course, my dream has always been to create those cool crazy computer interfaces you see in sci-fi movies. You know, the ones with translucent graphs full of nonsense data and spinning globes. And even better, we made one run on the Raspberry Pi. Now you can always know the critical Awesomonium levels of your mining colony.

Source for the demos on DropBox.

Color 101

The Eye

Subtractive and Additive Color Models

Basic Additive Color Models

HSV / HSB Color Model

Steal Someone Else's Colors

Steal Some*thing* Else's Colors

Sea Glass look and feel

Color palette produced by DeGraeve.com

Pick a Color and Change One Thing

Links

• "Creating Consistently Colorful User Experiences" at UXBooth.com. Parts 1, 2, and 3.
• Color Theory, Wikipedia
• RGB Color Model, RGB
• HSL and HSV Color Models, HSV

Today I'm proud to announce a project I've been working on for the past few months called Leonardo. I've long believed there's a need for a good desktop drawing app that is completely cross platform, free, and open source. Leonardo is that app.

LeonardoSketch.org

My vision is a drawing tool for the 21st century with a focus on usability, speed, and powerful plugins. The core of the app is written in Java, but more and more of the functionality will be built in JVM based dynamic languages like JRuby, JavaScript, and Jython.

Currently Leonardo is meant for doing UI mockups, simple multi-page presentations, and sketching; but we plan to add more document types and features in the future.

Please take a look at tell me what you think (or better yet join the dev list). We definitely need help in a lot of areas, so the more feedback the better.

Thanks!
 - Josh

Most book publishers don't really have a 'brand'. You buy a book because of the title or the author. No one cares who Stephen King's publisher is. However, every now and then a publisher comes along who simply makes cool books. A publisher who's books I will buy regardless of the title or author. No Starch Press is one such publisher.

No Starch has consistently published fascinating books on a wide array of topics. Their slogan is the finest in geek entertainment and they mean it. Currently my shelf includes an illustrated Periodic Table of Elements, Python for Kids, and the Super Scratch Programming Adventure. I'll be writing these up soon, but in the mean time I want to talk about a trilogy of cool books No Starch just sent me. They cover a topic near an dear to many an engineer and hacker: Legos.

Lego Technic Builders Guide

The first title is The Unofficial LEGO Technic Builder's Guide by Pawel "sariel" Kmiec (link). I've read Lego books before, but this is no ordinary title. Devoted exclusively to LEGO's Technic line of models for older children/adults, it dives deeper than I knew Legos could go. While I played with the Technic line as a child, I had no idea the wider Lego enthusiast community had taken their designs so far.

If you've never played with Technic sets, you should really take a look. They are designed around real-world models with functioning gears, motors, and mechanical assemblies. Think of a sports car with rack and pinion steering and a proper differential drive train, or a pneumatically controlled steam shovel. These sets are also the basis of Lego's robotics sets, as they allow you to build almost arbitrarily complex systems entirely from little Lego bricks.

At first glance you might think Pawel's book is just a set of models to build, but it's actually the opposite. He specifically doesn't give you models to build. Instead he focuses on the how, not the what. He explains how a differential drive train actually works, then gives you the instructions to build just that component. Then he shows how to improve it with more robust parts and smoother gears. His goal is to teach you *how* the mechanical systems , giving you the knowledge to integrate the components into your own larger models.

Toy parts, real engineering

As I read through the first few chapters I realized I was not only learning about advanced Lego techniques, but also an introduction to real mechanical engineering. In Chapter 5 he covers the many types of gears, what they are used for, and the unique advantages of each. Chapter 6 covers chains and pulleys, where he explains many of the common pulley combinations used in real mechanical systems. The illustrations are impressively clear and concise. Chapter 7 covers levers and linkages. Even if you've never heard of a Chebyshev linkage or Pantograph, you'll know how they work by the end of the chapter.

My favorite section is probably Chapter 8: Custom Mechanical Solutions. Pawel shows how to improve on the standard LEGO gearing systems with new designs that have unique advantages in strength, locking, and features. The Schmidt coupling is especially intriguing. Later chapters cover advanced mechanics like suspension systems, transmissions, tracked vehicles and the modeling process. The book is impressively comprehensive.

The book covers both old and newer Technic sets, explaining how individual components like the pneumatic system have evolved over the years. (I'm especially fond of the pneumatic claw system I had when I was twelve).

I heartily recommend this book to any adult. Be aware that this really is for older children, probably 12 and up. I imagine an 8 year old would be bored to tears reading it. For younger Lego enthusiasts I suggest one of No Starch's other Lego books (which I will covers soon).

So. Verdict: buy or no buy? Buy! Buy Now!

Though normally 29.95$ you can get it by Christmas for only 19$ if you order with Amazon Prime.

I've always meant to go back and read some of the really old scifi that people have always talked about but I've never read.  Now is finally that time. As a fan of mainly 50s through 70s (Asimov, Clarke, Heinlein, Niven), I've rarely read anything earlier than the late forties. (Jules Verne being a notable exception.)  My goal is not so much to read the novels for pure enjoyment, but to determine if they really are worth of their place in history?  Were they really that good? Did scifi get better? Has it gotten worse again?   In that spirt, lets the the time machine to 1917.

A Princess of Mars

Edgar Rice Burroughs, 1917, 326 pp

I've read a few of the Tarzan novels by and never felt drawn into them.  With the upcoming film adaption, John Carter, I thought it was time to finally get into the series.

A Princess of Mars is the story of Civil War vet John Carter searching for gold out west in the 1870s. He is mysteriously transported to Mars and quickly captured by a race of tall multi-armed green martians.  Thanks to his fighting skills, resourcefulness, and a body accustomed to the heavier Earth gravity; he quickly learns the language of his jailers then escapes with the captive princess Dejah Thoris of the red martians (who conveniently look like really attractive humans).  Throughout the book he goes on various adventures across the planet, gaining fame and glory among the martians all while learning the secrets of their planet.

The Martians call their planet Barsoom, so you will often hear the novels known as the Barsoom series.  Burroughs wrote 10 more in the series over the next thirty years though I get the impression they get progressively derivative as time goes on.

Princess of Mars was his first novel but it's much better than I expected. The science is horrible by today's standards because it was written in a time when we believed Mars had canals, water, and possibly intelligent life, but for the time it was pretty visionary.  He reasonably explains the different societies, lighter than air travel, light based power sources, and the thin but sustaining martian atmosphere. Pretty good for the time it was written.

Make no mistake: this is a swashbuckler.  People of the teens and twenties liked their buckles fully swashed, and swashed they shall be. The Princess of Mars has exotic women in skimpy outfits, green bug-eyed villains, oodles of chase scenes, and sword fights by the score. It's quite fun to read and imagine it played in a theater between The Lone Range and Flash Gordon. Being public domain and free on the Kindle doesn't hurt either.

Conclusion

So, is it worth reading?  I say yes. It's a fun and fast read as well as a piece of sci-fi history. You will find references to Barsoom in many later works throughout the 20th century. It also inspired a generation of authors and scientists from Clarke to Sagan.

Wikipedia entry

Amazon Kindle page

John Carter movie website

I'd like to ask my dedicated readership a very big favor. I'm starting a podcast with my friend Robert Cooper. The challenge is determining the direction. In a lot of the fields we are familiar with there are already some great podcasts (like the Java Posse). We can't decide if it should be programming centric, cover technology issues, or discuss things that are more future oriented (driving cars, space travel, etc.).

So we'd like your help. We recorded three different podcasts with different topics. If you can spare the time to listen to them we'd love to get your feedback. You can email me at joshua at marinacci dot org.

A warning, these are very rough. I've barely edited them, haven't added music and credits, or trimmed them. For the final podcast we are targeting 30 minutes. Anything longer feels like something no one would listen to.

Thanks!
  - Josh

Direct MP3 links

• Programming topics: Excelsior JVM, VM Kit, Dalvik, and Flash
• Self-Driving Cars, the Price of Oil, Voice Recognition
• The Post-PC era, iPad, and browsers

Almost since it was first released, fans of the Raspberry Pi have asked when it the hardware will be updated with better components. A faster CPU perhaps? Double the RAM? Built in wifi? The list of components you could upgrade is long. This request was brought up again when the Raspberry Pi foundation announced the sale of the two millionth Pi.

First I think we should step back for a moment and consider the magnitude of this achievement. 2,000,000. Two meeealion. That’s a whole lot of tiny computers. Not only has this sales volume let the foundation move production back to the UK, these Pis have been used to build computer labs in Africa, teach children Scratch programming, photograph endangered species in infra-red and countless micro-servers where a Pi is strapped to the back of a Costco hard drive. In short, the Raspberry Pi has become an engine for innovation.

At first, I too wanted a new Raspberry Pi with a spec update. True, the specs are anemic. It’s fine and well to say ‘what do you expect for 35$’ but that doesn’t make my code run any faster. Upon further reflection, however, I’ve realized that not updating brings some benefits as well.

Keeping the specs identical means a stable platform. If I buy a Pi three years from now it will run software exactly as my first Pi from a year ago did. Stability is very important; especially when we are talking about software often used in poor conditions without IT staff. The same goes for accessories. Every camera module and GPIO extender is built for this specific device. They will continue to work perfectly in the future.

Keeping the specs identical means our code has to get faster instead. Modern software is blazingly inefficient and it tends to not age well. X Windows on the Raspberry Pi is extremely slow, even though it ran fine on my 486 in college at one tenth the speed. I could only dream of owning a 700mhz computer in 1995. Instead of throwing faster hardware at our problems we need to improve our code. I’m currently building a GPU accelerated graphics API, targeting the Raspberry Pi first. If it can run at 60 fps on the Pi then it can run anywhere.

Keeping the specs identical means we explore and document everything. While slow, the Raspberry Pi has some very interesting hardware that can do amazing things when used properly. Only devices with a long life span get fully explored. Just look at the things people have done with the NES and C64s. Because these devices were so popular they were documented (i.e.: reverse engineered) in exhaustive detail. Today I could build a simple NES emulator over a (long) weekend if I chose, thanks to the hard work done by the community over the years. If we keep the specs the same then the Raspberry Pi will be similarly dissected and documented.

I do not long for a new Raspberry Pi. I long for better software that lets me do more with what we already have. Here’s to another two million identical Pis; each a spark for a new idea, not new hardware.

There's been a ton of talk lately about several mobile operating systems and their problems, such as language restrictions, fragmentation, and anti-competitive practices. It's never a good idea to talk bad about your competition, so I'll take this opportunity to simply say a few things about the webOS (the OS that powers Palm's Pre and Pixi phones) that you might not know.

As always, I am writing this as Josh the blogger. These are my opinions alone and do not reflect the opinions of Palm Inc.

• webOS devices are part of the web, not tethered to a desktop computer. You install apps through the web. You your data is backed up to the web. OS updates come through the web. Your address book is a merged view of your contacts living in the web. You never have to sync to a desktop computer. I know some Pixi users who have never once plugged their phones into a computer, because their phone is already a part of the web.
• The webOS treats it's users like grown ups: they can install any apps they want. What if the app duplicates a built in app? Fine. What if the app isn't in the on device catalog? Fine: you can install apps from the web or beta feeds without any restrictions and do the marketing on your own. What if the app hasn't been reviewed, came from my cool programmer friend, and might hose my device? Well, if you enter the developer code into your phone then you've accepted the risk and can install any app you want. There's a whole community of people making cool but unauthorized apps. They are called the Homebrew community, and Palm encourages them. You're an adult. You can make the decision of what to install on your phone.
• The webOS lets you use any language you want to develop apps. While Palm doesn't provide tools for languages other than JavaScript, C, & C++, there are no restrictions against using any other language. Our new PDK gives you a clean POSIX layer with direct & standard access to input (SDL), the screen (OpenGL), and device services (API bridge). There's nothing stopping you from porting a C# compiler or a Lua interpreter. Developers are free to use whatever tools they wish. The results are what matter. Good apps are good apps.
• The webOS doesn't have fragmentation. All webOS devices run the same OS, regardless of form factor. They are all updated over the air, for free, in all countries and carriers. This means that 99% of webOS devices have the current version of the OS within a few weeks. There is no fragmentation of the operating system across devices or form factors. This lets developers focus on making great apps, not waste time supporting 18 versions of the OS.
• The webOS is built from the DNA of the web. Yes this includes using HTML, JavaScript and CSS as the primary application development layer, but it's more than that. I can just start typing to have my question answered by wikipedia. The address book contains your contacts that live on the web. If my wife changes her Facebook profile photo, my phone is automatically updated. I can write an app that links to other apps through Javascript calls. The web is about connections to the people and services you care about, not just HTML pages. So is the webOS.

At Palm we care greatly about the end customer experience. We are also developers, so we care greatly about the developer experience. And most importantly, we don't see the two at odds. Happy developers create great apps that create happy customers. It's a win, win. That's why we are doing everything we can to make happy developers. We don't always do everything perfectly, but when something is broken we do our best to fix it and be transparent. It's how the web works and it's how the webOS works.

So, as a developer, I hope you'll think about the benefits and freedoms of the webOS, and consider it for your next mobile application.

references

• Palm's Developer Center
• PDK: Plugin Development Kit
• Palm's Hot Apps competition

Over the weekend I moved app bundler to its own project. It is now hosted on GitHub and has a real Ant task.

In brief, AppBundler is a small tool to turn your collection of jars into a native executable for Mac and Windows, as well as JNLPs and single jar apps. With the new ant task you just define a small XML file listing your jars and the main class, then make this call from ant:

    <appbundler
        bundle="bundle.xml"
        target="mac"
        destdir="dist"
        libdir="build/jars;lib"
    />

That's it. Now that App Bundler is independent I'm looking for some help improving it. In particular I'd like to support native Linux executables (shellscripts? rpms? debs?), JavaFX apps, bundling native libs (partly working), and embedding a JRE with the app. If you are interested in helping please join the GitHub project.

App Bundler on GitHub

Every day new things happen that bring our visions of the future to the present -- or are just damn crazy ideas that have to be told. Here are a few.

Human Flight

Some guys in europe have made progress on building Da Vinci's dream of human bird wings. In this video they manage to fly 100 meters. Some say it's a fake, but I sure hope it's real.

link

Sugar Shot

A group of amateur rocket builders are working on a rocket to sub-orbital space (100km) powered not by your usual high powered rocket fuel, but rather a cheap fuel based on sugar. Wish them luck.

Sugar Shot.org

Wooden Skyscraper

Steel and concrete are not the most eco-friendly of skyscraper building materials. Why not return to wood? Architect Michael Green wants to build a 30 story building in Vancouver. Modern fabrication techniques could make it possible.

Wooden Skyscraper @ Co-Design

Copter Madness

What happens when futuristic quad-copter technologies combines with hackers obsessed with avoiding law enforcement? Only one outcome is possible: flying web servers. Prototypes already exist.

link

The future is now, people. The future is now.

The Old Future

And for a reminder of how we built the previous future, The Verge has a great article up on the new book: The Idea Factory: Bell Labs and the Great Age of American Innovation.

link

In my hunt for what's next I've been reading a lot of books lately. A lot of books. As part of my search I decided to hunt down some of the classics in the computer science field that I'd missed over the years. First articles, then research papers, and some Alan Kay work. That led me to a book I'd always meant to read but never found the time: Mindstorms, by Seymour Papert.

You probably don't know the name Seymour Papert, but you if you are reading this blog you almost certainly know one of his greatest creations, and the topic of Mindstorms, the programming language Logo.

My first experience with computers in the early 80s was an Apple II running Logo. Though I obviously didn't realize it at the time, Logo was surreptitiously teaching me math, geometry, and Lisp. (Yes, Logo is a pure functional language). It probably set gears in motion to encourage my later pursuit of software as a career. Here's a quick example:

to spiral :size
   if  :size > 30 [stop] ; an exit condition
   fd :size rt 15        ; many lines of action
   spiral :size *1.02    ; the tailend recursive call
end
spiral 10

image from wikipedia

I haven't finished the book yet so I'll leave the review for another day. Instead I want to talk about the main thesis of the book's section on teaching (and really the main point of the book itself): How can we teach math better, and are we even teaching the right thing?

Early on Papert makes the point that children often identify with a deficiency: "I can't learn French, I don't have an ear for languages". These identities become entrenched and difficult to change, and the are reinforced by a society that is largely mathaphobic. Then he gets to the part that really made me stop and think:

It is easy to understand why math and grammar fail to make sense to children when they fail to make sense to everyone around them and why helping children to make sense of them requires more than a teacher making the right speech or putting the right diagram on the board. I have asked many teachers and parents what they thought mathematics to be and why it was important to learn it. Few held a view of mathematics that was sufficiently co-herent to justify devoting several thousand hours of a child’s life to learning it, and children sense this. When a teacher tells a student that the reason for those many hours of arithmetic is to be able to check the change at the supermarket, the teacher is simply not be-lieved. Children see such “reasons” as one more example of adult double talk. The same effect is produced when children are told school math is “fun” when they are pretty sure that teachers who say so spend their leisure hours on anything except this allegedly fun-filled activity. Nor does it help to tell them that they need math to become scientists— most children don’t have such a plan. The children can see perfectly well that the teacher does not like math any more than they do and that the reason for doing it is simply that it has been inscribed into the curriculum. All of this erodes children’s confidence in the adult world and the process of educa-tion. And I think it introduces a deep element of dishonesty into the educational relationship.

quote from Mindstorms by Seymour Papert. emphasis of last sentence in the original text.

This really made me think. Why did I love math and so many kids don't? Was it genetic? (unlikely) Was it a family member? (probably) Was it a good teacher? (certainly). We can't depend on happenstance to make children who like math. When a kid asks the question "Why should I learn math?" what do we tell them that isn't doublespeak? Surely we have a better answer than 'to be able to check the change at the supermarket'. (itself a largely irrelevant task today)

Well, I can't answer this for everyone, but I want a solid response when Jesse one day asks me the question. My best response so far: Math lets you understand things and make things happen.

Your response?

Mmmwaa haa haa. It lives! I've gotten Java to run on webOS natively with a new set of Java SDL bindings. That means it just *might* time to start a new project. Read on for how it works and how you could help.

For a while I've been following an open source project called Avian. It's a very lightweight and highly portable JVM that can run almost anywhere. Recently I tried a new build and was able to get the ARM port running on webOS!  This is good news because Avian can run pretty much any Java code if you supply it with the right runtime (it can optionally work with the OpenJDK libs).

Now, of course getting a command line app it run is not very interesting. Really we want to talk to the screen to make some real graphical applications. So that brings us to part two: SDL.

If you've been doing desktop programming for a while you've probably heard of SDL, the Simple DirectMedia Library. It's a fairly low level graphics and audio API that runs pretty much everywhere, including on webOS.   But, of course, like many low level APIs it's built in C. So if I want to use Java I need to some wrapper to call it.  The existing wrappers out there are very old and didn't work well on Mac, so it was time to build my own.

Over the weekend I learned how to use Swig, a JNI wrapper generator and successfully ran my new SDL wrappers on Mac, Linux, and webOS.  Here's a quick screenshot:

it's not much but it proves that everything is working.

So what's the next step?  Honestly... I don't know. I created this specifically to let me code Java on webOS, but the SDL bindings would probably be useful for cross platform desktop applications as well.  We could port Amino to it, or do some funky multitouch stuff. It would certainly be great for people creating games. I need your advice.

What would you like to do with this library? What higher level APIs would you like? If you have any ideas of what you'd do with this lib, or would like to contribute to the project (help on Windows compilation would be greatly appreciated), then please message me on twitter: @joshmarinacci.

Thanks!

- Josh

Thanks to my HTML Canvas Deep Dive at OSCON, .net Magazine asked me to write a tutorial for them. The topic was just something interesting with Canvas. I'm a huge fan of infographics, as well as .net Magazine, so I jumped at the chance to write for them. I recently discovered an amazing treasure trove of data at the World dataBank, so that formed the core of the article.

My tutorial will take you from drawing a few shapes using canvas to processing real data from CSV files, then finally adding some interactivity and sprucing up the graphics. It should take you about one hour to complete, and if you know basic JavaScript then you're all set. It was a lot of fun to write. I hope you enjoy it.

Read it now

I am giving a presentation on the future of desktop interface at OSCON in a few weeks. To help prepare for the session I'd like to use you, gentle readers, as my guinea pigs. The following essay is an extremely rough version of what I will be presenting. Please imagine it with humorous illustrations and no grammatical errors. I will greatly appreciate your feedback. What parts should I expand? Where are my arguments unclear or flawed? Would you come to see this talk?

Welcome to The Future of Desktop Interfaces. I'm afraid your presence is actually a ruse on my part. I am *not* going to tell you what the future of desktop interfaces will be. Rather my goal is to trick you into inventing the future for me. So really you are here because I am lazy. Remember, necessity is the mother of invention. Laziness is the father.

Introduction

It is my belief that in a decade 90% of people will use a tablet, smartphone or other non-desktop device as their primary computing interface. I actually made this prediction two years ago so have only eight years left, and the success of the iPad implies that we may actually be ahead of schedule. At this point I think my prediction is relatively uncontroversial. Tablets and smartphones have a managed or 'curated' computing experience. These devices actually meet the computing needs of most people better than a traditional desktop PC. Note: for the purposes of this discussion I mean both laptops and desktop computers running MacOSX, Windows, or a Linux Desktop. anything with an exposed filesystem. These managed computing devices will continue to get better and more powerful, mostly replacing the PC.

So, that's great for the 90%. They will be able to get their jobs done with no fuss. But what about the 10%? What about the people who create content professionally? What about the programmers? The digital artists? The data analysts? The hackers? Are PCs going to atrophy as all attention moves to the 90%? I don't think so. In fact, I think this could be a renaissance of desktop computing. We've been kind of stuck in a rut for the past decade. Desktop interfaces haven't changed much since about 2000. Certainly they are prettier, but they haven't' really gotten better or more productive. I think we could have some really interesting things coming. But first, a diversion.

This is a cave painting [image]
This is a painting from the wall of pompeii, circa 70 ad [image]
This is a painting from the middle ages [image]
This is a painting from the high renaissance [image]
This is a painting from the 1850s [image]

We can see a trend of greater and greater realism built over the centuries leading up to height of the great renaissance painters like Michaelangelo. Then a plateau. Once we had achieved realism where do we go? More portraiture. More landscapes. Painting started to get boring. Then something happened in the 1870s. All of a sudden we get impressionism, cubism, surrealism, and abstract modernism. we see more change in a 70 year period than the previous 700. What happened?

[pictures of Van Gogh and Picasso paintings]

Photography was invented. Until the photograph the commercial purpose of painting was to capture and recreate reality. Most paintings were portraits of rich people. But no painting could compare with the photograph at recreating reality, especially not for the price. The photograph made realistic portrait painting obsolete. This was both a blessing and a curse. Painters needed to dream up with something new to paint. And dream they did. Freed from the need to duplicate reality there was an explosion of new ideas and trends. Painting had new life, which lead to amazing things.

I hope the same thing will happen to desktop computers. PCs have been the primary computing interface for humans for the past thirty years. By definition the they have to serve the needs of all people. But if 90 % of people will use something else, then maybe desktop interface can evolve again. Maybe they can change to meet the needs of the 10% far better.

Trends

I can't reliably predict anything a decade out in our industry. Things change too quickly and there are too many unknowns. However, there are a few trends that I think we can take a look at. The next few years will be shaped by the following forces:

* Moore's law. We have a glut of CPU, GPU, and storage resources on our personal computers. A glut that we don't' really take advantage of yet, and this glut shows no sign of stopping.

* Mature software development tools and toolkits. One engineer can create an app in a few weeks that would have taken a team of programmers months just a decade or two ago. This is partly thanks to our tools like modern IDEs, version control systems, automated build systems, etc. We also have robust toolkits and APIs that let us code at a higher level. Combined with an excess of RAM we can build complex desktop software far faster.

* App stores: while I don't like the curated part of desktop app stores there is no denying that they open the market for smaller software developers. A small team can make an app that will appeal to a very niche market and still sell it profitably because they have access to the entire world. This makes narrower products far more feasible than was possible 10 years ago.

* Ubiquitous networking

* Info glut:

The 10 Percent

Before we talk about what the interface will look like, let's talk about the problems that the 10% have. When I first suggested this topic some people thought I meant that interfaces would become hard to use again. That usability is only for the 90%. Not true. the 10% needs quality software as well, but we need it to be deeper. We have specific needs that must be addressed and are willing to spend the time to learn more powerful interfaces. In particular, we have a torrent of information to be managed.

Every time I get a new computer the hard drive doubles and I always fill it up. Only half of this is photos and videos. I also have endless documentation sets, PDFs, gigabytes of emails, backups of my mobile devices, and word docs stretching back to the early nineties. I personally have more information to manage than most companies did thirty years ago. I need a way to manage it.

Along with this information I have lots of devices that I need to manage as well. iCloud is nice but it doesn't scale very well. I have an iPad, two iPhones (for me and my wife), an iPod touch for my son, and several test phones (Android, webOS, Windows Phone, and Meego), and a few cameras. And that's just the mobile devices. I now have a home media server and a Roku box for the TV. Soon I will have home automation components for my thermostat, to control the lights, water the garden, run the sprinklers, handle security, and watch the baby. Thanks to Moore's Law our homes will soon be awash in computing. That's a lot to manage. I can't do it all from an iPad.

So where do we start to address these needs? First: hide the filesystem.

information management

Hide the filesystem. Use robust shared data stores underneath. (Man, I really wished BeOS had survived). I'm not saying we need a database to replace the filesystem but at least hide it. I don't care how my stuff is stored as long as it works, and works quickly. The example most people are familiar with is iTunes. MP3 libraries were the first widespread case where we hit the complexity wall. Most people simply have too many songs to manage effectively using directories. Instead we need a database that can search and filter by multiple criteria and be very responsive. iTunes does this for music.

[picture of iTunes]

I'd like to see this interface style applied to more kinds of files. Here is an app for academic researchers to manage the many scholarly papers they have to read.

[picture of Papers]

[picture of Sparrow]

Sparrow is a great email client for Mac that is much faster than the system default. It sync with social networks to get avatars. It has intelligent threading. It's good enough that I spent 20$ to replace a free system app. But it's just email. It doesn't handle the rest of my communication. And while beautiful it's not very customizable. Customization matters as much as beauty.

I'd like to have a single place to store my external communication: IM logs, SMS logs, all tweets, all emails, all FB posts. One app. One interface. When I'm composing an email to someone I'd like to see all of the messages I've ever sent to them. And of course this should magically sync with all of my online services to keep up to date.

Idea I want a single place to see all of my code across all projects, be aware of all version control systems. My IDE only manages the projects I'm currently editing. I want something to manage *all* of my projects, both personal and professional, including my build services and the bug tracking systems I'm currently involved with. Most of these systems have APIs so I don't it would be difficult to build.

Apple is moving in the direction of system wide saved queries, similar to what iTunes offers, but they are doing it very cautiously. There is so much more we can do.

customization and automation

Just as great painters would make their own paints and canvases, we need the ability to create our own workflows and customize our tools.

* apps communicate together

* build new apps out of pieces of other apps

* customize the general computing environment, but still

* be able to handle anything

the line between a custom workflow and real programming is fuzzy

Let me give you some examples:

iTunes smart lists and IDE keymaps

We need to take this to the next level. I should have a keymap that works system wide in all apps. The Mac has smart lists that can be used in any app, but only for photos and albums. This should be available for any kind of media list.

I should be able to change the interface of any app. In a drawing program I can change the toolbar, but why doesn't *every* action in an app have a toolbar item? Why can't I create different toolbar sets for different kinds of projects? Then these sets should be shared across apps.

Automation

If every action has a toolbar item then we could take this to the next level and actually script our apps together visually. Mac OS X does this with automator but they never took it as far as it could go. Now it appears that Automator will be crippled by the new Mac App Store restrictions. This is a shame. I think Automator never really took off because not enough apps supported it and there was no easy way to share scripts between people. My ideal vision would be something like: visually create a script to take the current document of photoshop, convert to PNG, post to Flickr, send out a Facebook update and Tweet to the Flickr link *tomorrow morning at 9am EST*. This should not be hard to do in the 21st century, and yet our tools don't make this easy to do. This is really a problem with app communication. I'm not entirely sure how to solve it, but the potential is huge.

If we start to think of a desktop app as a collection of modules rather an a monolithic whole, then we can start doing these sorts of cool things.

With such a modular system the line between customization, automation, and real programming becomes very fuzzy. If we make it easy to create and share these scripts then we can make the desktop twice as powerful.

Integrate the web

Once we make our apps modular and scriptable they can start talking to the web. There are some simple things we can do today. Why don't more desktop apps have 'share via twitter' buttons? Why doesn't photoshop have it? I've been working on an open source drawing program called Leonardo Sketch. One of the first features I added was the ability to share a snapshot of what I'm working on right now through Flickr, Twitter, and Facebook.

I'd like to take this to the next level. I recently added an asset manager to Leo Sketch. It's an iTunes like view that shows you all of the clip art, fonts, palettes, and textures that I have to work with. But why should my asset collection be limited to what's on my computer? I've added a flickr search which will find creative commons licensed images based on keywords. next I want to integrate Google Fonts. Then I can access a huge collection of fonts from anywhere in the world, easily searchable.

How else could we ingrate the web into desktop apps? How about selecting text and having Bing translate it into another language, right from within my drawing. Or let me see the most popular color swatches that are tagged with 'summer'.

How about an IDE that will let me search for small open source code libraries. Say I'm working on an app that needs to parse a CSV file. Instead of jumping to a web browser I'd like to be able to search git hub for code snippets that match my current working language. It shouldn't be any more complicated than code completion. It would show me 8 snippets which take a file and return a string, along with their ratings. When I chose the one I want it downloads the code, compiles it, and puts it in my class path.

Context awareness Computers must learn from us and do things for us.

The other half of integration and automation is the computer doing things for us without having to request it. This trend is already happening from two very different directions. On one end our phones are learning more about us, which enables services like Siri. On the other end our IDEs are getting smarter and smarter. IntellJ IDEA not only knows what possible methods can fit the current spot in my code, but it will automatically add the imports for me. Because the editor has so much contextual knowledge about what I'm doing right now (I'm editing a particular place in a particular file in a particular project with a particular class path), it can do lots of things for me, or at least monitor what I am doing and give me advice. We should have all our apps doing this.

My word processor should let me type in an equation and offer to evaluate it for me. I should be able to type in a reference to a stock symbol and have it turn into a link with the current stock value. If I'm listening to music my calendar should tell me about an appointment 15 minutes before hand with a silent unobtrusive message, then increase to an alarm and turning off the music as I get closer to the appointment time. There should be a system wide switch to turn off all messages and alerts when I want to be in concentration mode.

My laptop knows where it is based on my phone's GPS and the local wifi access point. It should be able to adjust itself based on the location just as my phone does. The possibilities are huge here, but it worries me that almost all of the innovation is happening on the phone side, not the desktop side.

Identity Management and Service Sharing

Finally identity management. Originally we thought identity was just a handle. Then we thought it was your real name representing a single unified you. You have one identity on the web, period. But that was wrong too. Now we understand that identity is far more complicated. When I do something on a Google service am I acting as Josh, the author and open source coder, or am I acting as Joshua, the Nokia researcher? The answer is: it depends. I might be either of those, or some mixture.

We also have identity scattered across many places with no way to integrate them while protecting my privacy. This is a huge mess that is going to keep getting worse. I'd like to see an OS wide identity system. Any app, including the browser, which wishes to integrate with the network can ask the identity system for credentials. This allows any app to talk to anything, and at any time I can change which identity I'm using. This could be done per app or even for the desktop as a whole. I can imagine doing this with a virtual desktop system where one desktop is 'Josh the author' with a green background and menu bar. The other desktop is 'Josh the engineer' with a blue background and desktop. Each has credentials that can't be shared between them without explicit actions by me, the human.

We can see some of this in password managers and browsers that sync their settings, but this really needs to be system wide.

A plea to Desktop Linux

There will never be a year that Linux conquers the desktop. That era is over. The world is going mobile. Instead of focusing on a complete desktop OS, create an awesome desktop environment that can be seamlessly layered on top of any proprietary OS. Over time people will use more and more of your stuff, until they can switch entirely. Especially if you make the switch easy by having cloud based backup of everything (hello version control!).

My favorite app for Mac now is a command line tool called Brew. It uses community developed 'recipes' which download and compile lots of linux programs and libraries. With Brew I can be on a Mac but have ridiculously easy access to the rich ecosystem of linux tools like apache, imagemacgick, sdl, and node.

What I want is a graphical Brew app. I install it once and log in. I then downloads and configures my favorite email and browser apps, all of the command line programming tools I need, and anything else provided by the open source community. Even my settings are synced from a cloud server. *That* is how linux can win the desktop. You will never win over the masses. Focus on the hyper users and let them ease into a fully free desktop.

Conclusion:

I hope that you have gotten two things out of this essay:

First, most computing is going to managed devices but the desktop interface can have a rich future ahead of it, if we are willing to build it.

Second, I hope you come away with some ideas for how we can move the desktop forward. We are going to live in the future we make so we'd better make a good one. I understand it's going to be difficult, but this really needs to happen. We must accept that people are reluctant to change, but do it anyway. If you are right then we will win in the end. (or at least our ideas will).

Most of of my free time work for the past few months has gone into Amino, the UI toolkit that Leonardo is built on, but Leo itself has gotten a few improvements as well. I'm happy to announce that the next beta of Leo is up, including:

• Amino gives us a more uniform look and feel, now skinnable with CSS
• Rulers!
• The Make a Wish Button, now the easiest way to send feedback.
• the canvas properly scrolls and zooms with real scrollbars now
• Under the "Path" menu you can now add, subtract, and intersect shapes.
• export to PDF
• actual unit tests for exporting to SVG & PNG, almost every kind of shape is supported now
• Tons of bug fixes

Unfortunately, as part of the Amino toolkit overhaul certain things have gotten slower. In particular doing layout when you resize the window is significantly slower. Don't worry, I have lots of speed improvements coming to Amino which will address this in Leo.

As always, please test and file bug reports. The export filters in particular are probably still have bugs to fix.

Builds are here:

A big part of my new job at Palm is education, in the form of tutorials, blogs, and of course speaking at conferences. Two new speaking engagements have recently come up. Palm Developer Day and OSCON. Read on for details.

Palm Developer Day

This month I'll be doing the day long Introduction to WebOS session. In this session I'll take you from zero to 60 in about five hours, giving you everything you need to know to make great apps for the webOS. This Developer Day is now sold out,(we've expanded. see below) but we are planning to do it again later this year after we work out the kinks. We also plan to video record the sessions and put them on the web. Stay tuned for more details.

Update

I thought we were sold out for the Palm Dev Day, I've just heard that we have expanded the capacity and reopened registration. Space is going fast, so sign up now!

OSCON

Yes, I'll be at O'Reilly's Open Source Convention again this summer. In addition to attending (a scant 2 hours from my house this time!) I'll also be speaking on Marketing your Open Source Project on a Shoestring Budget. I'll discuss different ways you can get the word out without breaking your budget, and throw in a few case studies.

If you've never been to OSCON before and live in the Pacific NorthWest I highly recommend attending. It's a great opportunity to get out of your particular technology bubble and experience what the rest of the tech world has to offer. I went two years ago and learned about Jython, Arduino, Trac, an extreme unit testing; all worlds away from my usual Java / JavaFX background.

The conference is July 19th-23rd, and I'll be speaking Friday morning. If you make it here be sure to let me know so I can buy you a beer. (Oh yeah, Portland has some of the best microbrews in the country).

A splendid time is guaranteed for all!

The webOS auction has ended successfully. Every item sold, some for far more than I thought they would. Combined with some anonymous donations we raised over 6000$ for the Hill Family. I am overwhelmed and incredibly grateful. I knew the webOS community was passionate but I had no idea. We couldn’t have done this without your support. Thank you so much!

Now, on to the details. I’ll be shipping all items out this week. If you won something and haven’t paid yet, please do so. You should have received an email from the 32auctions.com site. I’m going to send all domestic items USPS unless you request otherwise. If you are international buyer please let me know if you have any special shipping requests.

My wife and I are traveling to Atlanta with our little one in a week to spend some time with my family and present them with the check. Again, I cannot thank you enough. I am truly amazed by the webOS community. Thank you.

 Josh

Greetings Earthlings!

Today's the first day I haven't been traveling, so I can finally catch my breath and write down some notes. It's been a helluva week. Last week I drove to Portland for OSCON to give several presentations and be involved in general geekery (if you follow me on Twitter, that's why you saw so many posts tagged with #oscon)

Monday

Due to a cat emergency (Nori is fine now) I arrived mid-afternoon, missing the tutorial sessions for the day. I spent the rest of the day working on slides and met with some of my new HP co-workers. I have to say the HP guys have been great to work with. They are very enthusiastic about what we can build with webOS.

Tuesday and PJUG

The morning was spent in the Erlang three hour technical session. I love OSCON because I can learn about things completely out of my element. Knowing nothing about Erlang before I can now build a basic multi-threaded program in it. It's got some very interesting concepts. It feels like a mix between Lisp and Prolog. Functional and match based.

Tuesday evening I gave a presentation to the Portland Java User's Group. For the first half of the talk I went over long term trends towards mobile devices, tablets, etc. and the shift away from PCs as the primary computing interface. Then I dove into how the mobile web solves the N-device problem with some technical tips and UI guidelines for mobile devices (use stylesheets, have large click areas, pare functionality down). For the last part I covered Palm's take, covering Ares, our mobile browser, our app ecosystem, and when it's appropriate to do one over the other. (And how webservices are the answer for everything :). I'll have slides for this talk up soon.

Afterwards we went downstairs where the Oracle dev outreach rep bought us all beer, then headed out for some Voodoo Doughnuts. ButterFinger doughnut for the win!

Wednesday

Wednesday morning we showed up to the expo floor early to get everything set up. I brought a bunch of Palm T-Shirts, a box of webOS books, about 80 aluminum water bottles, and 10 phones. The booth was very well attended and Ares was a big hit. I definitely need to get more of these nice water bottles, at least for the pacific northwest. We have so many bikers and hikers here, people use these things constantly.

Wednesday morning HP had a session covering all of the ways HP is involved in open source. I did a 12 minute segment covering webOS architecture, app development options, our catalog, and a 5 minute Ares demo. (yes, only 12 minutes for all of it!) At the end we gave away a couple of phones to people who asked good questions. (This is a lesson to attendees. Always stay till the end!)

Book signing

OSCON is run by O'Reilly. Since I wrote Swing Hacks for them five years ago they asked me to do a book signing at the Powell's booth. As I expected no one wanted me to sign a five year old book on an even older technology, but I did have a nice time chatting with the guys at Powell's (an excellent local Portland bookseller with one store dedicated to technical books).

Thursday

Thursday I took the day off to spend time with my wife in Portland. Primarily Nordstrom's. We must have priorities.

Friday

Friday morning I did my personal session on Marketing Your Open Source Project on a Shoestring Budget Attendance is generally lower on the last day, so I wasn't surprised to see only about 25 people there. I wish O'Reilly had put me into a smaller room though, as it was built for about 250 and felt very empty. The talk was very well received by the audience, though. Several came up to me later telling me how much they liked it. Definitely something to repeat in the future. I'll have the slides up soon.

Next I attended "Repent Repent, the 2038 crisis is almost upon us" a tongue in cheek talk about the Y2038 problem where unix dates will roll over to 1901. Finally I saw the humorous keynote on The World's Worst Inventions. Describing it can't do it justice. Just go watch it.

Friday night my dinner guests bailed on me (or rather, hard crashed after 8 days of conference, poor guys) so Jen and I went out for some excellent Portland Sushi. I tweeted about it and someone showed up to join us. Go Twitter! Saturday morning we packed up, had a breakfast at a local cafe (Milo's Cafe, *highly* recommended. huevos rancheros & crab cakes were awesome!), then drove home.

Monday: Mobile Portland

The rest of Saturday and Sunday I was pretty much a zombie, but Monday afternoon I drove back up to Portland for yet another event. Jason Grigsby, who has worked on some high profile mobile apps, is the leader of MobilePortland.com, a local mobile developers group. A week ago their July meeting speaker plans fell through so he asked me if I'd talk to them about webOS while I was in town for OSCON (not realizing I live only 2 hours away).

So Monday I drove up to Portland and gave a 1 hour presentation that leaked into about 2 hours followed by Thai food afterwards with some of the crew. I gave them an overview of webOS, the development options, then spent quite a time in Ares showing how easy it is to build for. During a lengthy Q&A session they asked some really good questions and we got to dive into how the developer experience is very important for us. I also met some HP developers from Vancouver, two reporters, and a writer for PreCentral. It's amazing how many mobile related people live in Portland.

UStream recording of my session here

Whew. I think it's time for some coffee or a nap.

I'm writing this from a hotel room in SunnyVale, recovering from the tremendous event we put on for our dedicated developers at Palm's first ever webOS developer event last Friday and Saturday. The turnout was great. Over 100 developers paid their own money to drive, fly, and chopper in to Palm HQ. I taught an intro to webOS session for the entire first day, then answered questions and attended sessions the second. Topping it all with dinner at a local brew pub was a splendid idea.

My great thanks to my fellow Developer Relations Team and the many dedicated engineers who came to present, answer questions, and socialize with our developers. I know it meant a lot to the attendees to have such a personal connection with Palm. Extra special thanks to our CEO, John Rubenstein who personally addressed the developers at the end of the first day.

All in all, a great success. Slides and photos are forthcoming. Now time to sleep for a few days until next week when I'll be speaking on HTML 5 at the Web 2.0 conference.

- Josh

Every day or so I read another blog post (or ranting comments) about how BlackBerry could be rehabilitated, or how Nokia could restart Maemo and build the ultimate smartphone again. Things came to a head after Jolla announced their first phone for sale. Surely this phone with an amazing user interface will vindicate the N9?! Amazing technology plus a killer UI? Marketshare is theirs for the taking!

I’m sorry; but no. Most people don’t understand how a smartphone platform works. Simply put: there will not be any new entrants to the smartphone game. None. At all.

Obligatory disclaimer: I am a researcher at Nokia investigating non-phone things. I do not work in the phone division, nor do I know any internals of Nokia’s phone plans, or Microsoft’s after the acquisition of Nokia’s devices group is complete. I hear about new devices the same way you do: through leaks on The Verge. This essay is based on my knowledge of the smartphone market from my time at Palm/HP and general industry observations.

A few new Android manufacturers may join the game, and certainly others will drop out, but we are now in a three horse race. The gate is closed. I’m sorry to Jolla, Blackberry, the latest evolution of Maemo/Meego/Tizen, whatever OpenMoko is doing these days, and possibly even Firefox OS. No one new will join the smartphone club. It simply can’t happen anymore. You can’t make a smartphone.

There was a time when a small company, with say a few hundred million dollars, could make a quality phone with innovative features and be successful. This is when ‘successful’ was defined as making enough profit to continue making phones for another year. In other words: a sustainable business, not battling for significant marketshare. Those were the days when Palm could sell a million units and be incredibly happy. The days when BlackBerry had double digit growth and Symbian ruled the roost.

Then came 2007. It might be over-reaching to say ‘the iPhone changed everything’, but it certainly was an definitive event. The 1960s began in January of 1960, but ‘the sixties’ began when the Beatles came to America in early 1964. Their arrival was part of a much larger cultural shift that started before 1964 and certainly continued after the Beatles broke up. I would personally say the sixties ended memorial day of 1977, but that’s just my opinion.

The Beatles appearance on the Ed Sullivan show is a useful event to mark when the sixties began, even though it’s really a much fuzzier time period. Steve Jobs unveiling the iPhone in 2007 is a similarly useful historical marker. Everything changed.

Data networks

The first big change was data networks. In the old days there really wasn't a data network. Previous phones were about selling minutes and, to a lesser extend, texting. carriers didn’t really care about smartphones. They didn’t push them or restrict them. As long as you bought a lot of minutes the carriers didn’t really care what you used.

There were no app stores back then, just a catalog of horrible JavaME Tetris clones at 10 bucks a pop. I owned a string of PalmOS devices during this period. Their ‘app store’ was literally boxes of software in a store which you had to install from your computer. No different than 1980s PCs. While my Treo had access to GSM, it was merely a novelty used to sync news feeds or download email very slowly.

Around 2006 the carriers 2G and 3G data upgrades finally started to come online. Combined with a real web browser on the iPhone you could finally start doing real work with the data network. This also meant the carriers became more involved in the smartphone development process. Clearly data would be future, and they wanted to control it. Carriers request features, change specs, and pick winners.

Carrier influence means you can’t make a successful smartphone platform without having strong support from them. This is one of the things that doomed webOS. The Pre Plus launch on Verizon should have been huge for Palm. Palm spent millions on TV ads to get customers into the stores — who then walked out with a Droid. Without having strong carrier support, all the way down to reps on the floor, you can’t build a user base. To an extent Apple is the exception here, but they have their own stores and strong existing brand to leverage against carrier influence. Without that kind of strength new entrants don’t have a chance.

The cost of entry

Another barrier to entry in the smartphone market is the sheer cost of getting started. A smartphone isn’t just a piece of hardware anymore. It’s a platform. You need an operating system, cloud services, and an app store with hundreds of thousands of apps, at least. You need a big developer relations group. You need hundreds of highly trained engineers optimizing every device driver. The best webkit hackers to tune your web browser. A massive marketing team and millions in cash to dump on TV ads. You need deep supply chains with access to the best components. The cost of entry is just too high for most companies to contemplate.

To continue with webOS in 2011, I estimate HP would have had to spend at least a billion a year for three years to become a profitable platform — and that was two years ago. The cost has only gone up since then. There are very few companies with the resources. You already know their names: Apple, Samsung, Google, and Microsoft. All vertically integrated or well on their way to it. You aren’t one of these companies.

Access to hardware components

Smartphones need good hardware to be competitive. With the 6 month cycles of today’s marketplace that means you have to access to the best components in the world (Samsung), or have such control of your stack that you can optimize your software to make do with lesser hardware. Preferably both.

Apple has the spare cash to secure a supply chips and glass years in advance; you do not. If Apple has bought the best screens then your company has to make do with last years components. This compromise gets worse and worse as time goes on, making your devices fall further behind in the spec wars.

Retreat to the low end

A common solution to the component problem is targeting the low end. After all, if you can’t get the best components then maybe you could build a decent phone out of lesser parts. This does work to an extent, but it limits your market reach and opens you up to competition at the low end. You are now competing with a flood of cheap Android devices from mid-tier far-east manufacturers.

Even if you OEM hardware from one of these low-end manufacturers you are now in a race to the bottom. Your product has become a commodity unless you can differentiate with your user experience. That requires the telling potential customers about your awesome software, which requires a ton of cash. Samsung spends hundreds of millions each quarter on Galaxy S ads. This path also requires an amazing UI that will distinguish you from your peers.

A disruptive UI

Even with an paradigm shifting UI you’ve got to overcome all of the difficulties I outlined above. Most people in the wealthy world have smartphones already, so you not only have to convince someone to buy your phone, but to leave the phone they already have. Your amazing UI has to overcome the cost of change. Inertia is a powerful thing.

Most likely, however, your new platform won’t have such a drastically different interface. Smartphones are a maturing platform. A smartphone five years from now won’t feel that different than today’s iPhone. Sure, it will be faster and lighter with better components, but it will still have a touch screen with apps, buttons, and lists.

Unless you’ve figured out how to make a screen levitate with pure software you won’t be able to shake up the market. Google Glass is the closest thing I can think of to a truly disruptive interface. Adding vibration effects to scrolling menus is not.

No hope?

So does this mean we should give up? No. Innovation should continue, but we have to be realistic. No new entrant has any chance of getting more than one percent of the global market. That could still be a success, however, depending on how you define success. If success is being profitable with a few million units, then you can be a success. You will have to focus on a niche market though. Here’s a few areas that might be open to you:

Teenagers without cellphone contracts. Make a VOIP only phone. Challenge: you are now competing with the iPod Touch.

Point of Sale systems. Challenge: this is an enterprise only pitch and they have long sales cycles. You might be dead by then. They also don’t care about user experience, so your awesome UI doesn’t matter. Small to medium businesses will use apps on standard devices like iPads, so you are back to where you started.

Emerging markets: half of the world is buying their first smartphone. This is an opportunity if you can get in fast with cheap hardware, but now you compete with FirefoxOS.

Mozilla is targeting emerging markets where last generation hardware is more likely to succeed. Even so, Mozilla is working very closely with local carriers to ensure success while facing down competition from low-end Android devices. They also have the advantage of being a non-profit. Their ultimate goal is not to become a profitable phone company, but rather keeping the web open and free. This is probably not a viable option for you, and even Mozilla may be too late to follow this path.

The sad truth

Smartphones are a rapidly maturing product. Soon they will be pure commodities. Just as I wouldn’t suggest anyone build a new line of PCs or cars, smartphones are becoming a rich man’s game. Unless you start with a few billion dollars you have no hope of making a profit. Maybe you could follow CyangoenMod’s approach of building value on top of custom Android distros, but even that risks facing the wrath of Google.

Sorry folks. There's plenty of room to innovate elsewhere.

I'm tired of hearing people talk about how we need a new pipeline to bring oil from Canada to Texas for processing. They say we need to do this for the US to have "energy independence". This is bullshit. Anyone who claims this has no idea how global commerce works. Oil is a fungible commodity so whether Canada sells their oil to the US, China, Brazil, or Switzerland makes no difference. Let me explain.

Global commerce is a like a bathtub. Imagine a bathtub filled halfway with water. The US is a one end, China at the other. Other countries are at other spots. Now imagine what will happen if you pour a gallon of water in at the US end: it will be higher for a split second and then the water level will even out through the entire bathtub. If you pour the gallon in at the China end the same thing will happen. Because the water can freely flow throughout the bathtub, and because all water is the same, the bathtub will have the same level regardless of where you add more water.

Global commerce is like the bathtub. When we are talking about products that are uniform, such as natural commodities like rice or oil, and there are no barriers to trade, then the product will flow uniformly throughout the world. Adding more oil to the world's supply will lower the price for everyone. Removing from the supply, or increasing demand, will increase the price for everyone. All oil is the same and can be shipped anywhere so it is called a fungible commodity. It doesn't matter who Canada sells their oil to. It goes in to the global pool and raises or lowers the price for everyone.

So now we come back to energy independence. Energy independence sounds like a nice goal, but what does it really mean? This is about an oil pipeline, not all possibly energy supplies, so we are really talking about oil independence. So what does that mean? Does it mean that we have energy in case China decides to keep their oil?

As we just discussed, oil is a fungible commodity. If China 'keeps their oil' it means they are telling chinese oil manufacturers to sell oil only within the country instead of on the open market. By definition suppliers want to sell wherever they can get the best price, which is why the global market evens out for fungible commodities. If China imposes such a domestic rule then they are telling their own people not to sell for the best possible price. Thus China is hurting it's own industry. Chinese oil manufacturers are making less profit than they could otherwise.

If China 'keeps their oil' just means they increase their consumption, well that is no different than any other country increasing their demand. The price will rise globally. It won't help us anymore than if we got the oil directly from Canada. If somehow processing Canadian oil closer to home saved 5% on costs then that oil would be sold on the open market to get the best price, not just in the US. It's a global commodity, remember. The price will rise or fall for *everyone*. Building a pipeline provides no advantage to the area the pipeline is built through. You can't be independent from a global commodity without hurting yourself.

But what about jobs?

I have also heard the claim that this will bring more jobs to the US. That is true. Even if the price is global it would be better to have the work done in the US instead of other countries, right? According to this article at CBS News

analysis suggests that Keystone's job-creating potential is more modest. The U.S. State Department calculated last year that the underground pipeline would add5,000 to 6,000 U.S. jobs. One independent review of Keystone puts that number even lower, with the Cornell University Global Labor Institute finding that the pipeline would add only 500 to 1,400 temporary construction jobs. The authors of the September report also said that much of the new employment stemming from Keystone would be outside the U.S.

Transcanada itself cast doubt on its employment forecast when a vice president for the company told CNN last fall that the 20,000 jobs Keystone would create were temporary and that the project would likely yield only "hundreds" of permanent positions.

So, only a few hundred new permanent jobs. It seems like there are far better ways of creating jobs than digging a 1700 mile trench.

Please send feedback and comments to my twitter account @joshmarinacci instead of on the blog. Thanks!

I'm speaking at OSCON in Portland next week, and what a busy week it will be. In addition to my personal session on marketing open source projects, I've added some Palm stuff in collaboration with HP. If you can't attend OSCON but will be in Portland I will also be speaking at the Portland Java Users Group. I'll also be working at the HP booth where we will be giving away phones, books, tshirts and some super nice water bottles. Here's the full schedule:

• Tuesday 6:00PM: Introduction to the Mobile Web
  Portland Java User's Group
  Oracle Building, 8th Floor room 8005
  Pacwest Center,
  1211 SW 5th Avenue
  Portland, Oregon
  
• Wednesday: 10:40AM HP's Session: Cloudy with a Chance of Revolution
  This is an overview of where HP is going in the cloud, including a section on webOS and Ares.
• Wednesday: 3:10PM Swing Hacks book signing I'll be signing copies of Swing Hacks at the Powell's booth.
• Wednesday: 6:00PM O'Reilly Author Meet and Greet
  O'Reilly booth, #313
• Friday 10AM Marketing your Open Source Project on a Shoestring Budget
  Learn how to generate interest and build a userbase for your open source project.
  Portland 255
  

No Starch Press is on a roll with its series of Lego themed books. While most of them are about model ideas or construction techniques, Beautiful Lego is different. This is a Lego art book. In classic coffee table style it is filled with gorgeous photos to thrill the reader. Beautiful Lego does not seek to discuss 'can Lego be art', but takes it as fact. These are works by artists, just artists using the medium of Lego instead of paint or clay, and the results speak for themselves. Stunning.

As part of my ongoing efforts to create better designed software, I some how ended up creating my own new UI toolkit. This is really a part of my belief that a decade from now 90% of people will use phones, slates, or netbooks as their primary computing device. Amino is my experiment building software for that other 10%: the content creators who need killer desktop apps, the programmers who want great tools, and the knowledge workers who need to manage incredible amounts of information at lightning speed. Amino is the toolkit for these apps.

Today I am talking with Matt Grimm, the final member of the Retro Game Crunch trio. You can also read the previous interviews Shaun Inman and Rusty Moyher. There's still a few days left to help push the Retro Game Crunch to the finish line. Pledge now!

Updated!

I know it's been quite a while since I've posted. I have no defense other than to say I have an 18 month old baby. Toddler on the move 24/7 makes for a very tired daddy.

For Christmas Jen and I finally bought a TV after four years of distraction-less living. We finally decide it was time after countless evenings watching Hulu on my 15" laptop. We were adamant, however, that we would not buy cable. We just want a better way of watching Hulu, NetFlix, and a few other sites. To make that happen I bought the latest Roku device, Angry Birds edition.

I'm really enjoying my new job at Nokia. Unfortunately there is not much I can talk about since I'm exclusively doing research for future products. This is a change for me. I'm used to talking about what I work on. In fact, it's been my job for the past 4 years to do just that. On the other hand, the reduced travel schedule has given me more time to think about other non-smartphone related things, which is quite a nice change. And last week I came to a realization: driverless cars will change everything.

Disclaimer: I did not pay for many of the books I review here. One of the perks of being an O'Reilly author is easy access to free copies of almost everything O'Reilly publishes. However, all of these reviews are freely done of my own initiative. I choose the books I review and I receive no compensation other than the free copy. These are my own opinions and do not reflect the opinions of O'Reilly or my employer Nokia.

The Arduino Cookbook, by Michael Margolis

When you first begin hacking with Arduino, as I recently have, you will most likely spend the first few weeks scouring the Internet for information. The Arduino system is so cheap, powerful, and flexible that you will immediately think of a million things to do with it. This can be a problem. Not only do many of us lack the time to build every project we've dreamt up, but using just the web for information is problematic. The docs on Arduino.cc are great for introductory topics but I quickly found my self at its limits. As a software guy I need to know not only about Arduino itself, but sensors, components, 3rd party libraries, and power systems. In short, I need a complete electronics background to fully use my Arduino board. That's where the Arduino Cookbook comes in.

The second edition of Arduino Cookbook, by Michael Margolis, was recently published by O'Reilly. In my opinion this is the best one stop shopping source for Arduino information. It is not a pure introductory tome, though the first chapters do give you a quick review of Arduino to keep you up to date. The bulk of the book is organized around functional topics; things you would actually want to *do* with your Arduino.

The first few chapters cover the Arduino language, math, serial IO, and basic switches. Though it was not hard for me to pick up the Arduino language (essentially a simplified C++), these chapters covered a lot of finer details I had missed when reading the online docs. Each chapter is structured as a series of how-tos such as "Shifting Bits" and "Using a Switch Without External Resistors".

Later chapters cover specific topics like Getting Input from Sensors, Physical Output, Audio Output, and Wireless Communication. I really like that each how-to section not only shows you how to complete the task at hand but also gives you background into what is really going on. This is especially useful when you reach advanced topics like driving motors. The book gives a background of different kinds of motors, how they work, and how they are controlled before diving into specific tasks. This structure gives you a great electronics primer as you learn the ins and outs of Arduino.

If you buy only one book on Arduino, make it this one. It gives you everything you need to get the most out of your hacking endeavors.

on Amazon, paper and Kindle

or

direct from O'Reilly as paper, ebook, or no-DRM PDF

First, watch this amazing video created by a newspaper industry research group. It depicts the digital newspaper of the future. The surprising part? The video was created in 1994! And yet the newspaper industry didn't listen to their own research.

I'm very excited to announce that two of my presentations have been accepted to OSCON this year (thankfully back in Portland again). OSCON is one of my favorite conferences because I get to learn as well as teach. There is such a diverse set of topics that I try to get out of my comfort zone and learn something new every year. (One year it was an intro to Arduino). OSCON will be this July 25th-29th in Portland Oregon. And let me tell you: Portland in July is simply beautiful, with the best microbrews in the country.

Tomorrow we will hopefully awake with news of a magical Apple tablet, so tonight I thought I'd give you a few things to read as you drift off to tablet dreamland with touchable sugarplums.

World of Ptavvs, Larry Niven, 188pp, 1966

I'm very happy to announce that my interactive book, HTML Canvas: A Travelogue, is now available for the iPad. It includes the same great content as the webOS version: a complete introduction to HTML Canvas with interactive examples, for just $4.99. Several bugs have been fixed in this build, which are coming soon to webOS as well.

Last night I declared Internet Bankruptcy.

My name is Josh Marinacci. I used to be in the webOS Developer Relations team at Palm. I'm auctioning off all of my webOS devices and swag that I've collected over the years, including some very rare items, to help my brother in law fight cancer.

Though engineering has always been a natural fit for my career, I have long wanted to be an artist. I suppose I'm not truly sure what it means to be an artist, but I still dabble, play, and learn. That seems to be enough.

I know IFRAME, I know. We've had a good run. You've tried hard and back in the day you were somethin' special. The way you could bring in content from any domain was nothing short of amazing, and you certainly took out the trash when you bumped off FRAMESET. But that was then and this is now. A lot has changed in the past few years. CSS and AJAX are really hitting their stride and you just can't hack it. I'm willing to overlook a few margin bugs, but this?! Well this is simply the last straw.

Over the years I've worked on a lot of open source projects. I've also worked on quite a few commercial projects. What a lot of them have in common is the need to market themselves to developers, but without any marketing budget. When I worked on JFXStudio my budget was 20$ a month from my own pocket.

Thank you for helping me Bridge The Gap, a webOS auction to help my brother in law fight cancer. Your support means more to me than I can say. I'm constantly amazed by the passion of the webOS community. I have some new updates to share with you.

I'm happy to say the Retro Game Crunch Kickstarter project succeeded! It was close for a while, but in the last 24 hours you pushed it over the line to 111%.

Hi. My name is Josh Marinacci. You might remember me from the webOS Developer Relations team. Despite what happened under HP, webOS is still my favorite operating system. It still has the best features of any OS and an amazing group of dedicated, passionate fans. I deeply cherish the two years I spent traveling the world telling everyone about the magic of webOS.

It's been a month since I posted so I'd say it's time for a rant. I've been traveling a lot lately so the object of my wrath this week is alarm clocks. Most specifically the alarm clocks in hotel rooms, but home use clocks don't get off easy either.

I've been wanting to get into electronics and building physical things for a while. I have a lot to learn though. My only exposure to micro-controllers was when I played with an Arduino for a day about two years ago. The last time I picked up a soldering iron or drew a schematic was my lone electrical engineering class in college nearly twenty years ago. My degree is in computer science with a focus on graphic and AI giving me a decidedly software-only career. This makes picking up electronics both challenging and fun.

Building Mobile Applications with Java Using GWT and PhoneGap

Animation is just moving something over time. The rate at which the something moves is defined by a function called an easing equation or interpolation function. It is these equations which make something move slowly at the start and speed up, or slow down near the end. These equations give animation a more life like feel. The most common set of easing equations come from Robert Penner's book and webpage.

easeInCubic:function(x,t,b,c,d){
returnc*(t/=d)*t*t+b;
},
easeOutCubic:function(x,t,b,c,d){
returnc*((t=t/d-1)*t*t+1)+b;
},

easeInCubic:function(x,t,b,c,d){
returnc*(t/=d)*t*t+b;
},

                var t = t/d;
                t = easeInCubic(t);
                var val = b + t*(c-b);

        function easeInCubic(t) {
            return Math.pow(t,3);
        }

        function cubicOut(t) {
            return 1-Math.pow(1-t,3);
        }

function easeOutCubic(t) {
     return 1 - easeInCubic(1-t);
}

easeInQuad:function(x,t,b,c,d){
returnc*(t/=d)*t+b;
},
easeOutQuad:function(x,t,b,c,d){
return-c*(t/=d)*(t-2)+b;
},

function easeInQuad(t) {  return t*t; }
function easeOutQuad(t) { return 1-easeInQuad(1-t); }

easeInOutQuad:function(x,t,b,c,d){
if((t/=d/2)<1)returnc/2*t*t+b;
return-c/2*((--t)*(t-2)-1)+b;
},

        function cubicInOut(t) {
            if(t < 0.5) return cubicIn(t*2.0)/2.0;
            return 1-cubicIn((1-t)*2)/2;                
        }

easeOutElastic:function(x,t,b,c,d){
vars=1.70158;varp=0;vara=c;
if(t==0)returnb;if((t/=d)==1)returnb+c;if(!p)p=d*.3;
if(a<Math.abs(c)){a=c;vars=p/4;}
elsevars=p/(2*Math.PI)*Math.asin(c/a);
returna*Math.pow(2,-10*t)*Math.sin((t*d-s)*(2*Math.PI)/p)+c+b;
},

        function easeOutElastic(t) {
            var p = 0.3;
            return Math.pow(2,-10*t) * Math.sin((t-p/4)*(2*Math.PI)/p) + 1;
        }

Much like a painter or musician, sometimes I an idea forms in my head and will not let me rest until it comes out. Usually such an idea is an algorithm or graphics demo, but this time it came in the form of a game; a game which will not quiet until born.

Who are you?

As I write this I'm flying home from New York City where we (Palm) threw an event known as the webOS Developer Day NYC. Really, we should have called it a party, due to the extreme fun and exhaustion we all experienced. But this post isn't really about the event, it's about the webOS developer community.

Below are my three main session proposals for OSCON, plus a few random ideas near the bottom that aren't fleshed out. Please give me some feedback on what you like and don't like. My goal is to have four really solid submissions. Thanks!

I had hoped to have my next tutorial article done by now but, alas, travel and JavaStore deadlines snuck up on me. I'm currently flying to Sweden for the annual OreDev conference.

The TouchPad is on it's way to stores, the catalog is full of apps, and Jesse finally went to sleep.  It is done.

All of the rampant speculation about the new iPad amuses me. Not because I think the speculation is wrong, but just unnecessary. Apple is actually a very predictable company. They release and update their products according to very reliable patterns. Perhaps we just want to believe that something truly unexpected will happen, even when 99% of the time it doesn't. For example..

The iPhone 4s

Over the past few weeks I've done more experiments and improvements to my ebook prototype. I'm still not sure what I'm going to do with it once I'm all done, but it's been an educational exercise nonetheless. Here's what I've done so far:

I've reorganized the code and put it into a github repo. Everything I'm going to show you is available to use and fork from right here. Click on any screenshot below to see a live example.

Listening to some podcasts about mobile devices I heard over and over statements like "iPhone changed the world with multi-touch" and "Android could compete with Apple if it had multi-touch." This simply isn't true. Okay, while perhaps not a lie, the success and value of of multitouch is extremely overrated. In fact, the iPhone barely uses multi-touch!

Hi. My name is Josh Marinacci. You might remember me from the webOS Developer Relations team. Despite what happened under HP, webOS is still my favorite operating system. It still has the best features of any OS and an amazing group of dedicated, passionate fans. I deeply cherish the two years I spent traveling the world telling everyone about the magic of webOS.