The problem with computers today is disk space. Good computers today are reasonable specs combined with SSD drive technology. My hardware advice is basically; just get a MacBook Air on your budget and resist the MacBook Pro unless you want to store a lot of photos and songs, in which case you remove the superdrive and load it with the biggest HDD you can afford. Never let the budget move you off of SSD, instead drop the secondary HDD and go with the cheapest 128GB Air. But of course people would like to potentially store all their photos and songs in one place and 128GB isn't enough after 3 years of photo archival. Just because you don't currently have a huge iPhoto library, everyone aspires to become a domestic documentarian and hates the idea of running out of disk space.

The way to solve this is to turn filesystems, or at least program file management into the problem domain of databases. Make the filesystem eventually and discriminatingly consistent. Apple is taking steps in this direction with iTunes Match, turning your collection into an iCloud enabled and legalized semi-streaming service. The first time you play a song in your iCloud library it gets downloaded, but the bulk stays in the cloud. I imagine you could then push things in and out of "offline mode", or make iTunes manage it. Apple needs to do the same with iCloud.

This also solves the other problem with hard drives, their unreliability.

Let's do this at a lower level. iCloud could continually scan your SSD drive for files you only rarely seek. I would not be surprised if Apple were working on an iCloud solution that jumps in when you run out of disk space and pushes things to "online" mode. Algorithms can easily detect files that do not need fast access. OS X apps with could access an API to correct false positives. Merge Spotlight, Disk Utilities and Time Machine into one interface to manage this.

Speaking about tech conferences:

I do some public speaking from time to time. Hopefully I haven’t been casually sexist in those appearances, but posts like Brittany’s are a useful reminder that when you’re on stage, it’s easy to incorrectly assume that everyone in the room agrees with you. More to the point though, women are sadly underrepresented in the tech industry, and bad experiences like these aren’t going to help that situation. I’m not just talking about it from a bleeding heart liberal perspective, either. I fully believe we’re under-performing in innovation because we don’t have sufficiently diverse voices involved in the products we’re building.

It’s not just about ideals. If I were an angel investor I’d be interviewing women 7 days a week. If I were a politician I’d be arguing for the healthiest possible environment for female entrepreneurs. If I were a globocorp with a community fund I’d focus on women and take the heat for it. If I were a woman I’d be frustrated trying to express these ideas, because pushing things forward is frequently perceived as militant by both women and men.

Framing the problem as a lost opportunity helps the discussion and creates empathy towards the arguments, where otherwise you’d meet frustration, even anger. If you are a product creator, I encourage you to think hard about the other half. Working in advertising I have seen the success first hand. Proactively pushing feminism and women’s ideas into the discussion can start to sound condescending, especially in marketing. But you must trust me this is precisely not the case with established pretext.

As long as node.js earned its share of fans and hacker accolades one of the benefits was touted to be one runtime for both environments (browser and clients). That is, JavaScript in the front, JavaScript in the back. Up until now this did not seem like a real benefit to me, and indeed few frameworks actually delivered on this promise, or even tried. However structured and clever your code, you'd always need to think about "front" and "back". Backbone.js blurs the line by reducing your backend to an API without any HTML output. But what line exactly? Where is the trend stopping? What trend?

Templating is an awkward beast in web development. Most template engines start with a loader of ANY text file of ANY structure and replace tags with code, at the end of which placeholder text is injected. The DOM kind of is a template engine when you think about it. It starts with a tree and has methods to juggle that tree about, a scripting engine for the logic and methods to modify and inject values. We're in this in-between phase where we love the power and expressiveness of normal template engines, but rarely reach for its power because the looping and value injecting is all done by JavaScript now-days. What I'm suggesting; if what you're dealing with is almost always a DOM, why not express your output in a programmable DOM? And what better tool to juggle the DOM tree then JavaScript and a library like jQuery?

Forward thinking site authors are going this way, but as usual problems present themselves because the rest of the world hasn't adapted to this mode of development. Thing is, making a website play well with important services like Google crawlers and Facebook "Like" buttons requires your site to play by the rules of REST, serving content stuffed HTML. It's probably just a question of time until these services catch up with modern web development and start "pretending" to be JavaScript enabled, but until they do they're a pretty good excuse to ignore the exciting development of new, mostly node.js happy frameworks. Indeed, Google has started indexing DISQUS comments, usually not part of the initial DOM.

What I'm hoping for is a framework that extends the components necessary for a true frameworkial merge of the browser and backend, to both sides of the development model. Web servers are then simply public repositories for interface recipes and URL modeled stateful communication (static files and REST APIs respectfully). We'll need a URL router that works as well when deployed client side as it does when delivering fresh requests. The datastore wraps methods in a thin AJAX crust when in the browser, but in all other aspects behaves the same. The backend runs jQuery for what we used to call the template layer, but is now, prophetically speaking now, simply called: Tree.

