JarrodSpillers.com

At the start of the fall semester I began a continuing education class at the New York School of Visual Arts - Advanced Metalworking. The goal for taking this class is to construct a 11-12th century Norman helmet for use in full contact western martial arts in the SCA. I am beginning this post over a month into the class as much of the initial class time was spent honing skills and techniques needed for smithing.

I began actual work on the helmet by creating a pattern with the help of my amazingly talented instructor/master armorer Jeff Wasson. Here we see a portrait/profile diagram of the helmet I am attempting to create.

And a cross section looking down from the top… the outer ring is the rough line of the helmet, the inner ring is a cross section of my head.

The first step was to cut out two identical helmet halves… these are two football shaped sections of 12 gauge mild steel. Using a paper pattern I marked the cutting guides on to the sheet metal. Cutting the sheet metal with a hand operated plasma cutter is quite satisfying… reminds me of the tool they used in the movie “Aliens” to both cut and seal the big bulkhead doors.

After rough cutting with the plasma cutter I used an angle grinder and then a belt sander to hone in the shape and de-burr the edges. I also gave each of the two halves an initial bend using a very large hammer and working the steel cold. Here is one of the two halves ready for shaping:

Working mild steel with hammer and anvil cold is certainly possible, but heating it up makes it so so much less work. Fortunately the SVA metal shop has a big furnace for just this purpose.

Starting to get nice and hot…

The next step is to quickly pull the helmet half from the heat and dish the metal into a bowl shape using a hammer and a dish shaped tool set into an anvil. You have to work quickly as the metal cools off very fast!

This is after a few rounds of heating and dishing… we can see the half starting to take shape…

Here is one of the conical sections that is nearly finished…

Here are both halves together for reference… still a bit of work left in getting the rough shapes correct, but its getting there!

The workshop:

Still much left to do on this project… I will continue to update this post as work continues!

UPDATE  12/17/08

My original plan was to update this post as I progressed, but despite my best intentions I am now updating only after having finished the entire project.

…After more heating, shaping, hammering, bending, etc I managed to get the two halves close enough to the desired shape to then weld them together. Just before welding I realized that there is a very good reason you don’t hammer sheet metal too heavily when cold - it WILL crack. One of the halves, much to my dismay, had a massive series of cracks right in the middle where it needs to be the strongest. I did end up having to make a new piece from scratch but it taught me a valuable lesson about the nature of steel.

When steel is cold its molecules are interlocked and non-uniform which provides strength and flexibility. When cold steel is bent or hammered it’s molecules begin to line up in a more uniform pattern known as “work hardenening”. Once steel becomes hard from overworking it becomes very brittle - the same behavior can be seen by bending a piece of metal back and forth until it snaps. When heat is applied to metal it causes the steel to move around on an atomic level. This allows you to work and shape it not only more easily, but without fear of hardening and breaking the metal.

The last step before assembly is called planishing. Basically you take a much lighter weight hammer and take out all the peaks and valleys in the surface of the shaped metal. This is done either from the “inside” of the metal with the finished side resting on the anvil or by striking the finished side with the “inside” resting on a concave surface that matches the basic shape of the metal being planished. After much tweaking here is the final two helmet halves ready to be welded up.

And then after welding and a little grinding:

The next step is to take down the weld seam with an angle grinder and then, using a belt sander, remove the hammer marks and any peaks or valleys left in the metal that were not taken care of during planishing. The belt sander is a life saver… here it is in all its glory:

After finishing the top part of the helmet I went about cutting out the remaining pieces using the plasma cutter and a little bit with the Beverly shears (basically giant scissors for sheet metal). At this point in the project I neglected to take pictures due to being in a rush to finish before the end of the semester, but here is the result of a ton of measuring, cutting, hammering, grinding, welding, sanding, and sweating.

The final stage of construction was the attachment of the bar grill. For the type of combat I do a bar grill is crucial… getting hit in the face with a big piece of rattan will ruin anyone’s day. I assumed that this would be one of the more difficult parts of the project, but it really turned out to be quite straight forward thanks to Jeff’s experienced eye helping me set the pieces and get the spacing correct.

We started by first tacking on 1/4 inch bar stock to the cheek flaps and then adding the bottom most horizontal bar. After letting the welds cool down I then tested that a) I could get the helmet on still and b) that the bar grill extended down far enough to provide sufficient protection to the throat. After being satisfied with the position of the first pieces we attached the main vertical bar that runs down the center of the entire face opening.

Here is Jeff helping me get the bars tacked in place:

