Slashdot Mirror
Six Months Developing Software For Wearable Computing
An anonymous reader writes "Twilio's Jon Gottfried has written an article about the lessons he's learned after six months of developing software for Google Glass. He has some insightful points: 'I expected it to be very similar to building mobile applications for Android. In fact, I began learning to build Android applications in preparation. My efforts were for naught, because the Mirror API is a RESTful web service. This means that developing applications for Glass is actually more similar to building a website than it is to building an Android application.' He also talks about how this fits in with the future of technology: 'I would argue that Google took the only option available to them. The only truly scalable products of the future will be developer platforms. Facebook, Twitter, Twilio, Google, Apple, Microsoft, Arduino – all of these products have been successful in large part by embracing and empowering their developer communities. No company is omniscient enough to imagine every potential use of their products. This gives developers an immense amount of power to define the success or failure of an entire product line.'"
So soothing :)
I'll just put this here: http://www.youtube.com/watch?v=8To-6VIJZRE
I read that entire article and I honestly have no idea what the point was. I was excited to learn about how a RESTful API was employed in a heads-up application and learned...nothing.
what does "'I would argue that Google took the only option available to them. The only truly scalable products of the future will be developer platforms. Facebook, Twitter, Twilio, Google, Apple, Microsoft, Arduino " have to do with a REST api? nothing.
there's not much cool stuff to do before the native sdk(gdk), apparently. but the guy is just pushing twilio, so hey, why not push it as "only truly scalable products" and put in arduino with something that has shit all nothing to do with the other stuff.
you know what's _truly_ scalable? RUNNING BINARIES ON END USER DEVICES. why? the only device needed to run is the one that the user has - that's truly scalable to as many users who have a device.
wasn't there some news of a rootable firmware coming out though?
world was created 5 seconds before this post as it is.
Came here hoping the article would talk about deeply embedded firmware, CPU constraints, low power tradeoffs, etc. (I'm an embedded systems kinda guy). Left disappointed.
It blows my mind that something which on the surface screams of "deeply embedded system" is characterized as "similar to building a website".
Don't get me wrong, I know there's a lot of stuff underneath to make it all work, that's the stuff I find cool, I'm not an app developer... but for example when the Kinect came out, some of the first articles were really detailed embedded-systems level articles about the product.
Actually all the guy says is the thing uses a client server API (I had to google "RESTful") which uses HTTP (unless otherwise) and from wikipedia it sounds similar to what a website with forms and no javascript would do, but maybe you can do web 2.0 shit while respecting the constraints (stateless client and what have you)
He doesn't even tell us where the client and server reside. The client is the glasses, sure. But where's the server? Is it running on the computer inside the pair of glasses, on an Android smartphone you have in the pocket or on the world wide web? Do the glasses run Android, Chrome OS, other? All high level questions are left unanswered as well.
On the not-deep hardware side we don't even get to know anything about the CPU and RAM (such as ARM, 1GB or MIPS, 32MB) nor anything about the networking (3G, 4G, bluetooth 4.0, wifi)
The article is pretty awful, but your understanding of "REST" is pretty poor. Might give that a second lookup.
Sure I didn't understand. Maybe I should spend the next 24 hours non-stop on studying the subject. maybe not.
What in particular makes the CSS rendering model more processing-intensive than the rendering model of a similarly capable "native" toolkit? And what makes JavaScript more processing-intensive than .NET, Java, or any other kind of bytecode that's intended to execute on more than one brand of hardware?
'I would argue that Google took the only option available to them. The only truly scalable products of the future will be developer platforms. Facebook, Twitter, Twilio, Google, Apple, Microsoft, Arduino
Do you see that red mustache? He drank the cool-aid. The whole pitcher.
I'm also trying to figure out how online social networks, a software development company, a hardware / software company, and an experimental hardware board for hobbyists all fit together with Google Glasses in some way. That cool-aid was spiked with buzz words.
Better known as 318230.
It would really only be a 1 minute investment to understand that it's not just about HTML forms.
Having developed products with embedded GUIs using both C code, and .NET I have to agree that running bloated HTML based graphics will suck the life out of any embedded application. The performance is so drastically different that a 200 MHz processor and C code will run circles around a 1.2 GHz processor running .NET and be much more stable.
It might take a different class of programmer to make the C code work, but in the end it will be a much more interactive platform that does what it should every time you give it input, instead of having to sit there and wait for the OS to catch up with you, while watching an hourglass kinda-sorta spin.
We ran 100 MSec screen refreshes with C code (plus we had about 20 PID loops running) and no problems with CPU load while running on that 200 MHz processor, but the 1.2 GHz .NET application that replaced it struggled to be interactive at a 500 MSec screen refresh rate, processing half as much input data, and forget about doing any real time control with it.
When you changed the screen fast enough, the .NET app would eventually go off to la-la land and push 2 or 3 (or 20) rounds of PID calculations on the stack while not updating the outputs, and then run the calculations in reverse order on the way back off, and cause all sorts of bad_things to happen. Not only was the hardware almost 3X as expensive to run the .NET solution, We had to add an extra black box to do the real time stuff with C code anyways.
But hey you can just make 1 screen layout in Blend and have .NET resize it for you when it's drawn instead of having to do take the time to support a few different screen resolutions in development, and have every customer wait every time they change the screen instead. Vastly better user experience!
I only tried to know whether HTML forms are RESTful (or can be) and I don't know.
Also, crap, I must have mixed up what's stateful and stateless (server is stateless and client is stateful)
I only have the wikipedia article on REST and never did web dev (I can write raw 1990s html with no css and no tables, that's all)
So, I'm sorry to say some dumb stuff and showing some lazyness but I really wondered what that damn "RESTful" means, it's the only technical term in the entire article and it isn't really explained. The only thing I understand from it is that it uses HTTP since the author says it's a "RESTful web service". There's "asynchronous" too. (is google maps an asychronous application?)
does the composition of your slave threads you are wearing right now stem from a computing device ? naked truth is its built into the computation composition of your clobber, just ware IT on your sleave as its just a passing fashion.
bæ8Ã0sÃOE?5r©oÂÃ?âz:ÃÃAÃ?ÃOEÂ6fXÃ?]Â
"No company is omniscient enough to imagine every potential use of their products."
Yes that's true. World is smarter than a single company. So why would a company need to do everything when developers across the world can do more smarter work.