March 2014 Archives

Four short links: 31 March 2014

Four short links: 31 March 2014

Game Patterns, What Next, GPU vs CPU, and Privacy with Sensors

  1. Game Programming Patterns — a book in progress.
  2. Search for the Next Platform (Fred Wilson) — Mobile is now the last thing. And all of these big tech companies are looking for the next thing to make sure they don’t miss it.. And they will pay real money (to you and me) for a call option on the next thing.
  3. Debunking the 100X GPU vs. CPU Myth — in Pete Warden’s words, “in a lot of real applications any speed gains on the computation side are swamped by the time it takes to transfer data to and from the graphics card.”
  4. Privacy in Sensor-Driven Human Data Collection (PDF) — see especially the section “Attacks Against Privacy”. More generally, it is often the case the data released by researches is not the source of privacy issues, but the unexpected inferences that can be drawn from it. (via Pete Warden)
Comments: 2

Connected for a purpose

Are we finally seeing connected vehicles doing more with the connection than infotainment?

A few months ago, I rented a Toyota Prius and was driving it up the 101 when, predictably, I ran into a long stretch of mostly-stop-with-some-go traffic. I remember thinking at the time, “It’s too bad this thing didn’t see this traffic jam coming; it could have topped off the battery and I could be motoring through this bumper-to-bumper on much more efficient electric drive.” Instead, I entered the traffic with the battery relatively depleted and ended up running the engine a bunch even though I was only going 5 mph.

Then last week, I was getting my car worked on and saw this sign in the waiting room:

Mini_Drivetrain

That was cool because it was the first time I had seen an auto manufacturer (in this case, Mini) using externally obtained data to actually improve how the car operated instead of using it for some lame in-dash “experience.” It got me thinking. Read more…

Comments: 3

Formulating Elixir

Simon St. Laurent and Jose Valim explore a new functional programming language

I was delighted to sit down with Jose Valim, the creator of Elixir, earlier this month at Erlang Factory. He and Dave Thomas had just given a brave keynote exploring the barriers that keep people from taking advantage of Erlang’s many superpowers, challenging the audience with reminders that a programming environment must have reach as well as power to change the world.

Elixir itself is a bold effort to bring Erlang’s strengths to a broader group of developers, adding new strengths, notably metaprogramming, along the way.

Watching Elixir grow has been a unique experience for me. I’ve seen other languages (JavaScript and XSLT) emerge, but Elixir combines solid foundations on prior (Erlang) work with a remarkably open conversation about how to structure the language. Jose tries things and asks for feedback, takes suggestions well, and values questions about how best to make the language accessible. Even without a standards organization, the process has remained open, stable, and productive.

Whether you’re interested in Elixir itself or just in the challenges of creating a new combination in a world filled with past experiments, it’s well worth listening to Jose Valim.

  • We’ve had functional programming since 1959 – why the burst of interest now? [2:10]
  • Moving from Ruby to Erlang “making Rails thread-safe, that was my personal pain-point” [3:13]
  • “Every time I got to study more about the VM, the tooling and everything it provides, my mind gets blown.” [6:12]
  • Why Elixir started, and how it’s changed as Jose learned more. [10:08]
  • Integrating new Erlang features (R17 maps) into Elixir. [15:43]
  • When can you use Elixir in production? [18:07]

I’m looking forward to seeing a lot more Elixir, even as I need to catch up on updating Introducing Elixir. I’m not sure it will conquer the world immediately, but it will certainly leave its mark.

Comment

Horseshoes, hand grenades, and building mobile applications

The difference between location and proximity: knowing you’re in the restaurant vs knowing what table you’re sitting at.

As the old proverb goes, “close only counts in horseshoes and hand grenades.” It doesn’t quite apply when building mobile applications, however. Smaller screens and the resistance to extensive keyboard input define the input and output constraints of mobile apps, but there is something more fundamental that a mobile application can do. At its best, an application that knows where you are will augment reality to help you navigate and interact with the physical world. These applications are sometimes described as “location” applications and sometimes described as “proximity” applications. Many people are guilty of using the words interchangeably — myself included. In response to my post on iBeacon basics, Alasdair Allan called me out on Twitter:

