I’m not doing a whole lot of performance optimization these days, but when I do, I will definitely return to this awesome blog post about using the standard library’s Benchmark module: http://rubylearning.com/blog/2013/06/19/how-do-i-benchmark-ruby-code
Archives for category: Uncategorized
People in the Rails community talk about RESTful routes all the time. Here is a good resource for understanding what that means: http://everydayrails.com/2010/07/18/understanding-rest-and-routes.html
If your routes are in fact restful, they will by default look something like this:
URL of post 1: myawesomesite.com/posts/1
URL of post 2: myawesomesite.com/posts/2
URL of post 100: myawesomesite.com/posts/100
1, 2, and 100 correspond to the primary key of each of those records (1st, 2nd, and 100th records in the database).
At thoughtbot, many of our clients are start-ups. Actually, some of them are even pre-start-ups. We are helping them prototype something out to introduce to a few interested parties or test users. In that case, the default URLs above feel awkward. Do you really want people to know that they are creating the 5th ever post on your system? Not a great way to engender trust. So, I’ve noticed that we frequently use either random strings (“slugs”) to cover up the primary key number or vanity URLs so that the URL reads like a sentence rather than an integer.
Treehouse has a great blog post out on how to create vanity URLs in Rails. I will definitely be referring to it in the future: http://blog.teamtreehouse.com/creating-vanity-urls-in-rails
Ah Memoization. You are such a hard word to say or correctly spell (because muscle memory always makes me type "memorization" – ironic, no?) but you are so nice to use.
Memoization, for those not in the know, looks like this in ruby:
def so_memoized
@blah ||= thing.stuff + thing.other_stuff
end
In case this incredible example isn't explanation enough, I will explain a little bit:
We want to know the value of @blah. If we do not currently know the value, our so_memoized method will evaluate it using thing.stuff and thing.other_stuff and assign the value to @blah so we can use it later. But if we already know the value of @blah, it won't have to. Lazy! Just like the best programming is.
Ruby Weekly recently included this awesome blog post on a nice way to use memoization with more complicated methods: http://6brand.com/ruby-speedup-memoize-those-methods.html
Neat!!
I haven't blogged in a little while and I don't want to say that blogging more is my new years' resolution, because then I will surely never do it more.
But, I am happy to be starting out the new year with some good programming learnings and thought I'd share one recent article I found helpful here:
(via Ruby Weekly: http://rubyweekly.com/)
This isn't exactly programming related, but it is making my life better, and that's what programming is all about, right? Make lives better!!
This afternoon I found myself in a bit of a pickle. I received an error from a website that was asking me to send a quick description of the problem with a mailto: link. You know, one of those links you click on that opens up the Mail app on your Mac? Blech.
I knew I had gmail set up as the default for these links on my home computer, so I set out to google how to change this.
First I read this: http://www.howtogeek.com/howto/3814/make-gmail-the-default-application-for-mailto-links-in-google-chrome/
Much too old. Chrome preferences no longer look like this.
Plenty new, but only instructs you on how to make gmail the default when asked 'yes' or 'no' and I wasn't receiving a prompt.
Finally, I found this: https://productforums.google.com/forum/?fromgroups=#!topic/chrome/sPhxiTQlf4s
The thread matched what I was seeing and was from August, so I decided it was trustworthy. I copy-pasted the following into my address bar:
javascript:navigator.registerProtocolHandler("mailto","https://mail.google.com/mail/?extsrc=mailto&url=%s","Gmail")
And nothing. Then I realized that I needed to copy-paste it into the address bar *on a tab with gmail open* and IT WORKED. Hooray.
Hope this helps someone else live a happier, more gmail friendly life.
When I first started learning Ruby, one of my favorite ways to “learn” was to go to meetups or other social-y tech events and ask people how I should learn. This not only played to my strength (socializing) but was a nifty way of feeling productive when I was really just putting off the hard stuff (actually learning).
Many of these advice-givers told me to “just build something.” Well guess what? I couldn’t. I am not one to give in or give up easily. But, as I’ve written about before, there were too many times where I sat down to do something and made zero progress because of my total lack of knowledge. At a certain level of beginner-ness, it’s impossible to know what you don’t know. I frequently tell people that it took me months to fully understand the different use-cases for a text editor and the terminal. How is someone who doesn’t understand what terminal is for supposed to “just build something”? In my experience, one must learn before one can do.
It’s been two and a half years and countless hours since I started down this path. And just a few weeks ago, I came to a realization: I need to do in order to learn!
During my first few weeks as an apprentice, I spent my days basking in the freedom of independent, supported studying. I would watch Railscasts, read long blog posts, and play around with my own little practice app. When I had a question, I could turn to my mentor and ask him. When I wanted to pair on my app, I could pair. When I wanted to zone out and watch talks on Conf Freaks, I could do that, too.
But what I realized after a couple of weeks was that I wasn’t learning. Well, that isn’t true. My goal as an apprentice was to learn as much as possible. And for someone 2.5 years into learning, pure study was not providing me with the skills that I needed to take my web development skills to the next level. With the help of my thoughtbot mentors, I changed course. I’ve spent the past 5 weeks taking my own stories, creating a git branch, and diving right in. I’ve been learning by doing.
So why the sudden 180? First, different levels of skill require different approaches. Total beginners need to start with the basics. This means understanding basic vocabulary and tools. These skills are hard to learn by doing because it’s oftentimes not even possible to get started without them. At my level now, I have enough experience to find my way out of most sticky situations. I still need to “phone a friend” (aka – put out a call for help in campfire or g-chat or even IRL) once every few hours, but that seems pretty standard in the dev world.
Second, it’s easier to be motivated to learn once you start doing. I still believe that absolute beginners need to start with unapplied learning. I’m reading So Good They Can’t Ignore You, and it’s reminded me that in the early days I actually really hated coding. I would put it off all the time because it was really not that much fun. But I persevered through the hard times and now I’m having a blast. In short: learning by doing is more fun. But if you’re just getting started, you’re going to have to put off fun for later. Unless you enjoy longs hours of reading dry text. In that case, get ready for immediate fun!!!
As John Dewey wrote, “Perhaps the greatest of all pedagogical fallacies is the notion that a person learns only the particular thing he is studying at the time.” What I’ve found through my crazy Ruby journey is that one must learn in order to do but one must also do in order to learn. So really I’ve learned a lot about learning. Doesn’t get much more meta than that!
Over the past few weeks, I've been learning a lot about git. People often confuse git and GitHub: git is a version control system, GitHub is a web app that will take all of your code versions (saved through git) and make them easily shareable across teams.
As part of my git training, I've been learning how to make small, easy-to-read commits (which means clean code and clear commit messages). Part of that includes "committing" (saving) and "pushing" (sending the code to GitHub) multiple times a day. Sometimes even multiple times an hour.
Recently, I was working on a project that was asking me for my github username and password every time I pushed. Talk about annoying! While I went along with it for a while, I decided to embrace laziness and try to find a way to stop this annoyance.
A few minutes later, I found this help article: https://help.github.com/articles/why-is-git-always-asking-for-my-password
Bottom line: I was being asked my password because I had cloned this project from GitHub using https instead of ssh. To fix this, all I had to do was go into the project in Terminal and type in: git remote set-url origin git@github.com/user/repo.git (adding jessieay as user and dotfiles as repo).
Lessons learned:
1. Git is hard. But so handy. I'm glad I'm getting better at it.
2. Embrace laziness.
A long long time ago when I was doing marketing (aka – in June), a/b testing was something I was deeply involved in. While I mostly focused on a/b testing our automated and marketing campaign emails, we also used services like Optimizely to a/b test our marketing website.
Today I read a blog post with an interesting argument for doing server-side a/b testing: http://www.bigfastblog.com/ab-testing-in-ruby-on-rails
Optimizely and other client-side a/b testing solutions are easy to get up and running but, as the post points out, these solutions make both versions available to all users (javascript makes them look different to the end user, but anyone who knows her way around developer tools can see both versions). Only server-side a/b testing ensures that half of your customers don't find out that the other half is being shown a different layout, pricing, products, or all three. The fluid-features gem (highlighted in the post) looks like an awesome way to implement a/b testing with Rails. I hope to try it soon!
Thanks to this blog post from a current Dev Bootcamp student: http://flavorite.tumblr.com/post/33774572841/ruby-inject
What up, DBC network!!
Had my first meeting with my Dev Bootcamp mentee yesterday. At first I was kind of dreading the idea of having a weekly commitment on top of my existing schedule, but it was great chatting with him and learning about what brought him to DBC and what his goals are.
I can also tell that mentoring will be a big opportunity for *me* to learn. Yay selfish motivation! Scott already told me about this neat UT Austin course on Rails he used to get going, which he says he prefers over Hartl: http://schneems.com/ut-rails
Jessie Codes 