another day, another blog
Today I Learned that dispatching via GCD to the main thread will let running code escape an enclosing @try/@catch block.
Consider the following (over-simplified for clarity) example:
Unfortunate, while trying to recover gracefully from unhandled exceptions in background threads within tests.
Per my previous post, I’m trying to be better about recording “Duh” / “Aha” moments in my experiments with Rails to 1) improve my learning / general consumer-of-open-source-software habits, and 2) in hopes that I don’t make similar same silly mistakes again.
fields_for with a serialized has_many relationshipI’ve used plenty of nested forms recently, but always (and now, in retrospect, not always necessarily) with ActiveRecord-based has_many relationships.
Today, I was adding a new attribute to an existing model, and wanted to add some attributes that would simply be attached to the model via a serialized field, rather than any sort of join (similar to the setup in this post).
I wanted to store a set of BillItems on each User, but since they would be fairly isolated from anything else in the database and be tied strictly to each User, I decided to just attach it to each User.
And because each User could theoretically have many BillItems, we’d want to ensure :bill_items was serialized as an Array.
I was finding, though, frustratingly, that the following form was being generated incorrectly – only a single bill_item field was represented in the form, and even when sanity checking by iterating over bill_item records manually, the field markup was missing the indices necessary for the form to recognize each field as a separate form parameter. So when the template looked like this:
The output looked (sadly) like this:
What the docs missed out on saying (under One-to-many) is that: rather than the projects_attributes= attributes writer method just being 1) recommended, 2) worth considering, and 3) available to be replaced by a accepts_nested_attributes_for if :projects were already an association on the model, it’s actually required for fields_for to correctly nest the fields.
And, of course, :bill_items not being a proper association, I wasn’t able to use the standard accepts_nested_attributes_for helper and ran afoul of this. With the correct *_attributes method defined, the form finally displays perfectly, so that bill_items are passed through correctly, as an Array:
Lesson learned, and change committed.
I’ve been working closely with our intern Cory, and have now been put in the situation of having to explain why Rails is doing X or not doing Y more in the last couple weeks than the whole of the last several months. (It’s also worthwhile saying that it’s incredibly nice having someone to bounce thoughts off of again – no more coding in vacuum.) After each time one or both of us gets tripped up on something, I’m reminded to store that bit of knowledge somewhere useful.
I / we / anyone (me) serious about improving as a programmer needs to dive in and really understand how things are put together. With that goal in mind, I’ve got a couple resolutions to declare:
1. I’m going to be more diligent about reading Rails code – I’ve done my fair share of poking, but I’m going to be much more stringent about reading documentation and code to really understand what’s going on.
2. I’m going to stop lurking / being an isolationist on Github and be more proactive about submitting patches, which I’ve been improving at over the last few months (especially for documentation, as I encounter things that end up being “duh” moments).
redirect_to:redirect_to is an awfully common method in controllers, and most people use it without thinking or looking too deeply at the internals. Cory tried to be a little more correct with one particular redirect_to, though, by adding :status => :unauthorized, and we found that the controller, in fact, no longer redirected the user. Instead, it displayed a “You are being redirected.” message and simply sat there.
Digging into the source shows us that redirect_to works by returning a HTTP response status of 302 to the browser (of course) – which then knows to look up response’s location and fetch that instead.
So when a 4xx response code is passed in, it overrides the default 3xx redirect status code and the browser simply displays the response_body and (seemingly) chokes. I’ve committed a change on the docrails Github project to clarify this point for anyone staring at the documentation in the future.
More up in a second blog post!
I’ve been having a ton of fun lately playing with ifttt, a service that lets you easily glue together different web services you use / rely on every day. If you remember Yahoo Pipes (wiki), ifttt is based off the same ideas – but is much easier to approach, think about, and use. There are a couple of other ifttt flow blog posts around, but my favorite blog entries are the ones that show instead of tell – so, here we go:
The favorite use I found for it so far is my Game of Thrones task – I love The Atlantic‘s coverage but really couldn’t care less about their other Entertainment articles, and they don’t have category-specific RSS feeds. This way, I get things delivered straight to my inbox!
And, in the interest of keeping my inbox relevant, I have higher-frequency / immediate-action-required tasks tied to my GTalk, which makes sure that I can react quickly.
(I’ve noticed that more of my tasks are tied around consumption/notification rather than production. The other blog posts I’ve linked to above seem to tend toward duplicating/publishing content elsewhere, which is an interesting difference.)
The site is really nicely designed and is genuinely fun to use. Get on the invite list and start creating – I’m excited to see what other fun uses I find.
Note: Hah, if you look closely, my Rent reminder, the second task from the bottom has never fired. Clearly, the service is still in beta. I still use Resnooze for scheduled email reminders about things, but am looking forward to ifttt stabilizing enough for me to switch!
I used to care about “women in tech.” I used to jump into those discussions, blood boiling and hands flailing; I used to like to point people to some of my favorite articles and books, and partially still can’t help but click on every single gender-related article to pop up on HN…
… but after years of this nonsense, I’ve given up. There’s very little to be gained from discussing that topic – frankly, most people just get upset because they’ve already made up their minds. So I tend to try to take the higher road and ignore all the hubbub.
Until, of course, when they agree with me (grin). Blogger Jolie O’Dell has taken most of my thoughts and packaged them up nicely in a carefully articulated post:
We are misguided to demand more women in tech when there simply isn’t an adequate supply of competent technological professionals to support gender parity. Women in tech begins with little girls playing with science- and math-related toys, and it takes much longer than just a few months or a few years to undo the sociological mores of a few millenia.
I wholeheartedly believe that root of the women-in-tech problem is what we present (How Society Works, and Your Place In It) and show (“Math Class is Tough!“) to our girls. There isn’t enough out there to teach these incredibly impressionable girls (how many girls do you think say they like science at the end of elementary school? And how many at the end of high school?) that math and science are cool, can be cool, and can even make you cool.
This is what I care about – and this being my blog, I figure I’m allowed to try and sell you some of my favorite ways to fix this problem. There are so many ways to get involved, either by taking an active mentorship role or just helping them out with resources. Here’s a list of organizations I’ve been involved with over the years:
And some programs that look interesting: (Please comment if you know of any others that are similar / might be interesting!)
Now stop complaining about the problem, and go make something happen! :)
Today I signed a lease. I signed a lease that I negotiated down (helped in part by the current state of the real estate market), essentially decreasing rent per room in our five-bedroom by $200.
Today I ended a stint with a startup. I ended my time at Aardvark as part of The Mechanical Zoo, and on Tuesday I start my time at Aardvark as part of Google.
And to think I could have been five months into my Master’s thesis, wrapping up the first month of my last semester at MIT.
I laughed out loud to myself today as I was waiting for the bus to take me home from the landlord’s office – I like this life.
Last week at around this time, I had just been told that my four roommates were moving out, and that I either had three weeks to fill four rooms or find a new place for myself. I got the rent down, two roommates stayed (plus the dog and the cat), a friend moved in, and we did the Craigslist dance to fill the last room. So now we’re good, with a little terror, stress, and hopefulness thrown in.
Two months ago at work (plus change), all of us piled into a room like we normally do for our end-of-the-week meeting. We were told that a term sheet had just been signed for us to be acquired by Google. Due diligence was done, HR negotiations occurred, and secrets were held for far too long from far too many people. We start at a different office in three days – and I’ll be bringing my personal little knot of excitement, apprehension, and curiosity.
In looking at life post-college, I was worried it’d be too routine – I thought that without “landmarks” to look forward to (winter break, summer vacation, finals, formals, trips), I might be bored and let time slip by without noticing. Well – now school looks methodical and predictable and the extraordinarily safe option.
What have I learned? That question will, hopefully, be answered thoroughly in the future in frequent intervals, but for now, a brief summary of my favorite learnings of the last several months:
But I know I continue to be extraordinarily lucky. So I’m extraordinarily thankful – and am excited to see what else is in store!
After staring at a rake task for twenty minutes and manually testing some cases in a console, I’ve got some interesting larnin’s about ActiveRecord::Base.find and what it does with an options hash.
Background
There are typically two ways to provide conditions for a database search via ActiveRecord. The first is find, which looks like this most of the time: User.find(:all, :conditions => {:first_name => 'Bob', :last_name => 'Smith'}, :limit => 5). find takes two arguments: {:all, :first, :last}, and an options hash (more here).
Or taking advantage of existing relationships, which basically ORM-magic away a one-to-many foreign-key relationship between tables, e.g. some_user.files would return an array of some_user‘s File objects. So on and so forth.
And a third way, which I like and think cleans things up really nicely but is apparently not relevant to this bit of learning, is using named scopes (more references) – essentially, a way to wrap up any part of that options hash into what looks like a method on the model itself. An example involving a female named scope on our beloved Usermodel.
class User < ActiveRecord::Base
named_scope :female, :conditions => {:gender => 'female'}
end
This allows you to not only get all female Users by calling User.female, but also allows combining of named scopes and the find method to minimize repetition and narrow the scope of a query. For example:
User.female.find(:all, :conditions => {:first_name => 'Christine'})
But wait!
In a script I was working on recently, I needed to loop through an array, and look something up at each step:
args = { :select => 'some_attr_id', :limit => 5 }
user_array.each do |user|
if condition
files = user.files.published.find(:all, args)
else
files = user.files.unpublished.find(:all, args)
end
... < do stuff with the files >
end
Interestingly enough, as args passed through the loop each time, it picked up the parameters added by the user-files relationship! Meaning, the first time through the loop with User 1, the args hash looked like this:
{:include=>nil, :readonly=>nil,
:conditions=>"`files`.user_id = 1",
:joins=>nil, :select=>"some_attr_id", :group=>nil,
:offset=>nil, :limit=>5, :having=>nil, :order=>"files.created_at DESC"}
… which makes all sorts of sense, considering a query like user.files.published would just be a search across some files table with user_id and a published conditions, but how irritating that the args hash was 1) mutable at all, and 2) modified by being passed into the ActiveRecord query!,
I think I wrote something awhile back about good companies vs. good people – but what about good companies vs. good work? I just finished up a conversation with a friend who’s in the situation of being in love with the company he works at, but hates the tedious, somewhat degrading, but admittedly necessary work he actually does there. (Yes, he was an intern – but what an awful experience to have, and lesson to be taught!)
When should you sacrifice your own happiness / career development / intellectual stimulation for a product you’re excited about? Can you love the product and love the work? Or does loving the product just blind you to what you’re doing (and vice versa)?
I suppose it all boils down to how idealistic you are. Is this going to be the game-changer? Is there really nowhere else as, or almost as, exciting – but where you get to do interesting and challenging work? I usually think so – he may not. How does loyalty play into this – when are you obligated to stay with a company when you’re only being satisfied ideologically and not intellectually? (I say almost never – or that it’s only up to you to effect a change so that you are intellectually satisfied. But I’m only selectively idealistic, and incredibly selfish when it comes to my development.)
(p.s. – failed a bit with blogging once a week – but hopefully I can put something up soon about last weekend, which I spent at http://w2sf.startupweekend.org/ , and get back on track.)