Author: geostock

Here are my normal steps for starting a project:

1. Have idea
2. Buy Domain Name
3. Start sketching idea out
4. write some code, push it to github
5. stop working on project
6. goto 1;

Turns out, I’m not alone:

For example, I’ve got 30 domains and I’ve only done something awesome with 3 of them. Sometimes when I log into my DNS manager I just see 27 failures. I think to myself, there’s 27 potential businesses, 27 potential cool open source projects just languishing. If you knew anything you’d have made those happen. What a phony.

To break this cycle, I’m taking a page that’s often repeated in blog posts and on Hacker News (although when I’m looking for the references, I can’t find them). From now on, I’m putting it all out there.

If I’m working on something, it’s going public.  The way I see it, this accomplishes a few things:

1. The shame factor is much higher. When I have a domain name, you probably can’t see it (unless there’s something that let’s you search `whois` records by the name of the person that registered the domain? Is there?), but with my code out on github, you can see whether or not I’ve been working on those projects.

2. Feedback.  Last night I asked on twitter about a problem I’m having:

JavaScript programmers, and especially JS Game developers: how should I handle key input on a text based game? https://t.co/Vjm5hHOilq

— George Stocker (@gortok) April 17, 2014

Almost immediately, Justin Niessner replied with:

@gortok State machine rather than re-writing the onkeypress handler?

— Justin Niessner (@CrshOverride) April 17, 2014

I knew about State machines, I’ve even written a patch for Evan Plaice’s JQuery-CSV library that allows it to work on Macs (Todo: put that fix in my branch), currently it’s only in use on The Motley Fool‘s Scorecard (Portfolio) tool to import CSV files that I wrote. But what I didn’t know was that they were applicable to my situation. I’d never thought about them being used in gaming. Because I put my code out there, I was able to get an answer and do some research into how games implement the state pattern.

3. Blog posts. Putting my code out there gives me something to reference when I’m writing a blog post, and it helps me to remember the state that my code was in when I’m writing the blog post. In the old days of Subversion, the ‘end’ product would be all that showed up, not the numerous steps to getting to that end state.

4. Tracking Progress: Fear may be a good motivator, but actual progress is motivating too. It’s easy to forget progress when everything is private. In my own mind, I started programming yesterday, nevermind that it was 14 years ago. It’s easy to forget those little bumps along the way. I must have relearned trivial CSS knowledge half a dozen times over the past 14 years, and without writing it down and documenting it, I’ll probably relearn it half a dozen times more.

As of today, any non work-for-hire code I have on Github, I’ve turned public.

It’s scary, but isn’t that what learning is all about?

The following image about programmer productivity is making its rounds on the internet:

As Homer Simpson might say, it’s funny because it’s true.

I haven’t figured out the secret to being productive yet, largely because I have never been consistently productive. Ever. Joel Spolsky talks about this in one of his blog posts:

Sometimes I just can’t get anything done.

Sure, I come into the office, putter around, check my email every ten seconds, read the web, even do a few brainless tasks like paying the American Express bill. But getting back into the flow of writing code just doesn’t happen.

These bouts of unproductiveness usually last for a day or two. But there have been times in my career as a developer when I went for weeks at a time without being able to get anything done. As they say, I’m not in flow. I’m not in the zone. I’m not anywhere.

I’ve read that blog post about half a dozen times now, and It still shocks me that someone who we see as an icon in the programmer community has a problem getting started.

I’m glad I’m not alone.

I’m not here to share any secret methods to being productive, but I can tell you what has kept me from being productive:

• Open Floor plans
• Developers arguing about Django vs. .NET
• Developers arguing in general
• A coworker coming up to me and asking, “Hey, did you get that email I sent?”
• Chewing. Apparently I suffer from Misophonia
• Not understanding the problem I’m working on
• Not really believing in the project
• Not understanding where to start
• Facing more than one task that needs to be complete BECAUSE THINGS ARE ON FIRE RIGHT NOW
• Things BEING ON FIRE RIGHT NOW DROP EVERYTHING
• Twitter Notifications on my Phone
• Email pop ups
• Really, any pop-ups
• IMs
• My wife asking, “Hey, when you have a minute could you do X?”
• Long build times
• Noise
• Constant parade of people going past my desk
• MandoFun
• Wikipedia (Seriously, don’t click on any links)
• Hacker News
• The Internet in General

