gavinlaking

def shopkeeper_navigation
  contents = ''
  links = [
    {:label => "Dashboard",                   :value => shopkeeper_dashboard_path,  :paths => []},
    {:label => "My Products & Services",  :value => shopkeeper_products_path,   :paths => [shopkeeper_services_path, shopkeeper_returns_path]}, 
    {:label => "My Customers",                :value => shopkeeper_customers_path,  :paths => [shopkeeper_promotions]},
    {:label => "My Shop",                     :value => shopkeeper_shop_path,       :paths => [shopkeeper_paypal_details_path]}, 
  ]
  links.each do |link|
    if (request.path =~ %r(#{link[:value]}.*)) || (link[:paths].any?{|path| request.path =~ %r(#{path}) })

gavinlaking

If we should store assets on the filesystem rather than in the database because access is faster, then why are we not storing data on the filesystem rather than in a database? A database typically consists of a couple of files, one being the hunk of data itself, the others, supporting files like indicies.

So, why not use the filesystem as it was designed: direct and flexible. Store our data using the right tool for the job. I can't think of anything that an off-the-shelf database ACIDically provides that our filesystems can not already do.

Consistency may be lacking, from the respects of ensuring that a file is as it says (size, contents, etc), however, is it not the job of those wishing to store data to ensure it is correct before persistence? i.e garbage in, garbage out. 

gavinlaking

If we should store assets on the filesystem rather than in the database because access is faster, then why are we not storing data on the filesystem rather than in a database? A database typically consists of a couple of files, one being the hunk of data itself, the others, supporting files like indicies.

So, why not use the filesystem as it was designed: direct and flexible. Store our data using the right tool for the job; individual files storing discrete pieces of information. I can't think of anything that an off-the-shelf database ACIDically provides that our filesystems can not already do.

Consistency may be lacking, from the respects of ensuring that a file is as it says (size, contents, etc), however, is it not the job of those wishing to store data to ensure it is correct before persistence? i.e garbage in, garbage out.

What are your thoughts?

gavinlaking

require "bcrypt"
require "benchmark"

password = "My_Rea11y-B1G_S3cr3t"
salt = "2d3ec54c5fa27b9e9d8a3e7f1ed9f7f7c4b1c7e2f7da5c"

stretches = [1, 2, 3, 4, 5, 6, 7 ,8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20]
stretches.each do |cost|
  puts "\n\n-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-"
  puts "Cost = #{cost}"

gavinlaking

#!/bin/bash

set -exo pipefail

BUILD_ENV=$1
if [ `uname` == 'Darwin' ]; then
  OSX=1
  JSCOMPRESSOR="yuicompressor --type js"
else
  OSX=

gavinlaking

$ ruby tmp.rb

Rehearsal -------------------------------------------------
file read       0.000000   0.000000   0.000000 (  0.003113)
file to array   0.040000   0.010000   0.050000 (  0.039986)
#matches        0.230000   0.000000   0.230000 (  0.230347)
---------------------------------------- total: 0.280000sec

                    user     system      total        real
file read       0.000000   0.000000   0.000000 (  0.001798)

gavinlaking

<?xml version="1.0"?>
<root>
  <item>
    <name>Map Function keys to match Apple</name>
    <identifier>private.itunes_fkeys</identifier>
    <autogen>__KeyToConsumer__ KeyCode::F1, ConsumerKeyCode::BRIGHTNESS_DOWN</autogen>
    <autogen>__KeyToConsumer__ KeyCode::F2, ConsumerKeyCode::BRIGHTNESS_UP</autogen>
    <autogen>__KeyToKey__ KeyCode::F3, KeyCode::EXPOSE_ALL</autogen>
    <autogen>__KeyToKey__ KeyCode::F4, KeyCode::LAUNCHPAD</autogen>
    <autogen>__KeyToConsumer__ KeyCode::F5, ConsumerKeyCode::KEYBOARDLIGHT_LOW</autogen>