His comment was spot-on. In this post, I’ll define (and be very precise about) the difference, the importance of which leads directly to the level of interest in proximity — and informs the excitement levels around technologies like iBeacons. Read more…

Comment

What BlackBerry is up to these days

Practically dead in smartphones, BlackBerry is dominant in the auto industry.

Here’s a surprise, via Bloomberg:

“BlackBerry’s QNX operating system, used to power its BlackBerry 10 phones, has become the technology of choice for mapping, communication and entertainment systems in cars from Ford Motor Co. to luxury German brands Porsche and BMW.”

BlackBerry acquired QNX in 2010 from Harman International, a long-time supplier to the auto industry. “Long-time supplier” is the crucial bit. As for why QNX has done well, Bloomberg explains:

“‘QNX is the standard right now,’ said Matthew Stover, an analyst at Guggenheim Partners in Boston. ‘It’s proven and people know what it is.’

A key to maintaining the lead is QNX’s track record in running safety systems, crucial in situations where a software freeze could mean a car accident.”

By the logic of Silicon Valley, that’s a disruption waiting to happen, as Google and a consortium of automakers have foreseen. But this also underscores the ways in which the market for software in heavy industry, and in physical machines in general, is different from the market for software that stays strictly virtual.

[H/T Jim Stogdill]

Comment: 1

The Case for Test-Driven Development

An interview with O'Reilly author Harry Percival

Harry Percival, author of Test-Driven Web Development with Python, discusses how he got into TDD, why you should too, and shares some tips. In the podcast above, listen to Harry talk candidly about the types of tests that make sense, what and what not to test, and at what point a program becomes complex enough to warrant testing. Below is a mostly matching text version of the same interview. Let us know your thoughts on TDD in the comments—your own war stories and what convinced you (or didn’t!).

Why write tests? How do you know it’s not a waste of time?
The theory is that it’s an investment—the time you spend writing tests will get paid back in time you don’t have to spend debugging. Also, the theory goes that tests should help you to write code that’s easier to work with, as well as code with less defects. Because having tests encourages you to refactor, and to think about design, your code should end up cleaner and better architected, and so it should be easier to work with, and your investment pays off because you’re more productive in future as well.

So that’s the theory. But the problem is that there’s delayed gratification—it’s hard to really believe this when the reward is so far off and the time required is now. So in practice, what was it that convinced me?

I first learned about testing from a book called “Dive Into Python”—it’s a popular book, maybe some of the people listening will have read it too? They may remember that Mark Pilgrim introduces testing, in fact he introduces TDD, in chapter 10. He uses the classic TDD example, which is a Roman Numeral calculator, and he shows how, by writing the tests before we even start writing the code, we can really get some help in how we implement our calculator. So he writes his tests, I should be 1 and II should be 2 and IV should be 4, and so on, and he shows how it helps us to build a really neat implementation of a Roman numeral calculator.

Read more…

Comment
Four short links: 28 March 2014

Four short links: 28 March 2014

Javascript on Glass, Smart Lights, Hardware Startups, MySQL at Scale

  1. WearScript — open source project putting Javascript on Glass. See story on it. (via Slashdot)
  2. Mining the World’s Data by Selling Street Lights and Farm Drones (Quartz) — Depending on what kinds of sensors the light’s owners choose to install, Sensity’s fixtures can track everything from how much power the lights themselves are consuming to movement under the post, ambient light, and temperature. More sophisticated sensors can measure pollution levels, radiation, and particulate matter (for air quality levels). The fixtures can also support sound or video recording. Bring these lights onto city streets and you could isolate the precise location of a gunshot within seconds.
  3. An Investor’s Guide to Hardware Startups — good to know if you’re thinking of joining one, too.
  4. WebScaleSQL — a MySQL downstream patchset built for “large scale” (aka Google, Facebook type loads).
