CARVIEW |
Popular topics:

Building Modern Web Apps, Build 2013, TechEd North America, and More
Tech events you don't want to miss
Each Monday, we round up upcoming event highlights from the programming and technology spaces. Have an event to share? Send us a note.
Modern Web Applications Utilizing HTML5 APIs webcast: Ido Green covers techniques and tools for building great “modern” web apps, including tips on Chrome DevTools, HTML5 power tools, and modern web app design techniques. Register for this free webcast.
Date: 10 a.m. PT, May 30 Location: Online webcast
TechEd North America: This is Microsoft’s main conference for IT professionals and enterprise developers. Get hands-on experience with more than 200 self-paced labs. If you need to convince your boss to let you go, there’s even a guide to help. For more information and to register, visit the TechEd website.
Date: June 3–6 Location: New Orleans, LA

In-Memory Databases, Burning Silos, Reintroducing Dart, and Google Glass Gatherings
Weekly Highlights and Insights: May 19-25
In-memory Databases: A discussion of near real-time manipulation of massive datasets
Burning the Silos: Minimize boundaries to reduce product cycle times.
Dart Is Not the Language You Think It Is: Seth Ladd’s enthusiastic reintroduction of Dart prompts a voluminous discussion on Slashdot.
Is that the Google Glass?: The anthropology of an always-on society
Tracing the Disappeared: An interactive visualization of CIA rendition flights

TurboGears Just Keeps Getting Better
A quick look at the open source web framework
Alessandro Molina, is CTO at Axant.it and a member of the TurboGears web framework development team. I recently got the chance to sit down with him to talk about the exciting opportunities TurboGears offers users, how being open source has affected the proejct, and what we should expect next.
- The current focus of the TurboGears dev team is reducing dependencies and making the framework faster! [Discussed at 0:12]
- Yes, TurboGears 2.1 and forward supports MongoDB! [Discussed at 1:56]
- TurboGears make editing code on the fly very easy. [Discussed at 3:45]
- It takes an open source community to raise a web framework. [Discussed at 4:57]
You can view the entire interview in the following video.

How Web Pages Can Extend (or Drain) Mobile Device Battery Life
Dr. Angela Nicoara on mobile browser energy consumption and ways developers can minimize energy use through design.
According to recent Global Mobile Data Traffic Forecasts (PDF), the number of mobile-connected devices will surpass the world’s population this year, and by 2015, there will be 788 million mobile-only Internet users. A recent paper, “Who Killed My Battery: Analyzing Mobile Browser Energy Consumption (PDF),” pulled together by the Deutsche Telekom Innovation Center in Silicon Valley and Stanford University researchers and published in the ACM 21st International World Wide Web Conference (WWW 2012) proceedings (PDF), takes a look at the growing popularity of mobile web browsing and the effects on energy consumption.
I reached out to Dr. Angela Nicoara, senior research scientist at the Deutsche Telekom Innovation Center in Silicon Valley who worked on the project, to find out why mobile browser energy consumption is a growing concern and what developers need to know going forward. Our interview follows. Dr. Nicoara will present the researchers’ findings in the “Who Killed My Battery: Analyzing Mobile Browser Energy Consumption” session at the Fluent 2013 conference next week in San Francisco, CA.
Why is browser energy consumption becoming more of an issue with the growth of smartphones and mobile browsing?
Dr. Angela Nicoara: Despite the explosive growth of smartphones and growing popularity of mobile web browsing, their utility has been and will remain severely limited by the battery life. Smartphones’ energy constraints are here to stay, and as such, optimizing the energy consumption of the phone browser while surfing the Web is of critical importance today and will remain so in the foreseeable future.
End-to-End JavaScript Quality Analysis
Velocity 2013 Speaker Series
The rise of single-page web applications means that front-end developers need to pay attention not only to network transport optimization, but also to rendering and computation performance. With applications written in JavaScript, the language tooling itself has not really caught up with the demand of richer, assorted performance metrics necessary in such a development workflow. Fortunately, some emerging tools are starting to show up that can serve as a stop-gap measure until the browser itself provides the native support for those metrics. I’ll be covering a number in my talk at Velocity next month, but here’s a quick sneak preview of a few.
Code coverage
One important thing that shapes the overall single-page application performance is instrumentation of the application code. The most obvious use-case is for analyzing code coverage, particularly when running unit tests and functional tests. Code that never gets executed during the testing process is an accident waiting to happen. While it is unreasonable to have 100% coverage, having no coverage data at all does not provide a lot of confidence. These days, we are seeing easy-to-use coverage tools such as Istanbul and Blanket.js become widespread, and they work seamlessly with popular test frameworks such as Jasmine, Mocha, Karma, and many others.
Complexity
Instrumented code can be leveraged to perform another type of analysis: run-time scalability. Performance is often measured by the elapsed time, e.g. how long it takes to perform a certain operation. This stopwatch approach only tells half of the story. For example, testing the performance of sorting 10 contacts in 10 ms in an address book application doesn’t tell anything about the complexity of that address book. How will it cope with 100 contacts? 1,000 contacts? Since it is not always practical to carry out a formal analysis on the application code to figure out its complexity, the workaround is to figure out the empirical run-time complexity. In this example, it can be done by instrumenting and monitoring a particular part of the sorting implementation—probably the “swap two entries” function—and watch the behavior with different input sizes.
As JavaScript applications are getting more and more complex, some steps are necessary to keep the code as readable and as understandable as possible. With a tool like JSComplexity, code complexity metrics can be obtained in static analysis steps. Even better, you can track both McCabe’s cyclomatic complexity and Halstead complexity measures of every function over time. This prevents accidental code changes that could be adding more complexity to the code. For the application dashboard or continuous integration panel, these complexity metrics can be visualized using Plato in a few easy steps.

