Melbourne Ruby - April 2014

[Pat Allan]

Hi everyone

The Melbourne Ruby meet will be happening this Thursday evening, with our usual array of entertaining talks, delicious food (Vietnamese finger food), tasty beverages (both with and without alcohol), and delightful company (featuring your fine selves).

WHEN: Thursday 24th April, arrive at 6pm for a 6:30pm start.
WHERE: Inspire9, Level 1, 41-43 Stewart Street
WHAT: Four speakers, plus socialising, food and drinks.

Our line-up this month is:

* Duncan Bayne: Building and debugging native Ruby extensions
* Pete Yandell: Why you shouldn’t use test factories
* Rhiana Heath: Accessibility - more than just alt tags
* Steve Gilles: So you've decided to run a RubyConf

To aid with reliable catering numbers, if you can RSVP via Meetup (or ping me off-list if you’re not a fan of Meetup) that’d be brilliant :)
http://www.meetup.com/Ruby-On-Rails-Oceania-Melbourne/events/173468172/

This month, food is sponsored by Envato, Lookahead Search and Redbubble, the drinks by Zendesk, and the space by Inspire9. All perfect candidates for our Prime Minister’s knights and dames of the realm.

What’s the catch, I hear you ask? Well, you’re stuck with me hosting, as Mario’s off to share his wisdom at RailsConf in Chicago! If you’ve any questions or thoughts, get in touch - I'm looking forward to seeing you all there :)

—
Pat

[Rhiana Heath]

Hi Pat,

Thanks for having me, it's always fun to present.

Here's a link to the slides for my presentation last night.

http://www.slideshare.net/RhianaHeath/accessibility-abridged-33921021

Thanks,

Rhiana

[Pat Allan]

Thanks Rhiana, Steve and Pete for speaking - and thanks for Duncan for being cool with shifting his talk to next month, due to me scheduling too many talks this time around.

Below are the notes from this month’s meeting. The videos will be online soon.

__ __ _ _ ____ _
| \/ | ___| | |__ ___ _ _ _ __ _ __ ___ | _ \ _ _| |__ _ _
| |\/| |/ _ \ | '_ \ / _ \| | | | '__| '_ \ / _ \ | |_) | | | | '_ \| | | |
| | | | __/ | |_) | (_) | |_| | | | | | | __/ | _ <| |_| | |_) | |_| |
|_| |_|\___|_|_.__/ \___/ \__,_|_| |_| |_|\___| |_| \_\\__,_|_.__/ \__, |
|___/
Sponsors:
* Thanks to Inspire9 for the awesome venue and video recording!
* Thanks to Envato, Lookahead Search and Redbubble for filling us with
delicious food!
* Thanks to Zendesk for the tasty beverages!

Welcome!

Upcoming Melbourne Ruby Events:
* Hack Night - Tuesday 13th May
* InstallFest - Thursday 15th May
* Presentations Night - Thursday 29th May

Other Upcoming Events:
* Rails Camp Australia 15 - Brisbane, May 9th-12th 2014.
* Web Directions Code - Melbourne, May 1st/2nd 2014. Use MELBOURNERUBY code for $50 off.

News:
* DHH says testing first is overrated.
* Rails 4.1 released
* Heartbleed

Hiring:
* HotDoc - looking for Rails/JS developer, CBD - full time - j...@hotdoc.com.au
* Envato - job details are at envato.com - or talk to Pete.
* Digital Dialogue - 3 senior developers, Ruby/full-stack, processing large datasets - tim....@digitaldialogue.com.au
* Lookahead Search - recruiters with tech lead, mid level and senior roles
* Inspire9 - looking for an intermediate Ruby developer and an intermediate front-end (JS) developer - p...@inspire9.com


—
Pat

> --
> You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rails-oceani...@googlegroups.com.
> To post to this group, send email to rails-...@googlegroups.com.
> Visit this group at http://groups.google.com/group/rails-oceania.
> For more options, visit https://groups.google.com/d/optout.

[Rohan]

I wasn't able to make it last Thursday, but as a fairly heavy factory user, I'm interested in the alternative. Will talk videos be posted, or Pete, do you have some slides you could post?

Cheers,
Rohan

On Saturday, 19 April 2014 18:41:09 UTC+10, Pat Allan wrote:

[Pat Allan]

Hi Rohan

The talks were definitely recorded, but they’ve not been uploaded yet.

And while Pete did have some slides, they’re going to be far more useful with the discussion around them. Hopefully we’ll have it online soon :)

— 

Pat

[Rohan]

Awesome, thanks!

[Pat Allan]

The videos of last month’s talks are now online:

Rhiana: https://vimeo.com/93790803

Steve: https://vimeo.com/93790802

Pete: https://vimeo.com/94119136

— 

Pat

[Rohan]

Thanks, Pat!

On the topic of avoiding factories, I can see the benefit for unit tests, but I'm curious about the recommendation for integration/acceptance specs, where it seems that a complex tree of objects is often required, since by definition, you're integrating many parts. I could see that being constructed through a factory or a factory-like method, or directly through the UI (which would be impractically slow and couple the spec to parts of the site that aren't the focus of the test). Any thoughts?

Rohan

[Chris Berkhout]

For full-stack integration tests, I'd try to do things through the UI (falling back to putting scenario-specific data straight into the DB only if there is a really good reason to break from full-stack). They're going to be relatively slow anyway.

Keep in mind that at that level of testing you can probably write scenarios that each assert correct behaviour of a bunch of stuff... you don't need to keep it to one assertion per scenario, so slow setup actions have more of a chance to earn their keep.

Cheers,

Chris

[Simon Russell]

This probably belongs in another thread. (I'm one of the random
audience people you probably can't hear in the video.)

But I'd say that I always try and avoid using the UI in full-stack
tests where it's not actually the thing I'm testing, both for
performance and sanity reasons; having to fix a heap of tests because
they rely on a particular UI setup isn't that fun. (Clearly can be
avoided/pain-reduced by wrapping the UI in some helpers for setup
stuff, perhaps even a factory!)

The general guideline I (try to) go by is that in a Cucumber sense,
the "given" step should be DB-direct, the "when" should be UI
invoking, and the "then" should be DB-direct unless you're actually
asserting something about the state of the UI. And you should have
overlapping short stories about how different parts of that process
should work. Note that the main thing I've been working on for the
past couple of years is a fat JS client connected to a non-Rails
backend; but I've found the same pattern to be relevant to Rails apps.

I'm on the not-entirely-convinced-that-factories-are-bad side of the
fence (I use them a lot). They can indeed hide poor design, but the
same can be said about many things. It seemed to me that a lot of the
talk was "change your objects so that create! is the same as a
factory" -- i.e. the default values make business sense, or nulls are
allowed. It works in some situations, but seemed to shift a lot of
the complexity elsewhere, sometimes distributing it throughout your
codebase. I'm not sure that dispersed and potentially duplicated
complexity is any better than concentrated complexity. I'm also
fairly sure that sometimes it's just not possible to have a valid (in
the business sense) object that doesn't have any attributes set.

(I might also add that if you're going to have factories, then they
should be combined with something like Faker to make sure they always
generate different objects; you shouldn't be relying on stuff
hard-coded in factories (or fixtures, for that matter) in your tests.)

It's a good conversation to have though; and it's probably not
actually discussed enough. I've certainly seen a lot of bad things
done with over-reliance on factories (combined with full-stack
integration tests for maximum pain). And some of the design changes
talked about would improve any system.