HTTPS in local development environment (with subdomains, stunnel and [optionally] pow and [bonus] iPad)

In every web developer's life there's a moment your baby wants to go secure, and this means putting your web app on HTTPS. That is, simply put, adding SSL on top of everything. Sounds simple? Well it should be. For production/staging solution you should read your own app hosting provider's docs, e.g. SSL Endpoint | Heroku Dev Center. And for your local dev env, read on (well if you're on OSX or *nix at least).

First, I've found no reason not to use pow, both for same-machine (via http://somesub.yourbaby.dev) and same-network (via http://somesub.yourbaby.192.168.1.111.xip.io) testing.
Tip: even if you don't fancy pow, and use different ports for running stuff instead, you can still use this technique with http://somesub.lvh.me:3000 (same-machine, resolves to 127.0.0.1:3000) or http://somesub.192.168.1.111.xip.io:3000 (same-network, resolves to 192.168.1.111:3000), somesub being any subdomain.

Then, we're going to use stunnel to put that SSL on top of our fine-running web app. So, I've compiled a little script to automate the stunnel certificate + configuration generation, here it is (any patches/comments are welcome). Install/copy it somewhere, then go to your project's directory and run:

stunnelo.sh yourbaby.192.168.1.111.xip.io

Hopefully, it will produce all the necessary files in ./var/stunnel/yourbaby.192.168.1.111.xip.io/

Finally, you may run (in a dedicated terminal window):

stunnel var/stunnel/yourbaby.192.168.1.111.xip.io/stunnel.cnf

then hopefully go to https://anysub.yourbaby.192.168.1.111.xip.io and see your same old app running in total security.

Wait! In a moment you'll notice your browser not being happy about the certificate we've just created, so here's a...

Bonus:
The self-signed certificates this technique creates are obviously will not be trusted by any browser on any device by default. This will get even more messy if your app involves a number of services you're running in the same dev env.
For computers, a browser will usually allow you to install the certificate in question when it sees it, so you will be annoyed just once. For iPads/iPhones — that's what same-network testing is for — you will have to take var/stunnel/yourbaby.192.168.1.111.xip.io/stunnel.crt and mail it to yourself, then open the attachment on your iPad and that's how you install the certificate there and go debugging.
Obviously, you can have any number of such stunnel configs in ./var/stunnel/ — go wild with the domains you are to test.

p.s. I've tried to use tunnels, but it provides no means of control over the certificates and thus, complicated scenarios bring... uh... complications.
p.p.s. Thanks go to xip.io-cert for outlining self-signed certificate generation.

rails 3.2+ controller specs helper for extracting a model object's accessible attributes

put it in spec/support/accessible_attributes.rb

subdomains in rails apps: a current brief

Subdomains (or second level domains) are still a nice way to present separate interfaces to a single web app — commonly to give a certain kind of customers the feel-n-touch of a dedicated app install.

Here are most of the related aspects based on a particular Rails3 project:

• some model Group, representing a customer, or rather a group of users, has a string column domain (migration not shown, but don’t forget to index by that column)

  in app/models/group.rb:

  has_many :users
  before_validation :downcase_domain, :if => :domain_changed?
  validates :domain, presence: true, uniqueness: true, length: {maximum: 255}, format: /^[0-9a-z-]+$/
  
  
  def host
    "#{domain}.#{ROOT_DOMAIN}"
  end
  
  
  protected
  def downcase_domain
    self.domain = domain.to_s.downcase
  end
  

• under assumption that you’re using devise and your (group’s) user identity model is User (updated for everchanging devise 2.0.4)

  in app/models/user.rb:

  belongs_to :group
  devise :database_authenticatable, ..., :request_keys => [:app_subdomain]
  
  
  def self.find_for_authentication(conditions={})
    group = Group.find_by_domain(conditions.delete(:app_subdomain))
    return nil unless group.present?
    conditions[:group_id] = group.id
    super
  end
  

• you’ll have some admin interface where the groups are managed (e.g. active_admin, not recommended)

  in app/admin/groups.rb:

  link_to group.domain, root_url(host: group.host)
  

• you will certainly want to do something specific in config/routes.rb

• you’ll want some handy helper method, to know which guvnor you’re serving

  in app/controllers/application_controller.rb:

  helper_method :current_group
  def current_group
    return @current_group if defined? @current_group
    @current_group = request.app_subdomain && Group.find_by_domain(request.app_subdomain)
  end
  