Doug Hanks on how the MX series is changing the game
Doug Hanks on how the MX series is changing the game
Doug Hanks (@douglashanksjr) is an O’Reilly author (Juniper MX Series) and a data center architect at Juniper Networks. He is currently working on one of Juniper’s most popular devices – the MX Series. The MX is a routing device that’s optimized for delivering high-density and high-speed Layer 2 and Layer 3 Ethernet services. As you watch the video interview embedded in this post, the data is more than likely being transmitted across the Juniper MX.
We recently sat down to discuss the MX Series and the opportunities it presents. Highlights from our conversation include:
- MX is one of Juniper’s best-selling platforms [Discussed at the 0:32 mark].
- Learn if the MX can help you [Discussed at the 1:00 mark].
- What you need to know before using the MX [Discussed at the 6:40 mark].
- What’s next for Juniper [Discussed at the 9:39 mark].
You can view the entire interview in the following video.

From JavaScript to Declarative Markup
Evolving enhancements for web developers
Web architecture separates structured content (markup), presentation (style), and behavior (JavaScript). As recently as a decade ago, many developers worked in all three, but the years since Ajax arrived have brought more specialization. The rise of JavaScript in particular has led to approaches that have JavaScript carry the load. In the past few weeks, I’ve been delighted to see work that suggests a different path forward, one that takes greater advantage of the flexibility markup offers.
Last week, at the Artifact Conference, I was delighted to return to the world of web designers. The crowd was full of people who know very well what JavaScript can add to their site and how they want to include it, but who don’t focus on it. JavaScript is just a tool, often even a tool wielded later in the process after the basic framing of the site is complete.

