Mastodon

Dark Mode

mastodon (this link opens in a new window) by mastodon (this link opens in a new window)

Your self-hosted, globally interconnected microblogging community

So I’m just now realizing that Mastodon is a Rails 6.1 application. I just looked over the Gemfile, and it includes a lot of the usual gems, notably cocoon, right at the end. I have a love/hate relationship with this particular gem.

I love how it solves the problem it addresses. It’s an ingenious solution, and a clever implementation. Also, its author is also very supportive, and has done a lot of work to document it well and answer questions, on GitHub and StackOverflow. I dislike the fact that the form markup sort-of-has-to-be so fiddly for non-trivial cases, but I accept that tradeoff for preventing round trips to the server for interactions with subforms.

What I hate is that Rails has never introduced a feature to do what this gem does. I get it, but I hate it. Really, I guess the only way to prevent a round trip is to make this sort of self-HTML-form-markup-generating code in Javascript, and Rails isn’t about Javascript. In that respect, I actually appreciate that the team has NOT tried to include this approach out of the box. I just wish there were a way to have my cake and eat it too.

Hopefully, my next app will be Rails 7, and free of jQuery, not just by default, but also on principle. Unfortunately, this means I won’t be able to use cocoon, but maybe someone will remove the jQuery requirement by then. Maybe I should do it.

Also, maybe this is finally the impetus that will get me to try Mastodon.

From Node to Ruby on Rails | D U N K

Building the web app in Rails took me 2 days – the same thing in Node would have taken 2 weeks. I’ve also included things I wouldn’t have attempted to build on Node/Express until I proved the idea out (editing a profile? Psht please – I’ll wait till someone requests that). People in the HN comments always accuse the Node ecosystem of making you re-invent the wheel for every project. But I thought that was just the way things were. Now I realize the truth to their words.

Source: From Node to Ruby on Rails | D U N K

I’ve been saying this for years, but DHH endorsed this writeup.

Ruby on rails : problem of verifiying the SSL certificate while installing bundle

I’m new with ruby on rails and while creating my first project with this command rails new n_project, i got this error

run bundle installFetching source index from https://rubygems.org/ Retrying fetcher due to error (2/4): Bundler::Fetcher::CertificateFailureError Could not verify the SSL certificate for https://rubygems.org/.
There is a chance you are experiencing a man-in-the-middle attack, but most likely your system doesn't have the CA certificates needed for verification. For information about OpenSSL certificates, see .... To connect without using SSL, edit your Gemfile sources and change 'https' to 'http'.
Retrying fetcher due to error (3/4): Bundler::Fetcher::CertificateFailureError Could not verify the SSL certificate for https://rubygems.org/.
There is a chance you are experiencing a man-in-the-middle attack, but most likely your system doesn't have the CA certificates needed for verification. For information about OpenSSL certificates, see .... To connect without using SSL, edit your Gemfile sources and change 'https' to 'http'.
Retrying fetcher due to error (4/4): Bundler::Fetcher::CertificateFailureError Could not verify the SSL certificate for https://rubygems.org/.
There is a chance you are experiencing a man-in-the-middle attack, but most likely your system doesn't have the CA certificates needed for verification. For information about OpenSSL certificates, see .... To connect without using SSL, edit your Gemfile sources and change 'https' to 'http'.Could not verify the SSL certificate for https://rubygems.org/.
There is a chance you are experiencing a man-in-the-middle attack, but most
likely your system doesn't have the CA certificates needed for verification. For
information about OpenSSL certificates, see ...

Source: Ruby on rails : problem of verifiying the SSL certificate while installing bundle

I develop software using a pretty varied mix of technologies, including C#, VB, Postgres, SQL Server, and Azure services of all kinds, but mostly Ruby on Rails. After 15 years of using it, I find that it remains one of the most force-multiplying tech stacks in the world. With it, by myself, I can develop software faster than entire teams of outsourced, waterfall-managed, Java/React projects. (And I proven that multiple times.) Not only that, but the future is looking even brighter with Rails 7.