After the main middle piece was set, attaching the remaining bars was a slightly tedious, but fairly easy job. Here we are with just a few vertical bars left to be attached:

After finishing the bar grill I attached the decorative nasal piece and put some rivets into the band that overlaps the top and bottom sections (also decorative).

To call the helmet finished I spent many hours doing many different types of grinding and sanding in order to get a nice satin finish.  Pictures of the finished product soon to come!

Last week a ran into a bit of an issue trying to write Rspec Stories for the app I am working on. The app in question depends on a remote service based authentication system. Creating “test” users on a remote user authentication service already running as production for other apps was not really an option. Getting around this proved to be problematic as Rspec Stories entire point is to test the “full stack”.

Seeing I had no alternative and really just needed to sidestep authentication here, my first instinct was to try to directly set a user id in a session object:

Story "a fantastic story", "blah", :type => RailsStory do
  Scenario "a user does stuff" do
    Given "logged in as a user 'someone'" do
      @user = User.find_by_login('someone')
      session[:user] = @user.id
    end
    Then "all my tests pass and we live happily ever after" do
      get "/users/#{@user.id}"
      response.should be_success # login is required here... FAIL!
    end
  end
end

This does not work as I had guessed. It turns out that the session object you have access to within an Rspec Story is NOT the same object as your actual controllers will look to when you run your story. I am sure there is some hackity way of prying open the Rails stack and modifying the REAL session object, but going down that road just didn’t feel right.

My next instinct was to pull in Rspec’s wonderful stubbing/mocking framework and just stub out all the authentication. Bringing mocking into Stories was as easy putting this in my story/helper.rb file

require 'spec/mocks'

We are using a heavily modified version of the restful_authentication plugin, so I just needed to figure out a way to stub #login_required to always return true and #current_user to always return whichever user we want to be currently “logged in”. The problem is that in a Story context we are dealing with potentially ALL controllers… and there really doesn’t seem to be a way to access instances of individual controllers until AFTER a request has been made. My next thought was to stub such that all future instances of ApplicationController would contain the stubbed version of the authentication methods. Im sure this is possible to do, but it also seemed incredibly messy.

This got me thinking: “why am i searching for these complex solutions… lets just do this the most simple way possible”…

In the context of restful_authentication all that needs to happen for a user to be “logged_in” is for the user’s ID to be set in a valid session. My solution for getting it there? Monkey patch in a fake login method that can be called within the story:

class AccountsController < ApplicationController
  def fake_login
    set_session_for_story(params[:login])
    redirect_to "/users/#{current_user.login}"
  end
end
class ApplicationController
  def set_session_for_story(login)
    self.current_user = User.find_by_login(login)
  end
end

Story "a fantastic story", "blah", :type => RailsStory do
  Scenario "a user does stuff" do
    Given "logged in as a user 'someone'" do
      create_a_test_user(:login => 'someone')
      post "/sessions/fake_login", :login => 'someone'
      response.should be_redirect
    end
    Then "all my tests pass and we live happily ever after" do
      get "/users/#{@user.id}"
      response.should be_success # login is required here... SUCCESS!
    end
  end
end

This is the simplest way I could come up with for causing the Rails app itself to set the proper user into the session rather than trying to peel back the layers of the app running within the story and manipulate the correct session object directly or trying to deal with stubbing/mocking instances of objects that hadn’t yet been created.

I then took this little bit of hackity and moved it off into another file (/stories/fake_login.rb) so I could then just require it in any story where I needed an authenticated user.

By now most Rails developers have come to know and love (or not?) RESTful resources and the controller code that implements them. For the most part Merb’s implementation of resources will be familiar and adheres to the same convention - GET safe creates, updates, destroys, a single base URI for a single resource, etc.

One small difference with Merb’s resources is in regards to the implementation of destroying a resource. In Rails you run into this weird situation where performing a destroy on a record via a browser is nearly impossible without relying on Javascript to create that ugly dynamic form that gets triggered by using the link_to method and passing “:method => :delete”.

<%= link_to "Delete Image", { :action => "delete", :id => @image.id }, :confirm => "Are you sure?", :method => :delete %>
# => <a href="/testing/delete/9/" onclick="if (confirm('Are you sure?')) { var f = document.createElement('form');
f.style.display = 'none'; this.parentNode.appendChild(f); f.method = 'POST'; f.action = this.href;
var m = document.createElement('input'); m.setAttribute('type', 'hidden'); m.setAttribute('name', '_method');
m.setAttribute('value', 'delete'); f.appendChild(m);f.submit(); };return false;">Delete Image</a>

Not ideal IMHO.