Things that have contributed to making me productive in the past:

• Quiet atmosphere
• Quiet workspace (A private office works wonders)
• Understanding the next step I need to take in a project
• Knowing the problem space well
• No interruptions
• Seriously: No interruptions
• Staying off Twitter
• Staying off Hacker News
• No hardware problems
• Loving the project I’m working on
• Short build and debug times
• Not debating politics on the internet

 

It’s telling that half of the things that keep me from being productive are problems I’ve created; but some of them aren’t. Like Open Office floor plans.

Ultimately, each of us controls what makes us unproductive. I suck at peaceful confrontation. I either come of too strongly, or I sit there and let the other person walk all over me. I’m really not good at it at all. As such, I don’t have any good advice for handling the external forces that contribute to not being productive, but I do know this: Whatever I can control, I should control. That means:

• Turning off notifications on my iPhone (this has the added benefit of increased battery life)
• Giving myself a reward for 3 hours of continuous coding (usually in the form of “internet time” like checking Hacker News or twitter)
• Working from home when I really, really, need to get something done
• Investing in a good-for-the-price pair of noise canceling headphones
• Scheduling ‘no meeting’ times on my calendar. These are times shown as busy to everyone else. It’s my work time.
• Not getting into programmer arguments around the office; people have strong opinions, and the programmers who have arguments love to argue. If there’s an actual business problem that needs to be solved, let’s grab a conference room and come up with the advantages and disadvantages of each approach. Let’s get some data. Let’s not just argue.
• Position my desk in such a way that passersby aren’t distracting.
• Taking a first pass at the problem, and *then* asking another developer to walk me through the problem so that I can get a better understanding of what to do. This accomplishes two things: First, it allows me to get the ‘lay of the land’ so that I’ll at least have a basic understanding of the forces at work. Second, it allows me to ask more intelligent questions when I ask for help

What makes you unproductive, and what do you do to combat it?

Discuss this post on Hacker News or Reddit.

Edited on 9 July 2014 for typographical errors.

My career has gone through many phases: Perl to PHP, PHP to VBA, VBA to C#, C# to Python, Python to JavaScript, and back to C# again. I’ve tried Dual booting, I’ve tried VMs, I’ve tried dedicated machines for each environment. I’ve tried corporate “certified” machines (Lenovo), I’ve tried building my own dev machines. Nothing is pain free, but after jumping through every hardware problem known to man, the least painful developer hardware I’ve found is

The MacBook Pro.

Just about every issue I’ve had with development revolves around three specific problems:

– Stability
– User Experience
– Developer Support Tools

Stability

The MacBook Pro (MBP) absolutely kills in the stability arena. The Operating system is stable, I don’t have to worry that patching my system will result in rebuilding the OS, and I don’t have to worry about Windows Updates.  For running VMs, ReSharper is amazingly stable, able to suspend and restart the VM quickly for when that’s needed.

User Experience

Have you ever had this happen to you? You’re in Windows, and you’ve hit “Postpone” on an update, only to walk away from your computer and find that the update installed and restarted your computer without your consent?  Or, if you’re using linux, and you make the mistake of using apt-get and it installing a new linux kernel, only to have your system hosed on reboot?  My personal best? That happened three times before

I wised up.

Apple’s user experience is top notch (iTunes notwithstanding). While there is some fussiness around setting up Python for a Mac, there are clear analogues for developers who want to develop for FOSS on a MBP. The OS comes back quickly from sleep; the keyboard and trackpad contain unobtrusive (yet useful) features.  The entire experience from opening the box to using it for actual development is insanely easy compared to other platforms, where sometimes sound drivers don’t work, or the installation fails for no particular reason.

One significant advantage to choosing a MacBook Pro is that Apple needs to only support a handful of hardware, instead of the thousands upon thousands of combinations of hardware choices that Linux and Windows need to support.

Developer Support Tools

