"We have two people who work full-time on products (one developer and one designer). It's often easier to accomplish some open source, blog writing, or workshop content during a one-day period as opposed to deep product development. So, I like PatientLikeMe's idea of a week every six weeks a lot. Fixing bugs, tracking new metrics, adding some polish, or implementing smaller (1- and 2-point) user stories are reasonable one day activities, though, and the deeper items can be handled by the two person full-time team."
- Dan Croak
"No, we schedule one "investment day" per week. For most people, it's Friday. It's alternative, Monday-Thursday, are "revenue days" (consulting for 14 team members, products like Airbrake, Trajectory, and Copycopter for 2 others). Same thing as Google's 20% time. Most people use their investment day for one of a few categories of things: * tool-building (open source, web services) * personal development (reading, pairing, reflecting) * content marketing * creating learning opportunities for others (workshops, ebooks, screencasts)"
- Dan Croak
"Those are the days we puff pipes, surround ourselves with mahogany, and debate investments: "You can't become a bloody fiscal hermit crab every time the Nikkei undergoes a self-correction! Asia's market has nowhere to go but up!" ... "Interesting." ... "Quite.""
- Dan Croak
"Is there an advantage beyond not having to type "bundle exec"? I've got aliases like "bake" for "bundle exec rake" and it's been fine. Is there less load time?"
- Dan Croak
"Great points. Agreed all around. A big step before qualifying and closing candidates is sourcing and attracting them. Lot of ideas on this New York City Ruby thread: http://www.meetup.com/NYC-rb/m..."
- Dan Croak
""What was the last Boston product that you thought was a beautiful product?" I don't think that question will stump people in 2012. My bet is you'll start to hear a consistent answer: LevelUp. That would be my answer right now. It is beautiful in it's design, in it's simplicity, how obvious it feels while using it (why wouldn't I take a $3 discount right now?), and how it affects all your other purchases (it's annoying to have to sign credit card receipts now). Before LevelUp, I probably would have said Zipcar. Their web app is beautiful, as is their iPhone app, and the whole experience is so useful and well-run that I have frequently advocated on their behalf to my friends and family."
- Dan Croak
"Jeff Cohen I'm not sure I understand how modules aren't inheritance if they are inserted into the lookup path. Can you explain your position a little more? How is it not inheritance when the lookup path looks like this? https://github.com/ryanlecompt... [#<class:b>, M3, #<class:a>, #<class:object>, #<class:basicobject>, Class, Module, Object, MethodLocator, Kernel, BasicObject]</class:basicobject></class:object></class:a></class:b>"
- Dan Croak
"@c84807bb5457755ec17ba32ff713a9b2 No reason, and I really like that linked article. I should have included in the list of "delegate" libraries I mentioned here: "So, let's say we do care about the transparent interface requirement. That's usually accomplished with method_missing or something from Ruby's delegate library like Delegator, SimpleDelegator, or Forwardable." I'll edit the post to include DelegateClass. My understanding of when you'd use DelegateClass over the others is that you know which class you want to decorate. It has a set interface and is faster than method_missing. Here's another real-world usage of DelegateClass: https://github.com/thoughtbot/..."
- Dan Croak
"Josh Clayton I really like that BasicObject code. The #class is maintained because you're subclassing from BasicObject and because you're defining #==?"
- Dan Croak
"Lin He I absolutely agree that version feels most natural in Ruby. While researching, I came across a number of posts that add a DSL to their decorator code, like coffee.with(:milk, :sugar). I don't think that's necessary when you have the nice #extend method revealing intent.I also agree with you that, in practice, the "can not use the same decorator more than once on the same object" is not much of a problem. One feeling I've had lately when I begin to write some code that I know will fit a pattern like "decorator" is to consider whether I care about the definition as laid down by an authority like Gang of Four. I'm not writing code to satisfy book authors. I'm writing code to satisfy myself, my team members, and future maintainers of the codebase. With that mentality, I do feel that the "difficult to tell which decorator added the functionality" drawback is important to consider. I think it's a little bit of a hidden timebomb that someone (probably not me, probably a future..."
- Dan Croak
"jacortinas It looks to me like Avdi isn't generally supporting or criticizing the article, but specifically taking a different position to this subset of Harold's approach: "Note that decorators also proxy message invokations to the wrapped object. In this case we’re forwarding the name method. Some folks will use method_missing to proxy all method calls over, but I’m of the mind that you should only expose the interface you care about and nothing more. This also helps document the actual contract established between the view and its collaborators."In the Gang of Four's "Design Patterns", they say stuff like: "A decorator object’s interface must conform to the interface of the component it decorates." and "The decorator conforms to the interface of the component it decorates so that its presence is transparent to the component’s clients. The decorator forwards requests to the component and may perform additional actions before or after forwarding." I believe Avdi is saying he feels..."
- Dan Croak
"One gotcha you didn't mention here is `heroku db:pull` alters the database column from an xml type to a text type. We still haven't submitted a patch to the taps gem so in the meantime, we're running this after we pull the database table that has the XML field: psql rails_app_development -c "ALTER TABLE beers ALTER data TYPE xml USING data::xml" psql rails_app_test -c "ALTER TABLE beers ALTER data TYPE xml USING data::xml" bundle exec rake db:schema:dump"
- Dan Croak
"gaveeno I didn't include the definition for :authorize_admin in the post, but in the app, its definition includes a check: if masquerading? That's why the masquerading? method is defined in the controller and then exposed as a helper via helper_method. I'll update the post to be more clear. Thanks for the comment,"
- Dan Croak
"I'm not sure I agree. My understanding of "responsive" is in order to serve different interaction needs from different users, we should provide responsive designs. So, if I'm reading the thoughtbot playbook on the train, I only have one hand for holding the phone because the other is holding the train for balance. I might also be holding a bag in one hand. So, I don't want to have to zoom for each page.If I'm reading the playbook at my desk, however, the thin column layout is also quite readable. The generous whitespace lets my eyes rest and focus on the content. It's responding to my desire to read quickly."
- Dan Croak
"Very true. The 480px value was chosen for mobile device reasons. I think in practice it works well, feels like a newspaper column, etc., but your point about users wanting different formatting is well taken. Readability's fantastic, by the way. Been finding myself using it more and more often lately."
- Dan Croak
"That's consistent with the response I heard from the other folks at thoughtbot. Fakes in particular were preferred. Thanks for the comment."
- Dan Croak