stonean

Historically I’ve never been one that required much to get the job done. For the better part of 10 years, I did my Java programming in Vim without any syntax highlighting and I was very productive. Over the past few years, as my focus has increasingly spread across multiple projects, I’ve started to embrace the little things that remove the need for me to keep track of my current development state. One such nicety is an informative bash prompt.

The first great step out of the standard prompt was the git_ps_tools project by Rein Henrichs. It’s one of the first things I setup when configuring a new machine.

Recently I’ve found myself needing to use the Ruby Version Manager project to easily switch between 1.8.6, 1.8.7 and 1.9.1 versions of Ruby for my various projects. Having multiple terminals using potentially different Ruby versions has become a little annoying. So, I’ve added a little more info to Rein’s prompt.

First, there is the ruby_pv script:

#!/bin/bash
# Return the ruby version
ruby -v | while read a b c; do echo "($b)"; done

Then I modified my original prompt:

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\]\$ "

To include the Ruby version:

export PS1="\[\033[01;32m\]\u\[\033[00m\]\[\033[01;30m\]\$(ruby_pv)\[\033[00m\]\[\033[01;31m\]\$(git_br)\[\033[01;32m\]\[\033[00m\]:\[\033[01;36m\]\$(git_pwd)\[\033[00m\]\$ "

So the resulting prompt looks like:

I happy to announce the release of RuHL version 1.3.0. This version simplifies RuHL by making it more flexible.

If a class attribute exits, RuHL will append to it, not override it.

If you have the following markup:

  <a data-ruhl="class: detail_click_hook, href: detail_url, full_name" class='list_link'> </a>

And the methods above return:

detail_click_hook => 'user_detail_123'
detail_url => '/user/123'
full_name => 'John Smith'

The result will be:

  <a href='/user/123' class='list_link user_detail_123'>John Smith</a>

Hashes can be passed into RuHL

With the previous example, detail_click_hook, detail_url and full_name were all described as being methods. However, having an object with methods isn’t always convenient. A lot of times, a hash is easier. For example, if I have a few users I want link to I may want something like:

  <ul>
    <li data-ruhl="_use: users">
      <a data-ruhl="class: detail_click_hook, href: detail_url, full_name" class='list_link'/> 
    </li> 
  </ul>

And the users method returns:

[
  { :detail_click_hook => 'user_detail_123',
    :detail_url => '/user/123',
    :full_name => 'John Smith'},
  { :detail_click_hook => 'user_detail_124',
    :detail_url => '/user/124',
    :full_name => 'Jane Doe'},
]

The result will be:

  <ul>
    <li>
      <a href='/user/123' class='list_link user_detail_123'>John Smith</a>
    </li>
    <li>
      <a href='/user/124' class='list_link user_detail_124'>Jane Doe</a>
    </li>
  </ul>

RuHL will find and use instance variables

Building on the previous example, before 1.3.0 RuHL would require users to be a method in scope. So if you had a controller method that created @users (like most people do), RuHL wanted a users method like so:

  def users
    @users
  end

While most think this is absurd, from a processing perspective this is more efficient, e.g. RuHL doesn’t have to look for instance variables in the scope. However this really annoyed some people. So, RuHL (by default) will now look for @users and use the instance variable.

Also by default, RuHL will log a warning letting you know it is using @users. You can turn off this warning:

Ruhl.log_instance_variable_warning = false

Since looking up instance variables is slower, you can turn off this feature by setting:

Ruhl.use_instance_variables = false

I am working on new documentation that will be up this week.

Had a request to honor the filter_parameter_logging when Lockdown raises a SecurityError on an invalid request. Lockdown now filters the parameters to hide sensitive data.

Thank you for bringing it to my attention.

I think it’s safe to assume that Lockdown will not be compatible with Rails 3.0 and since I have yet to find an authorization system with the same centralized rules philosophy, I need to make a drastic change.

Unless someone finds a critical bug, I will not be maintaining Lockdown. There will be a new (as yet to be named) project.

Why the big change? The first version of Lockdown was written for a pre 1.0 Rails application. Over time, it has been through a lot of refactoring, two major ones. Even having done that, there is still code that was written when I was first learning Ruby and was heavily influenced by my years as a Java programmer. I think it can be a lot cleaner/simpler.

The new project will be rack based to adapt easily to future changes and make it easier for Sinatra integration. I have been doing a lot of work with Sinatra lately and only see this increasing.

I’m not sure about the model level restrictions. I am not, nor was I ever, happy with the model level restriction functionality in Lockdown. Using it wasn’t intuitive and it’s implementation lacks intelligence . I’m not calling anyone out here, I wrote it and I think it sucks.