• you’ll need an initializer of some sort to set a constant and monkey-patch the request class, so…

  in config/initializers/subdomain.rb:

  ROOT_DOMAIN ||= ENV['ROOT_DOMAIN'] or raise "ROOT_DOMAIN must be set"
  
  
  # (): paranoid monkey patching :()
  class ActionDispatch::Request
    def app_subdomain
      return @app_subdomain if defined? @app_subdomain
      @@app_hostname_regex ||= /^(?:([0-9a-z-]+).)?#{Regexp.escape(ROOT_DOMAIN)}$/
      raise 'Wrong domain' unless host.downcase =~ @@app_hostname_regex
      @app_subdomain = $1
    end
  end
  

• then, for your production (and staging) environment on, say, heroku, you’ll have to setup your lovely app domain name (with wildcard subdomains) and set the environment variable ROOT_DOMAIN to it

• for test environment, which is also good for the handy circleci

  in config/environments/test.rb:

  ROOT_DOMAIN = 'lvh.me'  # yes, it's a magic domain for 127.0.0.1 //smackaho.st RIP
  

• for other environment cases, be sure to set either ROOT_DOMAIN or ENV['ROOT_DOMAIN'] as appropriate

• if you use factories (and girls, factory_girl)

  in spec/factories.rb:

  factory :group do
    sequence(:domain) {|n| "dom-#{n}"}  # or better still, use `forgery` with some smart randomness
    ...
  end
  

• if you use capybara (2.0.0 at least, recommended) and rspec (rspec-rails 2.12.0 at least)

  in spec/spec_helper.rb: (in Spork.prefork block if you use spork, recommended)

  Capybara.always_include_port = true  # unless you `visit` external sites in your feature specs
  

  and then in some spec/features/..._spec.rb:

  visit("http://some_domain.#{ROOT_DOMAIN}/some_path")
  # or
  visit(some_url host: @group.host)  # if you're playing dirty, using pre-fabricated data and route helpers, recommended
  

• in some spec/controllers/..._spec.rb you’ll have to include something like this:

  before(:each) do
    request.host = @group.host
  end
  

• don’t forget the specs for domains in spec/models/group_spec.rb and other relevant places

May your sub-domains be obedient to their master.

app cache manifest should be public

As a rule of thumb, as of today, if you don't want trouble, make your HTML5 application cache manifest publicly accessible.

clothing labels hell

One of the things that have been annoying me for years — not Google, but rather vaguely related to the information technologies — are the clothing labels.
They are mostly made of highly skin-irritating fabric, and they tend to outlive any piece of clothing they are super-securely attached to.

Why???

Buggers Must Die

It is somewhat pathetic to criticise Google, a company which always strives to do what's best for us simple people — for free!
But.
I think they've just crossed the line with the “New Gmail Look”.

BTW, I hope you understand the irony of the first line: I really don't think I must feel obliged for their “free” email service — however good and accessible it is; quite the contrary, I feel I'm contributing to Google an irreplaceable and precious source of real-time information — the stuff the most world's (and certainly Google's) money comes from.

Personal opinions and tastes aside, the New Gmail Look is effectively incompatible with Mozilla Firefox — I know nothing of its compatibility with the new “good” Internet Explorer, unfortunately — and is clearly (cleverly) targeted for Google Chrome. To be clear, Gmail is functional in FF, but its CPU consumption there makes the combination unusable.
This is not something new or unexpected, both FF and Gmail have undergone development with this problem known — there are discussions, bug reports and blog posts like this one all over the internets — and I've been hoping a solution will be found before the New Look would become the only look, but alas, ah-ah, nope. At this moment, I have my peaceful internet existence violated and I feel forced to use the Chrome: Safari is also okay wrt Gmail, but it hasn't got nearly as much plugins as Chrome or especially Firefox have, so not much choice for a single-browser setup.

I don't think it's a fact to be taken lightly. I see something much worse than Microsoft coming, and I personally will now always try not to use Google products as the first option. Luckily, most alternatives to Google products actually outperform the latter.

Erm, yes, this blog will also be moved to a different provider in the nearest future.

p.s. Unrelated, kudos to Apple for making the choice of English flavour finally available system-wide. Alleluia!

google trance-laid he-brew

It's always fun to see automatic translation, but watching google trying to translate Hebrew is twice as fun: modern-day residents of the holy land don't use diacritics (= no vowel signs), the language does not have capital letters or much punctuation, and on top of that, Israeli names — both first and family ones — are very often just common words. Now you can imagine the level of ambiguity linguistic tools have to deal with here. And I have not even mentioned the abundance of foreign words which sometimes make writing hard to comprehend by even a native human reader.

pow, guard and rdebug - staying in the web app dev env heaven: for ruby 1.9 only

The new version (for ruby 2.1) is here.

