(oh my) Zsh themes Gone Wild! 18+
1 comment Latest by Jason Green Fri, 29 Jan 2010 14:11:02 GMT
Earlier this evening, I accepted a pull-request for theme number 18, which is now included in Oh My Zsh. To celebrate, I’ve updated the themes wiki page with fresh screenshots.
Here is a sampling of some of the themes that you can use out of the box with Oh My Zsh.
Oh My Zsh is much more than a collection of themes for your zsh config. It’s a way of life1.
Also, be sure to follow ohmyzsh on twitter now!
1 well.. at least while you’re in the terminal. ;-)
RubyURL goes GOP...
Will refrain from any political commentary, but was notified by some friends that the GOP was using the source code for RubyURL for their new URL shortening site (gop.am).
To celebrate, I decided to daisy chain a few rubyurl-based sites together and came up with:
Enjoy!
As always, you can fork/clone here
Sending email: Controllers versus Models
While reviewing some code recently, I came across controller code that resembled the following.
if @customer.save
CustomerMailer.deliver_welcome_message(@customer)
flash[:message] = "Your account has been successfully created. We've sent you a welcome letter with..."
redirect_to dashboard_path
else
...
end
Fairly typical Rails code. Nothing alarming here, but I wanted to evaluate the call to the mailer in this scenario. When it comes to sending emails from your application, you can choose to do it from the controller as in the example above or in your models. Our team prefers to do this from our model via a callback as we are considering this to be part of our business logic.
Each time a customer is created, we want to send them an email. This can be moved into the model and resembled something like the following..
after_create :send_welcome_message #, other callbacks..
def send_welcome_message
CustomerMailer.deliver_welcome_message(self)
end
There are a few benefits to doing it this way.
- We can test that this is being triggered within our model specs instead of our controller specs. (we prefer to spend more of our time working within models than controllers)
- We remove the dependency that all requests must be processed through our controllers.
- Example: We may one day create rake tasks that data and want these emails to still be sent out. (We’ve had to do this a few times)
I definitely don’t think doing this via controllers is a bad idea, I just lean towards keeping controllers as dumbed down as possible. This allows us to have less controller code that is focused on passing data to/from models and letting our models do the heavy lifting.
UPDATE: DHH was kind enough to post a more detailed response on his blog.
Using BETWEEN for SQL comparisons
Recently, Carlos, suggested that I should start sharing some basic SQL tips that help with performance and/or general usage. I recently came across some code that I didn’t like to read and/or write. For example, let’s take the following…
SELECT * FROM brochures WHERE published_at <= now() AND archived_at >= now()
Essentially, this is pulling back some data WHERE
the the brochures are considered published. (We have a project that allows people to manage their brochure launch dates ahead of time.) In fact, in this project, we have no less than 6-8 dates in the database that we’re comparing data on and it’s easy to get lost in the logic when trying to understand it.
Now, there isn’t anything inheriently wrong with how this condition is constuctued. As a matter of personal taste, I find it annoying to mentally parse. Also, I find having to write now()
more than once in a WHERE
clause to feel like I’m repeating myself.
Read it outloud…
“WHERE the brochures published at date is less than and/or equal to right now AND the archived date is greater than and/or equal to now.”
Who talks like that?
Luckily, there is a better and in my opinion, a more readable way to express this is with the BETWEEN construct in SQL. (postgresql docs, mysql docs)
SELECT * FROM brochures WHERE now() BETWEEN published_at AND archived_at
Let’s read this outloud…
“WHERE the current date is between the published at and archived at dates.”
This sounds more natural to me.
Additionally, you can also do the inverse with NOT
.
SELECT ... WHERE now() NOT BETWEEN brochures.published_at AND brochures.archive_at
Remember kids, “code is for humans first and computers second.”—Martin Fowler
Planet Argon Podcast, Episode 3: How We Manage Bugs
Earlier this week, we published Episode 3 of the Planet Argon Podcast. In this latest episode we responded to one of the ideas someone in the audience asked on this brainstormr, which was, “How do you manage bugs?”
We had a round table discussion about how we classify and prioritize bugs with our clients, ticketing systems, and other tools that we use to streamline this process.
RailsOnPg released
Hello fellow PostgreSQL and Ruby on Rails geeks,
Alexander Tretyakov (twitter) recently released a plugin for Ruby on Rails, which extends migrations and provides you with the ability to create.
While you can already do something like this with execute
in your migrations:
execute("CREATE VIEW my_tasty_snacks AS SELECT * FROM snacks WHERE food = 'Tasty';")
With RailsOnPage, you’re provided a DSL so that you can do the following:
create_view :my_tasy_snacks do |view|
view.select '*'
view.from 'snacks'
view.conditions 'food' => 'Tasty'
end
note: I haven’t tested the above, just a hypothetical example
Anyhow, if you’re in the habit of using views, functions, or triggers with your PostgreSQL database and are using Ruby on Rails, you might give RailsOnPg a whirl.