The idea of a centralized rule file will still exist in the new project. Therefore, converting your existing Lockdown based app to the new authorization system will only require a conversion of init.rb. I will be simplifying the dsl similar to this suggestion.

Unlike Lockdown, testing and documentation will be of equal importance to the code itself.

If you want to keep up to date with the progress, please follow me on twitter. I don’t tweet a lot of non tech noise.

To those who use Lockdown, thank you! The next project will be better.

Just released Lockdown version 1.6.1! This version addressed an issue with the rspec_helper introduced in 1.6.0. Essentially, since 1.6.0 introduced lazy loading, the init file wasn’t being parsed. So, when you include Lockdown::RspecHelper in you spec_helper, it calls Lockdown.maybe_parse_init to initialize the system for you.

I also fixed the mock_user method in the rspec_helper to stub out user_groups as an empty array. Was getting message ‘Mock :user received unexpected message :user_groups with (no args)’. Not any more.

Big usability release! Lockdown 1.6.0 is all about you, the developer. Tired of restarts? Tired of logging out to reset the session? Well, no more!

When Rails.configuration.cache_classes is false (development mode), Lockdown will reload the init.rb file on every request. In addition, the access_rights will be reset on each request. This means if you change public access rights in init.rb you don’t have to logout to have Lockdown apply the change. Slower, yes, but easier to work with when you are in heavy development.

This is a pretty big change, please run through your tests before promoting to production.

As always, constructive feedback is always welcome.

If you use Lockdown, a vote on RubyTrends would be appreciated. Knowing you took the time to cast your vote means a lot to me.

thanks,
andy

Hot off the gemcutter: Lockdown version 1.5.0

First off, you didn’t miss anything, version 1.4.0 wasn’t actually released. Just before pushing the gem to gemcutter I decided to make an improvement to the set_user_group logic. I felt the need to make it a bit smarter and let you know if you were assigning a public or protected user group to a custom user group.

So here’s what’s in this release:

1) Delayed the parsing of init.rb to the first request. I had a report of Glassfish timing out on startup and other issues when running running db:migrate with some plugins.

2) Improved set_user_group method logic to detect reuse of public or protected permission.

I know there are a couple of other issues on the lighthouse account and I will get to them when I can.

thanks,
andy

I’ve just released Lockdown version 1.3.2.

Lockdown is now being served up from gemcutter.org.

In this update:

• Lockdown will now report if permission belonging to public or protected groups is being assigned to custom user group.
• New rspec helper: login_with_permissions(*permission_symbols)
• The use of “puts” within Lockdown has been removed for all you Textmate users out there. :)
  • To have Lockdown use Rails.logger, just set Lockdown.logger = Rails.logger in config/environment.rb.

I’ll be tackling some of the other items on lighthouse next week. This week had some surprises that didn’t allow any extra time for Lockdown.

Update: RuHL has grown up a lot since this post. Please visit github for the README. I will be moving the docs here shortly.

Outdated:
I’m pleased to announce my new project Ruhl (Ruby Hypertext Language). Ruhl makes HTML dynamic with the addition of a ‘ruby’ attribute. It supports rendering with layouts and partials.

Simply put, Ruhl parses the HTML (with Nokogiri) and looks for the ruby attribute. It then executes the methods within the context of the calling environment. A simple call looks like:

  <h1 ruby="page_header">My default header</h1>

A call to process a Ruhl template looks like:

Ruhl::Engine.new( File.read(path_to_file) ).render(self)

The contents of the h1 are replaced by the results of the page_header method.

The idea is to avoid transforming the HTML into another language and make the designer’s job easier. If they need to go back and modify their work they don’t need the assistance of a developer.

Think Presenter pattern for the dynamic code aspect.

Checkout the github project for examples. There is Sinatra support, just require ‘ruhl/sinatra’ and you can use something like:

  get '/' do
    ruhl(:'layouts/application')
  end

This project is VERY young (just thought of the idea 4 days ago), so let me know what you think it needs to grow and improve.

I’ll be putting this to real world use in the next few weeks and will document various use cases/patterns as I discover them.

How to patch production code:

  # Grab the current production code
  git checkout -b name <tag|sha>

  # Update your code with the commit that will fix your problem.
  git cherry-pick <sha>

  # Show difference.  This is a review step.
  git diff <tag>..

  # Run your tests...

  # Create a new annotated tag
  git tag -a <tag name>

  # Push the new tag up so you can deploy it
  git push --tags