janx

{"source":"contract test { function multiply(uint a) returns(uint d) { return a * 7; } }","language":"Solidity","languageVersion":"0.2.1","compilerVersion":"0.2.1","compilerOptions":"--bin --abi --userdoc --devdoc --add-std --optimize -o /tmp/solc206349014","abiDefinition":[{"constant":false,"inputs":[{"name":"a","type":"uint256"}],"name":"multiply","outputs":[{"name":"d","type":"uint256"}],"type":"function"}],"userDoc":{"methods":{}},"developerDoc":{"methods":{}}}

janx

  // if 2nd arg is 'latest', everything is fine
  var event = book.NewRecord(null, 'latest');
  //event.get(function(err, results) {
  //  console.log(results);
  //});
  event.watch(function(err, result) {
    if(err) {
      console.log("error:", err);
    } else {
      console.log(result);

janx

#!/bin/sh

path=`find /your_gollum_project -name '*.md' | sed 's/\/your_gollum_project\///' | sed 's/.md\$//' | dmenu -i -fn Tamzen-12 -p "Edit gollum wiki:" -l 25`
url="http://localhost:4567/edit/$path"
[ -z $path ] || /usr/bin/chromium --app="$url"

janx

setInterval(function() { Array.prototype.slice.call(document.querySelectorAll('[data-reactid]')).forEach(function(element) { element.style.background = 'rgba(255,0,0,0.1)'; }) }, 500)

janx

#!/usr/bin/env ruby

if ARGV.size < 1
  puts "usage: ruby_tags [version]"
  exit 1
end

version = ARGV[0]
d = Dir["/home/jan/.rbenv/versions/#{version}/lib/ruby/gems/*/gems"]
raise "gems dir not found" if d.size < 1

janx

#!/usr/bin/env ruby

# get a list of all windows
window_list = `wmctrl -l`.split("\n").map {|l| l.strip.split(' ', 4)}

# write window names to a tmp file
File.open('/tmp/dmenu_goto_windows', 'w') do |f|
  window_list.each {|w| f.puts w[3] }
end

janx

Verifying myself: My Bitcoin username is +janx. https://onename.io/janx

janx

In simple applications the Domain Model (116) is an uncomplicated structure that actually corresponds pretty
closely to the database structure, with one domain class per database table. Such domain objects often have
only moderately complex business logic. In this case it makes sense to have each domain object be
responsible for loading and saving from the database, which is Active Record (160) (see Figure 3.3). Another
way to think of the Active Record (160) is that you start with a Row Data Gateway (152) and then add domain
logic to the class, particularly when you see repetitive code in multiple Transaction Scripts (110).

...

As the domain logic gets more complicated and you begin moving toward a rich Domain Model (116), the simple

janx

m = Member.find_by_email '[email protected]'
market = Market.find :btccny

puts "Ready ..."
a = m.get_account(:cny)
puts "balance: #{a.balance.to_s('F')}"
puts "locked:  #{a.locked.to_s('F')}"
gets
puts "Started."

janx

m = Member.find_by_email '[email protected]'
market = Market.find :btccny

ask = OrderAsk.new(
  source: 'debug',
  state: Order::WAIT,
  member_id: m.id,
  ask: market.target_unit,
  bid: market.price_unit,
  currency: market.id,