Recently I needed some data to test such features as pagination and search. I only had 10 fixtures in the database and this wasn’t enough to test on.
I could have created a bunch of records filling in the fields with random characters but that is a not a very eloquent solution. Instead I wrote a rake task saved as: lib/tasks/faker.rake.
Here is my code
desc "Insert 100 projects using the faker gem"
task :insert_projects => :environment do
require 'faker'
1..100.times do |i|
b = Project.create( :name => Faker::Company.name,
:slogan => Faker::Company.bs)
end
puts "Faked project records"
end
Originally I used .create! but I found occasionally there were conflicting records so a .save may pass false, now it won’t fail if it passes false and will carry on with the rest.
I have just added a feature to Crummy where you can give an argument of a symbol which is then translated to get the instance variable and evaluated like so:
before_filter :load_comment
add_crumb :comment # => add_crumb(@comment.to_s, comment_path(@comment.to_param))
It is a common task to produce an application with breadcrumbs. Before, there were many solutions to this issue, but now I have made it so there is only one needed: Crummy.
Crummy allows you to add breadcrumbs in the controller (class level and instance level) and the views. You can use instance variables, strings or symbols in some places. It’s very customizable and handles everything you’d need down to Rails helpers.
To install, type: script/plugin install git://github.com/zachinglis/crummy.git
One thing that separates us at Hashrocket is the fact that we have a great team of Ruby experts. This is great if you get stuck, there is always at least one person who can help you on something. We also follow the great agile principle of pairing, which means that if someone is doing something you are interested in, then you can watch and learn with them.
Everyone is hesitant to get into Backpack for the purposes of updating their status and it is too private to talk about on Twitter so I thought I would come up with my own solution. Originally the Backpack feature came from their In/Out application, my good friend David Smalley came up with his own Merb solution too, but I wanted something Rails and thus Holler was born.
It has only taken me 4 hours so far but I would like to introduce Holler. There are a few big features that I am planning on: Fluid integration similar to Shout, Javascript where its needed, tags, twitter integration (direct messaging to the application), more ways to view statuses.
Feel free to fork it and make your own changes! Get Holler.
I haven’t posted much recently as I’ve been very busy at work (more on that later) so I thought I would post another Rails tip.
## Model
class Person < ActiveRecord::Base
def to_s
self.title
end
end
# View
link_to person
# Output
<a href=\"http://foo.bar/person/1\">Zach Inglis</a>
View Pastie
Furthermore you could extend it like this:
## Model
class Person < ActiveRecord::Base
def to_s
self.title
end
def to_param
self.slug
end
end
# View
link_to person
# Output
<a href=\"http://foo.bar/person/zach-inglis\">Zach Inglis</a>
View pastie
This post popped up on my feeds and after clicking it I thought I would share my opinion here. What I have to say is more an extension of myself than a comment could do for me.
The authors main argument is that people who want to program in Ruby over Python with the Google Apps Engine are ungrateful.
First things first, +1 is fricking annoying, agreed. The people should press the star button and not comment unless they have anything decent to say
But as for the matter of wanting Ruby in Google Apps is not unfair. I have coded Python but my Ruby-fu is far far stronger. I could create wonderful things with the tools I have.
Learning another language to use a tool is a crippled philosophy. If you downloaded software to write plugins and it was a vastly different language, it could be a deal breaker for you, right? Why should it be any less? Google are getting traffic and a bunch of other goodies out of locking you into their domain.
After a brief discussion with Obie regarding Rails views, he suggested that I have a look at HAML. I did, and it is now my primary source for using as a templating system in Rails.
YAML and HTML but oddly enough, it really works. I was adamant to not use it, no matter how many people told me to take a look at it. Rightly so, it is a travesty to HTML views, but its a helpful, time-saving travesty.
My dream is to create a Flex-view-like language that uses XML like so:
<mx:DataGrid id="entries" width="{reader.width-15}" dataProvider="{httpRSS.result.rss.channel.item}" cellPress="{body.htmlText=httpRSS.result.rss.channel.item[entries.selectedIndex].description}">
<mx:columns>
<mx:Array>
<mx:DataGridColumn columnName="title" headerText="Title" />
<mx:DataGridColumn columnName="pubDate" headerText="Date" />
</mx:Array>
</mx:columns>
</mx:DataGrid>
It is hard for a lot of people on the web to agree with, as they’ve spent the last 4 years being shoved that “views and content are seperate”, but there is a lot of logic in the above code which I enjoy.
I am curious to know what other people think of the state of HTML, HAML, and other view systems, and what they’d like to see.
Have you ever started writing an application to notice there is a typo in the controller name, or you want to name it something else without rewriting your code?
You could change your routes as so;
map.resources :tasks, :controller => "tasks"
But that’s messy. I’ve written a short sake task to rename all your files to the correct new name. It is your job however to rename the class/module titles. If you use testing, as you should, run the tests and you can catch most errors.
Install it,
sudo gem install sake
sake -i rename.sake
Then use it
sake rename:controller FROM=todo TO=tasks
The model task is causing a lot more troubles. So for that I will wait till I create a script/rename
I was waiting until I switch my blog until Rails only and then going to install Warehouse and list all my plugins there, however having to been forced at gunpoint (or at least metaphorical gunpoint) to try Git, I am starting to really appreciate the nuances that it brings over SVN. I won’t go into that now.
I’ve had many plugins lying around the place ready for consumption by Rails developers but now I shall start storing them online for everyone to use.
Clickable Error Messages
Currently a bit of a hack-job, was built before I even jumped on the REST boat and knew about @object.to_xml but essentially makes the fields in error_messages_for clickable.
Dashboard Location
With this plugin it takes 2 minutes (no, seriously) to add Basecamp-like urls to your project. Thanks goes to both David Heinemeier Hansson and Derek Haynes for their plugins.
Form Helper Fieldset
Simply wrap your inputs and labels in a fieldset block, passing a string aswell if you want a legend and it wraps it in fieldsets in the html for you.
Of course there are more to come as I can track down some of my plugins in the wild.
Get the plugins from GitHub here!
Any other downloadable work will go on my profile.
It happens in Rails’ generate scripts and it happens in a lot of plugins, but please, please, stop with the f blocks.
Too many times do I see:
form_for @bar do |f|
And even in the hpricot docs I see:
Hpricot(open(@url)) { |f| Hpricot f, :fixup_tags => true }
Why do I hate it so much?
The beauty of Ruby and the reason a lot of you use it is because it is pretty, easy to read and easy to write. It’s not Java. It’s not Ruby semantic, it’s just unreadable. F may stand for something, but to understand what it stands to, I have to read the earlier code.
