Disqus - Latest Comments for skwp

Re: NO CHARGES OF TRUMP COLLUSION: Here's What You Need To Know About The Manafort Indictment

skwp — Mon, 30 Oct 2017 13:36:13 -0000

> but emails, uranium, hillary
> but bill clinton got paid too much
> but ..

that was in the past. let it go. she didn't win the election. it's time to fix the mess we have

Re: NO CHARGES OF TRUMP COLLUSION: Here's What You Need To Know About The Manafort Indictment

skwp — Mon, 30 Oct 2017 13:34:18 -0000

> there are literally no signs of collusion
donnie jr admits to meeting with russians to discuss magnitsky in exchange for dirt on hillary
> there are literally no signs of collusion
manafort is indicted
> there are literally no signs of collusion
trump goes on a tweet rampage
> there are literally no signs of collusion

I agree, there's probably no collusion here. But there sure is a whole lot of stupidity.

> but he's a great businessman
who picks terrible people to surround himself with

> but he's winning
can't pass any legislation with both houses under his control

> but he's working hard
golfs more than obama

> but he's draining the swamp
employing his family and billionaires

> but he's implementing policies we like
is he?

when the clown car crashes, who will be the one without an airbag? the internet has a long memory, mr shapiro. retain your dignity and stop this madness.

Re: Reverb.com Dev Blog | Scalable code without bloat: DCI, Use Cases, and You

skwp — Mon, 28 Jul 2014 10:14:54 -0000

@lwoodson really good summary. I'm going to get into namespaces and such in a later post probably, but I agree wholeheartedly with all your points.

@Dave Aronson yes definitely, we can nounify the verbs, and I'm not at all preaching that verbs are the only way to go, simply that reifying the process is the key. I do have a weak opinion in favor of verbs because they often map the most closely to business process language. However, we do use nounified versions when they are the most intuitive to read in English. In fact, I argue that English readability and mapping to business domain should trump almost everything else in naming, including any kind of consistency (all verbs vs all nouns).

Re: Reverb.com Dev Blog | HAL, Siren, Rabl, Roar, Garner: Building Hypermedia APIs in Ruby/Rails

skwp — Wed, 02 Jul 2014 16:32:59 -0000

Are you talking about on the client side? No, generally on the client we are just using glorified hashes. So we're not deserializing into objects, we're just deserializing into openstructs/dotted hashes. So in a sense yes we have the associations because nested hashes turn into nested objects. But not anything railsy. Also it's because on the client side we are not usually inside of Rails so we don't want AR objects or anything like that.

Re: Reverb.com Dev Blog | HAL, Siren, Rabl, Roar, Garner: Building Hypermedia APIs in Ruby/Rails

skwp — Wed, 02 Jul 2014 15:01:24 -0000

hey Clay, we are serializing using Roar/Representable. I haven't used activemodel serializers so I'm not sure... Roar does have bi-directional serializer/deserializer but in practice we have not used it. Instead we serialize using Roar and typically read it in on the other side using something like Hashie::Mash/Trash. Not sure if this answers your question or confuses things further :)

Re: My GPA at Code Climate is 3.59: A refactoring story - Black Matter

skwp — Thu, 01 May 2014 16:53:50 -0000

You might also remove all conditionals entirely by putting the knowledge about which locations to store into the controllers themselves. I.e. UserConfirmationController can say `skip_before_filter :store_location` if you don't want to store that location. Then each controller knows whether it should be stored or not, and you have no conditional or regex.

Re: Reverb.com Dev Blog | Testing complex conditionals

skwp — Fri, 07 Mar 2014 13:05:17 -0000

Hi, just a few clarifications on should syntax

1. the should syntax is not deprecated, it's simply not preferred

2. should syntax for one-liners like "it { should foo }" cannot be done with expect, and is actually fully supported. they decided to keep the syntax. See discussion here:

https://github.com/rspec/rs...

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Sun, 02 Mar 2014 09:06:25 -0000

Yes, most of the time when they belong to a specific part of the domain. So we might have workers/auctions for some of our auction related workers.

Re: Fender American Deluxe Telecaster 2011 Aged Cherry Burst Price Guide | Reverb

skwp — Sat, 15 Feb 2014 13:42:23 -0000

Hey Matt, Reverb is a marketplace - you commented on one of our price guides here, but you can check out a similar tele for sale on the left

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Wed, 29 Jan 2014 10:49:56 -0000

Exactly, although I have to say that app/workers feels a little wrong to me, since workers are not truly specific to the Rails app. They could in fact live in another application that just did sidekiq work. But we haven't broken out workers from the main app so it's fine for now.

The idea is the domain layer knows nothing of Rails. It may occasionally use activesupport for convenience, and it does talk to AR models, but it can theoretically be pulled out into a separate service layer, or non-Rails application.

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Wed, 29 Jan 2014 10:21:45 -0000

Hi Rafael,

We do have some structured folders (app/decorators, app/workers), but in our domain layer we lump together objects based on what some people would probably call a "bounded context", although we do it in a less religious fashion. Meaning, we'll have a namespace like "accounts" and inside we'll have CreateAccount, but if that uses some value object (say a Username), that object might just live there alogside the usecase. So far, we've been pretty narrow in our namespaces so that each folder ends up containing maybe 5 or so classes. In some cases if the domain is very complex, we'll create additional namespaces/folders inside there to hold subsections. However, we do not create folders like "services" or "value_objects" or etc.

So far we are preferring the modeling of the system to flow naturally - whatever english language and domain concepts are natural, rather than saying "these things are Services" and "these things are Foos" and assuming anything about their structure. The downside is that there isn't necessarily a clear pattern to what UseCase is in our system - but the upside is we haven't boxed ourselves in to any patterns either, as we're feeling out what works and what doesn't. Hope this made sense :)

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Thu, 23 Jan 2014 17:45:45 -0000