For Mac, Parallels is one of the best pieces of virtualization software out there. I can run a Windows VM and a Linux VM in Parallels and have everything just work, including each VM communicating with the others and the outside world over HTTP. I tried to get Hypervisor to do that over the course of two days and was met with failure.

There are some issues with Mavericks, however. If you click on a dialog that wants your attention (the bouncing icon in the Mac OS X Icon Bar) and the icon belongs to a VM on a different desktop (multiple monitors), you get… weirdness.

One area where Mac has been deficient before Mac OSX Mavericks was multiple monitor support, in that it didn’t really support multiple monitors. Now with Mavericks there is first class support for multiple monitors, but it’s not perfect yet.

Have you ever tried to get support for a Dell? It’s terrible. Hours spent on the phone to have a customer service representative tell you to wait for them to ship you a box so you can ship your Dell back for replacement. Contrast that with the Apple Store experience. I’ve taken my MBP to the Apple Store three times, and all three times I was in and out within 30 minutes, and *every single time* it was free. That’s incredible.

With the advantages the Macbook has over other development experiences, it’s hard to imagine reasons *not* to use it for development.

 

I’ve worked on six greenfield projects as a programmer¹. Do you know how many of those projects succeeded? Three.

That’s my shipping percentage for greenfield projects: 50%. When I think about the projects that failed, they had one or more of the following themes:

Not shipping early enough: It’s really easy to add fluff to a project. For one project we made a wrapper for the E*Trade API along with the architecture to securely handle OAuth tokens. It was quite an elaborate architecture for something that ultimately didn’t ship.

How to address it: Ship the most minimalistic thing you can. Lean startup talks about this as a Minimum Viable Product. Even more basic than this is to start with an experiment.

What we should have done, and what we did for a lot of features thereafter, is started with a landing page that promised people that product. Then we should have taken out the AdWords we were planning to take out, drive traffic to that landing page, and offer people to buy the experience that we are talking about.

If we had set up a button and a landing page for the product (Without actually building the product), we would have known how many people actually wanted it. It would have taken us about a week to have our idea validated. Instead, we squandered four months building something that we ended up not shipping.

Biting off more than we could chew: Years ago, Joel Spolsky wrote about Things you should never do, Part I (there never was a Part II). In it, he talked about the action that singlehandedly torpedoed Netscape:

Netscape 6.0 is finally going into its first public beta. There never was a version 5.0. The last major release, version 4.0, was released almost three years ago. Three years is an awfully long time in the Internet world. During this time, Netscape sat by, helplessly, as their market share plummeted.

It’s a bit smarmy of me to criticize them for waiting so long between releases. They didn’t do it on purpose, now, did they?

Well, yes. They did. They did it by making the single worst strategic mistake that any software company can make:

They decided to rewrite the code from scratch.

It’s one of those blog posts that you read, laugh at, and say, “We’re not that stupid. We won’t make that mistake.” and then you proceed to make that mistake. We did. The project was essentially a rewrite of the application that made all of the money. It was an attempt to unify different parts of the application and to be able to cross-sell and up-sell other products.

It was shut down one week before its beta launch; 5 months after the project began development work.

One of the major issues from a rewrite is getting executive level buy-in (and keeping it). A rewrite is a way of making programmers feel better about crappy code. Just rewrite it! The problem is that if you’re rewriting something, you’re not (by definition) making it better for the people who pay for it. At most you’re making it better for future features, and at worst you’re just making different mistakes.

Technical debt is real, and it has a disastrous effect on programmers’ psyche; but a rewrite isn’t a sustainable way of addressing technical debt.

How to address it: Ask the people who pay the bills frequently about their expectations, but frame it in such a way that they can’t weasel out of an answer. If you ask a business executive, “How long do we have?” They’ll say, “as long as it takes to finish.” They don’t really mean that. It’s not their fault — they have great intentions, but they don’t really mean that. They really mean, “As soon as conceivably possible.” One way to see what the threshold is is to ask, “If it takes us three months, how would that sound to you?” Watch their body language for the answer. If that number seems high to them, they’ll flinch, or stumble, or otherwise show that they think three months is too long. You may also get a response to that effect. If they seem fine with that, extend the length until you get past their comfort level. This also works really well on individual features.

