The Joys Of Programming

complexmath wrote:

If you do any non-Windows development at all, learn at least enough VI or Vim to be productive. It's preinstalled basically everywhere, while emacs is not. Then also find some editor that runs on all your platforms of choice that you absolutely love and become an expert with it.

I usually fire up Nano when using a *nix system. Vim will be my next conquest, I do believe.

complexmath wrote:

Git is great but it makes many rather common tasks surprisingly difficult and/or awkward (at least to me anyway): reverting changes, the equivalent of "svn blame", not spamming commit logs with merges generated from "git pull", etc. Maybe one of these days I'll try Mercurial...

I've been enjoying my time with Git. If nothing else, GitHub has been wonderful to work with over the past few weeks. Been assisting in GWJ development tasks, as well as loading up some of my own projects. The workflow change is probably the biggest difference to get used to coming from SVN.

Yeah, I've toyed with git a little, and I've found it really remarkably opaque. I just don't understand the document model they're using. It has the feel of a great solution, but there's some mental model of the change control process that I'm just not getting when I look at the documentation and toy with the examples.

I really favor Mercurial over git, simply because I think git reveals more internals than it really should, whereas Mercurial only reveals the internals when you want to do something arcane (which you probably shouldn't do anyway.) I suspect you may follow Mercurial examples better, Malor, and then be able to apply what you learn to git, since the distributed VC model is common to both and the important stuff will stand out better once you know what it is.

Either way, the modern style of distributed VC system is dramatically better than earlier stuff.

vi installed everywhere: Ahh, you remind me of the days when I needed to use ed to tweak config files and such because vi was in /usr/bin, and /usr wasn't mounted yet. :>

trueheart78 wrote:

I usually fire up Nano when using a *nix system. Vim will be my next conquest, I do believe.

Either nano or pico are generally available, but not always. And this may not be an issue for everyone, but I do a lot of logging into random servers to check on whatever. I really don't like Vim but it beats nothing.

trueheart78 wrote:

I've been enjoying my time with Git. If nothing else, GitHub has been wonderful to work with over the past few weeks. Been assisting in GWJ development tasks, as well as loading up some of my own projects. The workflow change is probably the biggest difference to get used to coming from SVN.

GitHub is awesome. I think they could really improve their documentation for creating pull requests, but overall it's a great tool.

Hypatian wrote:

vi installed everywhere: Ahh, you remind me of the days when I needed to use ed to tweak config files and such because vi was in /usr/bin, and /usr wasn't mounted yet. :>

Every time I use Vim I have flashbacks to using ed (or edlin on DOS). That's probably the source of my dislike

ED IS THE STANDARD UNIX TEXT EDITOR.

Okay so my work at work is exclusively in IDLE on windows.
Someone explain why I should bother with vim.

Vim is like a radioactive spider bite. It gives you super powers.

If you never touch *nix then there's little reason to learn vm. I really like UltraEdit when a GUI is available, but to each their own.

I am at best an intermediate user of Git and (previously) Hg, but here's my (possibly incomplete and possibly incorrect in places) understanding of some of the big differences between the two:

* The index ("staging area"). In Git, changed files must be staged to be included in a commit. In Mercurial, as in many other VCSs, when you commit, all changed files are rounded up and included automatically. I very much like the Git staging area, as it lets you craft commits that only reflect a particular change, even if you're in the middle of working on multiple things.

* Hg stores deltas, Git stores blobs. There's a very big cultural difference here, in that each of these approaches are efficient at a particular thing. Deltas are storage efficient. (Git blob packing helps close the gap, but does not eliminate it). Blobs are speed efficient - loading an old version into your working directory means simply grabbing those blobs, while deltas require starting from the beginning of history and re-applying each delta to build back up a working copy of the version you want.

* Git's history is mutable, Hg's is (largely) immutable. Immutable is safer, but when a junior developer accidentally checks in a configuration file with a password in it, it's nice to be able to prune that out of the repo history.

* These last two points (deltas vs. blobs, history mutability) are the visible tip of the iceberg that is the heart of the fundamental differences between Git and Hg. Mercurial commits are dependent on each other - they are deltas representing the change from the commit before them. Git commits stand on their own. They are snapshots.

Conceptually, we can imagine a series of Mercurial commits to build "Hello World!" to be something like:
Commit 1: "Hello"
Commit 2: (add in: " World")
Commit 3: (add in: "!")
You cannot infer the existence of "Hello" or "World" from commit 3 alone. It is built by applying it to the previous commits.

Whereas Git stores the entire thing at each step:
Commit 1: "Hello"
Commit 2: "Hello World"
Commit 3: "Hello World!"

The meaningful difference here isn't obvious from such a trivial example. Where it is meaningful is that Git's commits are not locked into a particular spot in a linear history. They are free to be rearranged.

Git is the Doctor Who of version control systems.

IMAGE(http://images1.wikia.nocookie.net/__cb20110427023930/halofanon/images/9/9d/Wibbley-wobbley-timey-wimey.gif)

People assume version control is a strict progression of cause and effect, but actually - from a Git perspective - it's more like a big ball of wibbly-wobbly timey-wimey... stuff.

Mercurial and other delta-based systems are based on the idea of this strict progression. Files have their starting contents, and then every change is a diff applied on top of the results of applying the previous diff, on forward.

Everything in the Mercurial history is fixed points in time and space. Branches get closed but don't go away, they just become dead-ends. Commits in a branch are permanently in that branch - the branch name is actually in the commit itself, and that's what defines that commit as being in that branch. The Mercurial graph doesn't change, only grows.

Git commits are not fixed points in time and space. They can be moved. For example, I might start a branch at a certain point in time, make a half-dozen commits, and then wish to merge it back into the main branch. Instead of merging my six commits back from the spot where I initially branched (which might be a few commits in the past in the main branch by now), I can "rebase" and make my commits start from the current HEAD instead of the one I was working from, bypassing the need to create an additional merging commit. What's more, instead of committing my sloppy sequence of 6 commits, I can squash them down to a single commit, and marge that. Now the history looks like I just made a single commit starting from the latest HEAD, instead of a bunch of commits starting from the old HEAD as I actually did.

We are able to do this - take my branch's commits out of their position in the graph, and re-apply them at the top of the graph - precisely because they are not deltas. They don't build on top of the previous commit. They are snapshots that stand on their own.

Git branches are just pointers floating around, pointing at positions in the graph. Commits are not intrinsically part of any branch - they exist in a branch by being part of a graph path that a particular reference is pointing at.

Git is a lot like UNIX - it's more arcane, less intuitive, and yet, when you get down to the bottom, actually simpler. The idea of each commit being a complete snapshot, and branches being simple pointers pointing to a spot on the graph, is in concept a lot simpler than a history of deltas or branching by way of embedding branch names into commits.

And please take all of that with a grain of salt, because, like, half of it could be wrong. But I think, allowing for some simplification, it's in the ballpark.

boogle wrote:

Okay so my work at work is exclusively in IDLE on windows.
Someone explain why I should bother with vim.

Unfortunately, no one can tell you what Vim is. You must see it for yourself.

When you know how to use it, Vim allows you to edit text with extreme efficiency. It's hard to explain because it is a complete destruction of your current concept of a text editor (something you click around in with a mouse and just type into).

Some have said it's like programming text instead of writing it. That's a decent ballpark way of describing it. Things that you take for granted as requiring repeated clicking, key mashing, and copy-pasting are done instead with bizarrely fast commands.

I can't agree with complexmath's statement that there's no point in Vim if you're not in *nix. Vim is the first thing I install in Windows. It's Vim's power in manipulating text, not its relation to any particular OS, that makes Vim special.

*Legion* wrote:

* The index ("staging area"). In Git, changed files must be staged to be included in a commit. In Mercurial, as in many other VCSs, when you commit, all changed files are rounded up and included automatically. I very much like the Git staging area, as it lets you craft commits that only reflect a particular change, even if you're in the middle of working on multiple things.
.

You can stage files to commit in Mercurial too. It's the whole file though, rather than a single change - not sure if git has the functionality or not to go line-by-line.

*Legion* wrote:

I can't agree with complexmath's statement that there's no point in Vim if you're not in *nix. Vim is the first thing I install in Windows. It's Vim's power in manipulating text, not its relation to any particular OS, that makes Vim special.

I suppose I should have qualified that by saying that I don't really like Vim, so it's more of a necessary evil for me.

*Legion* wrote:

Git is a lot like UNIX - it's more arcane, less intuitive, and yet, when you get down to the bottom, actually simpler. The idea of each commit being a complete snapshot, and branches being simple pointers pointing to a spot on the graph, is in concept a lot simpler than a history of deltas or branching by way of embedding branch names into commits.

No. That's an implementation detail. In both cases, the right way to think about it is as a snapshot. The details of what's actually stored on disk is irrelevant. If the details matter, you've broken your abstraction and your implementation is wrong. git seems to think that it is a virtue to break abstraction and expose the guts of the system. It's really, really not. That's my beef with it.

Mercurial, on the other hand, has a good abstraction, and therefore behaves as specified without nasty bits hanging out.

Everything you can do with git, you can do with Mercurial. Their capabilities are absolutely equivalent in every way. The only differences are implementation details (which should be hidden) and the way the capabilities are exposed (UI). The actual capabilities are the same.

It's just that git's way of explaining it makes it extra complicated and scary, and like you need to be a badass to figure it out. Like expecting that people *should* use rebasing instead of having it available as an optional tool for use once you understand how things work.

If I wanted to, I could rebase things in Mercurial to clean stuff up. I prefer not to because it makes me happier to have the full log. I might change my policy in the future for a project I'm the gatekeeper on, in order to make bisecting work better (since intermediate check-ins that don't build wreak havoc in that scenario). But Mercurial can rebase just fine, thanks.

Another good guide to what's great about VIM.

My team lead flat out told me this morning he wasn't going to read the copy of Version Control By Example I loaned to him this morning. He then asked me if I was going to change to Git or Mercurial (or Veracity) while he's in Spain for 3 months.

I said no, but he changed us from Vault to TFS the first day I took a vacation, without letting me know. After having just used his batch-file deploy script, and being told it was more robust than Jenkins, Cruise Control, or TeamCity, I'm pretty sure I'm going to change things while he's gone.

Any suggestions for a .NET 4.0 WinForms app, as far as continuous integration, source control, cool-sh*t-I-should-be-using? Previously rejected suggestions include:

  • Switch to Ruby or Python
  • Install Nintendo
  • Delete System32
Hypatian wrote:

(stuff)

This reads less like a well-supported argument for Mercurial, and more of a hazy, lightly-substantiated distaste of Git.

Maybe you used Git long ago when it was still a bunch of hacked-together shell scripts, but today, it's hardly "explain[ed]... extra complicated and scary", and one certainly doesn't "need to be a badass to figure it out".

Be good, or I'll install VSS on all your machines.

Does anyone have a good link to installing VIM? I've come to hate the new Visual Studio so bad for client technologies I've gone back to Notepad for the nonce. This has pissed off our CTO no end - apparently he has some sort of pathological hatred for actually knowing what the heck you're doing and actually getting anything done.

Our acquisitions guy got around him by asking for UltraEdit for his Perl, so I'm thinking maybe if I install SOMETHING, maybe he'll feel better about it, and that was on my list of stuff to check out because from what I understand it's more platform agnostic than most.

*Legion* wrote:
Hypatian wrote:

(stuff)

This reads less like a well-supported argument for Mercurial, and more of a hazy, lightly-substantiated distaste of Git.

Maybe you used Git long ago when it was still a bunch of hacked-together shell scripts, but today, it's hardly "explain[ed]... extra complicated and scary", and one certainly doesn't "need to be a badass to figure it out".

I'm not trying to make an argument for Mercurial. I have a light distaste for git.

However, I have an extremely strong understanding of the two that allows me to say for sure that their [em]capabilities[/em] are absolutely equivalent—the difference in the underlying model between storing things as deltas or snapshots really doesn't make a difference unless you're really tinkering in the guts of things. That's the main thing I wanted to speak up about.

Or to put it another way: I prefer Mercurial to git, but git and Mercurial are pretty much interchangeable and it's a matter of taste which one you use. You painted a picture of them being very different, but they're really not.

(And as far as tinkering in the guts of things goes, even though I'm not terribly fond of git, it's worlds ahead of the bad old days of CVS and other abominations built as layers on top of RCS.)

momgamer wrote:

Does anyone have a good link to installing VIM?

Try here for vim. And if you have some reason to want Emacs, go here. And there's always Cygwin, but that's a whole world of pain. *sigh*

complexmath wrote:

If you do any non-Windows development at all, learn at least enough VI or Vim to be productive. It's preinstalled basically everywhere, while emacs is not. Then also find some editor that runs on all your platforms of choice that you absolutely love and become an expert with it.

Git is great but it makes many rather common tasks surprisingly difficult and/or awkward (at least to me anyway): reverting changes, the equivalent of "svn blame", not spamming commit logs with merges generated from "git pull", etc. Maybe one of these days I'll try Mercurial...

I use WinSCP for editing files on a linux machine. I just right click the file and select edit, the file is downloaded and a notepad like app launches. I make the changes and press ctrl-s and it saves the file back to the file system. Never have to use vi or vim.

It's the difference between actively developing in UNIX and developing on files stored on a UNIX box. If you're living in UNIX and have multiple shells open all the time to be running stuff, being able to open a quick edit session on the file right in front of you is very nice.

Hypatian wrote:

It's the difference between actively developing in UNIX and developing on files stored on a UNIX box. If you're living in UNIX and have multiple shells open all the time to be running stuff, being able to open a quick edit session on the file right in front of you is very nice.

True, but I find going to the file in winscp is faster then trying to get vi to do what I want (for me at least).

Heh. Experience will tell, I guess. Back when I started at University (1993), our typical strategy for developing as CS students was to log in to our DECstation 3100 or 5000s in the computing cluster, and then not start X11 (because it was so slow) but instead start up a locally developed tool called niftyterm that would provide a high resolution text console with VT100 support. Developing from my 486DX4/100 in the dorm room, I'd usually telnet in to the timesharing servers (over token ring, not ethernet). If you're already used to working at the terminal, working in a remote terminal is no big deal. ;>

Anyway, on my side I get frustrated at how slow and painful it is to use GUI things to do stuff like scp files around, instead of using the command-line. So yeah, some differences in where you come from can make a world of difference.

Vim is a wonderful editor, and I use it just about every day, but I am not a hoary, neckbearded, kernel hacker zealot like some vim and emacs users are --not referring to present company.

My new favorite editor is Sublime Text 2

It is fast, has a great packaging system, is extensible and customizable (the backend is Python), and is multi-platform (OSX, Win, and *nix). I can even use vi hotkeys if I want.

Hypatian wrote:

You painted a picture of them being very different, but they're really not.

That's not exactly what I was going for. The topic was differences between Hg and Git, so yes, I focused entirely on the differences. (At least, that's what I thought I was responding to, but since I didn't quote anything and don't see anything when skimming, now I'm not sure what prompted the post. Lazy posting "FTW" )

My current favorite plaintext editor for windows in Textpad, and nano in *nix. I know most of the vi basics from some tutorials, and playing a lot of roguelikes. Almost all of my version control experience is with Subversion, which I like a lot.

Bonus_Eruptus wrote:

I said no, but he changed us from Vault to TFS the first day I took a vacation, without letting me know. After having just used his batch-file deploy script, and being told it was more robust than Jenkins, Cruise Control, or TeamCity, I'm pretty sure I'm going to change things while he's gone.

Any suggestions for a .NET 4.0 WinForms app, as far as continuous integration, source control, cool-sh*t-I-should-be-using? Previously rejected suggestions include:

I heart, heart, heart TeamCity, mostly because it seems to work with just about everything. I'd certainly recommend subversion if you can spare a low-end machine to run Linux and an SVN server. It's pretty simple to setup and run. Are you using any command-line build tools currently? The only windows one that I'm aware of is NANT, which I know works with TeamCity. I don't know if it specifically works with .NET 4.0 WinForms, but it probably does. Also, it works with NUnit, a unit testing framework for various microsoft technologies. Definitely try that out, too.

Continuous integration is an awesome kind of special sauce that just makes all development better.

I do enjoy a good text editor war*.

Real men use notepad...

[size=1]*In this instance war alludes to non violent discussions..so far ;)[/size]