Frankly we are trying to move away from autoloading as much as possible, but for now we have our autoload_paths having "#{config.root}/app" as a folder. This allows everything including app/reverb to get autoloaded in Rails. Although in our domain layer we explicitly require classes so we can fast_spec them.

We are starting to form the opinion that autoloading is toxic for the same reasons as outlined in Myron Marton's awesome blog here: http://myronmars.to/n/dev-b...

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Thu, 23 Jan 2014 12:07:04 -0000

You could probably also inherit from a model and define scopes there, thus making it more like a Role. Although I would prefer to implement Roles with composition/decoration, I'm not sure that AR scopes are definable in any way except through inheritance.

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Thu, 23 Jan 2014 12:05:53 -0000

To tell you the truth, this is a problem we have not solved sufficiently well. The short answer is we haven't felt enough pain here to dig into it, but the long answers are:

One way to combat too many scopes is to think about externalizing scopes to related objects. For example instead of User having hundreds of scopes like "sold_products", maybe you just do Product.sold.for_user. Or externalize into query objects like SoldProducts.for(user). These are techniques we use rarely, usually in the case of complex queries or scopes. Another way I can think of doing this is by "DCI" style of extending a model at runtime, something like user.extend(ProductScopes). I don't know how well that would work.

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Sat, 18 Jan 2014 13:17:49 -0000

We typically test them in isolation, and stub the boundary in the controller using something like stub_wisper_publisher, which is an rspec extension I wrote for Wisper. I'm planning to improve that bit so that it can better test publishers that take arguments, which is currently not easy to do. Sometimes if it's hard to test with stubbing, we do one happy path integration test from the controller.

Re: Reverb.com Dev Blog | Removing conditional logic, a thought experiment

skwp — Fri, 17 Jan 2014 13:56:57 -0000

That's a great technique Kris - I forgot to add it to my list above.

Re: Reverb.com Dev Blog | Ten resources for taking your Ruby skills to the next level

skwp — Wed, 08 Jan 2014 22:15:15 -0000

John it's great to hear from you! What's this about students - are you teaching?

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Fri, 27 Dec 2013 21:41:09 -0000

Cool. Personally, I would opt for a "def self.foo" for module functions for reasons of clarity, as well as visibility within a larger file. You can instantly see that it's a class method / module method that way.

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Thu, 26 Dec 2013 15:43:52 -0000

Functional programming is fun but Ruby is still very OOP oriented. Trying to make it look and behave like a functional language likely leads to "unusual" code, e.g. the module_function which has not been used on any of the projects I've worked on. If you write unusual and nonstandard code, you put the burden of understanding on people who have to maintain it, which I would say is a very bad idea. I would write idiomatic code stylistically in line with what most people are doing on most major projects.

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Thu, 26 Dec 2013 15:41:46 -0000

Yes we try to have one public entry point per class. If you have more than one it usually implies the class is doing more than one thing. This is the case for use case classes; there is obviously a case for having classes with many public methods when you're talking about value objects or something like that, but for use cases, I believe there should be only one method. I'd like to hear differing opinions on this..

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Thu, 26 Dec 2013 15:38:16 -0000

Yes, there are good and limited uses for send and dynamic methods, but be careful of the trade off. You might one day think to delete the foo_sign_in_path method not realizing it's being called by this other bit. Of course if you have proper good 100% test coverage you should be ok...but the reality seems to be that once code like this sneaks into the code base it's harder to figure out all the usages. Not saying it's terrible, just that it has a potentially high maintenance cost as your codebase grows.

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Fri, 20 Dec 2013 09:30:21 -0000

Hi Ilya, our Use Cases are pretty varied depending on when they were written. As I mentioned, we sometimes just use #execute methods although recently we try to be a little more semantic in the naming. Here are a few examples:

Reverb::Refunds::DirectCheckoutRefund.process_refund <-- newer usecase using a method name Reverb::Checkout::FinalizeOrder.finalize_order <-- repetitive method name Reverb::Curation::DisplayManager.random_for_homepage <-- this is a query to display stuff Reverb::Billing::LineItemBuilder.build_line_item <-- more noun-based naming for a Factory/Builder class

Many usecases will provide static methods as shown above, but are actually often used instantiated, because we use a listener framework (the excellent Wisper by Kris Leech). So we'll do something like this:

refund_processor = Reverb::Refunds::DirectCheckoutRefund.new(order, amount: 100) refund_processor.on(:success) do |refund| # some stuff end refund_processor.process_refund

I don't know if these are great examples, we are still trying to figure out what works or what doesn't. As I said, the main consideration for us is how closely it maps to non-developer terms for these things.

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Thu, 19 Dec 2013 14:07:52 -0000

Hey Nathan, I agree with your approach above. In fact it is what we are doing most of the time.

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Wed, 18 Dec 2013 19:57:08 -0000

Thanks!

Re: Reverb.com Dev Blog | Five architecture anti-patterns and solutions for large Rails applications

skwp — Wed, 18 Dec 2013 14:33:01 -0000

Wow, I've been doing ruby for 8 years and have never heard of module_function. So my first reaction is - that sounds a bit obscure and unusual.

I always prefer real classes that can instantiate themselves, break their functionality up into small methods that may access some ivars set by the initializers. Even if you provide a public API that involves a class level method as an entry point, instantiating yourself can often lead to cleaner code, especially for non-trivial use case classes that will need to talk to a variety of data and collaborator objects. Initializers are a good place to offer injectable dependencies as well.