Over the last month or so since switching to Windows I’ve been slowly piecing together my development environment and I have lots to share on what is and isn’t working. This post will be about Programming Languages I’ve played with and I’ll save Code Editors and Shells for another post. There are some exciting twists and turns!
Does this make me a Polyglot?
I didn’t realize this, but I’ve collected quite a few languages and databases I depend on over the years. Here’s just a short list of the things I’ve built and played with on Windows in the last month:
- Environments: Ruby, Python, Node, PHP, Libsass
- Databases: MySQL, SQLite, Postgres
- Servers: WEBrick, Puma, Apache, BrowserSync
- Frameworks: Ionic, Rails, Universal Windows 10 JavaScript Apps
It’s been a positive experience that a lot of these things installed quite easily. I said in my last post that following a tutorial, I was able to install Jekyll (and most of the software listed above) in under 30 minutes. My previous record on Mac was ~2 hours, add 20hrs if you need to install XCode. Most of the things above I installed using binaries or Chocolatey (Windows’ version of Homebrew).
Node is pretty impressive on Windows. You get the feeling that JavaScript (as well as HTML and CSS) are a first class citizen in the Operating System. I already have a list of dozens of Native Windows Apps I want to build using Node.
I hit Node/NPM’s MAX_PATH bug, that was interesting. I tried using a Gulp project from a shared Dropbox folder (node_modules/ in a Dropbox is a terrible idea, btw). The way NPM installs dependencies in deeply nested file paths voilates Windows’ 256 character filename limitation, i.e.
node_modules/module/node_modules/submodule/node_modules/subsubmodule/etc
While Windows should fix that, all it took was deleting my node_modules/ folder and reinstalling to fix. NPM v3 is on the horizon and reportedly makes NPM on Windows even more wonderful.
By far, the biggest issue I’ve had migrating to Windows has been Ruby on Rails…
Ruby on Fails
Over the past month I still haven’t been able to get my Ruby on Rails environment setup. If I were to call the boxing match today, I’d have to say: Ruby on Rails doesn’t work on Windows.
I know that people have got Rails running on Windows before, but general state of the framework is “broke”. For example, Rails’ XML parser dependency Nokogiri has been blocked on Windows with Ruby 2.2.2 since March 2015. A fix should be landing this week, but if not for one person (my new opensource hero), Lars Kanis, it may have never been fixed.
I was able to manually patch the gem, I did a bundle install and rails console only to discover another gem was broken. Dismayed, I told Rey Bango about the issue and he set me up with a one-on-one with Scott Hanselman!
Sitting down with Scott was great. He showed me cool things about the Windows CMD prompt, we talked podcasting, and he sat with me for over an hour trying to help get Rails working on my system. We sat there together googling binging error messages: fix one gem, another breaks. And repeat. I wish we could have high-fived at the end when we got Rails working, but I had to go and we never got the chance.
Any heavy microservice/submodule architecture is going to have dependency issues, but with Rails on Windows you see the whole House of Cards fall down all at once.
So why does Rails not work on Windows? Where does the blame fall? It’s tough to say.
In my personal experience, the team at Microsoft has been eager to help. Does that mean the finger points at the Rails core team? I don’t think so, not exactly. I think it’s probably a symptom of a lack of “device diversity” among the Ruby/Rails core team. They all probably use Macs and an issue on Windows means booting up a VM, which means those issues automatically fall to the bottom of the priority stack rank.
I’ve seen that in my own life with Open Source projects. Out of sight, out of mind.
x32_x64_x86_literally_dont_care
Another developer hurdle I feel that the Windows ecosystem needs to solve is choosing your architecture every time you install something. I realize there’s a huge difference between 32-Bit architecture and 64-Bit architecture, and I realize some people would like to choose, but most people simply don’t give a damn.
Choosing between Past/Present/Future Versions × Windows NT/XP/7/8/8.1/10 × My CPU means every time I find software I sit down to read a wine menu of software options (Note to self: “Software Sommelier as a Service”). In User Experience circles, we refer to this as Analysis Paralysis.
What’s even more confusing is even with an x64 processor, sometimes the 32-Bit option is the best choice! What a world we live in! This is probably a culture problem that’s hard to solve, but as a new user to Windows I shouldn’t have to inherit all this legacy baggage. In a world of one-click install App Stores, it feels like combing through dinosaur bones to build tools. It’s most certainly a problem Mac users don’t experience.
Biggest takeaway
Regrettably, #davegoeswindows has had significant cost on Paravel’s side project DayTrip due to Ruby on Rails issues. I’ve only made two (2) hotfix commits to the project (both from my Mac). Momentum is key to any product or startup and while I don’t think we’ve sacrificed yet, I sometimes wonder if I should have abandoned the experiment to maintain momentum. I will most certainly have to jump back to Mac to clear out some TODOs. Maybe Rails will right itself this week when Nokogiri ships. I don’t know.
My problem is I’m genuinely enjoying all the other things about Windows, so much so, I refer to the other computer as “Cartoon OS”. Windows feels modern to me.
I think my greatest takeaway from this last month has been; While the Web is Universal, our tools are not.
I can write HTML/CSS/JavaScript on any computer in the world and any computer in the world can read it. That’s magical and the core of Sir Tim Berners-Lee’s vision. Take that one level of abstraction up and suddenly the tools we use to build our HTML/CSS/JavaScript lose that universality.
I think that’s a shame. But I’m glad that Microsoft took interest in and inserted themselves into the Node project to get it working on Windows. Open Source and Open Technologies working across platforms seems like a great pathway to building the future of the Web.