- frak — transforms collections of strings into regular expressions for matching those strings. The primary goal of this library is to generate regular expressions from a known set of inputs which avoid backtracking as much as possible.
- The Boolean Trap — crappy APIs where true/false don’t mean what they seem. None of this is new, but every generation has to learn it anew. (via Pete Warden)
- Gumbo — open source pure C HTML5 parser.
- All Those People With Cheap Android Phones Have Started Buying Apps (Quartz) — revenue generated by the Google Play Store, from which many Android users get their apps, has grown 67% over the past half-year. By contrast, Apple’s App Store revenue grew 15%, according to Distimo estimates, which cover the top 18 countries. That sounds less impressive if you consider that the App Store brought in twice as much revenue in absolute terms. But the numbers are shifting fast. In February, the App Store was generating three times as much revenue, and last November it out-earned Google Play by a factor of four. Google is gaining.
Defining a powerful toolkit
The rise of the phrase “web platform” over the past few years makes me very happy.
This summer, I’ve seen all kinds of programming approaches as I’ve bounced between the Web, XSLT, Erlang, and XML, with visits to many other environments. As I look through the cool new possibilities for interfaces, for scaling up and down, and for dealing with data, I keep seeing two basic patterns repeating: walking trees (of data or document structure), and handling events.
Robo Regex, Crappy Code, HTML5 Parsing, and Play v App Numbers
A language built to support event handling, not strictly a functional programming language but fitting that mold. A deep understanding of markup structures. A home in the browser.
Thursday afternoon at Balisage, O’Neil Delpratt and Michael Kay discussed Interactive XSLT [2.0] in the browser, showing not just the usual transformations but a working engine for a graphical interface. Their earlier XML Prague paper also tells the story and shows more code detail, including a chess game.
Getting past the HTML / XML splits
A few years ago, I stopped talking about XML and starting talking about markup. After a few too many conversations with developers who had found XHTML, web services, and various other things that had proudly branded themselves with the “X,” it was clear from hostile responses that XML’s boom was done.
Many of Wednesday’s Balisage talks wrestled with the challenges XML tools face in a world dominated by competitors, especially HTML5. Today opened with a talk on making XForms work in HTML5 with browsers, followed immediately by a talk on replacing DocBook XML with XHTML5 (at O’Reilly). Two more abstract talks looked at filtering and an info space model, but the afternoon asked “Where did all the document kids go?” and then sought world domination by making XML invisible.
Organize and control content with the Lift web framework
Lift is a web framework built for the Scala programming language, running on the Java Virtual Machine. Version 2.5 recently shipped, and I’m highlighting features of the framework that I find appealing.
Last time it was transforms and REST services, and this time it’s two features around organizing and controlling access to content.
How do you manage the HTML pages on site? Maybe some pages are available to everyone, others require login or some condition for access, and often pages are grouped in some way. Lift has an optional mechanism for expressing all this in one place, and it’s called SiteMap. This is how it looks in code:
lazy val home = Menu.i("home") / "index"
lazy val poets = Menu.i("poets") / "list" submenus (
Menu("Larkin") / "a-z" / "larkin",
Menu("Tennyson") / "a-z" / "tennyson"
We’ve defined a site made up of a home page, and pages for poets we like. Why is this a good thing?
First, it’s a pretty readable representation of the site in (compiler checked) Scala code. You can probably figure out that we have a page called “home” found at /index.html (or / as it’s usually known).
What might not be obvious is that
Menu.i is using “home” as a key into your translation resources, meaning the link text will be the localized version—if you’re building an internationalized site. The link to the page can be generated by a
Menu.builder, a snippet you can use on pages to give your users navigation of the SiteMap.
The second menu item is called “poets,” served up from a template called list.html. On the home page, the navigation snippet would give you a link to the “poets” page, but by default is smart enough to hide the submenus until you visit the list of poets.
SiteMap also performs access control: if you use SiteMap, HTML pages have to be listed in it to be accessed. It’s a simple line of defense, but you can improve on this by adding location parameters. These are rules for controlling access to a page.
Let’s say we wanted to only offer some content to customers paying for our premium plan:
val PremiumCustomersOnly = If(
() => false,
() => S.redirectTo("https://shop.example.org/") )
This is an if-then-else construct, made up of two functions. The first function is a test for what qualifies as a premium customer. It’s an arbitrary computation, and in this example it’s
false, meaning nobody is a premium customer (in reality, we’d perhaps check a property of the logged user). If you nevertheless try to get to the page, the second function kicks in, and you’d be sent to our store front.
We can apply the “premium customer” rule to any part of the site, but we’re going to just restrict Tennyson poems:
Menu("Tennyson") / "a-z" / "tennyson" >> PremiumCustomersOnly
If you don’t like the
>> method name, use
rule instead. If you just don’t like this domain specific language (DSL), you can construct a SiteMap in longer-form method calls.
What’s great about SiteMap is the flexibility it gives you: if you can’t get the behavior you want out of the box, you can write custom functions and classes, and drop them into the SiteMap. If you want menus displayed in a completely different way, not handled by
Menu.builder customization, you can write a different navigation snippet. Location parameter rules allow you to isolate logic, and combine them as needed to parts of your site.
These blinders derail Drew Crawford’s detailed rant on Why mobile web apps are slow. It turns out that “slow for what?” is a key part of the question, as Crawford reveals near the very end:
It may also be true that the browser vendors have optimized their performance as far as they can, at least in the relatively stable fields of HTML parsing and processing, and CSS selectors and formatting. Adding
So how can we optimize mobile web development?
Windows 8 is mostly about touch.
There was a time, some fifteen years ago, when the choice of the programming language was a delicate decision. It stopped being a problem when .NET arrived. Because .NET languages compile to the Common Language Runtime, .NET compatible languages became more or less indistinguishable other than syntactically, and developers could happily mix Visual Basic with C# and even JScript.
In Windows 8, things are different.
A Windows 8 application runs on top of a new runtime environment—called “Windows Runtime” or WinRT for short. WinRT is a modernized and redesigned version of the .NET Common Language Runtime. You can write a Windows 8 application using C#, Visual Basic, or C++ for the logic and XAML for the layout. In doing so, you can take advantage of patterns that are made-to-measure for XAML, such as the Model-View-View-Model pattern (MVVM). In this regard, developing for Windows 8 is not that much different from developing for Silverlight or Windows Phone.
Evolving enhancements for web developers