… I’ll just point them to this article and explain that I’m just sweating the details. If you’re a programmer, that is a lot more important than most people and most programmers would believe.
Quick hack/warning for those using an alternative command line processor like TCC and also use Xoreax’ Incredibuild for distributed builds. Incredibuild is awesome, by the way, and if you have a larger C++ project that takes a long time to build, you should use it. And no, I’m not getting paid or receive free stuff for writing that.
However, if you have to start your Visual Studio instance from the command line because you need to set some environment variables first, or because of your general awesomeness, make sure you’re starting it from a stock Windows shell. Either the standard Windows command line (cmd.exe) or PowerShell will do nicely, thank you. If you start VS from TCC and have a couple of build tasks that spawn out to the shell, Incredibuild wants to shell out into TCC to run these tasks and the shelled out task don’t seem to return control to Incredibuild again. Yes, I was too lazy to investigate further as the method described above works.
Interesting story how a development team at Facebook debugged a resource handling issue in their iOS app.
What they found is another strong argument for using techniques like RAII to automate your resource management if you are working in non-garbage collected OO languages.
A couple of interesting articles about debugging. Debugging doesn’t seem to get a lot of attention when people are taught about programming, I assume you’re supposed to acquire this skill by osmosis, but it is actually one of those skills that should receive much greater attention because it’s one of those that separates highly productive developers from, well, not so productive ones.
Why I’m Productive in Clojure. I’ve long been a fan of Lisp and Lisp-like languages, even though I wasn’t originally that happy with having Lisp inflicted on me when I was at university. Because it was weird and back then I didn’t much appreciate non-mainstream languages. These days I do because that’s where you usually find better expressiveness and ideas supposedly too strange for mainstream languages. I guess that makes me a language hipster.
We have a Nest thermostat and I wasn’t too keen when I heard that Google bought them. Probably have to look into securing it (aka stopping the data leakage). While I understand the trade “your data for our free service” model from an economics perspective, I do take some issue with the “we’ll sell you a very expensive device and your data still leaks out to us” model. Nests aren’t exactly cheap to begin with.
Debugging on a live system that’s shouldn’t be live. Been there done that, on a trading system…
Netflix and network neutrality, as seen from the other side. I’m an advocate of regulating ISPs (especially the larger ones) as public utilities and essentially enforcing network neutrality that way. Netflix obviously has been going on about network neutrality for a while now but the linked article does make me wonder if those supposed “pay to play” payments were actually more like payments for the server hosting. You know, like the charges that us mere mortals also have to pay if we want to stick a server into someone’s data centre.
OK, I admit it – I’m a dinosaur. I still use the command line a lot as I’m subscribing to the belief that I can often type faster than I can move my hand off the keyboard to the mouse, click, and move my hand back. Plus, I grew up in an era when the command line was what you got when you turned on the computer, and Windows 2.0 or GEM was a big improvement.
One of the neat features of the console emulators on both on Linux and Mac OS X was and is that you could run a set of shells in a tabbed single console window. A post on Scott Hanselman’s blog put me onto Console2. That was more like it and I pretty much immediately housed my Windows shells – either cmd.exe or PowerShell – in there. Much better, but over time the pace of development slowed and the last beta release dates from 2011. It’s not like the Beta is buggy or anything – in fact, in my experience it works very nicely indeed – but of course as a software engineer I like shiny new things.
Enter, via another post on Scott Hanselman’s blog, ConEmu – or ConEmu-Maximus5, to give it its full name. If Console2 is the VW Golf to the stock Windows’ console emulator’s 1200cc VW Bug, then ConEmu is the VW Phaeton to Console2’s VW Golf. It’s got a lot more features, it’s actively developed, it works well with Far Manager if you miss the Norton Commander days and it’s highly configurable. Of course, it also can handle transparent backgrounds, but so can Console2.
For me, it has one killer feature – recent versions detect which shells you have installed on your machine and offer you a selection via the green “new tab” button (the one that looks a bit like a French Pharmacy sign), with a choice of running them either as a regular user or admin user:
Why is this such a big deal? Well, it’s neat if you’re using both PowerShell and cmd.exe, but for me it’s a killer feature because I like using TCC/LE, at least at home. TCC/LE is the familiar Windows command prompt at first glance but in the same way that ConEmu is a much expanded console emulator compared to the regular Windows one, TCC/LE is a much expanded command prompt that is a lot more feature rich and has a lot of sensible extensions. And because I’m such a dinosaur, I’ve actually been using its predecessors (4DOS and 4NT) way back when they were distributed as shareware on a floppy disk and you had to buy the manuals for them to get the registration code. And yes, I still have at least the 4DOS manual.
Back to console emulators, though. If I wanted to go nitpicking, both ConEmu and Console2 work less well over an RDP connection than the stock console, which is noticeable if you tend to remote into machines quite frequently. It’s not that they work badly, but Microsoft clearly spent a lot of time optimising the stock console to work well over RDP (or to have RDP work well with the stock console), so there is a bit of lag when scrolling. It doesn’t make either tool unusable but you notice it’s there.
Anyway, if you check out one new tool this week, make it ConEmu.
First, a confession – I actually occasionally call myself a coder, but in a tongue in cheek, post-modern and ironic way. Heck, it does make for a good blog title and license plate.
Nevertheless, with all the recent “coding schools” cropping up all over the place – at least if you are in the Bay Area – it does seem that being able to code in the context of a reasonably sought after web technology without much further formal training is the path to new, fulfilling careers and of course untold riches in an economy where recent graduates in all fields have problems finding work. Well, at least a career that allows you to rent a room instead of crashing on somebody’s couch.
There are some problems with the whole “mere coder” thing. Dave Winer has some interesting thoughts on his blog, and I agree with a lot of what he says. Scott Radcliff has some additional thoughts, which I also find myself agreeing with a lot.
The process of building a software system is a lot more than just coding unless you subscribe to the view that all the coders do is to take the gospel handed down by A Visionary Leader and convert it into software. Anybody who’s ever built a moderately complex system knows that software doesn’t happen that way, at least not the type of software that doesn’t collapse under its own weight shortly after its release. Of course that doesn’t sit well with the notion of The Visionary Genius that is all that is required to build the next and the narrative doesn’t work at all once you recognise that building software is, in most cases, a team sport.
Expecting someone who has learned to write code to o create a great piece of software is like expecting someone who’s just gone through a foreign language course of similar length to go and write the next great novel in that particular language. Sometimes you get lucky, but most of the time the flow isn’t there, the language isn’t yet used in an idiomatic way and all that together makes for less than an enjoyable experience. Some of the people who manage to enter the profession of software development will learn on the job and grow into people who can build robust, maintainable systems and those are to be congratulated.
The way most people use the term coder, ie in a non-postmodern ironic way, reminds me very much of the time when a programmer’s job was to unthinkingly program as part of a little cog in the giant waterfall development machine, which led to the WIMP (Why Isn’t Mary Programming) acronym. Basically, if the keyboard wasn’t constantly clattering, there was no programming going on.
That said, maybe we are at a point in time where an army of coders as the modern equivalent of the typing pool is able to create good enough software. Given that most users are conditioned to believe that software is infuriating and buggy, we as an industry might well get away with. Is that the world we want to live in, though?
As creators of software, we do have the ability to choose the environment that we work and live in. If you care about quality, work with like-minded people.
Me? I prefer to call myself a software craftsman. I’m not an engineer, I write code but that’s almost an afterthought once the design is figured out but at the end of the day what I do is build something that wasn’t there before, using vague guidelines that are wrong as often as they are right while trying to tease out what the customer needs rather than what they tell me they want. In most cases there is no detailed blueprint, no perfect specification that only needs to be translated 1:1 into lines of code. Instead, I get to use my experience and judgement to fill in the blanks that most people – myself included – probably didn’t even think were there.
Sounds like a job for a craftsman to me.
Like pretty much every other programmer with a Mac, I’m currently looking at Swift. Will I write anything but toy programs in it? I don’t know yet – I don’t really write any Mac-ish software on my Mac, just unix-ish programs. If Swift doesn’t escape the OS X and iOS ecosystems it’ll be a nice exercise in a neat language that’s not really that relevant to the world at large, or at least to my part of the world at large. Not that this sort of vendor lock-in can’t work well – Visual Basic 6, anybody?
I hope Apple will open the language to be used outside its software ecosystem but from what I have read so far, it’s tightly integrated into the iOS and Mac OS X runtimes so I’m not sure how feasible that even would be. Still, I’m pretty sure it’ll remain on my list of languages to play with.
It’s amazing how far we have come since I started playing with computers, yet they’re still not fast enough.
Admittedly I’m not the biggest fan of git – I prefer Mercurial – but we’re using it at work and it does a good job as a DVCS. However, we’re mostly a Windows shop and the out of the box performance of Git for Windows is anything but stellar when you are using ssh as the transport for git. That’s not too much bother with most of our repos but we have a couple of fairly big ones and clone performance with those matters.
I finally got fed up with the performance after noticing that cloning a large repository from the Linux git server to a FreeBSD box was over an order of magnitude faster than cloning the same repository onto a Windows machine. So I decided to start digging around for a solution.
The clone performance left a lot to be desired using either PuTTY or the bundled OpenSSH as the SSH client. I finally settled on using OpenSSH as I find it easier to deal with multiple keys. Well, it might just be easier if you’re a Unixhead.
My search led me to this discussion, which implies that the problem lies with the version of OpenSSH and OpenSSL that comes prepackaged with Git for Windows. The version is rather out of date. Now, I had come across this discussion before and as a result attempt to build my own SSH binary that included the high performance ssh patches, but even after I got those to build using cygwin, I never managed to actually get it to work with Git for Windows. Turns out I was missing a crucial detail. It looks like the Git for Windows binaries ignore the PATH variable when they look for their OpenSSH binaries and just look in their local directory. After re-reading the above discussion, it turned out that the easiest way to get Git for Windows to recognise the new ssh binaries is to simply overwrite the ones that are bundled with the Git for Windows installer.
*** Bad hack alert ***
The simple recipe to improve the Git performance on Windows when using a git+ssh server is thus:
- Install Git for Windows and configure it to use OpenSSH
- Install the latest MinGW system. You only need the base system and their OpenSSH binaries. The OpenSSH and OpenSSL binaries that come with this installation are much newer than the ones you get with the Git for Windows installer.
- Copy the new SSH binaries into your git installation directory. You will need to have local administrator rights for this as the binaries reside under Program Files (or “Program Files (x86)” if you’re on a 64 bit OS). The binaries you need to copy are msys-crypto-1.0.0.dll, msys-ssl-1.0.0.dll, ssh-add.exe, ssh-agent.exe, ssh-keygen.exe, ssh-keyscan.exe and ssh.exe
After the above modifications, the clone performance on my Windows machine went from 1.5MB/s – 2.5MB/s to 10MB/s-28MB/s depending on which part of the repository it was processing. That’s obviously a major speedup for cloning, but another nice side effect is that this change will result in noticeable performance improvements for pretty much all operations that involve a remote git repository. They all feel much snappier.
Visual Studio 2013, much like its predecessor Visual Studio 2012, also “features” the SHOUTY uppercase menus. As in Visual Studio 2012, these can be turned off using a registry setting.
tl;dr – run this command in PowerShell to turn off Visual Studio’s uppercase menus:
Set-ItemProperty -Path HKCU:SoftwareMicrosoftVisualStudio12.0General -Name SuppressUppercaseConversion -Type DWord -Value 1