"programmingblog" entries
The web is eating software
Web technologies have become the default, and are spreading
A few years ago, venture capitalist Marc Andreessen wrote that “software is eating the world”:
Six decades into the computer revolution, four decades since the invention of the microprocessor, and two decades into the rise of the modern Internet, all of the technology required to transform industries through software finally works and can be widely delivered at global scale.
That may be true, but Andreessen seems to have left out some of his earlier, more Web-centric visions (though perhaps he considers them complete).
Software may be eating the world, but the Web has been “eating software” in a similar sense for as long as the Web has been visible.
On the front end, the browser has grown from being a strange dumb terminal of documents and forms to a full partner. The browser not only provides a window into the world of classic websites, but helps us deal with devices that we can reach over a network. Their interfaces may be invisible or basic on the physical device, but offer much more when accessed through a browser. Web apps, though frequently not as capable as their desktop competition, long ago passed the point where their collaborative possibilities were more valuable than the details they lack.
Why Ruby blocks exist, part II
Putting return values to work
Last time, we showed you how to use Ruby’s each method with blocks to process the elements of an array, and how it can save you a lot of repetitive looping code. That was just an introduction, though.
In our previous examples, the block was a final destination. We passed data into blocks, but it never came back out (unless we printed it to the screen). Today we’re going to look at block return values, and how your methods can use them to manipulate your data in even more powerful ways.
Before we move on…
We should mention that there are two syntaxes for blocks in Ruby. In the earlier post, we used the do ... end syntax:
my_method(my_argument) do |my_parameter| # Code here end
With blocks that fit on one code line, it’s often preferred (though not required) to use the alternate curly-brace syntax for blocks:
my_method(my_argument) {|my_parameter| # Code here }
We’ll be using the curly-brace style of blocks today.
Java 8, now what?
What you'll need to know to start your Java 8 migration process today
There was recently a thread on the London Java Community mailing list about when people should think about adopting Java 8. Lambdas, an improved collections library, new date and time support, and a host of under-the-hood tweaks, add up to a lot of compelling reasons for people to upgrade. There’s still a lot of confusion over when and how to accomplish it, though, so here’s a helpful guide.
When will Java 8 be released?
The GA (General Availability) release of Oracle’s JRE and JDK, which is probably the JVM that you’re using, released March 18th. It may take other JVM vendors a while to release their implementations if you aren’t using an OpenJDK or the Oracle JDK.
So I should just upgrade on release date, right?
That would be a very brave move to make. A huge amount of resources go into testing Java 8 and ensuring that things will work out of the box on the day of release. However, the massive ecosystem of Java libraries means that not everything can be tested to destruction in time. It’s incredibly likely that there will be outstanding bugs upon release. You should expect update releases a month or two after GA, they’ll solve the major problems.
It’s also important to think about what libraries or frameworks your application depends on. If you’re just writing plain old Java then an existing codebase is likely to work fine. If, on the other hand, you depend on a library or framework that tries to do something clever then you may run into problems.
Choosing a templating language in clojure
A brief look at Enlive, Hiccup, and Selmer
One thing that is striking when working in the Clojure ecosystem is the breadth of options available to tackle any given task. The community strives to write simple, interoperable libraries and what results is a daunting number of choices, all with their own benefits and trade-offs. Templating libraries in Clojure are no exception to this rule. The Clojure Toolbox alone lists eleven template languages at last count, and it is not even an exhaustive count of the wide array of techniques available for templating web pages.
In the forthcoming Clojure Cookbook, we cover three such libraries: Enlive, Hiccup, and Selmer. Let’s take a brief look at each of these libraries and discuss their places in the ecosystem.
Hiccup—Pure data, plain and simple
Of the three libraries we’ll cover, Hiccup is the most simple of the bunch. In Hiccup, HTML tags are just vectors of Clojure data; no HTML, no template files, no interpolation (per se), just data. An HTML node is represented as a vector of three parts: tag, attributes (optional), and contents (optional, any number).
Take an anchor tag, for example:
[:a {:href "http://www.rkn.io/application-architecture"} "Application Architecture for Developers"]
Which represents the following HTML:
<a href="http://www.rkn.io/application-architecture">Application Architecture for Developers</a>
To nest multiple elements like you might do in an unordered list, replace the content portion of the vector with the additional child nodes:
[:ul {:class "groceries"}
[:li "Apples"]
[:li "Bananas"]
[:li "Pears"]] ;; oh my!
Which renders as:
Upward Mobility: Animating the Leaves of Fall (in Australia)
It doesn't take many lines of code to make a snazzy animated background in iOS
One of nicest features of iOS development is that, frequently, you can pull off visual effects that look amazing without having to write a lot of code. It may be about to start the spring season here, but Down Under it’s heading into fall, so to honor those folks, we’ll animate some falling leaves. We’ll use a simple piece of code that will animate objects drifting down the screen.
I say drifting, because this trick only works for objects that are going to maintain a constant velocity as they descend through the space. Thus, it works well for things like leaves, pieces of paper, or other light objects that the mind will immediately accept as having reached their terminal velocity. In my case, I developed the code to handle confetti streaming down a “You’ve won” screen. Heavier or more streamlined objects require a bit more work to animate, because you need to simulate the effects of gravity and acceleration, otherwise the animation doesn’t look right.
So, to begin, we need some image assets. For this example, I’m going to use 3 leaf images I grabbed from a public clip art site, and cleverly renamed to leaf1.png, leaf2.png, and leaf3.png. I created a simple single-view storyboard project, and added a label in the center of the view. Now, all that’s left is to plop in the code:
The Essence of Feedback Control
Pick your auto-scaling metrics wisely
A while back, I wrote up some notes on the use of feedback control in auto-scaling server instances in a data center. Afterwards, a reader contacted me to ask whether the article didn’t “boil down to ‘pick your auto-scaling metrics wisely’?”
That’s exactly right!
Feedback control indeed “boils down” to picking the appropriate metric when making decisions. The whole idea behind feedback control is to base actions on the actual behavior (the “output”) of the system, and not merely on its operating conditions (the “input”). Conceptually, that’s all there is to it.
This is nevertheless a big deal, for two reasons:
Stacks in JavaScript
Practical data structures for practical purposes
In a previous blog post, I discussed why it is important for JavaScript developers to learn how to implement the classic data structures of computer science, such as stacks, lists, queues, and so on. I also talked about how in many cases, the problem being solved will suggest a particular data structure, resulting in an algorithm that almost writes itself. In this post I would like to provide an example of just such a case.
Let’s examine the problem first. We are asked to examine a text and find all the words that are palindromes. A palindrome is a word that is spelled the same forwards and backwards. Some examples of palindromes are “bob” and “racecar.”
Stacks in a Nutshell
The data structure we want to use to solve this problem is a stack. A stack is a list structure where access is only allowed at the top. Think of how you interact with a stack of trays in a cafeteria. If you want to get a tray, you get the tray that is on top; if you want to replace a tray, you place it on the top of the stack. That is how you interact with the data stored in a stack.
Event-driven application design with JavaScript
Look beyond jQuery to an MV* approach
When you start building dashboards for interacting with data, such as calculators, editors, or result browsers, understanding JavaScript and client-side MVC becomes important. Why do you need an event-driven application design and a separation of interface state and behavior? Let me walk you through some examples.
You’ve probably seen seen simple example editors, where the browser acts as an editor for to-do lists. In these applications, you edit to-do items, consisting of a text and a state (pending or done). These small editors are very helpful for studying monitoring events from the keyboard and partially updating page content. These are the main principles for building applications in web browsers.
Once you going beyond to-do list editors, the requirements quickly increase. For example, you might work with multiple counters that observe the cursor position, or the number of words in a text box. You might need to support multiple editing modes or text formatters, or edit actions and state synchronization with a backend.
A concrete approach to learning how to program
A solid foundation on which more meaningful learning can happen
As someone who has previously taught computer programming for nearly a decade, I’m often asked questions that involve “what’s the best way to go about learning to program computers,” or “what’s the best way to get a software engineering job,” or “how can I learn to build mobile or web apps?”
Most of the readers of this blog have probably faced the same question at some point in their career. How did you answer it? I’ve seen many different responses: “come up with an idea for an app and build it,” or “get a computer science degree,” or “go read The Little Schemer,” or “join an open-source project that excites you,” or “learn Ruby on Rails.”
The interesting thing about these responses is that, for the most part, they can be classified into one of two categories: top-down approaches or bottom-up approaches. Top-down approaches are informed by the opinion that it’s better to be thrown in the middle of an application or a framework which encourages the learner to piece together knowledge in that context. Many books and online tutorials use an explicit top-down approach, often starting with the basics of a popular methodology, framework or technology. The most visible example of this are books on Ruby on Rails — they almost always inevitably begin with a description of the Model-View-Controller design pattern, but defer the incredible number of non-obvious ideas that make it up (Object-Oriented Programming, for instance).
On the other hand, a bottom-up approach starts with the basics/fundamentals of programming and then slowly builds your knowledge over time. In contrast to top-down approaches, bottom-up approaches try to minimize the number of these non-obvious ideas that the learner has to take for granted. Khan Academy and Code Academy are two examples of online sites that use a bottom-up approach to teaching programming. For the most part, they completely leave out any specific framework and focus on fundamentals of programming.
Understand the four layers of JavaScript OOP in one short lesson
6 highlights from Axel Rauschmayer's webcast
Last week Axel Rauschmayer presented “The Four Layers of JavaScript OOP.” His approach to teaching JavaScript OOP is doing so incrementally, through layers. Each of the four layers builds upon the last. The lesson runs just under an hour.
- The live audience (1,500 attendees) brought certain foreknowledge to the course, represented by this graph (based on a live poll). Most individuals had knowledge of object oriented programming, whether with JavaScript or another language, and fewest had knowledge of prototype chains. [at 01:30]
- Axel walked through an overview of the 4 layers of JavaScript OOP and summarized each. [at 2:25]
- Layer 1, Single object. [at 3:55]
- Layer 2, Prototype chain. [at 14:52]
Layers 1 and 2 together form a simple core, which you can refer back to if confusion sets in. This way you can re-ground yourself at any point in the foundations of the course.