Anyway, I develop software on my personal MacBook Pro, upload it to a git host, and deploy it to a Linux VM on Azure. But my work-supplied laptop is, of course, a bog-standard, boring Dell running Windows. I feel an obligation to be able to use it to do everything I would normally do on my Mac, just in case the hammer falls, and they outlaw the way I work. So, on Windows, I use RubyInstaller. But, thanks to my company’s bog-standard industry practices of using Cisco products to lock down the laptop within an inch of usability, I’ve been unable to do a bundle update for awhile now, getting the error listed above.

I had previously worked around this situation by using CNTLM to tunnel command-line-based HTTP/S requests through my company’s firewall. This was no longer working.

I tried changing my Gemfile to use HTTP, instead of HTTPS. I tried getting gem to ignore SSL errors (and use HTTP sources). None of this worked either.

Yesterday, I had finally had enough of the problem, and decided to work through it. Helpfully, the error message included the fact that I was missing the Cisco Umbrella CA certificate in the certificate chain. Also helpfully, Cisco has a page where you can download their certificates, ciscoumbrellaroot.pem and crca2048.pem. Also helpfully, I found the linked StackOverflow Q/A. That got me started, and I finally figured out the RubyInstaller people have anticipated this problem. There’s a proper way of adding a certificate to your chain. Just drop the certs in C:\Ruby-xx-x64\ssl\certs. This allowed me to get rid of all the hacky workarounds, and now bundler works like I expect it to work on my work laptop.

Kinda a big announcement – Joel on Software

I took a few stupid years trying to be the CEO of a growing company during which I didn’t have time to code, and when I came back to web programming, after a break of about 10 years, I found Node, React, and other goodies, which are, don’t get me wrong, amazing? Really really great? But I also found that it took approximately the same amount of work to make a CRUD web app as it always has, and that there were some things (like handing a file upload, or centering) that were, shockingly, still just as randomly difficult as they were in VBScript twenty years ago.

Source: Kinda a big announcement – Joel on Software

It’s hard for me to express just how deeply wrong I find this to be, but I suppose that’s because I take it as an almost personal insult. Here’s a smart, driven guy who probably just became a (near) billionaire with the sale of a site devoted to programming Q&A, and yet, in my opinion, he’s completely out of touch with modern web development. I really resent this gaping hole in the collective knowledge of programmers on this planet.

I’ve been using Rails for 15 years now. I’ve used it to make dozens of applications. It is perfectly suited for making CRUD web apps. It was designed from the ground up to do so, and avoid the grunt work of other programming stacks, specifically Java. Unfortunately, Spolsky is not alone of his ignorance about it. I see lots of programmers singing the praises of Javascript, who dismiss Rails, usually because of its convention-over-configuration approach, but nothing can compare to the productivity of using Rails to write a CRUD web application. Nothing. It’s not even close. He’s absolutely right that Node and React offer no advantage over any other legacy option like Java or .NET. I went down the whole Java/Spring/Angular hole for one ill-fated project, and it’s a freakish, byzantine nightmare. The difference between the two stacks is so stark that I have to assume that people who make these kind of comments are completely oblivious to the fact that Rails exists at all.

Take file uploads for instance. Rails has had easily-configured and power capability from several hugely popular gems since (at least) the 3.x days. The stack has had its own implementation since 5.x. Either way, just configure a couple of lines in an initializer, pick a provider, enter your bucket name and API key, and then it’s literally just a few lines of code to add a file attachment to your model.

Spolsky continues to rant:

The biggest problem is that developers of programming tools love to add things and hate to take things away. So things get harder and harder and more and more complex because there are more and more ways to do the same thing, each has pros and cons, and you are likely to spend as much time just figuring out which “rich text editor” to use as you are to implement it.

