IE, spawn of Satan

From: Peter (BOUGHTONP)27 Aug 2013 23:49
To: CHYRON (DSMITHHFX) 30 of 58
Unlike yourself?
From: CHYRON (DSMITHHFX)27 Aug 2013 23:57
To: Peter (BOUGHTONP) 31 of 58
Been there, done it. :O)
From: ANT_THOMAS28 Aug 2013 08:01
To: ALL32 of 58
:'D (fail)



Since I've recently started a job which could be classed as slightly corporate I've noticed a reliance on IE. I was sent a link to sign up to something by one of the MDs and when opened in Firefox it said I should probably use IE. When I opened it in IE I got that up there.

Our SAP CRM system only seems to function properly in IE too. It's usually a slow pile of shit though.
From: af (CAER)28 Aug 2013 08:22
To: CHYRON (DSMITHHFX) 33 of 58
No source control? At all? Good grief.

You could at least stick the whole thing in a local Git repo, if only to keep track of what you've done yourself.
From: ANT_THOMAS28 Aug 2013 08:23
To: af (CAER) 34 of 58
That is something I need to do for many of my little projects. I always end up with multiple different revisions all over the show :$
EDITED: 28 Aug 2013 08:24 by ANT_THOMAS
From: af (CAER)28 Aug 2013 08:56
To: ANT_THOMAS 35 of 58
Hah :D It's not even difficult or slow
Code:
git init .

Then create/edit the .gitignore file and add the names of any files you don't want included in the repo (passwords, compiled stuff etc.), then

Code:
git add .
git commit -am "Yay, my first commit!"

That sets everything up. Then when you make changes:

Code:
git add lib/some_new_library.rb
git commit -am "Add SomeNewLib to repo. Fix a broken thing."

The '-am' parameters mean, respectively: automatically add modified files to this commit; use the last part of the command (the bit in "quotes") as the commit message.

You can make a new branch based on the current one:

Code:
git checkout -b fancy_feature

The -b means 'create a new branch'. Leave it out to switch to an existing branch. You can merge changes from another branch to the current one:

Code:
git checkout master
git merge fancy_feature

This switches to the branch 'master', then merges 'fancy_feature' into it. If you edit the same part of a file in two different branches, then try to merge them, you'll get merge conflicts, which are a pain in the arse to fix, so don't do that.

To see which branch you're on, and what files have changed since last commit:

Code:
git status

To see what specific changes you've made since last commit:

Code:
git diff

You can include a filename after that to only diff that specific file.

Thus concludes my 5-minute intro to Git.

EDITED: 28 Aug 2013 17:00 by CAER
From: ANT_THOMAS28 Aug 2013 08:57
To: af (CAER) 36 of 58
And a damn good intro it was!
From: CHYRON (DSMITHHFX)28 Aug 2013 10:02
To: af (CAER) 37 of 58
Depends what you mean by "source control". I do daily code backups and sometimes more frequently for extensive modifications. I also add comments in situ which I find more helpful than sifting through a separate document. For large and complex projects where I'm breaking new ground (to me) I will keep dev notes too, mainly for my own use. The way the business works here is that nobody does formal source control for web sites (that I've ever seen, but who knows what crazy new fad might catch on), these aren't team coding efforts, you can very quickly find all the documentation you want on google, and if you need to work on someone else's code, you just wade in and figure out how to get the job done with the least amount of work, knowing full well nobody in their right mind is ever going to look at the code unless something breaks, and it's all going to be junked (your code, and quite possibly even the markup/scripting languages/versions themselves) in a few short years anyway.
From: Kenny J (WINGNUTKJ)28 Aug 2013 16:02
To: CHYRON (DSMITHHFX) 38 of 58
That's nuts! It's good that you take backups and notes, but these days there are a lot of good ways to do source control with not much overhead.

We use Mercurial in my place, with TortoiseHg as a GUI for it. We used to use Microsoft Team Foundation Server and Visual SourceSafe, but for the way we develop and deploy, those weren't really suitable. I'm a big fan - using it has a low overhead, and you can either use it as a personal thing to track revisions only for your self, or create a repository allowing collaboration between the team.
From: Ken (SHIELDSIT)28 Aug 2013 16:16
To: ALL39 of 58
That's something I need to check into.  I don't do much coding but when I do I have shit scattered everywhere.  What would you recommend for someone like me who only codes a little?  Something very easy to use please!
From: CHYRON (DSMITHHFX)28 Aug 2013 16:23
To: Kenny J (WINGNUTKJ) 40 of 58
I've used version control before in a couple of different shops, and it makes sense where teams are concerned. No benefit to me in my present situation though. I went as far as installing and starting to use git here a few years ago, and then I thought, wtf am I doing this? It's just adding needless complexity, which I generally avoid like the plague unless really, really bored.
From: Kenny J (WINGNUTKJ)28 Aug 2013 16:29
To: Ken (SHIELDSIT) 41 of 58
I'd recommend Git or Mercurial. I've found these links to be useful when explaining the concepts to people:

http://en.wikipedia.org/wiki/Revision_control
http://www.joelonsoftware.com/items/2010/03/17.html
From: Matt28 Aug 2013 17:33
To: CHYRON (DSMITHHFX) 42 of 58
Source control is very useful for sole development. If only as a huge persistent undo buffer. Want to make a breaking change and don't want to backup files? Commit them to source control. What to test something that might not work out? Commit them to source control.

Next you're going to tell us you use notepad to code in.
From: CHYRON (DSMITHHFX)28 Aug 2013 18:30
To: Matt 43 of 58

Quote:
Want to make a breaking change and don't want to backup files?
What to test something that might not work out?

It's hilarious that you depend on a thing called "source control" to perform idiot-simple functions like "undo". 

As it happens, I code with textwrangler/mac, geany/linux, and (rarely) textpad/windows. Textpad is a really nice editor, I wish it was ported to linux.
EDITED: 28 Aug 2013 18:33 by DSMITHHFX
From: Matt28 Aug 2013 18:46
To: CHYRON (DSMITHHFX) 44 of 58
Where did I say I depend on it?

Undo buffer was an over-simplification.

If you have a project that you need to make huge sweeping changes to, do you copy it somewhere so you can undo your changes? If you use source control you don't have to bother doing that, because you would have already submitted code that you can easily revert to. It also means you can freely close files in your editor without loosing the undo buffer.

You can also create branches to test things and merge or delete those branches back into your main/trunk when you've completed them. Branching is in incredibly useful for having multiple working copies of the code, but without the ball-ache of not having duplicates of everything floating around. For example, you might have one tagged as "release" where you can provide quick fixes to otherwise know stable code and many others for continuous (often called "trunk" or "main") development. With version control software like Git and Mercurial you can cherry-pick changes between branches too, so you can keep your "trunk" up to date with fixes from "release".

I used to use Textpad, but gave up after the author abandoned it (7.x is functional no different to 6.x) and never got around to adding auto-complete / function argument hinting. If you don't want to pay for an Editor, Netbeans (IDE) and Notepad++ (Editor) are about the best you can get.
EDITED: 28 Aug 2013 18:52 by MATT
From: Matt28 Aug 2013 18:49
To: Ken (SHIELDSIT) 45 of 58
I heartily recommend Mercurial, but only because it has better tools than Git does. Git and Mercurial are very similar in functionality, but Git lacks good desktop GUI tools, where as TortoiseHG is just about the best source-control client ever.
From: Ken (SHIELDSIT)28 Aug 2013 18:58
To: Matt Kenny J (WINGNUTKJ) 46 of 58
Can you point me to the correct thing I'd need to install it on Windows? And will I need Python?
From: CHYRON (DSMITHHFX)28 Aug 2013 19:01
To: Matt 47 of 58
We used tortoise on one of my prior engagements. It is good.
From: Kenny J (WINGNUTKJ)28 Aug 2013 19:10
To: Ken (SHIELDSIT) 48 of 58
Jeez Ken, let me fucking Duck Duck Go that for you...
http://tortoisehg.bitbucket.org/download/

It installs everything you need, and if I remember correctly it has the version of Python it needs as a dll.

Setting up a repository is as simple as right-clicking a folder and using the relevant entry in the TortoiseHG menu.
From: Matt28 Aug 2013 19:11
To: Ken (SHIELDSIT) 49 of 58
TortoiseHG.

Install it, it adds shell extension to Windows. Create a folder in Windows Explorer where you want to keep your repository and right click in it and choose TortoiseHG > Create Repository Here. It will create a .hg folder and a .hgignore file for you. On Linux these would be hidden, on Windows you should just ignore them, even .hgignore, as you can manage everything with TortoiseHG.

Once you've created the repository, you can open the main TortoiseHG window by selecting the "Hg Workbench" option on the right click menu. From here you can submit, create branches, switch branch, roll back, etc. etc.

If you want to push and pull to a "remote" repository, you can set that up in the repository settings.

By "remote", Mercurial (and Git) essentially mean somewhere else. That somewhere else doesn't have to be another machine it can be another folder on the same machine if you wish. Mercurial and Git are both distributed version control systems, meaning there is no server, so although services like bitbucket and github exist, you shouldn't think of them as servers, but another client that you push to and pull changes from to keep up to date.