The "hit refresh to see CSS changes" is a big crime I've noticed on my (and my dev friends') time. My logic with my recent project is simple:
-You have a computer
-Computers automate tasks
-Automate all your repetitive tasks<p>There's obviously no one-size-fits-all here, but think outside of the box for your workflow. Add macros to your editor, use something like LiveReload or Brolink.vim (shameless plug) to reload pages, streamline your build process, heck, even use AutoKey if necessary. Point is, you're the brain, and the computer is your slave. You don't need to be doing petty work that your computer can do for you.
Since i am using a Win8 Workstation as well i am interested in the tools <a href="http://16154060.r.cdn77.net/images/desktop.jpg" rel="nofollow">http://16154060.r.cdn77.net/images/desktop.jpg</a><p>What terminal client is that ? Could be cygwin ?<p>Also looks like hes running a local ubuntu VM for dev !? I wonder how he syncs it to the laptop, if he does at all.<p>+ some other Tool icons i cant really make out :)
A really good read, however one of the points of waiting for an editor to load doesn't really make sense to me given the fact I use Sublime Text Editor and it loads instantly, I've never had to wait for it to load even when there are 30 tabs for it re-open. The liveReload plugin for Sublime eliminates the need of hitting F5 to refresh a page because as you make changes and save using this plugin the page refreshes: <a href="https://github.com/dz0ny/LiveReload-sublimetext2" rel="nofollow">https://github.com/dz0ny/LiveReload-sublimetext2</a><p>Unless you're an old school Vim user, I see it as somewhat pointless to learn it in 2013 as a new user, considering Sublime can be just as powerful (support for shortcuts, mapping to compilers and script generators) we've got a better array of fast and feature-packed editors that offer Vim like power without requiring a read of a user manual just to edit some files and compile them to save a few mouse clicks. I can see why people who know Vim would never leave, it's a powerful and besides the self-satisfaction of mastering a highly complicated editor, those I know of who use it can code like the wind. It's amazing seeing them racing about the keyboard doing things I do in mouse clicks with sometimes long keyboard shortcuts they just know off of the top of their heads.<p>The bane of my existence used to be documentation, but through a few simple self-disciplined changes I ensure that I document every variable, class and function so I can automatically generate documentation (well most of it) without wasting hours documenting hundreds of lines of code and files.<p>The article raises some very good points though. The smaller things like waiting for a project to compile, waiting for your browser to open, compiling your LESS stylesheets, refreshing your browser and heck even leaving your desk to make tea and coffee all add up when you tally the time up times a 5 day work week and are things we really don't focus on.
It seems like these trivial inconveniences could largely be avoided in non trivial broader ways. For example what is the need for having so many javascript and css assets when in Rails we are meant to use the asset pipeline by default? In this case it seems like it would make the most sense to utilize the asset pipeline, more so than most applications. Merge all those together, serving up 80 separate assets is insane. Isn't it?<p>I don't understand mapping the keyboard shortcut in Vim to reloading all browsers. Does that reload all tabs in all open browsers? What if I have a paused youtube video, or am saving my place in a large article that I am scrolled most of the way down the page. Doesn't that all take longer to fix than just going to the browser and hitting the keyboard shortcut in the browser? Since you're going to the browser anyway or else the reloading would have been meaningless?<p>The most obvious time sink that I can see from this article is that the tests are poorly optimised. But that isn't a trivial inconvenience. Having to wait 3 minutes, twice, every time you make a change in the code is a significant inconvenience. That should give plenty of time to do things such as reload a page. Designed properly tests are not meant to depend on one another just to run. Use minitest, use fixtures and fabricators. Test individual classes, test controllers, avoid full stack tests unless there is something that can't be tested about it at a lower level.<p>As others have said also Vim is a powerful tool but there isn't really very much it can do that a modern graphical text editor like Sublime Text 2 cannot... I'm sorry I am just having trouble making this article resonate with me. Is it something wrong with me or am I right?
"Vim is tough editor to pick up, especially late in your career. It is notoriously difficult to master."<p>Bull. I started using emacs when I was 18 and switched to vi at the age of 40.<p>The reason I switched was the I found many difficulties when I was using emacs on one hand and mouse-based editors on the other. One problem is that you can't easily cut-and-paste out of an emacs window because of the continuation characters. Another one is that if you use emacs and Windows editors, you'll end up confusing ^X^S with ^S and wind up typing the wrong thing into the wrong window.<p>You can get started with vi if you know the arrow keys, switching in and out of INSERT mode, as well as :wq and :q!. If you're using putty, visual cut-and-paste works great.<p>Learn how to use / and you're cooking with gas. I keep an old Unicos vi reference card around so I can gradually learn "dd", "G" and other useful keystrokes. But I was productive within 10 minutes of switching to vi.
He mentions switching to Share Mouse, after struggling with Synergy. I've been using Synergy with Mac, Win, and Linux for years. It just stopped working for me and I've been struggling to make it work. Over the years, it's broken every around once per year, and clipboard support has often been flakey in some directions. Anyone have experience with Share Mouse?
Excellent article and nice answers to queries, Sam!<p>I have one question. How were you able to manage a 23.5 ms time in the mini profiler over Internet? Were there no database queries involved while rendering that page?<p>Your website does load fast, no doubt about that.. :)
> Both runners insist on running every single spec in the queue before obliging and running the spec you want them to run.<p>Autotest has a fast start option that stops it from running the entire test suite on load. --fast-start of -f for short
Any concern with running Ruby 2 in development and 1.9 (presumably) in production? I'm doing it now for the startup time boost in both console and thin but worried I'll inevitably introduce some code that will not play nice.