tree = new HTML5DocumentTree 
    styles: [
        'static/base.css'
        new Stylus 'styles.stylus'
    ]
    scripts: [
        'static/jquery.js', 
        new TreeScript 'ready.coffee'
    ]
    # layout: new LayoutTree

class Animal extends Resource

class AnimalTree extends Tree 
    dom: [
        'div', {className: 'animal'}, 'I am a @name'
    ]

index = (req, tree) ->
    dog = new Animal name: "dog"
    dog.tree = new AnimalTree model: dog
    tree.find("body").append dog.tree
    return tree

routes = {'/': index}
router = new Router routes

Route callbacks always return DocumentTree instances. If the routes are triggered server side a tree.ready() is called and tree.render() written to the HTTP response object. That's the bit I'm not sure just how magical must be.

Tree is a superset server side DOM object. DocumentTree is a subclass of Tree that is smart about structuring itself as an HTML5 document. The app object is automatically attached to the window DOM object on render. scripts is a list of executables or URLs to wrap in <script> tags. ready() triggers all the $(document).ready callbacks.

I hope this got you thinking about the evolution of web frameworks. I'm not trying to be political about it, just recognizing that node.js people have a fucking good point about having the same runtime as that of the browser. And an inventive and creative community around it that's thinking much more about this stuff than I am. Check out the freshly released flatiron framework for some hints at the future.

The future of social media is lying. As more and more services close their grip upon who we know, where we are, and what we're doing, we'll come to the sobering realization that we're just not that interesting. We'll create personas to travel the world, meet interesting people, solve crimes and rescue kittens from burning houses. 'Who you are' has never been as interesting as 'who you pretend to be'. The future of social media is the frontier of a new fiction, and one that we can be an active, and sometimes unwilling participant in. We don't want real identities, we want really good identities.

Mike_FTW on BusinessInsider

Great insight. I love that people in advertising are obsessively observant just to see half a step further into the future.

Finally getting some not unwelcome free time at work, I did research around the node.js web frameworks and tools. I've been trying out Brunch, which is a great scaffolding and compiler tool built on top of Eco templates, Stylus stylesheets, Backbone and the now indispensable alternative syntax for JavaScript; CoffeeScript. Its purpose is to become a de-facto environment to build HTML5 application front-ends.

Working with Brunch for a real project now, it strikes me is just how much time in development gets spent in Brunch (CoffeeScript, Backbone, Stylus etc.), and how little time gets spent on the backend. I don't have such a strong preference for Python frameworks anymore. I'd pick Flask because Armin Ronacher is a damned genius, but the time it takes to knock together a Django or Flask app is closing in to very little indeed. Backbone just wants some RESTful JSON endpoints, and is happy to sort, edit and display data, but also communicate with JSONP enabled API's.

What if Brunch, currently a client side framework for harnessing all the new browser technology, slowly took over what current server side frameworks are good for? CRUD interfaces, form/model validation and a model persistence layer (ORM?). We'd have something like the Django admin module, but DOM and therefor design aware. The questionable WYSIWYG ethos but responsive and truly in-browser, in-DOM even.

One-off editables would be defined easily with data-* attributes like so:

<p>Phone number: <span data-key="mysite:phone" data-type="text" data-empty-value="No phone number">+354 616 1339</span></p>

<img data-key="mysite:logo" data-type="image" width="120" src="logo.png">

The idea being that authors can easily provide default values, but make them editable with no extra effort. Different data-type values call their respective admin widgets. Single-line text, Markdown text, image uploads, and more. Each widget knows how to update the element and child nodes thereof. Widgets have error and success awareness and can report user or server errors. For lists-of-things or anything more complex and tailored you would define those elements as Backbone models and views with your own widgets, or perhaps classes of multiple fields like a Django Form class.

The base classes are tuned towards persistance in Redis, but community extensions can be more document or relational centric.

But the framework needs to solve more problems.

The Empty HTML Trend

The web is moving to serving empty HTML sans data then populating the DOM with JSON. This is a problem for Google and such crawlers as all the data is invisible unless it's part of the content provided by the server on the initial HTTP GET. The Backbone.js documentation encourages authors to ship the initial data with the HTML, for quicker loading, but this still doesn't solve anything for SEO and indexation.

The stars of web development had a debate when Twitter launched with empty HTTP GET pages, populated by AJAX. I won't speak of Twitter's deployment of the technology, but I'm certainly a spokesman of the web being more about URL's than HTTP REST sinners and saints. Joe Hewitt has some excellent writing on this very topic.

The next generation web framework solves this problem by rendering the output in a headless WebKit process and then serving a string presentation of that document object. Testing frameworks like Zombie.js already do this. I wonder if this is fast enough to do on a per request basis, at least in a development environment.