Showing posts tagged tech

Git sub-tree merging back to the subtree for pushing to an upstream

While git sub-tree merge strategy works great for merging a library into vendor (when you want to pull HEAD on that library instead of waiting for releases), I had trouble finding documentation on pushing back to upstream.  This is annoying because one of the most obvious times you may want to use subtree is when you manage the library yourself, so can just pull straight from the repo, and want to push your maintenance changes back.

Surprisingly, and not what I have come to expect from git, it just works.  From the example in the docs I linked, when you are checked out on master

git merge --squash -s subtree --no-commit rack_branch

will merge the rack_branch into where you have specified.  But it just works the other way to.  If checked out on rack_branch

git merge --squash -s subtree --no-commit master

will do what you expect, so you can now just push your library branch back to it’s upstream.

Awesome!

Posted via web from a timocracy of one | Comment »

Testing a rackup (config.ru) file with Rack::Test

The ever useful rack-test gem let’s you easily integration test any rack project.  All you have to do is include the Rack::Test::Methods and define an app method that returns your rack app.  So people usually have a config.ru that just references their my_application.rb that they reference in their config.ru and then in their test file they can also reference that app and return it.  Something to to this effect:

 1 2 3 4 5 

class MySweetRackApp
  def initialize
    Proc.new { |env| [200, {‘Content-Type’ => ‘text/html’}, [‘success’]] }
  end
end

I had a project where I was actually trying to better breakdown a more complex app, and I wanted to just be able to use Rack’s built-in map method at the top level of my config.ru to route to different apps.  And in at least some of the cases I wanted to be able to test the whole thing.  Also, I figured sometimes it’s useful to actually be able to test your rackup file itself, all routing/mapping included.  So I dug around in the rack code and found how the rackup command handles the .ru file, and came up with this:

https://gist.github.com/28d510d9fc25710192bc

Posted via web from a timocracy of one | Comment »

Beware respond_to format with redirects in shared systems before_filter - DoubleRenderError

If you use an authenticated_system on your Rails site, with global before_filters for things like requiring login to access pages, be careful of missing formats in the respond_to.  I just tracked down a bug on an app where we were getting DoubleRenderErrors because of unauthenticated request directly to a csv file.  We had a before_filter that was denying request and redirecting them to login, in different ways, depending on the format, but hadn’t thought to include csv.  In this case, it is wise to include a catch-all at the end using .any

 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 

def anon_access_denied
  respond_to do |accepts|
    accepts.html do
      store_location
      redirect_to login_path
    end
    accepts.xml do
      headers[“Status”] = “Unauthorized”
      headers[“WWW-Authenticate”] = %(Basic realm=”Web Password”)
      render :text => “Could’t authenticate you”, :status => ‘401 Unauthorized’
    end
    accepts.js do
      render(:update) { |page| page.redirect_to login_path }
    end
  end
end

Posted via web from a timocracy of one | Comment »

The trouble with bash colored prompts munging your control-r bash history searches

Basically, you just want to be very careful properly escaping and ending color sequences in your bash prompt.  If you mess them up, when you try to use spiffy bash tricks that mess with your current line, such as control-r to search through your bash history and then left of right arrow to edit that line, you’ll get a partially overwritten line that is impossible to read or edit properly.

 1 2 3 4 5 6 7 8 9 10 11 

#Just be careful. Safest to properly end color sequence, so instead of this
#export PS1=”\[\033[01;32m\]\u\[\033[00m\]\[\033[01;31m\]\$(git_br)\[\033[01;32m\]\[\033[00m\]:\[\033[01;36m\]\$(git_pwd)\[\033[00m\]\$ “
 
#do this
USER_GREEN=’\[\e[01;32m\]’
#NO_COLOR=’\[\e[00m\]’
REPO_RED=’\[\e[01;31m\]’
PATH_BLUE=’\[\e[01;36m\]’
END_COLOR=‘\e[m’
 
PS1=”${USER_GREEN}\u${END_COLOR}${REPO_RED}\$(git_br)${END_COLOR}:${PATH_BLUE}\$(git_pwd)${END_COLOR}$ “

Posted via web from a timocracy of one | Comment »

Call a custom jar from ruby in jruby

 1 2 3 4 5 6 7 8 9 

#javac HelloWorld.java && jar cvf HelloWorld.jar HelloWorld.class
require ‘java’
require ‘HelloWorld.jar’
import ‘HelloWorld’
 
puts HelloWorld.new.hello
#=> “Hello cruel world”
 
#jruby hello_world.rb

Posted via email from a timocracy of one | Comment »

Tagging a git release with current branch name and date

Either add this to your .git/config

[alias]  datetag = !git tag `git name-rev --name-only HEAD`-`date \"+%Y%m%d%H%M\"`

or run it in your project folder to add it to the config for that project:

git config alias.datetag '!git tag `git name-rev --name-only HEAD`-`date "+%Y%m%d%H%M"`'

Posted via web from a timocracy of one | Comment »

Setting RAILS_ENV on Dreamhost when running Passenger

It may depend on which server you are on, but mine has mod_env
enabled, so it’s a simple matter of setting the ENV[‘RAILS_ROOT’] in
an .htacess file
 
SetEnv RAILS_ENV staging

Posted via email from a timocracy of one | Comment »

http://g.raphaeljs.com/

http://g.raphaeljs.com/

A sweet javascript charting/graphing library. Soon there may be no
need for flash/flex every again?

Posted via email from a timocracy of one | Comment »

Avoiding some of the negative trade-offs in the template pattern with ruby’s dynamicism?

So my buddy Tammer’s recent post about the Gang of Four’s Template Pattern reminded me of some code I saw recently. A start-up’s greenfield project had it’s authorization done in a pretty clean way using the template pattern. Basically every object determined what could be done to it, something like this:

After continuing this approach to fully cover CRUD you make a straight-forward set of accessors that can be used to easily enforce permissions in the controller in a programmatic way (this project was using on of the inherited resourceful-controller plugins, so that was a big plus). The developer who implemented this commented that the trade-off for this simplicity was having to look in each individual model file to figure out what a user can do overall. I figured I liked everything about this scheme except that trade-off, and since ruby is so dynamic, why settle for almost. Why not just reopen each class in the authorization file and add the methods. You still get the simplicity and encapsulation of having the model able to determine it’s own permissions, based on it’s state and methods, and there is still one place to look to review/change the permissions for the whole project:

Thoughts?

Posted via web from a timocracy of one | Comment »