Feb 24, 2012

The Fastest Way to Learn Ruby?


It felt like a slog but I don't know of a faster way...

                                  ,,   ,  ,,
: ::::, :::,
, ,,: :::::::::::::,, :::: : ,
, ,,, ,:::::::::::::::::::, ,: ,: ,,
:, ::, , , :, ,::::::::::::::::::, ::: ,::::
: : ::, ,:::::::: ::, ,::::
, ,::::: :,:::::::,::::,
,: , ,:,,: :::::::::::::
::,: ,,:::, ,::::::::::::,
,:::, :,,::: ::::::::::::,
,::: :::::::, Mountains are again merely mountains ,::::::::::::
:::,,,:::::: ::::::::::::
,:::::::::::, ::::::::::::,
:::::::::::, ,::::::::::::
::::::::::::: ,::::::::::::
:::::::::::: Ruby Koans ::::::::::::,
:::::::::::: (in Ruby 1.8.7) ,::::::::::::,
:::::::::::, , ::::::::::::
,:::::::::::::, brought to you by ,,::::::::::::,
:::::::::::::: ,::::::::::::
::::::::::::::, ,:::::::::::::
::::::::::::, EdgeCase Software Artisans , ::::::::::::
:,::::::::: :::: :::::::::::::
,::::::::::: ,: ,,:::::::::::::,
:::::::::::: ,::::::::::::::,
:::::::::::::::::, ::::::::::::::::
:::::::::::::::::::, ::::::::::::::::
::::::::::::::::::::::, ,::::,:, , ::::,:::
:::::::::::::::::::::::, ::,: ::,::, ,,: ::::
,:::::::::::::::::::: ::,, , ,, ,::::
,:::::::::::::::: ::,, , ,:::,
,:::: , ,,
,,,

Feb 13, 2012

Polyglot Persistence: When and Why?

What kinds of projects are candidates for polyglot persistence? Perhaps it's one's that are:

strategic and (rapid time to market and/or data intensive)

[more]

Feb 12, 2012

NodePDX: Better Together: Building Scalable Real Time Collaborative Apps with Node.js

Kav Latiolais presented Better Together: Building Scalable Real Time Collaborative Apps with Node.js.

The talk was a mix of real-time collaborative app design and backbone experience. Collaborative apps have minimum and maximum numbers of users in order for them to be fun. Advice: work on the single-player experience.

Keep your business logic server-side, i.e. make all your model changes in node. If you're going to get into using local storage, store model changes as they arrive. With backbone you have to be careful how you replace models - i.e. use the set command rather than replace it.

Backbone is inappropriate for some cases, e.g. a game with many model updates. Backbone is event-noisy.

The backbone example wasn't on github at the time of posting, but it will be here.

NodePDX: Geddy - A better framework for building apps on node began with a history of node frameworks

Daniel Erikson's talk, Geddy - A better framework for building apps on node began with a history of node frameworks began with a brief history of node frameworks: Connect -> Express -> Flatiron. His main complaint with them being that they all lack structure.

Geddy.js exists to provide that structure. Geddy is maintained by Yammer engineers and used by Yammer for their upload servers that server 5+ million users. Geddy's highlights are:

