Thanks a ton for posting this! You saved me a lot of trouble!
95 karma · joined September 23, 2010
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.
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 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?
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.
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.
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.
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).
Thanks for sharing this!
:a! <paste like normal> <C-c>
and that will paste with properly formatted text.
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!