Sorted by location-ish. I tried to reduce the list to places I think are good for visitors vs. my absolute favorites, but I put a section at the bottom for places that may not be for everyone.
580 SW 12th Ave
My order: Grilled mackerel breakfast with a bloody mary. Their Dalgona coffee is quite good too.
| gifify() { | |
| if [[ -n "$1" ]]; then | |
| if [[ $2 == '--good' ]]; then | |
| ffmpeg -i $1 -r 10 -vcodec png out-static-%05d.png | |
| time convert -verbose +dither -layers Optimize -resize 600x600\> out-static*.png GIF:- | gifsicle --colors 128 --delay=5 --loop --optimize=3 --multifile - > $1.gif | |
| rm out-static*.png | |
| else | |
| ffmpeg -i $1 -s 600x400 -pix_fmt rgb24 -r 10 -f gif - | gifsicle --optimize=3 --delay=3 > $1.gif | |
| fi | |
| else |
| ### | |
| # Scheme code is translated to YARV byte code, then evaluated in the | |
| # Ruby Virtual Machine | |
| require 'rbconfig' | |
| require 'dl' | |
| require 'fiddle' | |
| require 'strscan' | |
| class RubyVM |
| # First attempting to use Capybara directly, you will ran into issues when trying to set HTTP header. | |
| # Using Basic HTTP Authentication requires that we needed to set the header. | |
| # Also we need to set the Content-Type and Accept headers to ensure that Rails handles the input and output correctly. | |
| # When using Rack, Capybara delegates request and response handling down to Rack::Test. | |
| # So I used Rack::Test directly in my step definitions, and it works. | |
| # Rack::Test has a module called Rack::Test::Methods that can be mixed into a class to provide it | |
| # with methods for get, post, put, delete as well as last_request, last_response, header and more. | |
| # I mixed Rack::Test::Methods into the Cucumber world at the top of our API steps file like so: | |
| ############################## |
I spent some time on a little scripting project yesterday and decided to use Backbone and CoffeeScript. I've been looking for a reason to use Backbone just to become more familiar. I don't really use CoffeeScript, and even went through my periods as a CS hater. But it's always a good idea to stay familiar with what's out there. At the very least it'll make sure you're not full of shit when you talk to people about pros and cons. Anyway, this isn't comprehensive or even useful per se. I just thought I'd jot down some thoughts.
I should make a disclaimer that this wasn't a traditional project for Backbone. It was a node script that only uses models a collections. I needed to perform a bunch of actions on a dataset by hitting a REST api. I've been thinking for a while that tasks like this are often nicer if you can mock up a quick model domain around the api. Then you can work with Forum and Topic models and just do update and delete operations on them. Once you set these up, the scripting tasks become much mor
| # Thanks to @samsonjs for the cleaned up version: | |
| # https://gist.github.com/samsonjs/4076746 | |
| PREFIX=$HOME | |
| VERSION=1.2.3 | |
| # Install Protocol Buffers | |
| wget http://protobuf.googlecode.com/files/protobuf-2.4.1.tar.bz2 | |
| tar -xf protobuf-2.4.1.tar.bz2 | |
| cd protobuf-2.4.1 |
| #!/usr/bin/env sh | |
| ## | |
| # This is script with usefull tips taken from: | |
| # https://github.com/mathiasbynens/dotfiles/blob/master/.osx | |
| # | |
| # install it: | |
| # curl -sL https://raw.github.com/gist/2108403/hack.sh | sh | |
| # |
| events = | |
| events: {} | |
| bind: (topic, handler, context = this) -> | |
| (@events[topic] ||= []).push { handler, context } | |
| trigger: (topic, args...) -> | |
| if @events[topic]? | |
| event.handler.apply event.context, args for event in @events[topic] |
