fhwang

How is the data getting into these tools in the first place? If your applications are instrumented with OpenTelemetry, you can use the OpenTelemetry Collector as the first hop, and then you might be able to send the data to both tools at the same time.

https://opentelemetry.io/docs/collector/

It's always strange when you see programmers who don't understand why namespace collisions are bad.

Definitely. I've been spending a decent amount of mental energy on this and still feeling very fuzzy about it. I especially feel like bootstrapping techies treat their time like it's worth nothing, when it clearly isn't -- they just aren't getting paid in cash for it.

Convention over configuration was always easier in smaller decisions where people didn't have very strong opinions. i.e., "model files go in ./app/models/" When it comes to more subjective, more context-dependent decisions like authentication libraries, the general drift has (wisely, I think) been to build hooks into the core and let non-Rails-core developers have a healthy competition about which libraries are best.

Of course, this means the Rails user base is getting slowly more fragmented as more options become viable, but generally speaking this is a good problem to have.

Oof. Please remember it is much, much easier to measure something like labor participation rate (which is what the study actually measures) than work ethic (which is the interpretation that the blogger is drawing out of that data). If one group of people is working less than another, it might be because they're lazy and shiftless. It also might be because they're in a different environment, facing a different set of positive and negative reinforcements to hard work.

I've actually never heard the phrase "golden uterus complex", but I seriously wonder if it's any different from calling a black person "uppity". Which is also not cool.

Only a spaz would care about the difference.

Generally speaking I like to have at least one CI environment available for every branch that makes you nervous, plus master. So what number you're dealing with depends on the team. Sometimes you have eight engineers but only four of them are doing something major at any given time.

Of course, whatever you call what you deploy to production -- master, production, timestamp tagging, etc -- it should ideally pass CI before getting deployed as well. And there are merge conflicts to deal with, too -- that ideally belongs to whoever's doing branching.

So, maybe my ideal workflow looks like this:

  * Branch away from master
  * As you work in your branch, grab a CI server if you feel like it (telling
    everyone else)
  * Commit code in your branch, keeping an eye on your CI as you go
  * Periodically merge in from master, dealing with merge conflicts in your branch,
    *not* in master
  * When you feel like it's ready to go, get whatever review you feel like you
    need -- code review, product manager review, etc
  * If you feel 99% certain it's good, merge it into master and push that back to
    origin
  * Wait for master CI to pass
  * Deploy to production
  * Beer

From an etiquette point of view, there are things that can go wrong, not least the individual commitment to deal with merge conflicts before they get involved in master. And conflict resolution cannot be rushed. If you have engineers who are just gonna edit files randomly to get git to accept their merge, you're going to have problems. (But if you have those sorts of engineers, you already have problems.)

Yeah, personally I know a number of solid devs who like feature toggling but the notion has always rubbed me the wrong way. Especially because half the time I'm adding a non-trivial feature, I'm always semi-refactoring the code underneath to deal with the common patterns and concepts that emerge as a result of that addition. But I'm a big refactoring-as-you-go kind of person--I don't know how common this is.

Branching is definitely a significant investment for a team. It's best done when you've got somebody in-house who can guide everybody through the etiquette and how to use git to best support it. And if you want to do it all the way then you want to support in multiple places in your development stack -- QA servers, staging servers, CI, etc.

But for large units of work that genuinely should stay out of master -- large user-flow rewrites, big code refactorings or database migrations -- I find it a great way to have significant experimentation off to the side and then bring it back into master when it's ready for prime-time.

Branching can often be a good strategy if you have a large team and you don't want large uncompleted chunks of work to block quick fixes & deploys, etc. The situation you want to avoid is:

1. Engineers A & B are working on a medium-sized story that's not really done yet, but is in master anyway 2. Somebody discovers a small but critical bug in production 3. Engineer C can write a bugfix very soon, but can't deploy it to production because the other story isn't done yet.

But if your team never ends up saying "I'd deploy that but master isn't clean right now due to different changes", you probably just don't need to branch that much. Maybe your team is smallish or maybe you're capable of always breaking up work into really small increments. It really depends on everybody's situation.

Github does something sort of like this internally: http://scottchacon.com/2011/08/31/github-flow.html

Branching is more overhead in some circumstances but I've also found they can make things much easier. But I also wish that more people were comparing strategies and trade-offs because this stuff gets subtle and there are really lots of ways to do it.

Oh, yeah, I guess that's our Backbone redirect from the initial page to whatever the first "pane" would be. If we weren't using teh Ajax we'd do that, we'd use a 302 and then the browser history wouldn't get confused.

We'll figure out a fix for that. Thanks for the feedback.

No we haven't, and that's something for us to keep in mind if we think about switching, but for the time being all our stuff's in Vimeo and I don't think we have any plans to move it.

EDIT: Actually, on thinking on it for another minute, I suppose it'd be pretty easy to do detection to support people who don't have Flash installed. Thanks for the suggestion--I'll put that in our queue.

Unfortunately, Vimeo's HTML5 embed doesn't give you an API that you can use to close the video from JS, which is why we're using their older Flash embed. I'd love to make the switch once they change that, though.