In computing, memoization is an optimization technique used primarily to speed up computer programs by having function calls avoid repeating the calculation of results for previously-processed inputs.
In Ruby f.e., this can be achieved with the good old ||= operator.
I launched a Ruby Quicktips site: http://rubyquicktips.tumblr.com/. Here is some introduction:
I have collected some initial tips for this blog now and thought it would be time to write something about the blog itself. So, here we go…
Do you know these moments when you talk to fellow programmers, read a blog article or book and suddenly discover a neat, new trick you haven’t seen or used, yet?
This blog is all about this! It’s meant to collect all those little new Ruby & Rails commands and tricks you have learned about.
Don’t expect this blog to teach you about Ruby and/or Ruby on Rails from scratch, though; it’s random and intended to be used as way to quickly discover new snippets of Ruby code.
All the tips are quicktips, which means they are short, practical and mostly lack some context and detailed explanation. However, I always link to sources which explain the commands of each tip in more detail.
I constantly learn new stuff about Ruby and Rails from the sources mentioned above and I thought it would be a good idea to share what I learned with the public, so you can benefit, too. While this is totally awesome already, it’s even better when more people participate…
Let’s make this site the most awesome collection of Ruby and Rails Quicktips on the web! Your help is essential and very appreciated!
And don’t be afraid to submit something you think is trivial or maybe too complicated or specific; Ruby Quicktips is for developers of all skill levels! All you have learned is worth sharing and will probably help some of your fellow programmers, too.
You can submit your tips on the submit page or by writing an e-mail to rubyquicktips@tumblr.com.
You can comment on every tip on this blog. Please do so, if you discover an error, have an improvement to en existing tip or just want to leave a nice comment.
There are several options to follow this blog:
There will be one more option in the future as soon as this blog has collected enough tips for this option to make sense. :-)
So, I hope you’ll enjoy this blog and discover a lot of useful Ruby and Rails tips.
Now go, tell your friends and submit your tip!
Here are some interesting survey results. “What other languages are Ruby developers familiar with? How do they code? What tools do they use?”
These and more questions have been answered by more than 1000 participants.
Below, you can read a summary of the results and/or visit the individual result pages which include all the details (what I recommend):
Here is an excerpt from the original post by thoughtbot-giantrobots summarizing the results:
Thanks to the 1000+ developers who participated in our ruby community survey a few weeks back.
Here are the results as we head into 2010.
There are result reports linked to from within each section, and this post does not comprehensively list all the results, so click through if you’re interested.
Demographics
The demographics results show that PHP (36%) and Java (22%) are the dominant “prior languages” of many ruby developers. Notably, we left out Python. Sorry python folks.
We also see that more than half the people who took the survey work on ruby professionally on a small team.
Textmate (51%) wins the editor battle, with vim (21%) in second place - and “Distributed VCS” (git, hg, etc) dominates (83%) the version control section. I’m sure that credit and thanks are due to the github team for building a product which makes using a great VCS tool even better.
Formatting
The results show that in regard to an 80 character line limit, the “modern displays are wide enough to not enforce a limit” position wins out, though not with a majority. The questions about keyword spacing, and blank lines are fairly evenly split. A solid 75% of people always use parentheses on method definition — maybe enough to justify criticizing people who don’t?
Style
The results (part 1, part 2) show a strong preference for “self.method_name” over “class « self” for class method definitions and for only using exceptions in exceptional situations.
Database
The results show that a slight majority prefer to disallow null in boolean columns — but most are willing to allow NULL in Integer and String columns. Results are split on adding indexing “only when performance issue” vs proactively adding them to foreign key columns ahead of time.
Views and Rails
The results that many people use a shared folder for “global partials”, and show little consensus on how/where to send email from. I think this question got the most “other” replies — let us know how else you’re sending email in the comments.
Documentation
The results show that ruby programmers prefer meaningful variable names, and only like to document code when it’s complex and needs explanation. Almost 80% have committed a code change which effects only code formatting and not functionality.
Wrapup
Maybe most encouragingly, when asked about whether the types of questions in the survey mattered or were a huge waste of time, nearly 90% chose the “I think it’s worth caring about your craft, and these questions are professionally relevant” option. From our experience at conferences and user group events, that seems consistent with the commitment to quality and best practices that exists in the ruby community.
Yesterday, at the Ruby Meetup Auckland, I gave a short talk on RubyCAS and CAS in general.
You can find the slides at Google Docs.