Team dynamics: It’s weird how certain combinations of people just don’t work well together. Bob and Steve work well together. Steve and Emily work well together, and Bob and Emily work well together. Put them all in a group, and suddenly you have a dysfunctional team on your hands. In a company where developers often move to different projects, every so often those combinations crop up. It’s not a reflection on anyone in particular, but it’s bad when it happens. Sometimes a team just doesn’t gel, and from personal experience that can doom a project.

How to address it: Talk about it early, as soon as it becomes apparent. Team retrospectives (with beer) are a great way to loosen lips and to hear what people think. Don’t schedule it as a retrospective, schedule it as a time for the team to ‘talk about how we think we’re doing’. The first ten minutes will be positive, the next twenty will be a little deeper; but by the 35 minute mark you should start to hear how people really feel.

Any project I’ve worked on that has succeeded has either had these problems and worked through them quickly, or not had them at all. These are not insurmountable issues, but unchecked, they will torpedo projects.

“Watson, when I say you are instructive, I mean I learn from your mistakes.” — Sherlock Holmes to Dr. Watson

---

[1]: I’ve worked on a lot of different projects, but only 6 greenfield projects. Every other project had already shipped, and we were either developing new features, or we were just maintaining the project. I feel lucky in that I was able to work on 6 greenfield projects in a three year span.

Yesterday I posted about the Heartbleed bug, but didn’t address why it’s called “Heartbleed”. I err’d in the writing of that blog post on (at least one point):

It’s called “Heartbleed” because programmers love cute names. I haven’t actually found a credible source for its naming, so I default to the ‘cute’ reasoning. It’s accurate in general, if nothing else.

That was partially right. Programmers do love cute names. But that’s not the full story. After doing some more research, I found out why it’s called the Heartbleed bug, courtesy of this Security.SE answer:

In short, Heartbeat allows one endpoint to go “I’m sending you some data, echo it back to me”. You send both a length figure and the data itself. The length figure can be up to 64 KiB. Unfortunately, if you use the length figure to claim “I’m sending 64 KiB of data” (for example) and then only really send, say, one byte, OpenSSL would send you back your one byte — and 64 KiB (minus one) of other data from RAM.

Whoops!

So the function that has the bug is called “Heartbeat”, and the bug allows for the server to ‘bleed’ information it should otherwise not send back. HeartBeat + bleed = HeartBleed.

Clever.

---

Authors [foot]note: A shorter form of this answer made it into my inaugural Higher Logic blog post, as well.

I love Angular. It’s a great client-side MVC framework. One of its major issues is a lack of understanding of how to put together an Angular Application, and the documentation is no help there.

They tried to improve by including a reference application (app), but… Well…

Yea.

The problem with reference apps is that they’re not actually being used. Here’s the difference between the two:

It doesn’t have to be this way.

You can open source your Angular project.

There are traditional arguments against Open sourcing proprietary applications; but I argue that none of those apply here.

– It’s our proprietary code: It was, before you released it as an Angular application. Now anyone can see the entire source code of your project. Even if you minify it, they can still see it.
– It’s got our secret sauce in it: It probably shouldn’t. You should move any proprietary algorithms or methods to the server side, and expose the result through the API.
– It’s not very good!: That’s ok. Any app that has real world usage is useful to see.
– Someone may find a vulnerability: That’s good! They’ll let you know there’s something wrong
– What if our competitor sees it?: Since (by their nature) JavaScript applications are available to the client; it’s likely if they cared about it, they’d already have copied it. You don’t have a source problem, you have a legal problem.
– The source code is a mess! It’ll take us weeks to get it ready: Every company has a period of downtime. Business rarely goes full tilt 24/7. Use one of those periods between product launches to schedule this work. It’ll let your developers relax and recoup after a hard push.
– I don’t want to accept patches: That’s your right. It’s not exactly the smartest move, but putting the source code on Github doesn’t mean you have to accept other people’s patches.

With those aside, let’s look at the positive reasons for open sourcing your Angular Application:

– Community respect: People are more likely to trust someone they perceive as honest and open. Open sourcing your Angular app (That’s already ‘open’ anyway) gives you a net positive with little to no downside
– More eyeballs: It’s more likely someone will uncover a bug, and in the spirit of community, they may even issue a pull-request with a fix.
– Learning: Everyone learns when they open source something. The people who do it, and the developers who will see the code. Putting the code out there ensures that there are better examples of how a real world Angular application is structured.
– Recruiting tool: You may have unlimited vacation and free lunches, but one of the things that developers really care about is being on the cutting edge and have the ability for everyone to see what they do.

Open source your angular app. There are lots of reasons to do it and very few reasons not to.

This morning while getting reading for work I heard Fox 5 news talk about the Heartbleed Bug. Fox business correspondent Lauren Simonetti referred to it as the “Heartbleed bug virus.” Since it’s a live segment, I figured it was just a verbal gaffe, so I double checked against the recorded segment she does daily for Fox Business:

“Today is the day to refrain from online banking and plugging other sensitive information into the web. That’s because security experts have found a virus called the “Heartbleed bug.” It attacks the software used to provide encryption of 2/3rds of all servers on the Public Internet.” (emphasis mine)

It’s easy to make light of non-techie explanations of software problems, but the blame really is on us. We don’t do a great job of non-technical explanations. If you’re looking for a technical explanation of Heartbleed, here’s one.

For the non-techies among us (especially news anchors), I’ll try to provide a good non-technical metaphor for what the Heartbleed bug is.

The Heartbleed bug is a software bug, *just like any other software bug*. The term ‘bug’ may be confusing here, but we mean a bug to mean a defect in a line of code somewhere, causing the software to behave in a manner that wasn’t intended by its author. They’re named ‘bugs’ because the first computer software error *was literally caused by a bug in the computer*.

It’s called “Heartbleed” because programmers love cute names. I haven’t actually found a credible source for its naming, so I default to the ‘cute’ reasoning. It’s accurate in general, if nothing else.

In human terms, viruses are referred to as ‘bugs’. They’re often used interchangeably, as in “Thanks for giving me that bug that’s going around.”

In software terms, they mean completely different things.

A virus is a piece of software *intentionally* written to infect computers. They can do many different things, from turning on your web cam without you knowing to just being really annoying.

Bugs are *unintentional* defects in software.

In the case of the Heartbleed bug, the defect is the digital equivalent of you leaving your house unlocked for two years in plain view of everyone in the world, and them able to get into your house, listen to your conversations, watch everything you do and record absolutely everything you’ve looked at on the internet for the past two years, while you were looking at it². Any website, any financial transaction, anything. All without you knowing.

Normally you’d just change your locks, but that wouldn’t help you here. They have the digital equivalent of a skeleton key to 2/3rds of the locks in the world¹. Until the company that makes the lock revoke the skeleton key and issues a new one, there’s nothing you can do. Changing your locks won’t help until then.

That’s how serious this software bug is. In your daily travels on the internet, I can guarantee at least one site you use is affected by it.

So what can you do?

– Don’t log into your bank or any sensitive site until they’ve confirmed that they’re not affected by this bug, or they’ve issued new SSL certificates for their site.
– Change your password for each site *after* it has revoked its security certificate.
– Never use the same password on two sites. If you do, at least make sure your bank and other sensitive sites have their own passwords that aren’t used by any other site (or used on each other).
– Follow these helpful instructions to make sure Chrome looks for certificate revocations:

Use Chrome? Go to about://settings and check this box. It kinda helps (but not really, but still, check it anyway) pic.twitter.com/HOZkBTT77b

— Michael Pryor (@michaelpryor) April 9, 2014

To leave you with a bit of levity and to put this gaffe in context,
It’s not as if this is the first time a news anchor has made a technical gaffe. It’s even pretty low on the scale: The king of all tech gaffes would have to be Katie Couric and Bryant Gumbel’s hilarious description of what an email address and the internet is.

——

1: Techies will note that I’m conflating terms here between the skeleton key (SSL certificates) and your house lock (your password). Sometimes there just aren’t non-digital equivalents, so we make do.

