Help running the joint

[Don Morrison]

HI everyone,

As you may have noticed I have been really, really absent from the list and from the meetings. There are a few things that need to happen on a regular basis and I need your help:

* Regular website updates
* Update Twitter
* Update Facebook page (I deleted my Facebook account)
* Remind people on the list that a meeting is coming up
* Host the meeting - we are welcome to use Reno Collective as long as we want

Can I get a volunteer for each of these? One caveat, to take care of Facebook you'll need to be Facebook friends with the other members so you can invite them. Facebook for pages is woefully broken.

I've added a `self` repository to our GitHub Organization and a wiki page for you to register your desire to help.

https://github.com/renorb/self/wiki/Volunteer

Carry on,
Don

--
Don Morrison
@elskwid

[Tim Hammerquist]

Hey Don,

I completely understand. I don't have an abundant supply of time either. Ideally one of our members with an infinite supply of both time and energy can volunteer to make this the best little Ruby group in Nevada. (Anyone? Anyone? Bueller? Bueller?)

In the meantime, I can try to take some of the load off myself. Just let me know what and how, and I'll be as much help as I can.

Thanks for all your work, Don!

Tim

--
You received this message because you are subscribed to the Google Groups "reno.rb" group.
To post to this group, send email to ren...@googlegroups.com.
To unsubscribe from this group, send email to renorb+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/renorb?hl=en.

--
Tim <pen...@gmail.com>

[John Dell]

Don, I'm with Tim on a big collective back pat for you.  Your efforts are much appreciated.

I see penryu has covered everything on the github wiki except FB, so I'll take that.

John

On Wed, Nov 7, 2012 at 9:04 AM, Don Morrison <els...@gmail.com> wrote:

[Don Morrison]

John, Tim,

Thanks for jumping in like that.

Tim, do we need to discuss how to update the site? It's hosted on GH and is just a Jekyll site. We could also update it to use Octopress or something else if you like.

Take care,

Don

--
Don Morrison
@elskwid

On Friday, November 9, 2012 at 1:02 PM, John Dell wrote:

> Don, I'm with Tim on a big collective back pat for you. Your efforts are much appreciated.
>
> I see penryu has covered everything on the github wiki except FB, so I'll take that.
>
> John
>
>
> On Wed, Nov 7, 2012 at 9:04 AM, Don Morrison <els...@gmail.com (mailto:els...@gmail.com)> wrote:
> > HI everyone,
> >
> > As you may have noticed I have been really, really absent from the list and from the meetings. There are a few things that need to happen on a regular basis and I need your help:
> >
> > * Regular website updates
> > * Update Twitter
> > * Update Facebook page (I deleted my Facebook account)
> > * Remind people on the list that a meeting is coming up
> > * Host the meeting - we are welcome to use Reno Collective as long as we want
> >
> > Can I get a volunteer for each of these? One caveat, to take care of Facebook you'll need to be Facebook friends with the other members so you can invite them. Facebook for pages is woefully broken.
> >
> > I've added a `self` repository to our GitHub Organization and a wiki page for you to register your desire to help.
> >
> > https://github.com/renorb/self/wiki/Volunteer
> >
> > Carry on,
> > Don
> >
> > --
> > Don Morrison
> > @elskwid
> >
> >
> > --
> > You received this message because you are subscribed to the Google Groups "reno.rb" group.

> > To post to this group, send email to ren...@googlegroups.com (mailto:ren...@googlegroups.com).
> > To unsubscribe from this group, send email to renorb+un...@googlegroups.com (mailto:renorb%2Bunsu...@googlegroups.com).

> > For more options, visit this group at http://groups.google.com/group/renorb?hl=en.
>
>

> --
> You received this message because you are subscribed to the Google Groups "reno.rb" group.

> To post to this group, send email to ren...@googlegroups.com (mailto:ren...@googlegroups.com).
> To unsubscribe from this group, send email to renorb+un...@googlegroups.com (mailto:renorb+un...@googlegroups.com).

[Tim Hammerquist]

Don: Thanks for the info on updating the https://renorb.org website.

The site has been updated (partially) to reflect current information.
A few ideas for topics have been listed, and there's always the option
for a workshop style meeting. If you have any other ideas, please
share them with all of us by replying to the list. And if you just
want to show support for a particular topic or for the workshop
format, please do so!

Cheers!
Tim

[John Dell]

Hey Tim,

http works but not https.  Since we don't have an SSL cert, I wouldn't float that URL around.

John

Tim

--
You received this message because you are subscribed to the Google Groups "reno.rb" group.

To post to this group, send email to ren...@googlegroups.com.
To unsubscribe from this group, send email to renorb+un...@googlegroups.com.