Mixolyde wrote:
Bonus_Eruptus wrote:

I said no, but he changed us from Vault to TFS the first day I took a vacation, without letting me know. After having just used his batch-file deploy script, and being told it was more robust than Jenkins, Cruise Control, or TeamCity, I'm pretty sure I'm going to change things while he's gone.

Any suggestions for a .NET 4.0 WinForms app, as far as continuous integration, source control, cool-sh*t-I-should-be-using? Previously rejected suggestions include:

I heart, heart, heart TeamCity, mostly because it seems to work with just about everything. I'd certainly recommend subversion if you can spare a low-end machine to run Linux and an SVN server. It's pretty simple to setup and run. Are you using any command-line build tools currently? The only windows one that I'm aware of is NANT, which I know works with TeamCity. I don't know if it specifically works with .NET 4.0 WinForms, but it probably does. Also, it works with NUnit, a unit testing framework for various microsoft technologies. Definitely try that out, too.

Continuous integration is an awesome kind of special sauce that just makes all development better.

+1 on TeamCity. Easy to set up (even on Windows!), free (for 3 build agents and 20 build configs), flexible (can build native VS project files, MSBuild, NAnt, probably even Evil Team Lead's script, integrates with Subversion, Git, TFS, plus a ton of other VCS).
We use it for everything: Windows C++, C# projects, Java projects deploying to Linux. It really is a pretty great tool, made by the same folks that develop ReSharper, IntelliJ IDEA, etc. Here's their supported environments (as of version 6.5, the latest at this time):

IMAGE(http://confluence.jetbrains.net/download/attachments/37236940/TC_spider_May2011.png?version=1&modificationDate=1305728298000)

I default to Notepad++ for everything I can avoid Eclipse on.

I barely know enough vi to edit .properties files and shell scripts really.

But it does give you super powers.

My company uses TeamCity. Highly recommended, especially for smaller teams that don't even have to pay for it.

Dr.Ghastly wrote:

...Real men use notepad...

Real men also know when to stop using Notepad.

duckilama wrote:

I default to Notepad++ for everything I can avoid Eclipse on.

I'm sorely tempted to ask for more info on that, but I'm afraid I'd derail the thread finding the meaning behind it.