Brett

sup = git submodule update

for standup (lo is my pretty-print log):

work = !git lo --author bjones --before today --after \"two days ago\" --no-merges

info = !git st && echo && git lo && echo && git remote -v

ca = "commit -a"

dt = difftool --no-prompt

mt = mergetool --no-prompt

pff = pull --ff-only

stashall = !git add -A && git stash

I read the documentation a few months ago when I saw the flag somewhere and I assumed it was accurate too. I just cloned one of my repos with the flag and I was able to push and pull. Looks like the manpage needs to be updated.

I use !$ also but I'd suggest && rather than ; because if the mkdir fails (exits with non 0) the cd will still execute.

There's a very distinct difference between bad design and refactoring. Most people see refactoring as rebuilding poorly written code and it's not. Refactoring is taking what you have written and reassembling it to fit a better design. When it comes time to refactor, your private methods are some of the first to go, but they're not immediately a decision of bad design.

There's a real problem engineers have these days with trying to see too far in the future. We're engineers, not time travelers. YAGNI is a very prudent principle that most engineers forget to consider when they're starting development. Don't bother with overthinking designs and patterns before you even have a line of code written.

Honestly what you've described as your coding style doesn't sound poor at all. Write the code as it comes to you and make it work. Refactor once the code works and you start to see the possibility of a design.

It's difficult to see what exactly you're trying to condemn here since you didn't give any real examples, but labeling a methodology entirely "bad" based on subjective experiences seems a little silly. Software isn't black and white. There is never one way to do something nor is there one right way. Private methods are useful in some circumstances and can be used without being overly obscure. Some methods are only intended for use inside the class it was written for, and revealing them could lead to exploitation or complete breakage. Sure, people abuse private methods and conceal useful information, but slandering a certain behavior because of abuse is a unreasonable and naive.

I want to say I read it on the ICS page, but it appears the CS devs are reluctant to merge it into the mainline. This looks like the pull request from maxtaco which was closed after a long discussion. He talked about it not happening on #85.

Rather than async.js check out Iced Coffeescript which is supposedly getting merged into coffeescript eventually.

I've just been setting a cronjob on my linux box.

0,30 * * * * curl -Lso /dev/null http://mywebsite.com

At first sight this is enticing but when you think about it you'll see that anyone doing maintenance on these projects would be extremely confused looking for definitions of these magical variables. I'll stay away from this for now. If that reason alone isn't enough then the lack of support in IE8 (10% of the consumer market) should be unless you plan on hacking every variable with var element = rampus || document.getElementById('rampus');.

Some of these, and much more are here: http://amix.dk/vim/vimrc.html