JustAGeek

Thanks for this post, it's all too easy to forget all this in your daily routine. If the OP reads this, if you work at a company where much of this isn't possible, why not move on?

While the participants are encouraged to use TDD, this is no strict rule. The goal is to write the best, cleanest code you possibly can.

What I've found the most value in, is that you get to pair with 6-7 different programmers you've probably never met before - and thus you get to learn how other people approach the problem, you'll learn how your skills compare to those of others and you'll also learn a lot of little things, e.g. IDE shortcuts you didn't know of.

And you usually get to program in a language you might not be familiar with.

I've already attended two code retreats and it was very, very well worth it!

Thank you very much for linking to this email, some great pieces of advice in it!

To answer to the question in the title of this submission:

You should not. As soon as a feature has got released to all users of a software, you won't be able to disable it without some users becoming really dissatisfied.

The solution is not to release a new feature to all users.

Before even thinking about releasing a new feature, first ask yourself:

What is the goal of this new feature?

The answer to that question is your hypothesis, you need to try to answer by experimenting. That is, perform an A/B-test:

Launch the feature to a subset of your users and check if it achieves its goal. This goal must of course be measurable and ideally there are KPIs that you can use to check the success or failure of your experiment.

When the experiment is successful you deploy the feature for all users. If the experiment fails, you remove it for the subset of users and the rest will never know about it.

This also helps the codebase to stay clean, features not making it into the product, is code not making it into your codebase, which means less code to maintain, less complexity.

Yes, it does, why shouldn't it?

1. Edit some files

2. start git gui and commit

3. repeat 1+2 as many times as you want

4. git svn dcommit

5. all local commits will now be committed to the SVN repo

Well, actually git-svn is really useful when you work in an environment where SVN is used as VCS.

I've been doing this for almost three years now and haven't had any major problems yet.

Except for: Merging. Since SVN 1.5 (or so) merging in SVN got less painful because from then on when merging, SVN tracks which revisions have already merged from one branch to the other.

AFAIK it does so by saving the merged revision ranges into the svn:externals as meta data which can then be used for the next merge operation to prevent changesets to be merged twice into the same branch.

However, when you merge with git-svn this information will not be recorded, so the next person merging with SVN will probably run into problems.

Solutions:

a. you don't merge with git-svn

b. anyone merging with SVN explicitly tells SVN which exact revisions to merge

You can still use local branches of course and as long as you only merge from one local branch to the other with Git, there won't be any problems.

At my work place we luckily pretty much only have trunk and very, very short-lived branches, so this isn't an issue for me.

A correction, while the fact that SVN creates a copy of the entire code, when you create a branch, it isn't as horrible as it sounds, from the SVN documentation:

"When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're an experienced Unix user, you'll recognize this as the same concept behind a hard link. As further changes are made to files and directories beneath the copied directory, Subversion continues to employ this hard link concept where it can. It duplicates data only when it is necessary to disambiguate different versions of objects."

( http://svnbook.red-bean.com/en/1.5/svn.branchmerge.using.htm... )

That being said, the day my company will finally switch to Git will by a happy day... :D

On peepcode.com you can find several screencasts where you can watch experienced developers working on a mini-project while thinking out loud The series is called "Play by play". Here's the one with Zed Shaw: http://peepcode.com/products/play-by-play-zed-shaw

The others can be found here: http://peepcode.com/screencasts

Furthermore, there's http://www.cleancoders.com/ by Bob Martin. For several of the available episodes there are screencasts available in which he TDDs on some task, e.g. here: http://www.cleancoders.com/codecast/clean-code-episode-3/sho... Those screencasts are bonus material, so to speak, the actual episodes are well worth the watch, too.

All those screencasts cost money - but imho they're very well worth it!

I was about to suggest that book, too. Also, check out this blog post: http://agilitrix.com/2011/03/how-to-make-your-culture-work/ which outlines some of the ideas presented in the book "The Reengineering Alternative: A plan for making your current culture work" by William Schneider.

Well, that's what TubeStop is for: https://addons.mozilla.org/en-US/firefox/addon/tubestop/

I'm not the guy you replied to but I didn't know what to expect when I followed the link, I had no idea what "Nyan Cat" even means.

But it's on Hacker News, so it would be something interesting and valuable, right? ;)

A friend of mine ran into the situation of having to implement the same business logic in both Javascript and Ruby.

He wondered how to get around this and his solution is IncludeJS which allows to write the business logic in Javascript and use this code in BOTH Javascript and Ruby. He gave a talk about this during the Railsconf 2011, here's the URL where you can find the abstract and slides which provide some more details about this:

http://en.oreilly.com/rails2011/public/schedule/detail/19412

Nice! By they way, the hints, tips, tricks and plugins in that article can be applied to using Vim with other languages as well. Didn't know about Gundo or minibufexpl, for example.

I don't know if it's decent, I'm a Linux user but there's TortoiseGit: http://code.google.com/p/tortoisegit/ Current version is 1.6.3.0, so looks like it's considered stable enough to be beyond the 0.x-stage... ;)

Yes, JS was disabled. With JS enabled there's no blank page. :)

When I try to subscribe with my email, I get to this page here: http://skillsapp.com/subscribe/ which is blank, you might want to look into that. :)

Happening with FF 3.6.12 and Ubuntu.

Just chiming in to say that the website for knockoutjs is extremely well done, congrats!

Example right on the homepage, clear communication what it does, great list of examples on the other pages - way to go! :)