The other option in Rails is to create the delete link manually as a button or submit tag in its own little form - personally i use this approach because it is does not require Javascript to work, but I have never liked cluttering the DOM with tons of little forms.

Merb, has a different answer - one that tripped me up until I realized what was going on: use an intermediary page.

In Merb a GET request to /users/1/delete (with the users resource declared in the router) will route to the “delete” method in the users controller. The purpose of this page is exactly the same  as the “new” and “edit” methods - to provide an HTML form to someone (or something) interacting with the resource via a web browser. The idea is that in a non-Javascript world  you can still implement an “are you sure?” type confirmation AND get the added benefit of providing a GET safe destroy. If the developer would like to mimic the Rails inline javascript delete form style html link it is trivial to do so, but with the added benefit of graceful degradation (ie: still works without javascript).

The ideal solution in my humble opinion is first implement the full delete page with destroy html form and “Are you sure?” confirmation message and then after that is working (and tested). Next you would implement an Ajax destroy button that posts a DELETE request and will be routed directly to the destroy method in the controller. This way you get a great user experience when using a fully featured web browser, but are still able to use the app if you happen to not have javascript.

you bastard!

So its finally official… I am headed out to RailsConf in Portland, OR next week!

Thanks to my good friend and mentor Jerry Jackson forcing me to practice every day until I grew to like it, I am a die hard VIM user. To me it is just a much faster way to write code and edit text in general.

Once upon a time I was suffering from repetitive stress injuries to my mouse hand from long hours of 3D modeling and graphic design. Once I started to move away from the creative side of things and more to development (and thus using VIM regularly) that all went away.

Several weeks ago I began a new project here at my day job. For reasons of practicality I have been forced to deal with the evils of a more traditional IDE. The IDE in question is Visual Studio .NET (don’t get me started on how much I hate .NET – I will save that for a much longer and more thorough article).

Earlier today I noticed the all too familiar discomfort and tightness in the connective tissues of my wrist. The constant in all of this is the percentage of time I am using my mouse. The mouse is just VERY bad for your hands and wrist. With VIM you rarely leave the home row… the mouse becomes “that weird thing on your desk that you don’t use anymore”.

Hopefully I will be done with this project soon and be able to move back to some Rails projects where I can be back at home with a text editor that doesn’t hurt to use. Yet another compelling reason to stick with that archaic, esoteric old thing known as VI improved!

The situation: A class, it’s descendant, and a module included in the parent class all have a method of the same name. Calling super from the child’s method causes a call to the parent class and not the module…

module Something
  def foo(&block)
    puts "Hello Module,"
    yield
    puts "Goodbye Module... it was nice knowing you. "
  end
end

class ParentFun
  include Something

  def foo(&block)
    puts "Hello Parent,"
    yield
    puts "Goodbye Parent.. it was nice knowing you"
  end
end

class ChildFun < ParentFun
  def foo
    super do
      puts "I am a Child."
    end
  end
end

ChildFun.new.foo #=>
# Hello Parent,
# I am a Child.
# Goodbye Parent.. it was nice knowing you

Now put the module include in the Child class instead of Parent.

module Something
  def foo(&block)
    puts "Hello Module,"
    yield
    puts "Goodbye Module... it was nice knowing you. "
  end
end

class ParentFun
  def foo(&block)
    puts "Hello Parent,"
    yield
    puts "Goodbye Parent.. it was nice knowing you"
  end
end

class ChildFun < ParentFun
  include Something

  def foo
    super do
      puts "I am a Child."
    end
  end
end

ChildFun.new.foo #=>
# Hello Module,
# I am a Child.
# Goodbye Module... it was nice knowing you.

Interesting.

• Requirements and Dependencies

  1. svnmerge.py - a python script that helps you keep your branches in synch with the trunk. The script and full documentation are available at http://www.orcaware.com/svn/wiki/Svnmerge.py
  2. define a bash variable of the svn path ($TIS_SVN_URL in this case)

• Creating the branch

  1. stop your development server
  2. commit any outstanding changes to the trunk
  3. copy the trunk to a branch

     svn copy $TIS_SVN_URL/trunk $TIS_SVN_URL/branches/branch-name

  4. switch over to that branch

     svn switch $TIS_SVN_URL/branches/branch-name

  5. initialize the branch

     svnmerge.py init

  6. commit:

     svn commit -F svnmerge-commit-message.txt

• Working with the branch

  1. stop your development server
  2. occasionally perform svnmerge.py merge to keep in sync with the trunk