This is the continuing, enduring beauty of Rails. They continue to add things to the stack, like file uploads, but they do so in a way that makes them optional. If you want them, it’s, like, 3 lines of configuration, and you’re rolling. A rich text editor, as it turns out, is another perfect example. There has been a popular gem to provide the WordPress editor for a long time now, but Rails started shipping a native rich text editor in 6.x, if you want it. I’m using it in a significant way in a production application right now. I added it well after the site was launched, but it was easy, and it’s terrific.

Today we’re pleased to announce that Stack Overflow is joining Prosus. Prosus is an investment and holding company, which means that the most important part of this announcement is that Stack Overflow will continue to operate independently, with the exact same team in place that has been operating it, according to the exact same plan and the exact same business practices. Don’t expect to see major changes or awkward “synergies”. The business of Stack Overflow will continue to focus on Reach and Relevance, and Stack Overflow for Teams. The entire company is staying in place: we just have different owners now.

This is where I get worried. An investment and holding company paying $1.8B to buy a site like Stack Overflow is going to want to recoup its investment, and make more money in the future. In the old days, they used to say that investments needed to start making money in 7 years. I’m not clear that this old rule of thumb still applies, and SO is a private company, so we can’t see a balance sheet, but does anyone think that “SO for Teams” is making $250M a year? Big M&A announcements like this always say the same things about keeping the product the same. Let’s revisit this in a year, and see where we really stand.

Nine things we learned from the Epic v. Apple trial – The Verge

It’s particularly notable since some people are worried that macOS is inching toward the iOS model, making it a little more difficult to install unauthorized software with each new version. If you were already anxious about the Mac ecosystem closing off entirely, Federighi’s testimony gave you plenty more to worry about.

Source: Nine things we learned from the Epic v. Apple trial – The Verge

Indeed. Federighi says he’s worried about malware on macOS. I think that’s scaremongering. (Now watch me get a virus.) But, for all-around safety, I’ve come to the tenuous conclusion that requiring everything to be signed is acceptable. However, if Apple finally closes the last door, and begins to require that everything you install on a Mac to come through the App Store, we’re going to have a problem. As a Rails developer, I’m very worried about the trend of making macOS more and more like iOS, but I don’t seriously think they can ever do this, completely, and I’ll step through why.

A large part of the reason that Apple sells Macs is for development. Obviously, developers must make up a very small percentage of Mac users, being dwarfed by media creators, but the inescapable reality is that Apple themselves require a Mac to write software for their most-profitable products: the iPhone and iPad. So, even by Apple’s own rules, a generally-open development environment needs to exist to continue to support their mobile ecosystem.

Very closely related to this is that a lot of developers (like me) prefer the platform for developing web apps, which, again, is a type of development that helps Apple’s efforts. I mean, they don’t want people going off and creating Windows-native applications, right? So keeping the operating system of Macs in such a state as to make it productive for web development is — at least tangentially — also in their own best interests. However, this sort of focus almost requires the use of either Homebrew or MacPorts, which I have a hard time believing could be delivered through the App Store.

So, following the logic, and while I understand that it might be really attractive to Apple leadership to lock down macOS as tightly as iOS, I don’t see a path for getting there. At least, not in a way that won’t alienate the entire demographic of developers. Obviously, if they get really serious about it, they could lock the system down for iOS app development, but I think this would leave web development blowing in the breeze. If that were to happen, my only consolation is that Linux is just as nice for doing Rails development as macOS. It’s not as great for just about everything else, but it is a first-class platform to develop web applications on. So, moving back to Linux on the desktop is a viable fallback position for me, and the really great thing about that is that no one can take that away from me.

TECH | Stop using JPA/Hibernate · Blog de Laurent Stemmer

Here an example of a JPA entity (using Lombok for “simplicity”): <sarcasm quotes mine>