* Rails-like generators
* Rails-like routes
* Resources (as in REST resources)
* Content negotiation (renders differently depending on the Accept header)
* Models (validation, data types, instance methods, static methods)
* Bootstrap and jQuery are built in (i.e. mobile and tablet ready)
* EJS templates (replaceable with jade, handlebars etc)
* Logging
* Metrics (instruments all requests and controllers)
* Buffered streams (enables streamed file uploads, before filters)
* Process clustering
* No out of the box CoffeeScript support (boo, hiss)
* No persistence implementation as yet (it's about six months out)
* No built-in testing (Daniel says to use foounit)

To get started:
npm install -d jake geddy

Looks interesting. Thanks, Daniel.

NodePDX: Node.js for Front-End Developers

Garann Means is the author of Node.js for Front-End Developers. Garann is enjoyably opinionated. In fact, you should give her blog a read, it's entertaining. Garran presented DRYing out your client-side apps.

I'm being lazy, so this is a mix of quotes and links:
* "The server is becoming perfunctory. We just need to drop off our data on the server to persist it."
* "Backbone is the new jQuery. Reuse on the client-side is a new problem."
* "There's no reason to duplicate code [between client and server] if you're using node."
* "Request.js and r.js are key to consistent module managing across the client and server."
* "You're elements of reuse are: models, views/templates, route patterns, external/third-party utilities (underscore etc)."
* There's a proliferation of full-stack solutions for node.
* dnode for RPC.

NodePDX: BattleBots in the Clouds with Node.js


Ken Robertson presented BattleBots in the Clouds with Node.js. Ken demonstrated an HTTP-based bot battle running on his paas.io service.

NodePDX: Building a Real-time geolocation game with Geoloqi using Node.JS

Kyle Drake presented Building a Real-time geolocation game with Geoloqi using Node.JS which told the story of making a real-time game and solving performance problems along the way. They started out in Ruby and migrated to Node.

They had some cautionary advice:

Your performance bottleneck is your database.

It's all very well using TrendLang (I think they were talking about Node) but it's not going to help you if your database is the bottleneck. Kyle said that what you really need is real hardware (so not the cloud - yet). Real SSDs (there are some out there that can read and write at gigabytes per second).

Kyle advocated using Redis for pub/sub messaging. The node code is pretty straight-forward:

var redis = require('redis');
var subscribe = redis.createClient();
subscribe.subscribe('pubsub');

subscribe.on("message", function(channel, message) {
// ...
});
Kyle had FUDdy things to say about NoSQL databases asserting that there were global write-locks abound. Yet he did say that Riak was his current favourite NoSQL database.

Feb 11, 2012

NodePDX: ql.io - Consuming HTTP APIs at Scale

Okay. So ql.io looks pretty impressive. Subbu Allamaraju presented his talk, ql.io - Consuming HTTP APIs at Scale.

ql.io set out to address four core problems: parallelizing, sequencing, joining, and normalizing HTTP communication. It's goals are to be:
* easy - less to write to do what you need, and
* fast - limit the number of round-trips.

So what is ql.io? It's an HTTP gateway, built in nodejs, that provides an SQL-like DSL for consuming HTTP-based APIs.

Now I like what I've seen of ql.io. I looks very powerful. The put-off for me is choosing SQL as the conceptual framework for expressing operations. I get it, CRUD concepts map to RESTful operations. But SQL? Hmm. More exposure to ql.io will tell how well that works in practice.

To illustrate, here's a script that you can execute:

select ProductID[0].Value, DetailsURL, StockPhotoURL 
from eBay.FindProducts where QueryKeywords="mini cooper"
Of course this is only one half of the solution. You still need to create table in order to specify how to translate the DSL into action.

Congratulations ql.io!

Other notes:

* Caching is not part of the infrastructure - you can cache infront or behind of ql.io.
* Request body templates are defined in mustache.
* ql.io optionally streams via WebSockets.
* Yes, ql.io supports SOAP - puke.

NodePDX: Object-Oriented Patterns in JavaScript

Jesse Hallett's session, Object-Oriented Patterns in JavaScript, explored design approaches in JavaScript.

Jesse used Crafty and jstraits, Clojure Protocols, and type classes in Haskell as examples of well designed and though-provoking approaches for organising behaviour. He went on to illustrate what Crafty would look like if it were implmented in jstraits, and how to deal with conflicts that arise from composing traits - as opposed to traditional multiple inheritance schemes.

For his finale, he revealed his offering: etiquette.js.

NodePDX: Building Applications with Bricks.js

Jerry Sievert's presentation, Building Applications with Bricks.js, kicks off with a demonstration of implementing a wiki.

To begin with it's not apparent what bricks.js wants to be. Is it a replacement for Apache? Is it trying to replace expressjs? Out of the box, bricks,js provide us with an instant static server, a fast routing framework, and built-in plugins.

I'm not familiar with the bowels of Apache routing. Apparently, bricks.js offers a similar approach to routing with pre, main (default), post, and final "sections".

For his demo, Jerry uses the following npm packages: handlebars (compatible with Mustache), mongoskin (an API for MongoDb), and marked (a markedown parser and compiler).

Side note: You can straight up require a JSON file as of node v0.5.x. e.g.:
settings = require('./settings.json')