2: Heartbleed allows the attacker to see 64K of what’s in memory at the given moment of attack. This is trivial to automate.

A week ago Friday, I bid farewell to The Motley Fool, my programmer home for the past three years.

Three years. Wow. When I wrote that blog post, I wrote something vague because I had no idea what I’d be doing:

I’ll be working on the software that powers some of the Motley Fool’s online offerings. I get to play with ASP.NET MVC, C#, and work with a whole bunch of smart and passionate software developers.

Three years laters, that list is a lot less…
vague.

One question recruiters asked me when I started looking for a new home was, “Why are you looking to leave the Fool?” To which I’d mentally link them to my blog post about ‘leaving’ a great job, but out loud would say the stuff that you don’t really understand until you have one of those midnight realizations:

Programming is about solving problems. It’s about sharing those solutions with other people, and making the lives of people you’ve never met better through that interaction.

That’s what’s important about programming. It’s not about environment, company culture, free food, or unlimited vacation. Those are important, but they’re not vital. It’s about making an impact, and seeing that impact.

The Fool was my first ‘non-product’ company. In every other professional setting as a Software Developer, I’d always been part of a product company — a company that sold the software I wrote. I had always underestimated the effect of being behind a product until I was in a services company like the Fool.

A major difference between a product company and a services company is that you directly impact the bottom line at a product company. With every feature (or every improvement), you can see a direct impact on sales. At a services company, it’s a little nebulous, and at a company that really is established in their practices, they can pull a lot of levers to generate sales that have nothing to do with programmers’ work.

Ultimately, any other issue aside, that’s what made me realize I needed to look for a change. I needed to be useful and necessary to the business.

I enjoyed my time at the Fool, and they deserve the “Best place to work” award from Glassdoor.

No matter what, I will always be a Fool.

(Author’s Note: I meant for this to go out a week ago, but I kept re-writing it.)

In the previous two posts, I’ve compared and contrasted Windows vs. Linux, .NET vs. Python; but I haven’t dived (dove? diven? English is so confusing(!))  into what development actually looks like on Linux. For you .NET devs, I’ll try to draw parallels as I go.

 

I use Ubuntu as my operating system, but after trying (unsuccessfully) to use rdesktop, I moved over to Xubuntu.  I chose Ubuntu because of its driver support and ease of set-up compared to other Linux distros I’ve tried in the past.  

Python development (specifically covering the Django framework) needs a few tools put together in order to work correctly:

virtualenv: a tool that creates a separate virtual environment for storing packages used in a Django project.  In .NET, you can place libraries (packages) in the GAC, or you can use NuGet to install them into the project and bin deploy them along with the project.  In Python, by installing a package into the virtualenv, you’ve essentially done the same thing a bin deploy would do in .NET.  If you don’t install packages into a virtualenv, then you’re essentially GACing the libraries.  This is a bad thing for the same reason it’s a bad thing in .NET: You can’t have two DLLs (packages) with the same Assembly name.

virtualenvwrapper: A tool that makes virtualenvs easier to set up and maintain. instead of this command to load a virtualenv:

source ~/.venv/myproject/bin/activate

it’s this:

workon myproject

Nginx: nginx is a very versatile web server.  It can be used to reverse proxy calls such that instead of the following:

http://0.0.0.0:8000/

you have:

http://myproject.myboxname.com/

IIS provides this capability as well.

uWSGI: A lightweight web server that requires zero set-up; it’s used as a development web server for Django projects.  Its .NET equivalent would be the Cassini web engine.

byobu: an enhancement for tmux that allows a user to have multiple terminal (command line) windows open at once, and even have splits in the same window. It doesn’t have any direct equivalents on the Windows side, except to say that Console2 tries to take care of the tabbing functionality.

apt-get: A system package manager for Ubuntu (and other debian based systems).  It allows you to install new software with one command.  I heard they’re bringing it to Windows, and all I can say is, what took them so long?

pip: A python package manager.  Nuget for Python.

PyCharm: A Python/Django IDE by JetBrains, the makers of ReSharper.  It literally feels like Visual Studio for Linux. Sadly, it runs on Java, but those are the breaks.