@Entity
@Table("offer")
@EqualsAndHashcode
@NoArgsConstructor // for Hibernate
@Setter // for Hibernate
@Getter
public class BankAccount {
    @Id
    @Column("id")
    private String id;
    @Column("opened")
    private boolean opened;
    @OneToMany(fetch = LAZY) // ...simplified
    private Set ownerIds;
}

Source: TECH | Stop using JPA/Hibernate · Blog de Laurent Stemmer

Through a very long series of unfortunate circumstances, I was backed into using Java/Spring/Hibernate/Angular in a doomed project. This page had me nodding my head in agreement, and this code reminded me of the Lombock portion, which was its own special nightmare. I just went looking for what I had written for that project, and it would appear that I’ve totally deleted it. I normally keep everything, so I can go back and refresh my mind when I recall some particular technique I’ve used in the past, so this should tell you something about the brain damage using this stack will incur.

I’m going to digress to setup a point. I used gvim for many years, with a complicated setup, using NerdTree and several other plugins, to give me a UI with my project’s directory on the left side, and tabs of open files on the right. At some point, I got tired of fiddling with the configuration, and finally started using someone’s massive-but-well-integrated ~/.vim configuration from a GitHub repo. Finally, I realized that I was spending all this time and effort on making gvim work just like Sublime Text did out of the box, and I could just start with that. So I did. While I’ve flirted with other editors (notably, Visual Studio Code, and the excellent IntelliJ, while working on Java), I’ve basically stuck with it for about 7 years now.

Here’s the parallel. The thing that fans of the Java ecosystem can’t admit to themselves is that this whole stack: Java, Spring, Hibernate, Lombock, Javascript, AngularJS, etc., et. al., ad naseum… is all just a terrible pile of Jenga blocks which putatively exist to give you a functional environment like… wait for it… Ruby on Rails! Lock, stock, and out of the box. It seems to me that the motivation of people who still like to use gvim when Sublime Text and Visual Studio Code exist is the same sort of motivation of people who like to use a Java stack over something like Rails. Maybe they’ve done it so long, they can bang out the boilerplate with their eyes closed. Maybe they like the way you have to do everything explicitly. Maybe it makes them feel like a hacker.

All of the code above reduces to this in Rails:

class BankAccount < ApplicationRecord
    self.table_name = 'offer'
    belongs_to :owner
end

In an absolutely brilliant display of one of the biggest problems with using this Java stack, I went to remind myself what the @Table("offer") directive does. I am pretty sure it specifies the actual SQL database table name storing the instances of this object, but I literally can’t find any references to this pattern in the Lombok documentation. It is only through inferring it from a StackOverflow question that I am reasonably confident that this is, in fact, what it is doing. And if it weren’t for Spring and Hibernate and Lombok, there’d be about a hundred more lines of boilerplate code in that single class file.

The top comment thread on the HN discussion about this blog post points out just how bad of an ORM Hibernate actually is. With 15 years of experience with Rails under my belt, I can assure you that almost none of those issues apply to ActiveRecord. Of course, I’ve seen people complain about AR, but I think their arguments are always exaggerated, and probably come from a place of general discontent with having to use Rails at all. People like to complain that Ruby is “slow” because it is interpreted, but it’s precisely that on-the-fly reflection/interpretation that allows ActiveRecord to be so good at being an easily-programmed and powerful ORM. It’s trading machine time for ease of development and readability, and I have yet to see a situation where that was a bad tradeoff. When I encounter speed problems with using Ruby, I do something else. Either I optimize the loops, or push more processing to the database, or write the heavy-duty computation in something else entirely, like R.

While I’m on the subject of ORM’s, I find EntityFramework just as bad as Hibernate. I suppose it’s just the nature of an ORM in the context of a compiled language. After giving it a real college try, I gave up on it. I wrote a serious application in Visual Basic and C# which accessed the database through a library of functions wrapping raw SQL, and called them from the WinForms side, and it worked out very well. I’m glad I didn’t try to force EF to work.