You can config Git so that it always uses rebase when pulling: git config branch.autosetuprebase always

To override this simply use --no-rebase.

I agree that most of the slides would require further explanation but I still found a bunch of commands I've never heard of and actually could make use of, eg git bundle and git rerere.

So it's not totally worthless.

Could you please elaborate on that? What basic things did you have problems with?

Which issues did you have exactly? I'm asking because my team members want to switch to Git after having to suffer through my praising git for long enough and I'd like to know which traps to avoid.

My personal switch from SVN to Git was rather painless but that's probably because I "only" used git-svn and at first used Git pretty much like I used SVN and then step by step explored the possibilities offered by Git like local branches etc. pp.

That's what I'd recommend to anyone making the switch, first try it out with git-svn, don't use every new feature at once.

DVCS is a completely different paradigm, it requires some time to wrap your head around. :)

You can find some of the tips here: http://mislav.uniqpath.com/2010/07/git-tips

Ah, didn't know that, thanks. In fact, I haven't even known the 24 days before I looked it up in Wikipedia... :D

I'm a bit late to the party but whatever, just wanted to let you know that us Germans don't have 6 weeks federally mandated vacations, it's 24 days: http://de.wikipedia.org/wiki/Bundesurlaubsgesetz#Gesetzliche...

That's the minimum, most people I know have 28-30 days. On top of that you can get up to 5 days of paid educational leave.

The article as a whole is quite superficial, imho.

Not sure if those working in big companies like Deutsche Telekom or Daimler would agree to the claim that Germans don't have many meetings, for example... ;)

The author mentions that code becomes wrapped in a bad way, can anyone confirm that?

I'm tend to read more tech books than other genres, so if code becomes hard to read, then the Kindle would not be for me...

The title of this blog is quite unfortunate imho, it really is an article describing how NOT to switch to VIM and how the author eventually managed to come up with a good way of switching.

Good (and as so often, kinda obvious ;) advice.

It really doesn't matter.

What matters is having great coders, great ideas for your app and executing them effectively and efficiently which is possible with both PHP and Python.

You can write horrible code with both languages, it might be horrible in a different way but it'd still be horrible. :D

That said, if you're the only one having doubts about Python but the rest of your team wants to write the app in Python and they do have experience working in Python - why don't you trust your team's judgement?

As it doesn't matter, it would be the sensible decision to pick the language your team would like to code in, imho. :)

I actually found this quite accessible, I was expecting something very complicated or theoretical but it's a good visualization and explanation about the internals of Git.

This is actually my own test of whether or not I've really grokked something:

If I can't explain it to someone such that she understands it as well, I haven't really understood that something.

Like others said, current research suggests that being good or even expert in something is the result of the right kind of practice and lots of it.

Here are two good books about it: The Talent Code: http://thetalentcode.com/book/

Pragmatic Thinking and Learning by the Pragmatic Programmers: http://www.pragprog.com/titles/ahptl/pragmatic-thinking-and-...

That's how I understood it, too.

Exactly! Just keep it free but offer the possibility to donate for everybody not ordering the print version.