If you, like me, use pow and guard (with spork of Rails 3 standard setup) for the perfect web app development environment, you might have stumbled upon a problem of debugging the server with rdebug -c which tends to connect to a wrong process even when working on just one project (and that's because spork itself starts the remote debug server by default).

So, firstly, you will probably want to limit your server instances run by pow to 1 by
echo export POW_WORKERS=1 >> ~/.powconfig

Then, to actually enable remote debugging you should place the following in your ./config/environments/development.rb:


And finally, to set the port of your choice for the project,
echo export RUBY_DEBUG_PORT=10007 >> ./.powenv

Now, you are welcome to
touch tmp/restart.txt
and (after a bunch of your CPU's cycles)
rdebug -c -p 10007

You're back in heaven, have a happy stay!

>>~/.bashrc (yet another update)

An update of mines!: >>.bashrc (update):

>>~/.bashrc (update)

An update of mines!: >>.bashrc:

This is a drop-out replacement for cd:
0) pd DIR == cd DIR (plus push to the shell's dir stack, plus store DIR as LAST_DIR)
1) pd == pop a dir from the stack (the shell's BACK button)
1.1) if none, pd LAST_DIR (useful for new shell sessions after pd DIR or pd . in an old one)

p.s. Thanks to Vitaly@astrails for the idea on improvement.
p.p.s. fixed!

Time-buffered WUI update /javascript

When it comes to UI (and it naturally comes to js), there often are routines that you would like to perform on a certain event, but not necessarily on each such event, that is, just enough to keep a view updated at most times.
For instance, there are items being added to a sorted list: you'd like to sort the list whenever a new item arrives, but when a bunch of items arrive at once (over a short period of time), you'd like to postpone sorting to the last item in the bunch (for obvious reasons). And you want to keep things simple and refrain from event queuing, optimizing the sort routine and other complex stuff.
Well, in that case, something I call time buffering may help you. If your event handler looks like this:

function _onNewItem(item) {
 _addItem(item);
 _sortList();
}

With time buffering it'll look like this:

function _onNewItem(item) {
 _addItem(item);
 _timeBuffer("sort_list", _sortList, 500, 2000);
}

Not much of a change, eh? And the killer routine?

I'm sure you can fix my style (you're welcome) and add support for removing such list elements -- and associated actions -- cleanly (with something like function _timeBufferNoMore(act)), but you get the idea.

the boolean virtual attribute's gotcha (a checkbox in a rails form)

I am not sure where to post this, suggestions are welcome.

Whenever you create a virtual boolean attribute in your model, e.g.

attr_writer :some_boolean
def some_boolean; defined?(@some_boolean) ? @some_boolean : true; end  # defaults to true
attr_accessible :some_boolean

And make it a checkbox in the model's input form, e.g. (simple_form, haml)

!= f.input :some_boolean, :as => :boolean

And try to do some reasoning with it, e.g...

after_create { ... if @some_boolean }

You may be surprised as @some_boolean will always resolve to true (actually to 0/1, but both are true in Ruby).

A quick and dirty workaround would be... well... getting your controller dirty quickly:

before_filter :boolean_fix
...
def boolean_fix
  params[:some_model][:some_boolean] = false if params[:some_model] && params[:some_model][:some_boolean] == '0'
end

acts_as_taggable_on meets thinking_sphinx on rails (and nearly misses it)

Beware, for reasons unknown, instead of
indexes tags.name, :as => :tags
you have to write
indexes taggings.tag.name, :as => :tags
or you'll get too many results.

jQuery autoSuggest vs rails (and acts_as_taggable_on)

While AutoSuggest is quite wonderful as it is, there's also a lot of room for improvement (e.g. I've started using this fork since the original author doesn't seem too community-friendly).

Here's one tip on how to use it with rails (and simple_form) — or rather how to workaround the following issue.
When you write something like $("#post_tag_list").autoSuggest(...); for the first time, you'll expect AS to do all the wow stuff on the client side and have the original input field with the values as a parameter back on the server side, right?
Well, I did.
Unfortunately, you have to work harder: not only you must include the asHtmlID: "tag_list" option in the autoSuggest parameters, but (since that option actually defines the id's suffix only) you'll have to patch your controller allong the lines of:
before_filter :autosuggest_fix
and
def autosuggest_fix
params[:post][:tag_list] = params[:as_values_tag_list] if params[:post]
end

a jQuery templates tip: checking for optional fields

One tip regarding the templates

“Comments for this page are closed.” for some reason, so here:
When rendering an optional numerical field, the safest way to check on its existence is:
{{if typeof $item.data.optional_field == "number"}}...{{/if}}
(for other types, change the right side of the == accordingly)

The main problem with the way described in the doc is possible accidental name collision of the field's name with some other variable in the scope.