Do you have any insight into how many of your customers buy Sidekiq Pro for the extra features, as opposed to for the commercial-friendly license, or simply to help sustain the OSS development?
You've added new features to Sidekiq Pro over time -- do you think your business would have been viable had you started with no (or very few) additional paid features?
Most buy for the features. It's hard for a business to justify giving money to someone for nothing. I'm a big fan of selling something tangible, even if rather minor, rather than just a license. My guess is that I'd have 25% of my current sales if I just sold support/license.
I could be wrong but it seems to me that only the latest two designs (A Robot Named Jimmy and Verde Moderna) are what would be considered "modern" designs and the rest are from before the relaunch.
What's worse is that the two most common languages on GitHub (Ruby and JavaScript) are represented by shades of red/orange. I almost thought one of my repositories was in some kind of error state when I first opened it in the new design.
This exact same situation happened to me in the past month. My login page and its assets were copied, right down to the Rails asset digest fingerprints in the filenames as well as the Google Analytics code, which is how I discovered them.
I sent a sternly worded "Notice of Copyright Infringement" email and two weeks later their whole site was completely redesigned.
One option would be to use a service object (e.g. UserCreator) which would encapsulate the action (saving a user) along with the action to be taken (delivering a signup email).
With external observers, it's not always obvious whether they are enabled or not. Service objects make this more explicit and are easier to test as well.
A before_filter is just a method that runs before an action - there's no requirement for it to set an instance variable or redirect. In Rails 4, this method has been aliased as before_action to make this clearer.
Since the behavior of this method doesn't have too much to do with showing a topic, I think it makes sense. Extracting it also makes it possible to move it up to the ApplicationController for wider use.
Extracting it into a separate method is what makes it available for wider use--not the before_filter.
That said, you provide a justification--the topicality of the code itself to the idea of "show." It is a decent point that I missed in the article. I'll have to think on that.
I question this logic living in the controller at all, though. It looks like a model logic that should, from the controller perspective, look like current_user.review_for_promotion.
I don't mean to dwell on the technical issues, but I'd be very curious to hear more about the performance issues you encountered that the Rails Core members couldn't resolve. Was there ever any resolution apart from downgrading to 2.x, and are there certain things that should be avoided in Rails 3.x?
Whatever it was, it is gone now. This was Rails 3 early days… very early days. The problem was in the development environment only. It was a crazy memory leak — 50MB every page load or so. As you can imagine it because so unbearably slow we couldn't develop in it. Bizarrely it didn't manifest in production (even if we just flipped the bit to run mongrel — or was it nginx at the time ? — in production on the same dev computer/user/PATH, etc). You'd think that would make it easier to track down, but weirdly, it didn't.
I don't mind at all answering technical questions, ask away. What I object to is people who spot a jargon term or two they understand and fail to read all the surrounding paragraphs, and then lambast me for something they know nothing about. Which you clearly didn't do :)
> I'm also north of 90% probable that I could weaponize it to turn any image tag on the Internet into "roots your local machine"
Definitely not saying you're wrong, but I'm not convinced this is doable. Every exploit I've seen requires a request body -- how would you do that with an IMG tag?
Go on a Rails security safari, armed with the knowledge that any YAML parsing is victory, and pay very careful attention to code paths involving Rails/Rack route/parameter processing, especially anything which smells of magic. To clarify: I haven't actually done the work yet.
I'm actually going on a Rails security safari later, though not particularly looking to widen this/these vulnerabilities. I figure I've gotten enough out of the community over the years to contribute part of a workweek and get one more hole plugged.
Not unless nginx/apache routes the request directly to public/. There will definitely be more code-paths to YAML.load, but so far ActionDispatch::Http::Parameters has been the entry point.
You've added new features to Sidekiq Pro over time -- do you think your business would have been viable had you started with no (or very few) additional paid features?