One thing that always annoyed me about Ruby's enumerable methods is that they are very partial toward arrays. Sure, they play nicely with hashes or any instance that is setup to work with Enumerable, but still - hash goes in, array comes out.
I had the challenge of wanting to perform operations on the values of a given hash, and easily return a hash with just the values transformed. So I created a Hash method called hashmap.
class Hash
# Translate the keys/values of a hash and return a new hash
# {:one => 'one', :two => 'two'}.hashmap { |k,v| [k.to_s.reverse, v.upcase] } # => { 'eno' => 'ONE', 'owt' => 'TWO' }
def hashmap(&block)
inject({}) do |hsh, (key, value)|
arr = yield(key, value)
hsh[arr.first] = arr.last ; hsh
end
end
end
Enjoy!
Even some really great developers far superior to me make mistakes, I discovered. I was browsing through Github today, and came across the following:
def is_hd?
if self.is_hd == 1
return true
else
return false
end
end
This wasn't by an amateur developer, in fact, this code comes from a really great Ruby developer (name withheld). The if condition, like any condition, is asserting something. The above is simply checking if is_hd is equal to the number 1. You know that, I know that.
By now you've discovered a pet peeve of mine. Why is the author of this code returning true if the condition evaluates to true? How should this code have been written?
def is_hd?
is_hd == 1 # obligatory dropping of self when not needed
end
When Ken Collins first told me he was running Apache locally for development, I was confused. I thought: wow, that sounds like a lot of unnecessary stack for a local environment. And without Passenger, I'd still think the same.
But our friends at Phusion have created a really awesome module for Apache. So awesome that I'm now willing to consider Apache after having seen the light that is nginx. Passenger spawns Rails instances on demand, and allows you to be freed of spawning mongrels, and best of all, no more combining multiple application route sets that have run on localhost:3000 in your browsers history!
After adding as many entries as you need into /etc/hosts, all that's left to do to free yourself of mongrel madness is to add the appropriate entries in Apache's configuration.
<VirtualHost *:80>
DocumentRoot "/Users/brennandunn/dev/oss/ozark/public"
ServerName dev.brennandunn.com
</VirtualHost>
Now I have a handful of entries in both my hosts file and Apache's config, and am able to quickly jump around between projects. Oh yeah, and if you have a lot of ActiveResource based applications that talk back and forth to each other, definitely consider this approach. You'll never look back.
One often overlooked problem with creating or updating records with form data is that blank parameters (form fields left blank) are stored in the database as empty strings upon mass assignment.
I see world of difference between nil values and blank strings, and a lot of my code depends on knowing the difference. This being said, one form post can wipe out all of your nil values and replace them with strings unless you're careful.
My favorite way of getting around this has been to reject blank values when I set attributes on an ActiveRecord object.
@user.attributes = params[:user].reject(&:blank?)
In this example, I'm getting rid of any key/value pairs in the user hash that have blank strings as values.
There are numerous ways of taking control of your form posts if you, like me, think that a nil value should mean "nothing's here, because nothing has been assigned", and strings should be reserved for substantive values. I was playing around with this snippet of code for setting default values of nil or empty strings which essentially just acts like Object#blank?.
class Object
def or(alt)
(respond_to?(:empty?) && empty?) || !self ? alt : self
end
end
''.or 'Default Value' # => "Default Value"
'Full'.or 'Do nothing' # => "Full"
''.or nil # => nil
I got the crazy idea to start out writing a blogging application. Sure, I could use Mephisto or Typo, but I wanted something even simpler. Something for one blogger (me). Something that doesn't use Liquid.
Ozark isn't meant to be robust and feature filled, but it's not meant to be screencast worthy either. It incorporates a lot of what I've learned about rolling custom dispatchers, route sets, and renderers from having architected a CMS that powers some pretty big sites. If you're looking for high modularity, easy extensibility, and more, Ozark might be right up your alley.
Keep tabs on this blog to hear more about Ozark, the philosophy behind it, and how things are progressing. Now I just need to add RSS/Atom support!