• Merging branch back into the trunk

  1. stop your development server
  2. with a clean branch switch over to the trunk:

     svn switch $TIS_SVN_URL/trunk

  3. check properties on trunk for any merge stuff:

     svn proplist -v .

  4. Initialize the merge tracking support on the trunk, related to the given branch, using:

     svnmerge.py init $TIS_SVN_URL/branches/alpha02-dashboard

  5. commit:

     svn commit -F svnmerge-commit-message.txt

  6. update
  7. merge:

     svnmerge.py merge --bidirectional -S $TIS_SVN_URL/branches/alpha02-dashboard > merge_log.txt

  8. check merge log for any conflicts
  9. resolve any conflicts
  10. rake test
  11. commit:

      svn commit -F svnmerge-commit-message.txt

  12. svnmerge.py uninit -S $TIS_SVN_URL/branches/alpha02-dashboard
  13. commit:

      svn commit -F svnmerge-commit-message.txt

  14. svn rm -m ‘removing branch’ $TIS_SVN_URL/branches/alpha02-dashboard

First of all – what the heck is a “pipe”? The character referred to as a “pipe” (|), in Linux, Unix, or OSX, is used for redirecting the output of one terminal command into another (ex: ls | grep “something”). It is also very commonly used, albiet only for presentation, to delimit individual items of a site navigation or other menu. By now, any professional web developer knows that a menu of any sort belongs inside our good ole friend the unordered list. I won’t go into the benefits of using semantic markup here, but I do want to share my technique for achieving this very common menu style without adding any extra markup or unnecessary characters.

One technique used for achieving this is to put the | characters into the menu directly:

<ul>
  <li><a href="http://rubyonrails.org">Ruby on Rails</a></li>
  <li>|</li>
  <li><a href="http://w3.org">Web Standards</a></li>
  <li>|</li>
  <li><a href="http://ie7.com/">Hilarious</a></li>
  <li>|</li>
  <li><a href="http://jyte.com/">Fun for Geeks</a></li>
  <li>|</li>
  <li><a href="http://www.prototypejs.org/">Javascript is cool now</a></li>
</ul>

With this structure one need only display each list element as inline and give them some padding and the result will be the desired pipe separated menu. While this is more semantically correct than using a table or just putting everything in one element in a linear fashion, it is not as correct as it could be. Our markup should instead look like:

<ul>
  <li><a href="http://rubyonrails.org">Ruby on Rails</a></li>
  <li><a href="http://w3.org">Web Standards</a></li>
  <li><a href="http://ie7.com/">Hilarious</a></li>
  <li><a href="http://jyte.com/">Fun for Geeks</a></li>
  <li><a href="http://www.prototypejs.org/">Javascript is cool now</a></li>
</ul>

The pipe separator will need to be a background image (as any purely presentational image element should be). Take a screen shot of the pipe, or which ever character you want to delimit your menu with, slice it out, and save it to your images directory.

The next step is to add in some css class selectors to identify the first element in the menu and the last.

<ul>
  <li class="first"><a href="http://rubyonrails.org">Ruby on Rails</a></li>
  <li><a href="http://w3.org">Web Standards</a></li>
  <li><a href="http://ie7.com/">Hilarious</a></li>
  <li><a href="http://jyte.com/">Fun for Geeks</a></li>
  <li class="last"><a href="http://www.prototypejs.org/">Javascript is cool now</a></li>
</ul>

With our finished markup in a clean and lean state we can move on to styling it up with some css. We are first going to apply the styles necessary to get the nav to display horizontally. The “display:inline” property is responsible for removing each LI from the document flow and causing them to line up side by side. Setting the width of each li is a must for this to work. I then apply some left and right padding to separate the menu items. I have chosen to use em’s as my unit for padding, margin, etc, but declaring exact pixel values is still perfectly fine.

.nav li {width:auto;margin:0 auto;display:inline;padding:0 1.5em;}

To this same style I also add in my pipe background image. The tricky part here is getting the image to line up correctly with the text. To do this you will need to fiddle with the background-position offset values as well as aligning the background right. On the vertical offset a value of 0.5em seems to work well across most browsers.

