I work on the team with OP. It's worth noting that in our actual retros we always discuss things causing friction & drag. All of the congratulatory stuff is done out-of-band in an email sent out after retro.
To your other point: are we celebrating mediocrity? I don't think so. While the things we call out may not fit your definition of "extraordinary", when the main discussion points are around how you can improve, it is important to celebrate wins, even small ones, to see how you have improved.
For the last few months before I stopped doing Ruby full time I was using a workflow (on OS X) in which I downloaded a binary Ruby build (the one rvm uses when you do "rvm install --binary" on OS X) and extracted it to "/opt/rubies/2.1.0". I created a script called "activate" that exports the environment variables necessary to run Ruby and placed it under "bin".
Then for each project I would copy the entire ruby installation to my project root in a folder called "vruby". To load ruby for that project I would run "source vruby/bin/activate". It would setup all the environment variables with GEM_HOME pointing to a ".gem" folder under the project's root. Therefore gems are isolated to each project. To unload, I just close the terminal.
The vruby project automates this workflow, by installing a binary ruby using Traveling Ruby and symlinking it to the local project using GNU stow. The plan is to eventually support multiple Ruby versions and more platforms than just my Linux box. Unfortunately, I no longer do Ruby full time and don't have the bandwidth to make it as robust as I'd like. If you like this solution and need help setting it up, don't be afraid to get in touch.
I had an outstanding OSX update, installed that and rebooted. One of the two fixed it for me. Note: I DID NOT have to install the the root certificates, and if anyone else gets an SSL warning from DigiCert's root cert download site, I strongly recommend against downloading anything from there.
I'm having this issue as well. I deleted all digicert certificates from my keychain just in case. Still couldn't get to Github. I can get to the DigiCert Root Certificates download page, but it gives me an invalid certificate warning. It looks like the same issue as Github.
I really, really don't feel comfortable downloading a ROOT CERTIFICATE with an SSL warning on the page. Who knows what could be compromised in this case?
I'm going to try a couple other things first; I'd like to hear from a security expert, should we find this scary or just a small hiccup?
I've found that working like this is making it much easier to provide the best solution for my clients. I can identify risks faster and change on a dime. It's been a breath of fresh air so far, but I'm curious to hear what others think. (disclosure: I work at the company that published the post).
All the jobs I've had since college have had an open workspace. Of those, 3 stand out as particularly pertinent to this topic.
At Job 1, a consulting company, we had an agreed upon culture of noise. We had music playing loudly most of the time and about 30 developers collaborating on different client projects. High vaulted ceilings definitely contributed to noise. It was definitely chaotic, but we managed to remain productive regardless.
At Job 2, my current job (also consulting), we have talked at great length about keeping things quiet and respecting each other's concentration. We have side-rooms if we need to collaborate, and use them frequently. We use chat to ask each other questions rather than tapping on the shoulder (most of the time). I feel extremely productive there (even more so than job 1) and while offices might make tapping on the shoulder even less common, I feel a sense of camaraderie there that I don't think I'd get if I was isolated with a closed door.
Job 3 was by far the worst. It was a similar open space for the entire product team. However, we never had much discussion about communication style or noise, we just always said we don't like being interrupted. Looking back on it, I think productivity was easier at jobs 1 & 2 because we had all agreed on our culture, so we could find ways to work around it. Job 3 was hard because we never knew what to expect. One day it could be quiet and easy to concentrate, but the next it could be noisy and impossible to work in.
The lesson for me is that honesty and openness is most important. If people speak up when they are having a hard time concentrating, then everyone can work together to try to improve the situation. This assumes of course the team respects each other enough to compromise; but if they don't you probably have bigger problems.
Further, who has ever advocated for building desktop apps _without_ a framework? The comparison of client-side frameworks to server-side frameworks is the wrong comparison. If I'm going to build a sufficiently complex Mac app I'm going to use Cocoa, no question. If I just need to automate something and don't necessarily need a UI, I may look at AppleScript or even a simple shell script.
This is more of an apt comparison for web front ends. The choice of Backbone (or, in my case something that provides a little more value like Flight) vs. Ember/Angular is like choosing to build a CLI app vs. a full-on desktop app.
There are perfectly valid reasons for choosing either and in the right context, the right tool is worth its weight in gold.
At an earlier point in my career I was exactly the "highly technical person" in the above comment. I have always taken the approach to my work outlined in the OP, and therefore my emphasis on "getting it right" has caused me to switch jobs quite a bit over the past few years.
For people like me, understanding business constraints is crucial. We must constantly question decisions, not to condescend, but to understand.
Once I understand the context behind a decision, I can then decide if I agree with it or not. If I don't, then I'm in a fight-or-flight situation: try to change it (may not be a reasonable option) or get out as soon as my commitments allow.
Typically once I understand the constraints I start to less like a cog and more like part of a larger effort to ship in spite of our difficulties.
I'm had the same thought Obie. I find high level integration tests provide most of the value for me, with unit testing when I need help with designing code. Having a decent suite of high level tests saves me from having to smoke test the entire app every time I make sweeping changes. If the suite is passing, I know the features are working, at least in the basic cases I was testing for. I still have to do some level of manual testing, but it's nowhere near as much as I did before I became more obsessed with testing.
I get inspiration from Adam Lisagor, his videos are online at http://sandwichvideo.com/. He uses people in his product videos, not just the product. They have a very personal feel, which definitely reaches me. Of course, he has more than a bootstrap budget, but if you want to try filming people, check out The Frugal Filmmaker's blog for tips on setting up lighting, etc. on the cheap http://filmflap.blogspot.com/. Good luck!
I have yet to find a project management app I like more than AgileZen. It allows me to model my workflow, assess against estimates and to top it off it's very pretty. There are a few things about it that bug me: notifications suck and there is no interaction between projects. Other than that, it's awesome.
It is more complex than it used to be, but too complex? Our tools have finally matured to solve some of the worst problems with Ruby development (ie. monkey patching, namespace conflicts, forking to fix bugs, gem development, etc). It's definitely worth the effort.
You did an excellent job on your guide, but a lot of it looks more complex than it actually is. This guide is more than just Rails, you also walk through installing RVM & Ruby. Setting up a Ruby environment from scratch is somewhat complex. But once you understand RVM, getting started with Rails 3.1 is actually quite easy (but it's always a little more complex in the .beta and .rc releases).
Good point on my wording, thank you. I will change that to make it less confusing. As for middle-click, I really don't want to use the mouse. I don't use it for pasting anywhere else, so why would I change that for Vim?
You bring up an excellent point here Brian! I'd love to hear other things like this that aren't really development issues per se (no amount of unobtrusiveness will get us video transcripts). Are there other non-development issues we should keep in mind?
1) I'd love to hear about the different issues people have and what tools they use to overcome their problems. Seems like this would help give everyone a level playing field to start talking about developing for accessibility.
2) I've always had trouble with the "build it however now and we'll make it accessible later" approach. Unobtrusiveness needs to come first, Ajaxifying later. However, it's hard to sell that when you don't have much time to begin with. Perhaps you could speak to how we, as developers, could convince our clients (and fellow team members) that accessibility is a) so damn important and b) not just for blind people.
3) I'd also love to read how to make unobtrusive, accessible development work on a team. Do you develop the whole thing with no Javascript first, then come back around and hit it with Ajax? Can you do both at the same time? How would non-technical testers determine it's working properly?
Just some thoughts. It's a great idea and I can't wait to see what you come up with! Keep fighting the good fight Brian!