bphogan

Mainstream developers who attend schools that produce Java developers believe that this is a recipe book. I have seen this book used at conference talks for nearly 20 years. Countless blog posts aimed at beginners reference this book as the way to solve problems.

The book itself is pretty explicit that they are not recipes, but that doesn't mean it isn't used that way.

Don't blame the book - blame the curriculum that's based on it.

Windows 10's WSL (Windows Subsystem for Linux) is pretty amazing though. If you're only doing command line stuff, you might be able to get almost everything you want done with that instead. I managed to configure mine to run my tmux and vim configurations, get Ruby running, and install the Ubuntu version of Vagrant to provision some DigitalOcean machines. It all worked relatively easy.

The only stumbling block I ran into is that the Bash shortcut doesn't drop you to a login shell, so my .profile wasn't executing. From Powershell, start bash with --login or append --login to the Bash shortcut, and everything works pretty darn well.

But if you're gonna go the VM route still, just make sure you have tons of RAM. My 4gb Surface doesn't do a horrible job, but after the summer Windows update, I feel the pinch more than I used to.

Hope that helps!

I live in both camps. This is the same attitude I took issue with in the original article. It's condescending. "I have to keep telling you to not do something because we didn't plan for it."

I'm not saying it's an easy problem. But I am saying that blaming users for something doesn't give me confidence.

> I have to provide this guidance at least 2-3 times a day so instead I am publishing it here so everyone can find / link-to this guidance.

This may be oversimplifying, but if that's the case, then there's a design problem. Either you should make it work, or you should do some better defense against it up front.

If the solution is "eh, just work out of a Windows folder", this isn't really better than using a VM. Heck, I've been using WSL since the beta, and using Vagrant + Putty gives me better results.

I was hopeful it would get better, but then I saw this post and shook my head. "Silly users, stop trying to do things we didn't plan for you to do!"

I have fought through issues of setting up a development environment for modern web development for the last ten years in boot camps and classrooms. When everyone brings their own device, you run into tons of issues you can't control. Students get confused by differences in terminals, text editors, and many other factors. The instructor's environment must match what the students have. And these allow for that.

And if you think "well, if they can't bother to set up their own evironment, they shouldn't be writing code cos they're not smart enough," I'll offer this. While I agree that it's important to know your tools as a professional, we are not talking about professionals here. We are often not even talking about people who want to be professional software developers. There are many people who have studied their field for years and are probably much smarter than many of us here are now getting into code because it's a tool for them to do their work better. It is in my opinion arrogant to insist they set up their own tools before they can learn what we do.

I wish Codeanywhere and others the best of luck.

So people are.

I have been coding in JS since JS landed in a browser and right now it's just too much, with a new build system every six months, to new libraries and frameworks. This continous evolution is necessary because JS wasn't designed to do the things people are using it for 21 years later.

So I've been looking at Elm. A lot of people really don't like the syntax. But if you get past that, there's a lot of things there. There's a great architecture, a sane package manager, static typing, and all the other things people bolt on. And it sounds like while it currently builds JS, it's going to move towards WebAssembly when that's more widespread.

Even if Elm doesn't become "the next big thing", maybe it'll spawn something that is.

I hope Elm, or something like it, does sweep the table clean.

The people I respect and aspire to be are those who are currently in their late 40s or 50s talking about Elm and Elixir. They were the ones in their 30s and 40s telling me Ruby was it. They were right, because they used their experience.

They buy the iPhone because of the brand, or they use Android because that's the free phone that was available, or the one the Verizon store pushed.

Geeks like us spend a lot of energy projecting our beliefs onto an audience who simply does not care. I know I've gotten riled up about open standards and DRM and stuff like that; my non-geek friends just roll their eyes at me.

Maybe they do it because they don't care. Or maybe they do it because we geeks treat everything like a Chicken-Little sky-is-falling thing.

I dunno - if they were really in this for making you buy new headphones, they'd not bundle the adapter, like they did in the past when they switched from 30-pin to lightening.

It "geneerally works if" you " rebuild docker hosts on a daily or more frequent basis."

Perhaps I'm misunderstanding, but needing to rebuild my prod env several times a day seems pretty "not ready for prime time" to me.

That's like when we'd say that Rails ran great in production in 2005, as long as you had a cron task to bounce fastCGI processes every hour or so.

So, can you elaborate on why rebuilding the containers is good advice?

The future will most likely be fewer books printed because publishers will just stop doing it and offer print-on-demand, passing the price to the customer.

My tmux book was originally done like that - printed only on demand. And the price difference reflected it.

I prefer digital because I can send out updated copies of the books to readers for free, which I can't do on paper. And programming stuff changes so frequently.

So I guess I'm saying if you want print books, you should make that known by buying physical copies of books. Cos if the trends I see continues, I can't imagine it'll be practical to do print tech books too far into the future.

As a dev and a creative person, I understand the desire to get something out there. But documentation and tutorials aren't just something that's nice to have. They are your marketing tool, your adoption driver, and the way to create educated advocates for your project. They are as valuable to your project's success as a splashy "getting started" web site is.

Then I recommend listing work experience focused on acheivements. Recruiters want to see how your past experience will translate to future success so don't list job duties. List accomplishments at the job. How much revenue did the apps you wrote bring in? How many active users did the app you built support? Did you mentor other people and were they successful? Did you contribute to an open-source initiative?

"Built and maintained web applications using Ruby on Rails and React with over 200,000 active users per month."

I do list skills both in context and in a skills section.

My résumé has gotten me an interview every place I've sent it for the last 15 years. These things will never hurt you to do on yours. They will only help you.

I've heard that objectives hurt, and I know that work experience that reads like a job description hurts too. My wife is in HR and I've asked these questions of her network of people and that's the general consensus. So I hope that helps.