Dart Is Not the Language You Think It Is
A terse language without ceremony
When Dart was originally launched, many developers mistook it for some sort of Java clone. In truth, Dart is inspired by a range of languages such as Smalltalk, Strongtalk, Erlang, C#, and JavaScript. Get past the semicolons and curly braces, and you’ll see a terse language without ceremony. Dart has evolved into its own, and here are some of my favorite language features.
Dart is a source code VM
The Dart VM reads and executes source code, which means there is no compile step between edit and run. As with other popular scripting languages, it’s very quick to iterate with Dart. The Dart VM runs on the command line and servers, and can be embedded into browsers. Just point the VM at Dart source code and you’re up and running!
Dart is optionally typed
Dart understands that sometimes you just don’t feel like appeasing a ceremonial type checker. Dart’s inclusion of an optional type system means you can use type annotations when you want, or use dynamic when that’s easier.
For example, you can explore a new idea without having to first think about type hierarchies. Just experiment and use var
for your types. Once the idea is tested and you’re comfortable with the design, you can add type annotations.
Here is a comparison between code that uses type annotations, and code that uses var
for dynamic. Both of these code snippets have the same runtime semantics:
With type annotations:
void advance(double dt) { double dx, dy, dz, distance, mag; int size = bodies.length; for (int i = 0; i < size; i++) { Body bodyi = bodies[i]; // ...
Or, without type annotations:
advance(dt) { var dx, dy, dz, distance, mag; var size = bodies.length; for (var i = 0; i < size; i++) { var bodyi = bodies[i]; // …
Type annotations are great for the “surface area” of the code (such as method and function signatures), and the tools are getting good enough for you to consider using var
inside methods and functions.
Read more…

JavaScript Flexibility: Fun, But Use with Care
JavaScript is dynamically typed
When you begin programming in JavaScript, you’ll need to use variables. A variable is just a bit of storage to hold a value. Just about every line of code you write will use a variable of one kind or another, so it’s a good idea to get familiar with the kinds of things you can put in variables, and how you can use them. Now, if you’re coming from another programming language, like Java, you might be surprised to see how loose JavaScript is about variables and their type. JavaScript doesn’t care if your variable starts out with a string value, and ends up being a number: JavaScript’s dynamically typed.
In this installment of Head First JavaScript Programming Teasers, you’ll learn about the basics of variables, how JavaScript is dynamically typed, and why it’s a good idea to stick with one type for your variables.

Google Glass: From Google I/O to Maker Faire
Could technology be bringing people closer together?
I had quite an experience at Maker Faire this weekend. So instead of a follow up on Google I/O today I’m going talk about how wearables, specifically Google Glass, seem to be bringing people closer together rather than farther apart. So, more on Google I/O later in the week.
A Tale of Two Events
I first broke out my Google Glass at Google I/O where Glass Explorers and Googlers filled the Moscone West sporting the device. Glass Explorers are those that pre-ordered the I/O last year and winners of the #IfIHadGlass contest. The mood towards Glass at I/O was, generally, split into the have’s and have not’s. Those with them proudly showed them off while others fell into the following camps: carefully measured excitement, cool intrigue, and those who were over it. I think for the most part the subdued reaction was a reflection of attendees wanting to be able to get into the action immediately. It was a shame that Glass wasn’t available for purchase to those at I/O this year.
In stark contrast to that reaction was the response I received from attendees of this past weekend’s Maker Faire. My first inkling of what was ahead were the whispers. I would hear excitedly, “Is that the Google Glass?” which made me smile. However, when I met up with my 11:30 a.m. appointment at his booth and started talking about and sharing the Glass with him and his colleagues a mob quickly formed. Frankly, I got scared for a moment as a mass of people forced inward towards me, and then thought what if someone just takes off with these? But, no one did. These mini-mobs happened to me twice, both times in the Electronics area (not surprisingly). The outcome of these Glass flash mobs, however, was quite simply lovely. Individuals were polite, asked me questions, wanted to take pictures of themselves with it and that was it. Throughout the day people would comment on them, stop me to talk, but it was always a pleasure with people smiling ear to ear when I had them play with the device.
What will wearables really mean to society?
The quick answer for now—who knows? I have to say I was a bit overwhelmed by all of this social engagement. I had anticipated some notice, but this? Now, granted, the attendees of a Maker Faire might skew towards being interested in new gadgets and devices but my experience was unexpected—and wonderful. I talked to more random, happy people at this event than I have in a long while. It has given me a new perspective on recent issues that have come up regarding the Glass, such as invasion of privacy and the idea that we are disconnecting with the world more and more via personal devices, when in fact I was finding just the opposite. Maybe in time everyone will have a Glass or have seen one and it won’t be a big deal. But for now, it is generating interaction and discussion about technology with young and old alike.
Oh, and here you can see what it is like to be attacked by a T-Rex from my POV via the Glass, scary stuff. Click here to see the T-Rex Attack.
This will be the first post in a series on my journey through the world with Glass.
Get the Programming Weekly Newsletter
Stay informed. Receive weekly insight from industry insiders.
Ebook Deals of the Day
Video Deal of the Week
Get the O'Reilly
Programming Newsletter
Weekly insight from industry insiders.
Plus exclusive content and offers.