When I first started Silicon Florist, I was hoping to shine some light on startups and events that might not be getting the attention they so richly deserved. I don’t know that I’ve succeeded. But I feel like I’ve at least made a dent.
Now, I’d like to make the same attempt with another under-served and under-recognized population: Portland’s rich and varied user group scene. I mean, there’s a ton of great stuff happening in our user groups. But—unless you’re at every single user group meeting—you can’t really get a feel for just how awesome it is.
So, I’m starting a new series of posts. We’ll be peeking in on user groups in Portland. Taking a look at what they’re mucking with. Listening in our their discussions. And hopefully introducing you to a few groups about which you might not know.
Notes from the last pdxJS meeting
There is another webkit API that creates a local filesystem that your web app has access to. From what I understand this API does not give the browser access to your real filesystem. Instead it creates space for files to be saved on disk just for that web page. There is a flag that switches between a transient filesystem, which goes away when the browser window closes, and a persistent filesystem, which will keep those files on disk indefinitely until the web app or the user removes them.
This discussion of ECMAScript 1.5 features resulted in a request that I repost slides from a talk that I gave a while ago on that topic. Those slides are available here.
The Future Is Modules Not Frameworks by John Hann
Small modules could benefit from the use of something like the CommonJS module specification, which makes it easier to work with lots of libraries in one application without scope pollution. Though that brings up a question of exactly what a browser module should look like. A straight translation of the module definition that is intended for server-side code may not be the best option.
- Ender.js is a recently-created tool for building collections of small modules into frameworks. Ender offers a convention for organizing a module so that it can be easily included in lots of projects.
modules. It organizes modules by use case.
The node team is hard at work on porting node to Windows. In the process they are abstracting the under-the-hood components to make the platform-specific portion of node as small as possible. Some choice quotes from the slides:
Why is porting to Windows a priority?
The goal of Node, as with any programming platform, is total world domination.
If we can’t get at least gigabit throughput from a TCP pair over loopback on every OS, we’ve failed.
If we can’t have 10,000 idle sockets connected to a server and use less than 100mb RSS on every OS, we’ve failed.
The slides discuss some of the hurdles and nice bits of writing non-blocking code in Windows.
A point came up in our discussion that a common comment on Node is, “why would I need that many connections open at once?” The answer is that that kind of question stems from the traditional approach to web applications where a client connects, is served a response as fast as possible, and disconnects. Node is aimed at a new style of application – or at least a style that is new to high-scale web applications – where clients are constantly connected to the server via websockets or comet.
dnode is a new RPC protocol. It is built on JSON and has implementations in Node and in some other languages. The particular advantage of dnode is that it allows clients to serialize procedures to be executed on the other side of a connection. That process can be arbitrarily nested: a service receiving a serialized procedure can pass that procedure as an argument to another serialized procedure that is passed to another endpoint.
npm supports packages that include C and C++ code. Currently that involves packaging up the source code; when a user installs the package the binary component is built from source. In the interest of bringing Node to Windows, and since Windows users are less likely than *nix users to have access to a decent compiler toolchain, work is underway to support precompiled binary components in npm packages.
We also talked a bit about Google Chrome OS. Specifically, the ability that Chrome and Chrome OS have to run web applications that include binary components. If a web app is installed from the Chrome store – that is, if the user has accepted the app manifest that grants the app permission to run binary code – then the app can download and run binary code. The binary code is still limited by the restrictions of the page sandbox. And the browser does perform a verification step to make sure that the binary code does not contain any dangerous instructions that could break sandbox isolation.
Interested in having your Portland User Group featured in Silicon Florist? Drop me a line at firstname.lastname@example.org with your notes, and I’ll be happy to post them.