.nav li {width:auto;margin:0 auto;display:inline;padding:0 1.5em;background:#ccc url(/images/pipe.gif) no-repeat 0 0.5em;}

The final ingredient in this recipe is addressing the first and last menu elements. For the left most item we need to clear left padding and for the right most element we need to clear… you guessed it – right padding. We also have an extra pipe floating around on the first element. We take care of all this like so:

.nav li.first {padding-left:0;background:none;}
.nav li.last {padding-right:0;}

That’s pretty much it! Works very well on all the major Windows and Mac browsers. For a look at the final product I have thrown together a very primitive example of the menu for your viewing (and copying/pasting) pleasure.

PS – In case you were thinking hey why does this moron put all of his css styles on a single line?, you are in luck! My method for organizing and formating css just happens to be the topic of my next article.

Disclaimer: The following technique is nothing particularly new or cutting edge. This is simply something I often use and should be considered a “best practices” article for those concerned with web standards and accessibility.

Gone are the days of the table based layout… days where CSS, if used at all, would simply be a replacement for the notorious font tag. In this day it is very common for a stylesheet to contain many times more line of code than its corresponding XHTML document. Part of the challenge of writing good CSS is not just learning the correct properties to use, but formatting and organizing your document in a way that allows for easy maintenance and speedy display bug fixes.

Hit the reset button!

I typically start my CSS file by including the yahoo ui reset css file which does a very thorough job of clearing out of of the default stylings. This is extremely important to do so that you know that any styles affecting a given element are going to be found in your CSS document and not a bi-product of some default padding, margin, etc.

Organization of rules

I like to keep my css rules in a consistent order. My basic structure is to separate positional rules (columns and other containers that comprise the grid of page) from formatting rules (the more granular stylings). Here’s the rundown:

• Global Styles (body, lists, strong, etc)
• Headings (h1, h2, etc.)
• Text Styles
• Position/Grid layout
• Forms (which can be a mixture of layout and formatting)
• All other format rules (grouped logically and in as linear a fashion as possible)

Formatting of rules

The vast majority of stylesheets I come across when analyzing the construction of a website employ the more traditional formatting of putting each rule on one line.

h2 {
  padding: 1em;
  margin: 1em;
  border-bottom: 0.01em solid #b2b2b2;
}

This is indeed very readable and clean, but another method for formatting your CSS rules is to put the selector, block, properties, and values all on one line.

h2 { padding: 1em; margin: 1em; border-bottom: 0.01em solid #b2b2b2; }

This keeps the actual line count of your CSS document drastically reduced and makes for easy vertical traversing of your rules. The next technique to throw into the mix is to represent the “cascading” of your rules by appropriately tabbing descendents (use 2 space tabs). This one subtle addition to your CSS document will drastically improve the speed at which a single rule can be located, regardless of the size of the document.

#Masthead { background:#3d3e38; width:100% }
  #Masthead .topNav { width:57.6em }
    #Masthead .topNav li a { color:#656c4a }

The downside to this approach is that it does take some getting used and you are trading a very tall document for one that is very wide. Personally I have no issues with long lines of code as my text editor of choice, VIM, allows me to move rapidly no matter how big or small the individual lines are.

To keep each line as consistent as possible, and to help negate the reading difficulty that single line rules introduce, I try to stick to a consistent ordering of my properties as such:

1. width
2. height
3. padding
4. margin
5. float
6. border
7. display
8. background
9. font stuff (i try to keep these in their own rules, but sometimes you need to override something)
10. everything else

My rationale for this is that I want everything that affects the box model to be front and center. Things that apply only to the look and feel of an element or tag are generally of lesser importance when I am hunting down some weird IE issue or what have you. I am sure many other developers could come up with reasons for ordering the properties differently, but the important take away here is just to pick an ordering scheme and get used to using it – your productivity will increase.

ID’s vs Classes – when to use what?

The simple answer to this questi0n is: Use IDs when there is only one occurence per page. Use classes when there are one or more occurences per page.

ID’s are mainly used to identify layout structures and other strictly positional elements. Classes are used to describe an elements look and more granular characteristics that may be reused in other places within a page.

When it comes to actually using classes and IDs I prefer capitalized + camel case:

#FooBar

For classes I do something similar, but I don’t capitalize them:

.fooBar

This is fairly nit-picky, but I feel very strongly about using conventions. The important part is just to be consistent.

Flags

As pointed out in an article on stopdesign concerning css organization, flags can be a very useful way to move around a large document. Quite simply it is a method of labeling each of your rule sections with a unique identifier in a comment block. Using your text editor’s find feature, you can then jump directly to a section rather than trying to scroll or page up/down and visually locate it.

/* =HD Masthead
----------------------------------------------- */
#Masthead { background:#3d3e38; width:100% }
  #Masthead .topNav { width:57.6em }
    #Masthead .topNav li a { color:#656c4a }

A quick find on ”=HD” will land you exactly where you need to be to update your sites header rules (or “Masthead” as I like to call it since “head” implies something different in HTML terms).