Re: [pdxruby-beginners] meeting notes for 2011-11-15
Igal Koshevoy
attendees. We worked in separate groups for most of the evening, which
was great for giving individuals more personalized attention on
specific topics they wanted help with.
You'll find my notes below, and the notes from Rachel Sakry, who
worked with other teams than me in the reply section at the bottom of
this message.
* Rails search form's view and controller: Need to create a web form
for doing searches? Don't use `form_for`, which is intended for
manipulating new or existing ActiveRecord instances. Instead, use
`form_tag` to craft a custom form using helpers like `text_field_tag`
that provide input fields for your search queries -- see
<http://guides.rubyonrails.org/form_helpers.html> for details. A good
place to perform your search, as in actually loading the records, is
in your resource controller's `index` action. For example, if you're
searching for events, then make your EventsController's `index` action
smart enough to recognize a search query and have it display filtered
results. However, if you need a separate search page then you should
add a route, controller action and views for it. If you're searching
across different kinds of models, then you may want to add this search
action to a site-wide controller, such as one that you use for
handling your homepage, about page, etc.
* Heroku: Need to deploy a Ruby application with minimal fuss, low
cost and don't want to become a sysadmin? Heroku is a good choice, but
comes with various limitations and quirks compared to running your own
server. Their default stack is Ruby 1.9.2, Rails 3, PostgreSQL, and
has no persistent storage, so you must use an external service like S3
to store things like uploads. You can use other pieces of
infrastructure, but this can add complexity or cost.
* Rails with Inherited Resources: Want to write less "boilerplate" in
your controllers? Inherited Resources is a Rails plugin that provides
the RESTful actions for manipulating records for you, e.g. an
EventsController using Inherited Resources provides full support for
managing manages Event records using the usual
index/new/create/edit/update/destroy actions. It's also easy to
override if needed. See
<https://github.com/josevalim/inherited_resources> and
<http://railscasts.com/episodes/230-inherited-resources>.
* Haml: Want a more succinct way to write HTML? Haml provides an
elegant way to write your views in an alternative language that's used
to produce HTML. It makes sure that your code/markup is always
indented sensibly, simplifies setting class/id attributes on HTML DOM
elements, ensures tags are always closed, and may help with
comprehension. However, it's a rather different approach that some
will find annoying because you're writing code in one language that's
transformed into another language, and you have to know both. Learn
more at <http://haml-lang.com/>
* Sass: Want a better way to write CSS? You really need to see Sass, a
language for clearly describing your styles, which gets transformed
into CSS. There are two dialects, .sass and .scss, but they're just
visually different ways to do the same thing. The language makes it
possible to write styles with variables, functions, nesting of rules,
mixin, extension, etc. Unlike Haml, I can recommend Sass without any
hesitations. It's awesome. See <http://sass-lang.com/>
* Rails partials: Need to reuse markup? Don't copy code, learn to use
partials. http://guides.rubyonrails.org/layouts_and_rendering.html#using-partials
* Ruby editors: Vim, Emacs and Textmate are the most popular text
editors for writing Ruby code. Although I like using an IDE for
writing Java, I've never found a Ruby IDE that worked well enough to
bother with.
* Web application settings: How to store site-specific settings, e.g.
port for some service, email of admin, etc? A very simple solution is
to create a Ruby file with site-specific settings and have app read
it, e.g. have your Rails application or its initializers load the
file, e.g. <http://www.fromjavatoruby.com/2008/10/require-vs-load.html>.
A better approach may be to create a YAML file, which is read by the
application. A nice gem that makes this easy is `settingslogic`, see
<https://github.com/binarylogic/settingslogic>. Or you can see how to
do this manually
<http://railscasts.com/episodes/85-yaml-configuration-file>. If you're
using Heroku, be aware that you can't just upload files outside of
version control, so you'll need to add and commit your configuration
file into version control and deploy that, but be careful not to
publish this information to the public because it may contain private
information. Alternatively use config variables
<http://devcenter.heroku.com/articles/config-vars>. There may be a gem
that provides enough smarts to look in environment variables (for
things like Heroku) and config files (for things like Passenger), so
if someone can recommend one, I'd be interested.
* Experiment with the help of version control: Not sure how to write
something, but are afraid to experiment because you're sick of
breaking your code, losing work and making tons of backups with names
like "foo_controller~old_2_works_mostly.rb"? Go learn a distributed
version control system (DVCS) like Git <http://git-scm.com/> or
Mercurial <http://mercurial.selenic.com/>. Using a DVCS, you can
capture the content of your files at a point in time, see what you've
changed and when, switch back to different versions of the code, etc.
When you've figured out how to do something, clean up your exploration
into a set of neat, readable commits and publish them. If you're
interested in git.... Our very own Sam Livingston-Gray has published a
"Think Like (a) Git" guide at <http://think-like-a-git.net/>. You will
also find good documentation at <http://git-scm.com/documentation>.
Please be aware that there are different ways to explain git, so try
reading a few different guides because some will make much more sense
to you than others. Also, don't forget that you can create a local git
repository on your computer and play with it, which is a safe and
simple way to experiment.
On Wed, Nov 16, 2011 at 9:12 PM, Rachel Sakry <rache...@gmail.com> wrote:
> Thanks, everyone, for a great meeting last night. Since we ran out of time
> to check in at the end, I thought I'd post a summary of what I heard, and I
> hope others will do the same.
> I sat in on Jesse's presentation of his Sinatra app. I'd previously heard
> Sinatra described as a light-weight Rails substitute, and it was interesting
> to get a slightly more nuanced understanding of what Sinatra does. If I
> understood correctly (and someone please correct me if this isn't accurate),
> it's a gem that provides an API for dealing with HTTP requests. Some other
> stuff from my notes:
>
> RSpec/Behavior-Driven Development: BDD is a more meaningful approach to
> testing code than the traditional TDD. One advantage of RSpec over
> Test::Unit is that RSpec reads like English: "it { should do_a_thing }" as
> opposed to "def test_a_thing / assert..."
>
> "Factory" is a design pattern where you're not managing static files, you're
> writing code that writes code. One way this pattern is used is to generate
> "dummy data" for running tests on a database. (FactoryGirl is a gem that
> does this.)
>
> We also talked about Haml, an HTML rendering library that looks pretty
> awesome.
>
> My brain was kinda fried by the time Igal started presenting, so I'm hoping
> someone else will be able to summarize that discussion. (I look forward to a
> more extended walk-through of Citizenry at a future meeting, if folks are up
> for it.)
>
> Thanks to everyone who presented, and to Sam for hosting!
>
> Rachel
>
Bill Burcham
Kurt Sussman
I have used the rails-settings gem and really like it, but I'm getting
some strange failures under Rails 3. Which could be my fault, but I
don't know yet.
https://github.com/Squeegy/rails-settings
What I like about rails-settings: settings are stored in the database,
though you can set defaults to be used in case there is no value
stored for that setting in the db. Settings values can be arrays,
hashes, or objects. It's simple to use. Test coverage is good.
--Kurt
> partials.http://guides.rubyonrails.org/layouts_and_rendering.html#using-partials
Igal Koshevoy
> I have used the rails-settings gem and really like it, but I'm getting
> some strange failures under Rails 3. Which could be my fault, but I
> don't know yet.
>
> https://github.com/Squeegy/rails-settings
You should try to capture the steps needed to replicate these errors
and backtraces, and file bug reports. I'm pretty sure this is a pretty
simple library, and should be relatively easy to fix.
> What I like about rails-settings: settings are stored in the database,
> though you can set defaults to be used in case there is no value
> stored for that setting in the db. Settings values can be arrays,
> hashes, or objects. It's simple to use. Test coverage is good.
Thanks for the comment, storing settings in a database is a useful approach.
As long as your app has an admin user, storing settings in a database
is great because a newly-setup web app can start and provide friendly
web-based forms for the new admin to configure, offering lots of
nicely-formatted instructions, validation of user input, coping well
with tricky input (e.g. if you choose X, then you can't choose Y),
making it easy to choose options using select/radio controls, and
easily changing values online later using a simple form rather than
fussing with magical files or variables.
Unfortunately, I always end up with a settings file for storing the
session key, hostname/ports of external services, exception notifier,
and various libraries that insist on initialization-time configuration
or config files. It should be possible to set all these values from a
database or modify libraries to allow this, which is work, but also
creates another problem: how do you tell all your web application
instances to use the new setting values? Having each instance *pull*
to check if the settings have changed every time it processes an HTTP
request would be silly. Having to *push* a notification to refresh
settings by sending a signal to every instance on every machine would
be tricky or impossible. Maybe just displaying a big red message to
the admin when they change an initialization-time setting and telling
them they must restart all their application instances to get the new
value is a more reasonable approach since this would avoid a slow
"pull" or complicated "push" for updating settings.
-igal
Kurt Sussman
> On Wed, Nov 23, 2011 at 2:57 PM, Kurt Sussman <ratb...@gmail.com> wrote:
> > I have used the rails-settings gem and really like it, but I'm getting
> > some strange failures under Rails 3. Which could be my fault, but I
> > don't know yet.
>
> >https://github.com/Squeegy/rails-settings
>
> You should try to capture the steps needed to replicate these errors
> and backtraces, and file bug reports. I'm pretty sure this is a pretty
> simple library, and should be relatively easy to fix.
I switched to a maintained fork of that gem and all is well. For the
record, I am using
https://github.com/ledermann/rails-settings
I completely agree about benefits of debugging and submitting fixes to
'free' gems; I always learn a lot (probably because I have so much to
learn!), and the community gets a fix. In this case, the work has
already been done.
--Kurt
Igal Koshevoy
> On Nov 23, 4:17 pm, Igal Koshevoy <i...@pragmaticraft.com> wrote:
>> On Wed, Nov 23, 2011 at 2:57 PM, Kurt Sussman <ratb...@gmail.com> wrote:
>> > I have used the rails-settings gem and really like it, but I'm getting
>> > some strange failures under Rails 3. Which could be my fault, but I
>> > don't know yet.
>
> record, I am using
>
> https://github.com/ledermann/rails-settings
> I completely agree about benefits of debugging and submitting fixes to
> 'free' gems; I always learn a lot (probably because I have so much to
> learn!), and the community gets a fix. In this case, the work has
> already been done.
:]
-igal