Wednesday, August 31, 2011

Great things are created "on the side"

Let's pretend that you hold a full time job, or you're a college student absolutely loaded with work daily. This is normal. You're like millions of others in the world...

...except, you have these ideas you want to realize, or this personal project you really, really want to finish.

You constantly face this dilemma: work and work and work on non-personal project matters, or allot time to work on those ideas you have. The easy answer is to go with the typical work society asks of you - finish your college studies, try for grad school, aim for a good career, try to get that internship, please your boss, stay late after work - the list goes on and on. While none of these are necessarily "easy," they certainly are the standard way to do things.

But let's face it. If you're going to realize those ideas of yours that you're truly passionate about, or even those that you simply think are "cool" (which in fact could be better than the ones you're passionate about) you must allot time - even a little - to your project(s). This really makes all the difference.

Now, they say that if you really want to do something, you'll be able to allot time for it. But in this busy world, remembering this saying often just isn't enough to drive you.

Instead, take this advice: great things have been created "on the side."
Instead of even considering the idea, "Okay, self, I'm going to work on Project X every day from eleven to twelve midnight no matter what," it's far easier and more productive to simply go about it unthinkingly. Planning and setting explicit timeframes puts an unnecessary burden on you, one that you just won't keep up with if you're a fulltime college student or you're working at a major company.

If you instead just work on your little project "on the side" while doing the typical things society asks of you, you'll find yourself creating something you truly value and find useful. Examples from history that were also created "on the side" include the creation of...
(If you have other examples, comment and let me know!)

Bottom line: it's okay to work on a project "on the side" without designating strict deadlines and times to work. In fact, it might even be better.

Quick, last thing: working on a project "on the side" helps alleviate unneeded pressure you put on yourself if you really consider your ideas "big ideas." I personally am starting to see that it's easier to remove the weight you put on your ideas and instead go about creating them with a free and open spirit.

Read another interesting article about jumping on inspiration.

Saturday, August 6, 2011

PGError: ERROR: cached plan must not change result type... Solved

I got this error recently after deploying to Heroku:

ActiveRecord::StatementInvalid (PGError: ERROR:  cached plan must not change result type

It turns out the issue was just like that of this person: http://stackoverflow.com/questions/2783813/postgres-8-3-error-cached-plan-must-not-change-result-type.

Basically, I ran a migration / modified my database table, but didn't restart the heroku app. So, after running

heroku run rake db:migrate

I had to also run

heroku restart

and the problem was solved.

Why do we have to do this? According to this site on Heroku, "After running a migration you’ll want to restart your app with heroku restart to reload the schema and pickup any schema changes."

Thursday, August 4, 2011

Rails' link_to: specifying miscellaneous attributes

If you ever need to specify miscellaneous attributes, as I did when making my Rails 3.1 app mobile with jQuery Mobile, there's an easy way to do it.

Example: I want to create a link with the following...
<a href="" data-direction="reverse" data-rel="back" data-prefetch>xyz</a>

Just do this (in your embedded ruby html file):
<%= link_to "xyz", my_path, "data-direction"=>"reverse", "data-rel"=>"back", "data-prefetch"=>"" %>

The order of the variables after the path specification (my_path, in this case) generally does not matter, so you could put :class => "my_class" before, in the middle, or after those "data-" parameters too, and you could rearrange the "data-" parameters however you like.
Also, note the specification of "data-prefetch"=>"" in the case that there is no attribute to set equal to.

This whole idea came especially in handy for me because jQuery mobile uses such things frequently. However, the idea of specifying
"some_variable"=>"some_value"
in the link_to method can be applied to broader scenarios, too; it just might help you out.

Wednesday, August 3, 2011

Passing a path into a partial

I recently figured this out, and I thought others might find this helpful, too.

Ever want to pass a path into a partial - say, for a header, where there's always going to be a link in this one spot, but the actual path of that link changes? I encountered this problem when developing a mobile web app, where in the top left header section, I always wanted a "back" link, but the actual path of this link varied depending on the page.

Here's how I did it:
In the partial:
<% unless path.nil? %>
 <%= link_to "Dining Hall", send(path) %>
<% end %>
In the view that renders the partial:
<%= render :partial => "layouts/partials/header", :locals => { :path => "root_path" } %>

Instead of root_path, you could put, for example, books_path. Note, however, that passing "@book" or @book does not work, so this still has its limitations.

The whole trick is using the "send" method in the link_to. http://apidock.com/rails/ActiveRecord/Associations/AssociationProxy/send

I certainly found this trick to be useful, and perhaps you will too.