[LRUG] Chat Digest, Vol 98, Issue 5

Lee Chambers lee.chambers at testdrivenit.com
Tue Mar 4 14:59:30 PST 2014


Always so negative Paton why ? 

-- 
Lee Chambers
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Tuesday, 4 March 2014 at 22:02, 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. [JOBS] London - Backend developer at Audioboo.fm
> (Jonathan del Strother)
> 2. Re: MySQL to Postgres (Matt Spendlove)
> 3. Re: Startup Timeline (MG Lim)
> 4. Re: Rails - The Missing Parts (Uro? Jurgli?)
> 5. Re: Rails - The Missing Parts (Erich Kaderka)
> 6. Re: Rails - The Missing Parts (Simon Coffey)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 4 Mar 2014 18:20:04 +0000
> From: Jonathan del Strother <maillist at steelskies.com>
> To: London Ruby Users Group <chat at lists.lrug.org>
> Subject: [LRUG] [JOBS] London - Backend developer at Audioboo.fm
> Message-ID:
> <CAF5DW8+K+4mRs_vSqOhtrizAmcyhVxe_kkZ4nsPFp9_PxVLhew at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> Hello - I work at Audioboo, where we're looking for a an experienced
> backend engineer for a major expansion programme. Full job
> description below - if you have any questions, you can direct them to
> jon at audioboo.fm, or look me up on Twitter @jdelStrother.
> 
> -Jonathan
> (PS - We're not looking for contact from recruiters right now, thanks)
> 
> 
> 
> 
> Audioboo is a well established audio platform for major news
> organisations, sports teams, broadcasters and audiobloggers worldwide.
> With more than 2.3m registered users, over 1000 channels of pro
> content, and 20 million listens a month, keeping on top of the sheer
> volume of data and keeping our systems running smoothly is a serious
> job.
> 
> Audioboo?s presence is based around a website (http://audioboo.fm),
> the Audioboo app family, and an API which allows partners to integrate
> items as needed.
> 
> Please note this is a heavily technical role - not a management or
> front-end design role - and will be focused on:
> 
> - delivering excellent reliability and uptime, maintenance, and
> improving daily operations
> - expanding our capabilities based on management and application requirements
> - delivering usage statistics and integrating statistics management systems
> - supporting long-term objectives for ourselves and our major
> commercial partners like the BBC, Guardian, Southern Cross Austereo
> and dozens of other major broadcasters worldwide
> 
> **Required Skills/Experience**
> 
> - Ruby
> - Linux administration
> - MySQL administration and query optimization
> - Storing & querying large amounts of stats
> - Working with Amazon Web Services
> 
> **Desirable Skills/Experience**
> 
> - Network systems design and maintenance (server structure, load balancing, etc)
> - System configuration management - eg Chef or Puppet
> - SmartOS and/or Solaris administration
> - Continuous integration & TDD
> - Git
> - Google Analytics API - custom coding will be required
> - Payment systems (Stripe, SagePay)
> - Microsoft Azure, particularly Blob Storage and server creation
> - HTML5, Javascript, CSS3, HAML
> - Flash
> 
> 
> 
> **Personal Profile**
> 
> You should be a dependable, self-starting individual prepared to take
> on and own the safe and smooth running of the core structures.
> You should be an excellent small-team player prepared to work together
> with an expert CTO and the management team to enact rapid change and
> expansion of the platform while keeping all core services running
> smoothly and reliably.
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 4 Mar 2014 18:22:34 +0000
> From: Matt Spendlove <matt at cenatus.org>
> To: Andrew Stewart <boss at airbladesoftware.com>
> Cc: LRUG Users Group <chat at lists.lrug.org>
> Subject: Re: [LRUG] MySQL to Postgres
> Message-ID:
> <CABO-r9z-yaj8G7m-y9r5N+LxrWRMc2SoQnWch4HTGzKJx2fZoQ at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> It was a while back but
> mysql2psql<https://devcenter.heroku.com/articles/heroku-mysql>was
> successful for me. We had a few tables in excess of 3M rows..
> 
> --
> *Matt Spendlove - Cenatus*
> 458 Hackney Road, London E2 9EG
> +44 (0)7976 609379
> http://cenatus.org
> http://netaudiolondon.org
> 
> 
> 
> On Tue, Mar 4, 2014 at 11:12 AM, Andrew Stewart
> <boss at airbladesoftware.com>wrote:
> 
> > Hello LRUG,
> > 
> > What's the current best way to migrate data from MySQL to Postgres?
> > Everything I've found seems to be somewhat, er, "beta".
> > 
> > Thanks in advance,
> > 
> > Andy Stewart
> > 
> > _______________________________________________
> > 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/20140304/b22bb1ff/attachment.html>
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 4 Mar 2014 19:53:50 +0000
> From: MG Lim <mirageglobe at gmail.com>
> To: Oskar Pearson <oskar at deckle.co.uk>
> Cc: chat at lists.lrug.org
> Subject: Re: [LRUG] Startup Timeline
> Message-ID:
> <CAD2douBD7ZDdK1u2rB6BydVnv4qTDCDbrYvFmWeTxUoK6ikM+g at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
> 
> Hi all,
> 
> thanks for your time, in-depth suggested background readings and sharing of
> your experiences. It all boils down to an interesting journey at the end of
> the day.
> 
> Will keep you posted with some updates, nicely wrapped with ruby questions;
> somewhere down the path of between 5~10 years :). or 18 months if we r
> lucky.
> 
> definitely appreciated all the ideas. cheers.
> Jimmy
> 
> 
> On 4 March 2014 09:58, Oskar Pearson <oskar at deckle.co.uk> wrote:
> 
> > Hi Jimmy, All
> > 
> > > I am curious about how things for how ideas move on.... -> panning out
> > to projects -> gathering a team and finally to funding rounds?
> > > 
> > > More of a general discussion; but what have your experiences been; if
> > you have been in that path or part of that path? "I wish I had done that in
> > the beginning" moments..
> > > 
> > > Marketing hells? Traction problems and in reality, the project took a
> > good 3~5 years before media reported it as an overnight success.
> > > 
> > > 
> > > PS: particularly with ruby-based frameworks / meteor styled frameworks;
> > prototypes are quick to be churned out.
> > 
> > If you're interested in this stuff, I'd suggest having a look at the
> > news.ycombinator.com site, and Paul Graham's articles. London also has an
> > occasional hacker news meetup. http://www.meetup.com/HNLondon/
> > 
> > https://github.com/everpix/Everpix-Intelligence is relevant to the
> > funding and founding side of things. It's a dump of all the key VC and
> > other communications for their (failed) company, 2 years in.
> > 
> > Also probably relevant:
> > https://www.compass.co - their reports on key success factors are
> > pretty interesting
> > 
> > http://businessofsoftware.org/2013/02/gail-goodman-constant-contact-how-to-negotiate-the-long-slow-saas-ramp-of-death/
> > 
> > 
> > To quote the Everpix README:
> > > 
> > > Everpix was started in 2011 with the goal of solving the Photo Mess, an
> > increasingly real pain point in people's life photo collections, through
> > ambitious engineering and user experience. Our startup was angel and VC
> > funded with $2.3M raised over its lifetime.
> > > 
> > > After 2 years of research and product development, and although having a
> > very enthusiastic user base of early adopters combined with strong PR
> > momentum, we didn't succeed in raising our Series A in the highly
> > competitive VC funding market. Unable to continue operating our business,
> > we had to announce our upcoming shutdown on November 5th, 2013.
> > ...
> > > Here are some example of common startup questions this dataset helps
> > 
> > answering:
> > > 
> > > * What are investment terms for consecutive convertible notes and
> > an equity seed round? What does the end cap table look like? (see here)
> > > * How does a Silicon Valley startup spend its raised money during
> > 
> > 2 years? (see here)
> > > * What does a VC pitch deck look like? (see here)
> > > * What kinds of reasons do VCs give when they pass? (see here)
> > > * What are the open rate and click rate of transactional and
> > > 
> > 
> > marketing emails? (see here)
> > > * What web traffic do various news websites generate? (see here
> > 
> > and here)
> > > * What are the conversion rate from product landing page to sign
> > 
> > up for new visitors? (see here)
> > > * How fast do people purchase a subscription after signing up to a
> > 
> > freemium service? (see here and here)
> > > * Which countries have higher suscription rates? (see here and
> > 
> > here)
> > > * What frustrates people the most abour their photo collection?
> > 
> > (see here)
> > > * Do people actually edit their digital photos? (see here)
> > > * What would it take to acquire customers through online ads in
> > > 
> > 
> > such a business? (see here)
> > > * How much price sensitive are consumers for such online services
> > 
> > i.e. what's the price elasticity? (seehere)
> > > 
> > 
> > 
> > 
> > Oskar
> 
> 
> 
> 
> -- 
> Jimmy Mian-Guan Lim
> 
> Email - mirageglobe at gmail.com | Profile - www.mglim.com
> Twitter - twitter.com/mirageglobe | LinkedIn -
> uk.linkedin.com/in/mirageglobe
> 
> DracoTurtur <http://www.dracoturtur.com/> | Creative Web Engineering
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140304/df6f9d4d/attachment-0001.htm>
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 4 Mar 2014 19:54:55 +0000
> From: Uro? Jurgli? <jurglic at gmail.com>
> To: chat at lists.lrug.org
> Subject: Re: [LRUG] Rails - The Missing Parts
> Message-ID:
> <CADistHgVqCS9uNah5RT_pfM7fC=WpJme5WxUw7v8NJ5kXHivaw at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Great post Tom! I think most Rails devs that have spent time on a
> multi-year project can relate to your findings. And probably most have
> also come up with own solutions to organise the logic out of the
> controllers and models...
> 
> Having seen many projects with the same issues, I feel it is a missed
> opportunity for Rails not to level up and embrace conventions for
> "enterprise" use - to handle the codebase growth. Let's face it, there
> are more and more working rails application that are big, and they're
> not getting any smaller...
> 
> Off course you can say this is not needed, because you can apply good
> OO practices and cope with the growth... true. Too bad Rails is not
> helping you. More, in a lot of places it seeds anti-patterns and bad
> OO practices for which the price you pay later...
> 
> I think this kind of shift in direction would be well accepted and
> similarly bold but right one as the merger with merb was.
> 
> Tell me I'm wrong :)
> 
> 
> -- 
> Uros Jurglic | https://github.com/jurglic
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Tue, 4 Mar 2014 21:13:08 +0100
> From: Erich Kaderka <erich.kaderka at gmail.com>
> To: Najaf Ali <ali at happybearsoftware.com>
> Cc: London Ruby Users Group <chat at lists.lrug.org>
> Subject: Re: [LRUG] Rails - The Missing Parts
> Message-ID: <C181D0E3-5819-440D-BD30-40E2892323E6 at gmail.com>
> Content-Type: text/plain; charset="windows-1252"
> 
> Hi Tom,
> 
> I enjoyed reading the article until this point: 
> private
> 
> def send_emails_for(grouper)
> LeaderMailer.grouper_confirmed(member: grouper.leader.id).deliver
> WingMailer.grouper_confirmed(wings: grouper.wings.map(&:id)).deliver
> AdminMailer.grouper_confirmed(grouper: grouper.admin.id).deliver
> end
> 
> def assign_bar_for(grouper)
> # Asynchronous job because it?s a little slow
> AssignBarForGrouper.enqueue(grouper.id)
> end
> You can't test this class in isolation (you need to require all 3 mailers and AssignBarForGrouper). Maybe it seems ok now, but if there is in future another email with simple logic, you end up mocking every hard coded dependency for different scenarios. Plus I don't like passing ids to mailers, then in your mailer class you need to query for email ... I would suggest make both private methods public and introduce new object for sending emails
> 
> def send_emails_for(confirm_grouper_mailer: ConfirmGrouperMailer.new(leader_email: grouper.leader.email, wings_emails: grouper.wings.collect(&:email), admin_email: grouper.admin_email)
> confirm_grouper_mailer.deliver
> end
> I don't think you need to test successful interactor, this scenario should be covered by end-to-end test 
> 
> context ?when the interactor is a success? do
> let(:success) { true }
> 
> it { should redirect_to home_path }
> end
> The HN's discussion reminds of similar one here https://gist.github.com/justinko/2838490 
> 
> You can find DHH's opinions on architecture etc on Ruby Rogues episode 056 http://rubyrogues.com/056-rr-david-heinemeier-hansson/
> 
> Thank you for your article,
> 
> Erich
> 
> 
> On 4 Mar 2014, at 15:36, Najaf Ali <ali at happybearsoftware.com> wrote:
> 
> > > Using modules to mix in behaviour is the same as inheritance and the composition over inheritance argument has already been had.
> > 
> > I don't think I'm quite clever enough to follow the whole service objects vs. modules vs. objects vs. dependency injection debate, but this line in particular weakens your argument a little.
> > 
> > The composition over inheritance argument has indeed already been had: the primary reason that composition is better than inheritance is that inheritance needlessly couples type to implementation. Mixing in a module doesn't do that. There are other problems with modules (in particular when you have a lot of them, implicit dependencies can creep in between them) but "they are the same as inheritance therefore bad" strikes me as a little lazy.
> > 
> > 
> > On Tue, Mar 4, 2014 at 2:15 PM, Stephen Best <bestie at gmail.com> wrote:
> > @Riccardo Using decorators over extend gives you
> > 
> > * No method / instance variable naming collisions (counts for private methods too)
> > * Separate state
> > * Very obvious which decorations have been applied
> > * You can unwrap the decorators and get the original object back
> > 
> > The annoying this really is that the difference in effort is negligible yet the module approach is widely cargo-culted.
> > 
> > Using modules to mix in behaviour is the same as inheritance and the composition over inheritance argument has already been had.
> > 
> > 
> > On 4 March 2014 10:24, Riccardo Tacconi <rtacconi at gmail.com> wrote:
> > I created this project (very incomplete) to try few things and one was DCI: https://github.com/rtacconi/scriptrunner/blob/master/app/contexts/runner_on_project.rb. Yes I used 'extend' but it is 'expensive' and using mixins seems okay to me. What's the advantage of using decorators?
> > 
> > 
> > On 4 March 2014 09:37, Stephen Best <bestie at gmail.com> wrote:
> > Also why do Ruby developers insist on implementing DCI by mixing in modules at runtime? It's just completely unnecessary, why not decorate?
> > 
> > 
> > Stephen Best
> > 
> > +44 7745 790523
> > theaudaciouscodeexpiment.com
> > github.com/bestie
> > @thebestie
> > 
> > 
> > On 4 March 2014 09:35, Stephen Best <bestie at gmail.com> wrote:
> > DHH as usual saying the best way to design your objects is don't. GOOD LUCK WITH THAT.
> > 
> > 
> > Stephen Best
> > 
> > +44 7745 790523
> > theaudaciouscodeexpiment.com
> > github.com/bestie
> > @thebestie
> > 
> > 
> > On 3 March 2014 23:09, Mark Burns <markthedeveloper at gmail.com> wrote:
> > It's kind of similar, but DCI is kind of like a run-time only ActiveSupport::Concern.
> > It's still a big bag o' methods, but a big dynamic bag of methods. Maybe less chance of collisions, but
> > the principle is still the same as AS::Concern.
> > Interactors in the sense of the interactor gem are cleaner as you're not polluting a potentially already
> > overloaded domain model/persistence object hybrid.
> > 
> > 
> > On 3 March 2014 22:18, Riccardo Tacconi <rtacconi at gmail.com> wrote:
> > Hi Tom,
> > 
> > Your interactor reminds me the I part (interaction) of DCI, am I wrong? I see few similarities.
> > 
> > 
> > On 3 March 2014 20:38, Tom Blomfield <tomblomfield at gmail.com> wrote:
> > Hi all,
> > 
> > I wrote a blog post on Interactors in Rails - http://eng.joingrouper.com/blog/2014/03/03/rails-the-missing-parts-interactors
> > 
> > You might enjoy the discussion on HN, with DHH wading in https://news.ycombinator.com/item?id=7335211
> > 
> > Tom
> > 
> > _______________________________________________
> > 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://github.com/rtacconi
> > http://riccardotacconi.blogspot.com
> > http://twitter.com/rtacconi
> > 
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org
> > http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> > 
> > 
> > 
> > _______________________________________________
> > 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://github.com/rtacconi
> > http://riccardotacconi.blogspot.com
> > http://twitter.com/rtacconi
> > 
> > 
> > _______________________________________________
> > Chat mailing list
> > Chat at lists.lrug.org
> > http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> > 
> > 
> > _______________________________________________
> > 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/20140304/e9cbf8f1/attachment-0001.htm>
> 
> ------------------------------
> 
> Message: 6
> Date: Tue, 4 Mar 2014 21:21:40 +0000
> From: Simon Coffey <simon at tribesports.com>
> To: Tom Blomfield <tomblomfield at gmail.com>
> Cc: London Ruby Users Group <chat at lists.lrug.org>
> Subject: Re: [LRUG] Rails - The Missing Parts
> Message-ID:
> <CAAK-=xhmyLmnvjZCcxRHUNpPEQoT=YvFoKtRXudiRt5FA0Av=A at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
> 
> On 3 March 2014 20:38, Tom Blomfield <tomblomfield at gmail.com> wrote:
> > 
> > I wrote a blog post on Interactors in Rails -
> > http://eng.joingrouper.com/blog/2014/03/03/rails-the-missing-parts-interactors
> > 
> 
> 
> Nice article, thanks for sharing!
> 
> To play devil's advocate, though: despite using them myself, I'm a bit
> unsure about service objects/interactors/use cases.
> 
> We've got a fair few of them in our main app for things like user
> registration and so forth. While they've cleaned up our controllers
> somewhat, get a modest amount of reuse and are manifestly superior to
> AR lifecycle callbacks, I can never escape the feeling that they're
> still a bit of a junk drawer. ("Yeah, but what have you done for me
> *lately*?")
> 
> Misgivings:
> 
> * non-SRP: creating DB records, sending emails, firing background jobs
> * corollary: they tend to have a whole bunch of dependencies
> * corollorollary: testing them is still a pain (even with DI)
> * what actually *is* a UserRegistrationService instance[1]?
> * why do I have a whole class with a single public "run" method?
> 
> It often feels like they're little more than high-ceremony functions.
> With Interactors there's a bit of success/failure state being
> maintained, but it doesn't seem to do anything that raising exceptions
> wouldn't (less, really, if you've got to handle multiple failure
> modes).
> 
> We've extracted genuine cross-cutting concerns into a pub-sub event
> system[2], so things like email delivery are properly isolated, but
> there's still a gunky residue, which is why we've still got service
> objects.
> 
> So what is that residue? In our codebase it's often things that would
> live in a model constructor if Rails allowed you to define
> constructors for your models. But the pattern isn't consistent enough
> that I can just say, "okay, this gunk compensates for Rails," which
> makes me feel like service objects are still a failure of design
> somehow, but I can't put my finger on what's missing.
> 
> Anyone else share these doubts, or am I just making up problems for myself?
> 
> Cheers,
> Simon
> 
> [1] A ranty version of this objection:
> http://me.veekun.com/blog/2013/03/03/the-controller-pattern-is-awful-and-other-oo-heresy/
> [2] atrocious blogspam, sorry:
> http://techblog.tribesports.com/blog/2012/08/21/pub-sub-system-events-for-post-action-tasks/
> 
> 
> ------------------------------
> 
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org
> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
> 
> 
> End of Chat Digest, Vol 98, Issue 5
> ***********************************
> 
> 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140304/76425da8/attachment.html>


More information about the Chat mailing list