Vim: I can’t do Vim justice. It has a steep learning curve and I have yet to scratch the surface of what it can do for editing code.  I still haven’t decided on whether I’ll stick with Vim or move to Emacs.  Vim’s modal nature is my biggest complaint about it. 

I ended up moving to Vim from PyCharm after my Ubuntu system crapped out on me when I made the mistake of trying to uninstall a beta version of Crossover Linux.  After a fresh system install (luckly my Home directory was on a separate partition) I decided to forgo PyCharm and stick to Vim.

 

Problems with using Linux for Development

Installing updates is problematic, to say the least.  The Ubuntu software updater doesn’t separate out kernel updates from other updates, and if you’re not paying attention, you could inadvertently try to update the kernel while updating a package. Maybe it’s just my bad luck, but this has always resulted in issues for me that were not trivial to figure out (for a linux newbie such as myself).  

Window desktop manager crashing is far more common than it should be. Linux is really stable, Window Desktop managers are not. Here are a list of things that have crashed my window desktop manager, in no particular order: Starting Pidgen, opening an IM window, hitting ‘play’ on a piece of audio. Opening Chromium,  booting up, or installing updates. I’ve gone from the proprietary Nvidia drivers to the VESA drivers, to whatever I can try, and it still happens.  It doesn’t happen often, but when it happens it’s really annoying.

There is no good support for corporate (synonymous with Exchange and Outlook) email. After a lot of effort, Thunderbird can be used to read and write email, but if you’re using Outlook’s calendar, you’re pretty much stuck. If you use anything more advanced than Outlook’s Email and Calendar (like Tasks, To-Dos, or processing rules) you’re really stuck.  Your options become:

1. Try Crossover

2. Set up a terminal services login to a box that runs Outlook, and using rdesktop to connect to it.

3. Use Outlook Web Access, in all its (ahem) splendor.  The problem with this approach (besides the fact that it’s OWA) is that you can’t process existing rules in OWA. 

Crossover simply does not work for Outlook 365 (or any of the 365 services, come to think of it). A Terminal Services login is an ok alternative, but it has its own issues (copying/pasting, opening links, etc).

Corporate IM / VOIP service is almost non-existent.  We run a Cisco VOIP system, and they do not have a Linux client.  Even worse is that if you have the Mac version of their software, it can only talk to other Macs — it can’t do voice communication with Windows VOIP users. I wish I were kidding.

Overall, the switch from Windows / .NET Development to Linux / Python development has been a great learning experience, but looking back, I’ve spent too much time configuring and getting everything to work with everything else, and that should not be the way it is.  It’s 2013, we can’t do this better?

In the final part, I’ll detail what I consider to be the most optimal solution for a python developer to do both Windows and Linux development without Dual booting.

 

It was December 11th, 2012, and I was scared. Not because of the impending Mayan apocalypse, mind you, but because it was my first day doing something completely alien to me: developing software on a new platform, a new language, and having a completely new product to deliver.

That’s a lot of change to handle at once.

Looking back, .NET development would probably be just as scary to a seasoned Python developer as it is the other way around. At least I hope so, because Python development was initially very scary to me.

.NET development is based (almost) singularly around Microsoft’s tooling, and Microsoft has deep pockets, so they can spend money on marketing and great documentation. Where their documentation fails (and it does fail — who wants to study method signatures all the time?) the MVP community takes over and writes eloquent blog posts about some esoteric part of a new framework that behaves quite unexpectedly.