So, sure, rag on Rails. Call it slow. And, yes, compiled Java will always be “faster” than interpreted Ruby, but all the Java web sites I have to interact with are noticeably laggy and sluggish, compared to my apps, so there’s something to be said about the actual implementation, over the theoretical concept. While whole teams of “Java” devs are still writing class files in Java (and Javascript), for their object models, I’m done with my app, and moving on to the next one.

So, yes, by all means, please stop using JPA/Hibernate, but, I would go one step further, and advise people to just stop using Java for web apps entirely. That horse got passed 15 years ago. Even if you don’t like Rails, there are at least a few other stacks that would be far more productive than Java for web apps these days. Heck, I’d try to do Javascript on the frontend and backend before I’d try doing Java again. <shiver>

And that’s my “2 minutes of hate” for today.

What I wish I had known about single page applications – Stack Overflow Blog

I settled on JHipster, a development platform for building web applications using modern technology: Angular, React or Vue for the client side, and Spring plus Gradle or Maven for the server side. It’s been around for years, is very well documented, and has great community support.

Source: What I wish I had known about single page applications – Stack Overflow Blog

I think the author hit at least one nail squarely on the head: Team size is an important consideration for the tech stack. I would argue that a Java/Angular stack is probably only appropriate for large teams, which wouldn’t need jHipster anyway. I tried it once, and it took FORTY-FIVE minutes to bootstrap a site on my top-of-the-line Dell laptop. There are an astonishing number of moving parts buried inside of it.

I’ve been using Rails for 15 years or so now, and one can argue about its strengths and weaknesses compared to other webdev toolkits, but it works really, really well for one-person “teams” writing highly-focused internal tools. I’ve spent the past month writing a single-page app in VueJS inside of my current tool, and it’s been an interesting experiment. I may have more to say about it later.

DHH “not yet feeling the awesome” of WSL

This has been one of my all-time favorite Twitter threads. David Heinemeier Hansson, creator of Rails, is trying to “live” in Windows, and set it up to do Rails work. He’s blogging the “experience,” and it’s not going very smoothly. Everyone is telling him to use Windows Services for Linux for this, but he’s “not yet feeling the awesome.” I’ve tried using WSL several times for doing development on Rails applications. I, too, am not feeling the awesome, despite the cheerleading by Windows thought leader Scott Hanselman. Despite my personal experiences with it, given how vociferously people recommend WSL for Rails work on Windows, I kept wondering if I were missing something. I’ll take this as final confirmation that I’m not missing anything, and delete the mental bookmark to go back and try this again when it becomes WSL 3.

IMHO: The Mythical Fullstack Engineer – Stack Overflow Blog

It’s my experience that the above MVFE is pretty uncommon. The profile describes a person with skills requiring thousands of hours to master, but who doesn’t take part in the holistic decision making process. By nature, the value of a fullstack engineer stems from their ability to make competent unilateral decisions (decisions without asking anyone for permission). I’m sure there are people who mostly fit the MVFE, but I wager that they are few and far between. You could probably summarize my view about the MVFE as:

It’s very impractical to become a fullstack engineer without understanding the big picture.

In my mind, a fullstack engineer’s value is mostly derived from their ability to single-handedly design, architect, execute, and operate an entire end-to-end system. Assuming this is possible, it almost completely eliminates integration overhead.

Source: IMHO: The Mythical Fullstack Engineer – Stack Overflow Blog

There’s a lot of subjectivity in this article, but I think it covers the topic pretty well. I consider myself a full-stack engineer, and that self-identification hinges on both emphasized points above. First, I’ve spent the time to learn all the pieces. Other people don’t see all the late nights, banging away on my home lab, or my church’s setup, forcing things to work when they didn’t want to, integrating pieces all over the stack, setting up solutions to help people get things done, or just to scratch an inquisitive itch.

