juanpaco

const knex = require('knex')

function createDb({ allowWipe, connectionString, tables }) {
  const client = knex(connectionString)

  const retval = {
    client,
  }

  /**

juanpaco

I get into it here https://www.youtube.com/watch?v=h8ihxzfqH0A&t=1123.

But the gist is, in an event-sourced system, your *write* data by just writing events.  That is super simple and great for writing, but it isn't a great read model.  A good read model would look like a user row in a table, or a user document in a doc store of some sort.

In work I'm doing this morning, we have some user docs, and updating them is really a pain (CouchDB-- that's a different discussion).  It would be swell to just write an event of the flavor "userAttributeUpdated" with a payload that describes what was changed or something.  Then I could shape that into whatever I need for a read rather than having to maintain the read model while I'm writing.

Not sure if this is glossing over too much or not, so please let me know.  The above video link will help with that, and I think you could safely play it at 2x speed.

juanpaco

var async = require('async')
async.eachSeries(
  [ 1, 2, 3 ]
, function (key, next) { 
    async.eachSeries(
      [ 4, 5, 6 ]
    , function (key, innerNext) { // note the name change
        somethingAsync('something' + key, innerNext) // using the inner one
      }
    , function (innerErr) {

juanpaco

--------------------------------------------------------------------------------
Build a topic model (mallet) using a demo dataset (infovis)
  database = data/demo/infovis/corpus
    corpus = data/demo/infovis/corpus
     model = data/demo/infovis/model-mallet
       app = infovis_mallet
--------------------------------------------------------------------------------
    Available: data/demo/infovis/corpus
    Available: tools/mallet-2.0.7
    Available: tools/mallet-2.0.7

juanpaco

mkdir bash-fix
cd bash-fix
curl https://opensource.apple.com/tarballs/bash/bash-92.tar.gz | tar zxf -
cd bash-92/bash-3.2
curl https://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052 | patch -p0    
cd ..
xcodebuild
sudo cp /bin/bash /bin/bash.old
sudo cp /bin/sh /bin/sh.old
build/Release/bash --version # GNU bash, version 3.2.52(1)-release

juanpaco

When you say background job, are you referring to a Rails-specific implementation or the entire idea of delaying processing for a later time?

I'm quite happy to shed bad ideas I've accumulated. One good candidate for background processing I've always kept in my mind is sending an email on a user registration. I wouldn't want the email send process to tie up the request/response cycle, nor would I want a failure in that sending to cause a problem to the request/response cycle.

Is it an anti-pattern to delay that sending? I don't see how the concept is coupled to ActiveRecord, which is why I don't think I understand what you mean by "background job." But, my acquired wisdom could also be very wrong, and I want to shed that sort of thing.

juanpaco

var mongoose = require('mongoose')
  , db       = mongoose.connect("mongodb://localhost/sandbox_development")

var schema = new mongoose.Schema({
  blurb: String
})

var model = mongoose.model('thing', schema)

var instance = new model({blurb: 'this is an instance!'})

juanpaco

http://www.dzone.com/snippets/html-select-list-states-us

http://stackoverflow.com/questions/15984430/how-to-set-a-default-prompt-when-nothing-selected-for-select-using-css

juanpaco

#!/usr/bin/env ruby

print 'This is the output you are looking for.'

juanpaco

var databaseUrl = "mydb2"; // "username:password@example.com/mydb"
var collections = ["server", "followers"];
var db = require("mongojs").connect(databaseUrl, collections);
db.server.find({
  id: 1
}, function(err,res) {
   console.log(err)
   console.log(res)
   db.close()
})