[LRUG] Chat Digest, Vol 81, Issue 26

Wed Oct 31 06:03:41 PDT 2012

Agreed. 

Tom, have you looked at OpenGL shaders for performance? I've been playing with GPUImage the last week or so; it's for iOS but the plain OpenGL ES GLSL shader strings are in the implementation files.

Also reading the post I'll mention that more data input might not necessarily be better, e.g 120fps and high resolution frames of course mean more pixels to process (not to mention more noise from the sensor). For the project I'm working on I found quite a small image gave the best results, but as always YMMV!

Cheers

S

Sent from my iPhone

On 31 Oct 2012, at 12:30, chat-request at lists.lrug.org wrote:

> Send Chat mailing list submissions to
>    chat at lists.lrug.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>    http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> or, via email, send a message with subject or body 'help' to
>    chat-request at lists.lrug.org
> 
> You can reach the person managing the list at
>    chat-owner at lists.lrug.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Chat digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Pool Ball Tracker (Riccardo Tacconi)
>   2. Re: Looking for recommendations for a tester on a Rails
>      project (Graham Ashton)
>   3. Re: Looking for recommendations for a tester on a Rails
>      project (James Riley)
>   4. Re: Looking for recommendations for a tester on a Rails
>      project (JB Steadman)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 31 Oct 2012 11:18:42 +0100
> From: Riccardo Tacconi <rtacconi at gmail.com>
> To: Tom Blomfield <tom at gocardless.com>
> Cc: London Ruby Users Group <chat at lists.lrug.org>
> Subject: Re: [LRUG] Pool Ball Tracker
> Message-ID:
>    <CAAvWcKG1OdJbx61Y8JiKKArkrf2RqZZkst7KMKFJKrW-uWFMMQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi Tom,
> 
> It's a really cool project!
> 
> Cheers,
> 
> Riccardo
> 
> On 30 October 2012 14:23, Tom Blomfield <tom at gocardless.com> wrote:
> 
>> Hi all,
>> 
>> I emailed around a month or two ago about a GoCardless hackday for an
>> OpenCV pool-ball tracker that we're writing in C++ and Ruby.
>> 
>> A couple of people came along (thanks Stevie & Riccardo!), along with a
>> bunch of GoCardless people.
>> 
>> The preliminary results are now online -
>> http://blog.gocardless.com/post/34568593614/hacking-on-side-projects-the-pool-ball-tracker
>> 
>> Comments/suggestions welcome!
>> 
>> Tom
>> ---
>> GoCardless
>> 
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>> 
>> 
> 
> 
> -- 
> Riccardo Tacconi
> Ruby on Rails and PHP development - System Administration
> VIRTUELOGIC LIMITED <http://virtuelogic.net/>
> 
> http://github.com/rtacconi
> http://riccardotacconi.blogspot.com
> http://twitter.com/rtacconi
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20121031/a4f6491b/attachment-0001.htm>
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 31 Oct 2012 10:48:13 +0000
> From: Graham Ashton <graham at effectif.com>
> To: London Ruby Users Group <chat at lists.lrug.org>
> Subject: Re: [LRUG] Looking for recommendations for a tester on a
>    Rails    project
> Message-ID: <98475A58-1A62-4E57-81FE-37C1963F5EFE at effectif.com>
> Content-Type: text/plain; charset=iso-8859-1
> 
> On 31 Oct 2012, at 07:51, Najaf Ali <ali at happybearsoftware.com> wrote:
> 
>> Just another data point, but I've had a somewhat different experience to Ronny working with dedicated QA. At the one company where this was done we had one dedicated tester per every five or six developers. They had two basic functions for a given user story:
>> 
>> 1. Make sure that developers had implemented the acceptance criteria.
>> 2. Break the shit out of everything.
> 
> My experience is similar to Najaf's. I was working in a heavily regulated industry, building desktop applications on top of distributed databases.
> 
> At one point I remember we had 1 tester for every 2 developers, and I think that ratio remained fairly constant as the development team grew.
> 
> We also TDD'd everything that we could. Back then writing automated tests for GTK apps wasn't an option, so we had to check that the GUI was still hooked up and working manually (from a TDD perspective, I find it interesting that the thin view layer that sat on top of our controllers rarely broke).
> 
> We covered acceptance criteria by getting a "customer" to review everything we'd done before we handed it over to the test team. The test team were over worked as it was, so it was important to make sure they were only testing things that solved the users' problems and were likely to make it into production.
> 
> The testers' main role was (as Najaf said) to break everything. I found it amazing how bad at that developers really were. The knowledge of how something has been put together severely limits your imagination when trying to come up with failure modes.
> 
> That's not to say that developers couldn't quickly home in on lots of things that were likely to fail; we could. We just weren't good enough at thinking outside the confines of how we'd implemented it, and that was what was needed to find the whacky stuff that users would stumble into.
> 
> The big difficulty we had hiring testers was finding people who were interested in it. People who aren't motivated to break your app don't do a good job.
> 
> You'd think I should be able to recommend somebody. The only good tester I'm still in contact with taught himself to code on the side, then founded a company with a SaaS app that he built in his spare time.
> 
> --
> Graham Ashton
> Founder, The Agile Planner
> http://www.theagileplanner.com | @agileplanner | @grahamashton
> 
> 
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Wed, 31 Oct 2012 11:39:51 +0000
> From: James Riley <james at codansa.com>
> To: Graham Ashton <graham at effectif.com>
> Cc: London Ruby Users Group <chat at lists.lrug.org>
> Subject: Re: [LRUG] Looking for recommendations for a tester on a
>    Rails project
> Message-ID: <681DCA294EF34F5F9E2461C37BC2BBA0 at codansa.com>
> Content-Type: text/plain; charset="utf-8"
> 
> You raise some great points Graham, particularly that developers are bad at testing their own code. I've found this is particularly a problem when the application is one where the developers don't make regular use of it themselves. This can be either because what the business offers is not a service they'd personally use or because it's part of a backend application used by other departments of the company, such as the CMS for managing products.  
> 
> When working with testers/QA in the past, I've found it to be of great help and rather than make me lazy, have me working harder to pass on stable code to testers, knowing that I'm wanting to get code live and not delay the process. You want to 'put the ball in their court' with as few issues as possible, which also frees up their time to dig into the deeper, darker corners of the app and unearth issues that'd otherwise be overlooked.  
> 
> Interestingly, the testers I do know, do not enjoy the role and are looking to becoming full-time programmers so I'm unable to recommend any but would suggest it may be worth considering hiring a developer who's duties would include finding and fixing bugs. You'd get the benefits of having a second pair of eyes, a technically literate tester and the added bonus of the individual being able to fix the issues they find. You'd then simply hire another developer to test this new employees code, who could provide the same benefits, but then you'd need to hire ano? may need to rethink this approach, hah  
> 
> James Riley
> @mrjamesriley | SupaDupa.me
> 
> 
> On Wednesday, 31 October 2012 at 10:48, Graham Ashton wrote:
> 
>> On 31 Oct 2012, at 07:51, Najaf Ali <ali at happybearsoftware.com (mailto:ali at happybearsoftware.com)> wrote:
>> 
>>> Just another data point, but I've had a somewhat different experience to Ronny working with dedicated QA. At the one company where this was done we had one dedicated tester per every five or six developers. They had two basic functions for a given user story:
>>> 
>>> 1. Make sure that developers had implemented the acceptance criteria.
>>> 2. Break the shit out of everything.
>>> 
>> 
>> 
>> My experience is similar to Najaf's. I was working in a heavily regulated industry, building desktop applications on top of distributed databases.
>> 
>> At one point I remember we had 1 tester for every 2 developers, and I think that ratio remained fairly constant as the development team grew.
>> 
>> We also TDD'd everything that we could. Back then writing automated tests for GTK apps wasn't an option, so we had to check that the GUI was still hooked up and working manually (from a TDD perspective, I find it interesting that the thin view layer that sat on top of our controllers rarely broke).
>> 
>> We covered acceptance criteria by getting a "customer" to review everything we'd done before we handed it over to the test team. The test team were over worked as it was, so it was important to make sure they were only testing things that solved the users' problems and were likely to make it into production.
>> 
>> The testers' main role was (as Najaf said) to break everything. I found it amazing how bad at that developers really were. The knowledge of how something has been put together severely limits your imagination when trying to come up with failure modes.
>> 
>> That's not to say that developers couldn't quickly home in on lots of things that were likely to fail; we could. We just weren't good enough at thinking outside the confines of how we'd implemented it, and that was what was needed to find the whacky stuff that users would stumble into.
>> 
>> The big difficulty we had hiring testers was finding people who were interested in it. People who aren't motivated to break your app don't do a good job.
>> 
>> You'd think I should be able to recommend somebody. The only good tester I'm still in contact with taught himself to code on the side, then founded a company with a SaaS app that he built in his spare time.
>> 
>> --
>> Graham Ashton
>> Founder, The Agile Planner
>> http://www.theagileplanner.com | @agileplanner | @grahamashton
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org (mailto:Chat at lists.lrug.org)
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>> 
>> 
> 
> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20121031/3293e1a8/attachment-0001.htm>
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 31 Oct 2012 12:30:45 +0000
> From: JB Steadman <jb at pivotallabs.com>
> To: Chris Adams <chrisdaggimoh at gmail.com>
> Cc: London Ruby Users Group <chat at lrug.org>
> Subject: Re: [LRUG] Looking for recommendations for a tester on a
>    Rails    project
> Message-ID:
>    <CAK5aQA7F0Kq0MyY1SRDba1exJ1UmEkr7disdQfGEi4PRt7G7GQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hey Chris -
> 
> I've worked on projects with & without dedicated QA and have always been
> thankful to have them around. If you put some effort into collaborating
> with them, they can be invaluable in finding issues for which developers
> have a blind spot.
> 
> I'd encourage you to spend time using the app together and talking about
> the problems you see, not only when they just get started, but also
> occasionally thereafter. It's important to make them feel they have
> partners in the process.
> 
> Here are some other things I've found helpful for QA
> 
> - Actually make QA staff responsible for *quality. *QA can be a very
> unrewarding job when it's just about finding bugs or determining whether
> the app meets spec. Those are aspects of quality, but they are not the full
> picture. Grant them purview to say things like "this flow doesn't really
> make sense - I think there's room for improvement". Give them authority to
> reject work based on such higher-level problems. You'll get a happier and
> more deeply involved partner in quality.
> 
> - Involve them at the beginning of the feature development process. Include
> them in early planning discussions, even for provisional features that
> might never get built. Understanding the history of how a feature came to
> exist will contribute to meaningful testing. Additionally, full-cycle
> involvement will make QA staff feel like true team participants.
> 
> - Throughout the development lifecycle, I and the other engineers on the
> project spend dedicated time during the workday using the app. This is time
> that we would otherwise spend coding, and it's in addition to the
> application usage that occurs naturally as part of building features. About
> a half hour per engineer per week can get very good results.
> 
> Good luck!
> 
> JB
> 
> 
> 
> 
> 
> On Mon, Oct 29, 2012 at 11:13 PM, Chris Adams <chrisdaggimoh at gmail.com>wrote:
> 
>> Hi guys,
>> 
>> We're looking into hiring a tester to work with us in on a project we've
>> been building for the last 6 weeks or so,  to help catch bugs and issues
>> before they make it to production on a Rails app we're working on at AMEE.
>> 
>> We're working on an app that's fairly well protected by tests, but has a
>> few complex ajax interactions that keep catching us off guard as we
>> develop, so we're looking for someone who is particularly good at ferreting
>> out these kinds of issues.
>> 
>> The app is pretty small, so I assume we'd be looking for someone who might
>> be available on a freelance basis.
>> 
>> However, I haven't really worked with dedicated testers before, so this is
>> fairly new territory for me - does anyone on list have any recommendations
>> of people you've worked with, or any advice on working with testers like
>> above?
>> 
>> Thanks,
>> 
>> Chris
>> 
>> 
>> 
>> --
>> Chris Adams
>> mobile: 07074 368 229
>> skype: chris.d.adams
>> twitter: mrchrisadams
>> web: http://chrisadams.me.uk
>> 
>> 
>> _______________________________________________
>> Chat mailing list
>> Chat at lists.lrug.org
>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>> 
>> 
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20121031/aca40b1f/attachment.htm>
> 
> ------------------------------
> 
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> 
> 
> End of Chat Digest, Vol 81, Issue 26
> ************************************