For instance, I’ve run my own web server on a public address. This will cause you realize how hairy the raw, unfiltered internet is, and will force you to learn about the basics of hardening a server and firewalling a network connection in a New York minute. I’ve run my own email server. That will teach you about spam, attachments, white and blacklists, abuse addresses, and lots of stuff about making your server look legit to other servers. I’ve run a Windows domain for my whole family’s computers, with roaming profiles and everything. (Side note: do NOT use roaming profiles.) I’ve run my own personal cloud. My own mobile sync server. Media servers. TV recorders. The list goes on.

In my professional career, I’ve gotten to work on some of the biggest, baddest tech ever made. I’ve setup a Sun E10000 from scratch. When I took the official Sun training on the kit, I fixed the lab’s setup when it broke. I’ve configured a 384-tape robotic backup system. I’ve commissioned $15M of EMC disk cabinetry. I’ve trained extensively on Oracle, and setup a North-American-spanning network of 20 instances. These technological implementations are fading, now, but the concepts haven’t. We just answer the same questions with different hardware and software these days.

When I encounter a new technology, at this point, it usually doesn’t take long to slot it into the larger context of computing services. For instance, I recently tried to use Elasticsearch for a project at work. While I eventually found an easier way to do what I needed to do, through several weeks of experimentation, I now know what that technology is about, what problems it solves, how it works, and what it takes to implement it. Now I have this tool in my toolbox, and it’s very possible that I will yet use it for a different project. I’m incredibly grateful that I have a job where I can occasionally do a little “R&D” like this, to learn something new, but it takes substantially less time to divert my attention like this, than other people might spend, because of the experience I already have.

Second, I understand the field I write software to support, because I studied it. I think the modern incarnation of the programmer, toiling away in the bowels of a big company — which is most developers, by simple numbers — is the total inverse of this ideal. I have a degree in mechanical engineering. I’m a good engineer, for the same reason I consider myself a “full-stack” guy. I see the big picture, and how everything underneath it contributes to making it look the way it does.

Even more than studying the math and physics, I was drawn to engineering, because that’s how my mind works. When I look at an engine, I notice the systems that are interoperating: the mechanical masses, the fluid flows, the thermals, the electrical connections, the air flow. I feel these things in my gut and see them in my mind’s eye. I understand how all of these subsystems work to produce power and torque, the difference between those two things, and when it’s appropriate to focus on one over the other. To me, it’s the same thing with an IT solution. I can picture the large subsystems working together to make up the final system in my head, and see the servers, the services, the networks, the databases, the networking, and the automation that will be needed to implement it.

In a lot of ways, the training in how to think about a problem in engineering school is perfectly suited to creating full-stack solutions. Start with restating the problem. Get to the heart of the business problem you’re trying to solve. Where’s the friction? State the givens. What do we know already? What pieces of data do we have? How do we get that into the system? Finally, specify what you’re solving for. What are we missing? How are we going to transform what we have into what we want? How will the people who will use the system need the program to work, and the data to be shown?

Most people working in software in my industry have been trained in how to write some code, and that’s about the end of it. They might understand how to write a loop in Java, but they don’t understand how to setup a Java application server, or a load balancer, or a firewall, to say nothing about the database. They also don’t understand how our products work, how they’re designed, or what the engineers working on them need to help them in that endeavor. I find myself in the rather rare position of understanding both halves of this equation. In my 25-year career, I’ve met only a handful of people who can straddle the fence between the physical, engineering problem domain, and the IT implementation like this. In the manufacturing world, we are indeed few and far between.

There’s one other thing I want to talk about, and that this article’s presumption that Javascript is the piece for the front-end, in the jigsaw puzzle that is a full-stack web application these days. I still like Rails’ templates, and, of course, Microsoft is pushing Razor. Javascript enhances both of these things. However, the article hints at how a lot of people are doing the entire front-end in Javascript now, and I find that disappointing. In an aborted effort, I tried writing an application in Java with an Angular2 front end. The amount of duplication astounded me. When you combine this duplication with the fact that Java and typed Javascript are two of the most verbose languages to work with, well, you get a mess.