[Tim Hammerquist]

Yes, you're right, John.

Everyone, please use http://renorb.org until we can secure a CA-signed SSL cert. (That was actually a typo - force of habit.)

---

From: John Dell
Sent: 11/21/2012 9:39
To: Reno.rb
Subject: Re: {reno.rb} November meeting topics

[Andy Koch]

Migrating away from rspec?  Por que?

Andy Koch

[Don Morrison]

> Migrating away from rspec? Por que?

We've been migrating to minitest most of the year on our various projects and we've found a few things:

1) Speed gains - minitest is much, much faster. Mainly by virtue of it being simpler. Go check out the implementation https://github.com/seattlerb/minitest it's good stuff.

2) Design focus - RSpec gives you all kinds of amazing tools to do lots of crazy things in your specs/tests. When you trim down that toolset you may end up feeling some pain that you should have been feeling before but RSpec was making it easy for you. I'm looking at you #any_instance! That pain is a great motivator to improve your system design.

3) We can still use shoulda matchers!

4) Speed gains - did I mention those yet?

There's some other tangential stuff but that's what's been driving our move.

Don

[John Dell]

On Wed, Nov 21, 2012 at 10:25 AM, Don Morrison <els...@gmail.com> wrote:

2) Design focus - RSpec gives you all kinds of amazing tools to do lots of crazy things in your specs/tests. When you trim down that toolset you may end up feeling some pain that you should have been feeling before but RSpec was making it easy for you. I'm looking at you #any_instance! That pain is a great motivator to improve your system design.

Man, I'm addicted to any_instance in my controller specs when I want to cover failing paths based on some model attributes.  How do you avoid that without veering into Model territory?  I've looked at mini-test many moons ago, but not having any_instance was too much to give up. 

[Don Morrison]

> > 2) Design focus - RSpec gives you all kinds of amazing tools to do lots of crazy things in your specs/tests. When you trim down that toolset you may end up feeling some pain that you should have been feeling before but RSpec was making it easy for you. I'm looking at you #any_instance! That pain is a great motivator to improve your system design.
>
>
> Man, I'm addicted to any_instance in my controller specs when I want to cover failing paths based on some model attributes. How do you avoid that without veering into Model territory? I've looked at mini-test many moons ago, but not having any_instance was too much to give up.
>

Without seeing the exact example I would recommend using controller tests like unit tests for your controller classes. Keep them light. Don't spend a bunch of time testing which variables are assigned and all that (the internals of the controller actions). Instead, make sure that the action is available and accepts the correct attributes and (maybe) renders the correct view. Then use integration tests (with Capybara for example) to test the integration of controller class + model classes + conditions which can cover those failing paths you mentioned.

We could definitely go over this in more detail either on list with a gist of some code or at the next meeting. I've enjoyed pushing on my testing and design practices this way.

>
> --
> You received this message because you are subscribed to the Google Groups "reno.rb" group.

> To post to this group, send email to ren...@googlegroups.com (mailto:ren...@googlegroups.com).
> To unsubscribe from this group, send email to renorb+un...@googlegroups.com (mailto:renorb+un...@googlegroups.com).

[John Dell]

On Wed, Nov 21, 2012 at 10:53 AM, Don Morrison <els...@gmail.com> wrote:

> > 2) Design focus - RSpec gives you all kinds of amazing tools to do lots of crazy things in your specs/tests. When you trim down that toolset you may end up feeling some pain that you should have been feeling before but RSpec was making it easy for you. I'm looking at you #any_instance! That pain is a great motivator to improve your system design.
>
>
> Man, I'm addicted to any_instance in my controller specs when I want to cover failing paths based on some model attributes. How do you avoid that without veering into Model territory? I've looked at mini-test many moons ago, but not having any_instance was too much to give up.
>

Without seeing the exact example I would recommend using controller tests like unit tests for your controller classes. Keep them light. Don't spend a bunch of time testing which variables are assigned and all that (the internals of the controller actions). Instead, make sure that the action is available and accepts the correct attributes and (maybe) renders the correct view. Then use integration tests (with Capybara for example) to test the integration of controller class + model classes + conditions which can cover those failing paths you mentioned.

We could definitely go over this in more detail either on list with a gist of some code or at the next meeting. I've enjoyed pushing on my testing and design practices this way.

Ok, yea, I tend to keep my integration tests mixed in with my other tests which is probably a bad habit.  Looking at my code, most every instance of any_instance is in a spec that is acting like an integration test.  This would make a good meeting discussion topic.

[Don Morrison]

> This would make a good meeting discussion topic.

We could also do a periodical Google Hangout code review session. Weekly for an hour or so might be a lot of fun.