Comment

Just Enough Arel

Replacing hand-coded SQL with object oriented programming

If you were a web developer prior to ActiveRecord, you probably remember rolling your own SQL and being specific about which fields you retrieved, writing multiple queries to handle “upserts” (update or insert), and getting frustrated with how difficult it was to generate SQL dynamically.

Then Ruby on Rails came along with its ActiveRecord API, and all of that pain seemed to melt away into distant memory. Now we no longer have to worry about which fields to retrieve, “upserts” can be handled with a single method, and scopes allow us to be as dynamic as we want.

Unfortunately, ActiveRecord introduced new pains: the “WHERE” clause (i.e. the predicate) only allows connecting conditions with “AND”s, and the only comparisons allowed are “=” and “in”. To get around this, we often concede ActiveRecord’s shortcomings and revert back to raw SQL. But in Rails 3.0, we were introduced to another way.

Arel

The Arel relational algebra library is an abstract syntax tree (AST) manager and has the goals of “1) Simplif[ying] the generation of complex SQL queries; and 2) Adapt to various RDBMSes”. It’s the “engine” ActiveRecord uses to change method calls into actual SQL. To be clear, Arel only generates SQL, it doesn’t access the database and retrieve data.

With Arel, we are now capable of fully utilizing the power of SQL, without the mess of hand-coding it. ActiveRecord uses Arel to transform queries like this:

Into SQL like this:

Read more…

Comment: 1

Technology that gets under your skin

Embeddables won't just be a revolution in functionality, but will dramatically alter how people fit into society.

EmergingTechCoverSM2

Editor’s note: we’re running a series of five excerpts from our forthcoming book Designing for Emerging Technologies, a compilation of works by industry experts in areas of user experience design related to genomics, robotics, the Internet of Things, and the Industrial Internet of Things.

In this excerpt, author Andy Goodman, group director at Fjord Madrid, looks beyond wearable computing to a deeper, more personal emerging computing technology: embeddables. Goodman says that beyond wearables and implants lies a future symbiosis of human and machine that will transform not only the delivery of information and services, but human nature as well.


Andy_Goodman

Author Andy Goodman, group director at Fjord Madrid.

Wearables are yesterday’s news; tomorrow’s news will be all about embeddables, tiny computing devices implanted inside your body that monitor your health, improve your functioning, and connect you to the digital world.

There is currently a lot of buzz in technology and design circles about wearables, living services, the Internet of Things, and smart materials. As designers working in these realms, we’ve begun to think about even more transformative things, envisioning a future where evolved technology is embedded inside our digestive tracts, sense organs, blood vessels, and even our cells. Everyday objects will become responsive and predictive, connecting us to the data sphere and reducing the distance between our skin and the surfaces of the made world. What we see further out, beyond the realm of wearables and implants, is the future symbiosis of the human body and the machine. Read more…

Comments: 2
Four short links: 27 March 2014

Four short links: 27 March 2014

Understanding Image Processing, Sharing Data, Fixing Bad Science, and Delightful Dashboard

  1. 2D Image Post-Processing Techniques and Algorithms (DIY Drones) — understanding how automated image matching and processing tools work means you can also get a better understanding how to shoot your images and what to prevent to get good matches.
  2. Scientists Need to Learn to Sharedespite science’s reputation for rigor, sloppiness is a substantial problem in some fields. You’re much more likely to check your work and follow best data-handling practices when you know someone is going to run your code and parse your data.
  3. METRICSMeta-Research Innovation Center at Stanford. John Ioannidis has a posse: connecting researchers into weak science, running conferences, creating a “journal watch”, and engaging policy makers. (says The Economist)
  4. Grafana — elegant dashboard for graphite (the realtime data graphing engine).
Comment