Using an API back-end and a pure Javascript front-end is, perhaps, the single greatest argument against full-stack development you can make. Given the sheer amount of work involved in separating the front-end, completely, from the back-end, it almost requires two different people or teams. If you sat down, and wrote out the most terrible theoretical idea you could come up with for software development, it would probably look like “write a single application, broken right down the middle, in 2 different languages.” Unfortunately, that’s the nature of web development right now. I lament that this is where we’re at in our technological evolution, but until network bandwidth takes another leap forward, this is what we’re stuck with.

Ruby on Rails on Windows is not just possible, it’s fabulous using WSL2 and VS Code – Scott Hanselman

I’ve been trying on and off to enjoy Ruby on Rails development on Windows for many years. I was doing Ruby on Windows as long as 13 years ago. There’s been many valiant efforts to make Rails on Windows a good experience. However, given that Windows 10 can run Linux with WSL (Windows Subsystem for Linux) and now Windows runs Linux at near-native speeds with an actual shipping Linux Kernel using WSL2, Ruby on Rails folks using Windows should do their work in WSL2.

Source: Ruby on Rails on Windows is not just possible, it’s fabulous using WSL2 and VS Code – Scott Hanselman

I’ve been doing Rails for about 13 years as well, and I’ve been following Scott for probably about that long. Heck, being a tech evangelist for Microsoft, it was probably him that alerted me to the fact that WSL was being put into Windows to begin with. And using it for Ruby on Rails development is precisely why I wanted it. So when it was first released in Windows 10 Insiders Edition, I hastily upgraded my gaming rig to try it out.

There were literal, show-stopping bugs that prevented doing the “normal”  kind of Rails development, where you install a Ruby version manager, then install the bundle gem, then install Rails, then bootstrap your site.

I keep wanting to say “emerge” when I mean “install.” I guess using Gentoo broke my brain, but, really, that’s what’s going on. When you’re doing this sort of thing, you’re installing software that’s dependent on your environment, which is exactly why portage was created.

I filed some bugs, and watched and waited. A couple of them were fixed pretty quickly. But then other problems became apparent, and they weren’t going to be fixed any time soon, so I gave up.

Then they announced the release of a big upgrade to the system. So I tried again. And, again, I found problems that prevented me from being able to develop with Rails. So I gave up, and stopped watching this space.

Now Microsoft has been evangelizing a total rewrite of WSL, and how they’ve made it “native,” and how this fixes compatibility problems and speed issues. But all they’ve done is make the tool a total virtualization of the environment, when the whole point of WSL was that it was not a virtualized environment!

WSL was supposed to bring “open source” development (like Rails, and Node) out of the dark ages on Windows, and make it a first-class workflow on the platform. This was easy to believe, because Microsoft was really lagging in these popular development scenarios, and it could be expected that they were motivated to create a bridge to get back on equal footing with Mac as the platform of choice for working with modern web technologies.

However, the situation on Windows is now worse than ever. It used to be such a hassle to do this kind of work on Windows that you’d install VirtualBox, create a VM, map your VM’s drive onto a Windows mount point, and run your development tools on the files in the mounted drive. Now, WSL2 is basically doing that for you, and not even giving you the courtesy of a GUI to manage the virtualization settings. I guess the positive way of looking it is that they’ve created a VirtualBox-type Linux VM with all the file-system mapping pre-configured.

It’s telling that the workflow that Scott is proposing is to use Visual Studio Code with a plugin for remote development.

Whatever. It’s a hard pass for me, dawg. If I needed this, I’d just install VirtualBox, and be explicit about what I’m doing.

As a side note, I’ve been using RubyInstaller for years now, on my work laptop, and it “just works.” I mean, sure, you’re limited to a specific version of Ruby, but I just make that my base, and “emerge” that one on my Mac and the Linux host server, and everything lines up. So my need for any sort of virtualized Linux environment on Windows has already been satisfied.