Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Google Portables Software Technology

Six Months Developing Software For Wearable Computing 28

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.'"
This discussion has been archived. No new comments can be posted.

Six Months Developing Software For Wearable Computing

Comments Filter:
  • by Anonymous Coward

    So soothing :)

  • by Anonymous Coward

    I'll just put this here:

  • So... (Score:4, Informative)

    by gadzook33 ( 740455 ) on Saturday May 25, 2013 @03:54PM (#43823255)

    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.

    • Welcome to slashdot. Everyone else already knows the articles don't contain useful content and skip reading them. The more senior members also know the summary also contains little information, and will generally misrepresent what the article tried to get across, and thus also skips reading it.

    • I read that entire article and I honestly have no idea what the point was...(snip)..nothing...

      Thank you for that, thought it might be a waste of time.

      I didn't get past reading "Being one of the first cyborgs in the world" then a quick scan of the text scrolling down;
      figured it wasn't going to be that great of an article and heck I got what I needed from the submitter (right, wrong, or almost {grin}).

  • 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.


    • Re:uhh wtf? (Score:5, Insightful)

      by godrik ( 1287354 ) on Saturday May 25, 2013 @04:09PM (#43823331)

      But if the users run their application on their own device and never report back to Central Command, how are we supposed to sell them ads and know when they brush their teeth?
      What you suggest is unacceptable, we'll just claim it is not scalable to do that. And in fact, it is true, it does not scale out amount of profit.

      • It also limits things, as it's difficult to support a vast variety of devices unless they all happen to run the same processor, etc, or are all open source. Open source, would make me happy, limited devices makes Apple happy, but both have some downsides for a lot of developers. Web API based development has some disadvantages as well, but also some advantages to making power available on low powered hardware and scalability.

    • Except running binaries on end user devices requires processing power.
      Processing power uses electrical power.
      Google Glass has a battery that only runs for 2 hours under any kind of local processing load.

      Imagine where things would be if Google *didn't* rely on web-based services processing the results and calling this device a display. Sure, that may not be as scalable as alternatives, however when runtime is paramount than you can expect some different behavior.
      • You realise that web rendering, and running interpretted javascript code is significantly more intensive than a native UI rendering library, right?

        • 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?
          • The fact that the HTML, CSS and javascript need to be parsed and interpretted, as well as simply run, and the fact that they're designed with the flexibility to represent any web page in existance in mind, rather than with the ability to render standard UI widgets in mind with the option to add extra code if you need to do something custom.

            • by tepples ( 727027 )

              The fact that the HTML, CSS and javascript need to be parsed and interpretted

              HTML and CSS need to be parsed and interpreted. The XML definitions of forms used by modern UI toolkits likewise need to be parsed and interpreted. Java and .NET bytecode don't need to be parsed quite so much, but like JavaScript, they still need to be interpreted.

              • Except that the XML definitions of forms used by modern UI toolkits are describing a much more simple structure, and doing so with significantly less flexibility in terms of ability to style.

                The internal method to render a button is simple on most of these platforms –likely to be a matter of a single image draw to render the background, and a single image draw to render the label. It's dimensions and position are likely to be recalculated, and trivial to deal with.

                Compare that against what needs to h

  • 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,

    • 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

      • 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.

          • It would really only be a 1 minute investment to understand that it's not just about HTML forms.
            • 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 explai

    • 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 shou

  • '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.

  • 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.

To do two things at once is to do neither. -- Publilius Syrus