Posts filed under 'Railscasts Project'
Someone asked for the lyrics to my recent presentation at RailsConf. Enjoy!
The screen glows white on my laptop tonight
And my rspec won’t go green
I’m coding in isolation,
So my PRs are obscene
My doubts are howling like this swirling storm inside
Couldn’t keep it in;
Heaven knows I’ve tried
Don’t let them in,
don’t let them see
my github repos are mortifying me
Conceal, don’t feel,
don’t let them know
Well now they know
Let me code, let me code
Can’t hold it back anymore
Let me code, let me code
I want to play with rails 4.0.4
I don’t care
what they’re going to say
Let the nerds rage on.
The trolls never bothered me anyway
It’s funny how some distance
Makes everything seem small
And the impostor syndrome
Can’t get to me at all
It’s time to see what I can do
To test the limits and break through
No right, no wrong, Sandi’s rules for me,
I’m free!
Let me code, let me code
Matz is my favorite guy
Let me code, let me code
DHH will never see me cry
Here I stand
And here I’ll stay
Let the nerds rage on
My SQL queries fetching data that it found
I’m using ruby to draw frozen fractals all around
And one thought’s solidifying like an icy blast
I’m never going back, the past is in the past
Let me code, let me code
When I’ll rise like the break of dawn
Let me code, let me code
That perfect girl is gone
Here I stand
With the apps I’ve made
Let the nerds rage on
The trolls never bothered me anyway!
p.s.
The code to create those “frozen fractals” was found here:
http://singlebrook.com/blog/explore-mand…
April 25th, 2014
I’ve been invited to “speak” at RailsConf!
Yeah, I meant to use quotes because my talks generally involve alternate lyrics to popular songs with tech jokes thrown in.
Since my “talk” isn’t the traditional 40 minute discussion I will be the opening number for the lightening talks on Thursday evening.
I am so excited, and only slightly terrified.
March 5th, 2014
Check out my vocal presentation at Wicked Good Ruby Boston this year! This was so much fun.
I love the Boston ruby community, who is willing to endure my brand of ridiculous. Thanks guys!
October 30th, 2013
Sadly, I did not complete all of Ryan Bates’ Railscast videos before Railsconf ’11. I didn’t even get close.
It was a great idea that I simply couldn’t complete. But that doesn’t mean it has to die.
Through the conference this year there was a definite theme. And I’m not talking about javascript. @benscofield gave an ignite talk where he said, the way to be awesome is to:
START LOTS OF STUFF
Now, I am awesome. And I am awesome at starting lots of great stuff. And sometimes I finish it too. Particularly, if there is the possibility that I may be fired if I don’t. But @benscofield also said:
QUIT ON STUFF
You have to Know Your Limits as @eliseworthy said. And since @briandoll pointed out that the ultimate productivity hack is having kids, I’ve decided to take this project in a new direction.
It’s no fun practicing being awesome alone. So I propose a monthly meet-up where we watch a Railscast screencast together and discuss it afterwards.
Who’s in?
May 20th, 2011
I find myself with an odd moment to blog about episode #28. And I do in fact find this topic odd.
There isn’t much to say about it. I mean, in_groups_of *is* a handy little method that will transform your array into groups, as you might think. And this is useful for displaying tables as demonstrated by Ryan in the screencast.
But really? *yawn*
I think I’m done with starting from the beginning of the railscasts. My company is transitioning to Rails 3 and Ryan has been blogging about it since February.
Since I really need to catch up, I think it’s time to skip. I can always come back to the older posts later, right?
After all, I’m sure Julie didn’t do all of Julia’s recipes in order. Didn’t she save the canard à l’orange recipe till last?
So folks, where do you think I should skip TO? Does Episode 200: Rails 3 Beta and RVM seem like the most likely place to start?
December 1st, 2010
It’s Thanksgiving. I swear that September through January is always a god damn blur. Every now and again I’ll lift my head up, shout out some expletive and then get back to the business of getting through the holiday season.
At this rate, I’ve averaging one railscast per month. Considering that Ryan churns out at least one a week, my project doesn’t appear to be progressing as I’d hoped.
But hey, I have photos to make up for it.
November 24th, 2010
So wading through every single Railscast episode isn’t going as well as I had planned. Life keeps getting in the way. October is a very busy month. Halloween is very important to me and my family. And yes I do spend all month getting ready. Truthfully, I’ve been getting ready since August.
You do know that my brother is a horror filmmaker out in LA, right? Yup. Halloween is a busy time of year. And the theatrically of it all is just too hard for me to pass up.
In addition, it’s hard to stay focused on getting through these early episodes when more exciting things keep jumping out at me…. like the JQuery Conference this weekend. A whole lot of awesome.
But whether it takes a year or longer, I’ve made a commitment and I plan to stick to it. So, I’m combining three episodes once again into one blog post. They’re all related anyway. And I have a feeling that Ryan likely wrote this as one episode initially and then broke it out into three because he was busy as well. Shhh. It’s just our little secret, Ryan.
So, this threesome is more about security. Bottom line:
params <-- don't trust it
cookies <-- don't trust it
session <-- you can trust it
SQL INJECTION: Episode 25
When the dev places the user input directly into an SQL query, there is potential to really mess up the db.
This is BAD:
@tasks = Task.find(:all,:conditions=>"name LIKE ’%#{params[:query]}%’")
Input a quote and everything after that is considered pure SQL.
if params[:query] = " ' " + "DROP DATABASE"
YOU ARE F*CKED
end
There are easy ways to escape conditions.
tasks = Task.find(:all, :conditions=> [ "name LIKE ?", "%#{params[:query]}%" ]
This still looks dangerous to me but Rails will actually escape this for you. You only need to worry about escaping input in find methods if you’re using the :conditions parameter. If you’re using the dynamic find_by methods then Rails will automatically escape any input which will ensure that you’re safe from SQL injection.
So Ryan, you’re saying that the code below is safe?
tasks = Task.find_by_name(params[:query])
Really? Let’s try it out.
query = " ' " + "DROP DATABASE"
tasks = Task.find_by_name(query)
Whew! I still got my db. ;-)
MASS ASSIGNMENT: Episode 26
@user = User.new(params[:user])
Everything in the params[:user] hash is being sent to create the user record. Don’t ever trust the params hash. It could be anything.
One way to prevent problems is to set protection on your user model. attr_protected will disable mass assignment for the fields you want to protect.
So in Ryan’s example, he had a User model with a boolean field denoting whether or not a user is an admin. By setting attr_protected :admin in your user model, you’re preventing the admin field from being set.
Here’s another example:
stuff = {:login => "Hacker", :password => "hacked"}
@user = User.new(stuff)
When attr_protected :password is set, the code above will not update the password field. But this will:
@user.password = 'goodsecurity'
So, that’s good. But actually, its better practice to use attr_accessible to open the fields that you want to be set via mass assignment and automatically hide all the rest. This protects fields that can be set indirectly via associations.
CROSS SITE SCRIPTING: Episode 27
Allowing the user to input nastiness to the site directly is bad news. Adding data to a table directly from a view is fraught with issues. Ryan shows an awesome example of this. Try going to your favorite insecure website and type in any input text box:
I can haz hack? alert('i haz hakked u')
If you see an alert box, then this site is vulnerable to Cross Site Scripting. To avoid this problem, you need to escape user input. In older version of rails, you needed to use h method.
Really annoying to have to remember to add h to all your views. Another way to do this is to sanitize the input in the controller. Perhaps best to do it in both places. Or better yet, upgrade to Rails 3.
Rails 3 adds XSS protection by default. This means that you no longer have to manually escape user input with the h helper, because Rails will automatically escape it for you.
IT’S ABOUT TIME!!
But if you really wanna protect yourself, use html_safe. You can read up all about it and more on Yehuda’s blog: SafeBuffers and Rails 3.0.
Hey, let’s be careful out there.
October 20th, 2010
This is a favorite topic of mine. Maybe it’s just me, but it feels like all the other rubyists out there get to work on fresh code bases that are well tested using all the latest tools.
Well, sadly, that’s not my situation. We’re on Rails 1.2. Yeah. And tests? Well we’ve got them. And at one time they actually worked. *sigh*
So, debugging is very important to me. And in episode #24, Ryan tells how to decode the stack trace. And this is a very valuable resource. But honestly, I couldn’t survive without my IDE debugger.
Now, apparently no self respecting rubyist uses a debugger. First reaction I get from folks is, “We have tests”. Well, yay for you. Then I hear, “Well, you can always use script/console and puts statements.” And indeed, this is very helpful.
For example, you have the simple method below:
def my_broken_method(greeting)
greeting + ', ' + User.current.login
end
Let’s say you’re getting an unexpected name and want to checkout what User.current is really returning. Well, just add a puts like this:
def my_broken_method(greeting)
puts User.current
greeting + ', ' + User.current
end
And then from the command line you call script/console:
>> script/console
>> my_broken_method('Hello')
You should see something like:
#"2010-04-28 14:40:49.277067-04", "updated_at"=>"2010-09-28 17:18:25.755037-04""firstname"=>"Liana", "password"=>"ff1ec54a58581b7aa7ce3e9c9ee93c3599ae", "login"=>"lleahy"}>
=> "Hello, lleahy"
And from this, I can tell that I may actually want to use User.current.firstname instead of User.current.login.
Now this is okay for simple, direct debugging. I use it all the time. But sometimes you need to step through code, line by line to track down a problem. And when things get really scary, I rely on my trusty debugger.
Command line enthusiasts will sometimes use ruby-debug. This tool will allow you to “set a breakpoint, inspect variables, change the code and more”.
If this works for you, great. Me? I’m a visual, gui kind of gal. I’m not afraid to admit it. Yeah, I took the Vim class. And I do use vim when I’m working on the server. But for intensive programming I simply prefer using Netbeans.
I got started with Netbeans back when I was stuck on a Windows machine and couldn’t get my hands on Textmate. And since then, I’ve grown so attached to my debugger (and the visual source control cues that rock hard) that I can’t seem to ween myself off an IDE no matter how many plugins I try to integrate into vim.
Truth is, it doesn’t matter which tool you use as long as you use it productively. Likely, I’ll eventually switch to vim because somehow I’m “less than” because I don’t live my life on the command line. Doesn’t matter that I can write up a scary sql query with double digit table joins before you can say ‘foreign key’.
Sure the gui tools can be a crutch but as long as I understand the magic beneath, why can’t I have my unicorns and rainbows?
September 28th, 2010
Adding a counter to your models is a nifty little rails feature that requires very little setup. One more reason to revisit these old episodes is a little gem tossed in to episode #23.
The pluralize method. Rails does its pluralizations with the Inflector class. You can read all about it from Amy Hoy:
Rails’ use of pluralization is pretty smart, albeit not perfect. From “person” you get “people,” and “mouse” you get “mice.” If you’re tracking deer, though, watch out for “deers.”
Here are a few of her examples:
Inflector.pluralize('test') => "tests"
Inflector.pluralize('mouse') => "mice"
Inflector.pluralize('geese') => "geeses"
"mouse".pluralize => "mice"
exit 1.ordinalize => "1st"
Amy Hoy is wicked cool and one of my ror rockstar role models.
Wait wait—code AND design chops? INCREDULOSITY!
September 20th, 2010
We all know that hitting the database as little as possible is one of the keys to improved performance. But rails can sometimes feel like a magic unicorn you don’t want to touch lest it fade into the mist.
Go ahead. Look that gift horse in the mouth. Even Unicorns poop and it’s all there in your development log.
Sorry for the poop comment. We’re potty training at my house.
But in keeping with the poop theme here, there’s a lot of valuable information in your output.
In episode 22, Ryan shows us eager loading. By using :include in your finders, you can squeeze multiple queries into one. So take a second look at those loops and check out that dot notation.
There are other ways of joining on tables, such as using :join. Which makes me wonder. Any other examples of ways to take advantage of eager loading?
September 10th, 2010
Previous Posts