| CARVIEW |
Popular topics:
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.
Upward Mobility: Special Effects Wizardry
Dress up your UIViews with a few simple tricks
Most developers aren’t great UI designers (although, as with everything, there are exceptions). But there are a few quick tricks that can dress up an app, even if you don’t eat and breathe Photoshop. Let’s look at a simple iPad single-view app with two views, each of which contains a label and a text box.
This is about as Plain Jane as you can get in an application; the only concession to visual appeal that has been made is to use a grey background with white UIViews bounding the labels and text boxes. One easy tweak we can use is to make the UIView corners rounded instead of square, which will lend a bit of flare to the design.
This is actually harder than it should be. To set rounded corners, you need to dig down into the CALayer underneath the view:
#import <QuartzCore/QuartzCore.h>
@implementation ViewController
- (void)viewDidLoad
{
[super viewDidLoad];
self.topView.layer.cornerRadius = 5;
self.topView.layer.borderWidth = 1;
self.topView.layer.masksToBounds = YES;
self.bottomView.layer.cornerRadius = 5;
self.bottomView.layer.borderWidth = 1;
self.bottomView.layer.masksToBounds = YES;
}
@end
You need to set masksToBounds, because otherwise the corners will not be transparent, and the background color of the view will block whatever is beneath it in the parent view. The resulting view is subtly more classy. You can get more rounding by adjusting the cornerRadius value.
So far, so good. But that solid grey background is kind of blah, so we should dress it up a bit. An easy way to make a background pop is to use a gradient fill, a technique that the aforementioned Photoshop jockeys know and love.
Read more…
Kate Matsudaira: If You Don’t Understand People, You Don’t Understand Ops
Velocity 2013 Speaker Series
While automation is clearly making everyone’s lives who work in Operations much better, startup founder Kate Matsudaira (@katemats) acknowledges that “No one ever does their work in a vaccum.” You can try as much as possible to Automate All The Things, but you can’t automate trust. And trust is key to a healthy, thriving operations team (and your own professional growth, too).
In this interview, Kate discusses some of the things she’ll be talking about at Velocity next month. Key highlights include:
- The word “people” is pretty broad. What aspects of working with people should operations teams care about? [Discussed at 1:32]
- Ultimately, you depend on the people around you to help get work done, especially when you need to get funding, be it externally for a startup, or internally for an infrastructure or refactoring project. The more people trust you, the more likely that is to happen. [Discussed at 3:17]
- Cultural change takes leadership, but that leadership doesn’t have to come from the top. [Discussed at 5:00]
- You can be ridiculously technically competent, but if you can’t communicate well, it hinders your success in the long run. [Discussed at 5:40]
You can view the entire interview here:
This is one of a series of posts related to the upcoming Velocity Conference in Santa Clara, CA (June 18-20). We’ll be highlighting speakers in a variety of ways, from video and email interviews to posts by the speakers themselves.
Building Windows 8 Apps, Hadoop Developer Track Course, Write/Speak/Code, 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.
Zero to App in Two Weeks webcast: Kraig Brockschmidt shares lessons learned to help you improve your productivity and app-building efforts when programming Windows 8 apps in HTML, CSS, and JavaScript. Register for this free webcast.
Date: 10 a.m. PT, May 21 Location: Online webcast
Apache Hadoop Developer’s Track – 1 Day Course: This Big Data Cloud University class reviews Hadoop’s essential server components and details its relation to MapReduce, Hive and Pig programming. Course instruction includes hands-on labs. For more information or to register, visit the class website.
Date: 8:30 a.m. to 5:30 p.m. PT, May 25 Location: Los Angeles, CA
Google I/O, Big Data Adolescence, Visualization, and the Future of Open Source
Weekly Highlights and Insights: May 13-17
Google I/O: O’Reilly Editor Rachel Roumeliotis reports from the conference floor.
Big Data, Cool Kids: Fumbling toward the adolescence of big data tools.
Code as Art: Interactive Data Visualization for the Web author Scott Murray on becoming a code artist.
Real-time World-wide Wikipedia Edits: Stephen LaPorte and Mahmoud Hashemi’s addictive visualization.
Future of Open Source: The quality, security, and community driving open source adoption.
Exploring Hypermedia with Mike Amundsen
The Web Can Teach the Enterprise
The Web’s flexibility has helped it to survive and thrive, pushing well beyond the browser-based universe where it first showed its promise. While I’ve spent most of my time working with the HTML/CSS/JavaScript side, the HTTP side of the original HTML+HTTP combination that built the Web is perhaps even more flexible.
I enjoyed talking with Mike Amundsen, Principal API Architect at Layer 7 Technologies, who has spent much of his recent career encouraging enterprise customers to shift toward web architectures. While REST has emerged over the past decade to eclipse SOAP-based “web services”, Amundsen has eagerly promoted the next step beyond the simple CRUD-based model of early REST work: hypermedia.
Our conversation ranged from the history and foundations of REST through the many ways to integrate that work with existing enterprise practice to a glimpse at what the future might hold for frameworks, design, and architecture.
- REST as enterprise architectures principles applied to hypermedia (at 1:57)
- Transitioning from RPC-based models to hypermedia, by including additional information in response. (at 3:00)
- The value of opinionated message formats and eventual integration into opinionated frameworks. (at 5:51)
- Shifting from shared understandings of object models to messages. (at 8:50)
- “Enough coupling, but not too much” to allow mixing of technologies. (at 11:15)
- Human negotiation, HTTP negotiation, and responsive web design (at 14:20)
A Matter of Semantics
Structuring client-server communications with hypermedia messages
Messages on the Web carry three levels of information: Structure Semantics, Protocol Semantics, and Application Semantics. No matter the implementation style, all three of these are needed for any successful communication between client and server. This threesome (S-P-A) forms the essentials of communication over distributed networks.
Most of the time, though, these levels are obscured or muddled at implementation time. For example, both Protocol Semantics (how we create valid network requests) and Application Semantics (domain names like users, customers, orders, etc) are often mixed together in conversation ("You POST new users to this URL") and both of these are usually only defined in human-readable documentation and implemented in the source code of the client application itself. In other words, the protocol-level and application-level semantics are tightly coupled. An easy way to discover this is to see if you can take the same message format and implement your API using a protocol other than HTTP (e.g. WebSockets or FTP). I illustrated this "protocol-agnostic" design pattern back in 2010 ("A RESTful Hypermedia API in Three Easy Steps").
But there is a way to keep these separate from each other and view each of these aspects in their own light. In doing so, you’ll strengthen the quality and value of your message design while increasing flexibility and choices.
Structure Semantics
Structure Semantics provides the set of rules regarding how to create a well-formed message. XML has rather simple structure semantics. JSON's rules for well-formedness are a bit more vague but reachable since JSON.parse(…) turns out to be the ultimate arbiter of such things. Determining well-formedness of other, more complex media types (HTML, Atom, HAL, Collection+JSON) is tougher, but do-able even if external validators are not always available.
Building a successful web implementation that does not contain structure semantics is difficult—and that's a good thing.
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.