There are certainly not a lot of popular web frameworks in .NET. If you’re in the corporate world (hello, 80% of you), you’re likely either on Webforms or ASP.NET MVC. That’s a really small playground comparatively, making it much easier to ‘ramp up’ (especially if you include the sheer number of questions on Stack Overflow regarding those frameworks.

In Python, you’ve got a number of smaller frameworks, with Django as the BMOC. Django’s documentation is a complete 180 from MSDN, with an emphasis on prose over method signatures.

With .NET, the answer is normally a code sample away. With Django, it could be a code sample away, but normally it isn’t, it’s buried in some prose. An example that comes to mind is formsets, which were (unluckily for me) one of the first things I had to deal with in Django.

With Python development, you necessarily have access to the source code. For instance, you can read through the source code for Django on github, or if you have a neat editor like PyCharm, you can simply click to view it (much in the same way ‘Go to definition’ works in Visual Studio).

For Windows based development, the toolchain normally looks like the following:

• Visual Studio 2010/2012
• TortoiseHG (or Git for Windows)
• ReSharper (a must have. Really.)
• KDiff3
• IIS
• SQL Server Management Studio (regardless of DB location)
• Terminal Services (Remote Desktop)
• A really beefy machine. Really Beefy:
  • 8-core Intel i7 @ 2.93 Ghz
  • SSD (in my case, a 120 GB)
  • 8 GB Ram
  • Nvidia 9600 (For dual monitors)

For Linux based development, (at least in Python):

Pycharm or Vim (Or Emacs, but do we really need to have that fight here?)

TortoiseHG (still a plus — though I can’t get it to run on my current system)

KDiff3

Nginx (used as a proxy)

uWSGI (web server)

No DB installation required (normally Sqlite), or PostgreSql or MySQL (All three are used in my project)

Same beefy machine still works, but entirely possible to do all work on a remote linux server with very little fuss

Almost the first thing I noticed when starting out with Python development is just how easy it is to debug. In .NET, the workflow is:

• write code
• run unit tests (you do have those, right? RIGHT?)
• compile
• wait for application to JIT on IIS (or reset IIS and then wait for application to JIT if you’re using Spring.NET or some other DI/IoC that hangs out in resident memory)
• find error
• start all over again

Even on the beefiest of machines, that entire loop is still at least two minutes (I’ve seen it take as long as 5 minutes on larger solutions). That’s a long time to be staring at a screen.

In Python (specifically developing in Django), here’s the workflow:

• write code
• save code
• refresh website
• find error.

Time? About 10 seconds. Maybe. That’s an incredibly fast turn-around time, and makes unit testing less attractive (that’s not the only thing, which I’ll get to later).

What makes the workflow in Python so spectacularly different? It’s the nature of the beast. While Python isn’t strictly interpreted , it still doesn’t have the overhead compiling a .NET assembly has.

Another difference in Python development is just how easy it is to write scratch code (I’m thinking specifically of Django’s “shell_plus” module, but the same holds true with iPython):

It’s literally one command:

python manage.py shell_plus

And that command drops you into a REPL that has all the items in your Django project imported. Need to load a model? It’s already there. This somewhat reduces the need to use unit-tests as scratch code. You can test behavior in the shell, and then add it to your program.

Database development in Django is completely different than in any .NET project I’ve ever worked on. Django has its own built-in ORM, and the mere act of creating a model creates a Database table. With the South migration library, you can even version control your database and it’s all in one place. It’s simple to set up, and compared to the .NET model of database development, it’s painless. But it’s not without its own problems:

– The default is to have your Model objects be Django DB Model objects, and that means they’re bloated, ugly, and carrying around persistence information. This complicates unit testing (and unit testing is no longer unit testing when you bring in a database). If you want to get around that, maybe with a Functional Core, Imperative Shell model, you have to do *a lot* of work. I’m currently trying this approach on a personal project, and it *sucks*.

– Unit testing a Django application is not unit testing. By default, it pulls in your entire database. That’s integration testing. SSDs are required if you want your ‘unit tests’ to be fast, because Django is happily spinning up a database for your tests.

In .NET, database development reminds me of building a house from scratch *every*, *single* time. There have been improvements with the Code First Entity Framework stuff, but nothing as turnkey as Django’s ORM.

Deployment wise, .NET deployed applications don’t need as much scaling out of the box for large sites as Python/Django projects do. The deployment tooling for python projects isn’t as great as some of the solutions for .NET (I’m thinking of Jenkins vs. Octopus for .NET). I’ll get into deployment tooling for Python in a later post, but essentially it’s built for developers to deploy, not for *anyone* to deploy.

Overall, I’d have to say that .NET and Python development have different strengths. Neither side has a clear advantage over the other, at least for *large* projects.

In Part III, I’ll talk about my Development set-up, and why I’m moving to Mac OS X for Python development.