Forem: vinney cavallo

Using webpack-dev-server and HMR on a Remote Machine/VPS

vinney cavallo — Wed, 27 Jun 2018 04:00:00 +0000

Setting up webpack-dev-server HMR on a remote machine to work over nginx isn’t fun - but USING IT IS!

The Problem: Using webpack-dev-server’s livereloading and HMR features on a remote machine (probably over nginx)

The Solution is further down on this page for the impatient (or those who very reasonably don’t care to read about how I got into this situation and how long it took me to solve it!).

The Fluffy Backstory

The joys of livereloading, hot module replacement, instant style updates and their related, rapid relatives have only recently come into focus for me. Now that I’ve seen this dazzling light the idea of toiling away in a dark alley of constantly Ctrl-Ring a browser window makes me very miserable. I’ve recently adopted a workflow that involves working on a remote, hosted VPS over SSH in the terminal. I love almost all the things about it, but it briefly pushed me down the dark Ctrl-R alley. The main reason is simple: You’re no longer hitting a localhost:NNNN page anymore - instead you’re going out over the internet.

There are a few issues:

On-Disk vs In-Memory builds of the site
Hosts and DNS
Ports (who uses which ports, who knows this, how to tell the various parties what’s where)
Firewalls
Things about HTML headers
Things about websockets

I spent hours and hours and purpled all google searches I could think of. sometimes after spiraling around I’d come back around to older google search results but this time I’d have a different set of configuration combinations as a result of walking through previous google search results so I’d try some of these things mixed in with weird combinations of other stuff I’d already tried.

It was one big shitty salad of port, host, webserver combinations.

By the end, the viable solution is, in summary, this:

A publicly-accessible URL (let’s call it http://devenv.com. and I already checked, it’s taken) with DNS records pointing this domain to the IP of the VPS we’re working off of.
A static-built version of the files at /dist, served up by a simple nginx server block pointed to the static index.html when navigating to http://devenv.com.
webpack-dev-server running, serving an in-memory version of the site over local port 8080.
- another nginx server block using a subdomain such as http://live-and-hmr.devenv.com which proxies the websocket connection over to the above webpack-dev-server process on 8080.

What I didn’t understand originally was that webpack-dev-server is a server (duh) and as a result nginx should not be doing the serving of that resource. It merely needs to step aside and hand off the responsibility to webpack-dev-server. This tripped me up, conceptually, before it clicked and prevented me from reasoning properly enough about the solution in order to arrive at it earlier.

One wouldn’t have to use the two URLs (with and without the subdomain going to the static and dev-server versions) but I found it convenient to be able to work off the HMR dev-server version 90% of the time while keeping the convenience of building the site and flipping over to the static tab for a sort of more productiony experience.

I thought a bit about why there were so few Stack Overflow posts or blog article about this solution and I arrived at: The remote dev vps approach is relatively uncommon and it may be even less common among front end developers. This is a bit of an assumption and maybe a rude-ish one, but one which is grounded by this bias: Front-end-mostly devs are more likely to be spending their valuable time working on javascript/webpack/gulp/styling workflows, etc. - all of which are noble pursuits and beautiful, but its easy to spend much of your time in that world without having to worry about hosting details, nginx, processes/ports, and the like.

To be clear, this is not a value judgement. Quite the contrary; being a mostly-back-end-developer myself I started off with very little knowledge on the front end challenges listed above and I have a lot of respect for those who know this stuff inside and out.

It has been a long and rewarding journey for me.

The Solution

Enough of my yakking! When I finally got the thing working I hastily noted it all down in a GitHub Gist (after doing a lot of wild, expletive-laced celebratory gesturing). The Gist will likely make enough sense to someone well-versed in webpack and its configuring, but I don’t know that its the clearest thing. Let me know if you have questions.

Link to gist

Embed (margins are off on dev.to. go to the source linked above..):

Bonus for Rails + Webpacker users

There’s another post forthcoming on Rails + Webpacker over VPS, but for now here’s another hastily-written gist with the solution for that setup (warning: it’s weirder):

Link to gist

Questions, comments, concerns and ridicule all welcome below!

Setting up Middleman and Tailwind CSS

vinney cavallo — Wed, 06 Dec 2017 21:16:00 +0000

Middleman and Tailwind make landing pages a breeze (get it?). Here’s how to get them to work together!

I’m a big fan of the Middleman static site generator and static sites / markdown blogs in general:

My consultancy’s site, exnil.io is built on Middleman.
My personal blog is built on Jekyll - a sort of cousin to Middleman.
And this site you’re reading is Octopress, a kinda defunct Jekyll nephew. (used to be Octopress… Migrated to Jekyll in 2018)

Lately I’ve been drinking the utility-first CSS kool-aid with glee. As others before me have also noted, Adam Wathan’s blog post makes the argument quite well, so I won’t get into my reasons here. Since I just mentioned Adam, it won’t be a surprise that my utility-centric CSS framework of choice at the moment is Tailwind CSS, which he co-created (or “is currently co-creating” since they are currently hard at work on the road to 1.0. And really when can the creation of any piece of software be in the past tense?)

I set out to build a pre-launch landing page for a new web app idea for which I am attempting to take a community pulse. I’m tentatively calling it Rate my Refactor and the point of it is to facilitate discussion and advice around specific instances of refactoring and code quality.

The speed and friction-reduction afforded by both Tailwind and Middleman make their team-up a natural choice for a simple landing page. In an effort to hit the ground running I popped over to Google to find some direction on getting Middleman, Webpack, PostCSS and Tailwind to all play nicely together. (disclaimer, I’m traditionally a back-end developer so the unholy union of npm/yarn/webpack/gulp/js/postcss/etc/etc doesn’t just come naturally to my fingertips.)

I found a whole lot of nothing Googling around for this. Probably because most front-end devs come out of the womb knowing their way around yarn balls, gulps, and webby packs - but as I said, that’s not me. Apparently I’m not alone: http://www.impostorroster.com/posts/cannot-understand-how-webpack-works.

So I figure there’s gotta be someone else out there looking for this answer.

Hello, someone! Here it is:

Show Me How To Do It Already!

Here’s a GitHub repo all set up for you. These are the main bits:

Middleman settings:
- the activate :external_pipeline line in config.rb
Webpack setup:
- settings for js and css in webpack.config.js
- the contents of package.json
Tailwind config:
- postcss.config.js
- tailwind.js (generated as directed in their installation docs)

As an added bonus, this repo also has the configs necessary for an easy Heroku deploy.

The Final Product…

I invite you to check out Rate my Refactor for an example of a basic Middleman+Tailwind+Heroku site. Since you’re reading a programming blog you probably care at least a little about refactoring - so why not sign up for the email list while you’re over there?!

Thanks! If you have any improvements or problems please drop them in the comments below.

Easily center content in vim

vinney cavallo — Tue, 28 Mar 2017 20:38:14 +0000

Finding your center

This was originally posted on my programming blog.

I use vim for absolutely everything that I reasonably can. When editing code I typically have a vertical split with files open in both panes - so there is content across the whole screen. But when I'm writing non-code text I usually only have one file open and I like to keep an 80-column margin. This means I have a relatively narrow column of writing all the way on the left side of the screen and it feels and looks weird.

I like to get it centered left-to-right on my full-screen vim window. This is how I accomplish that.

Check out the original post to learn more. For the impatient, here's a snippet:

" centers the current pane as the middle 2 of 4 imaginary columns
" should be called in a window with a single pane

 function CenterPane()
   lefta vnew
   wincmd w
   exec 'vertical resize '. string(&columns * 0.75)
 endfunction

" optionally map it to a key:
" nnoremap <leader>c :call CenterPane()<cr>

Let me know if you find it to be broken in some situations or think it can be improved. Or better yet, if you found a better way to do the same!

Hi, I'm vinney cavallo

vinney cavallo — Tue, 14 Mar 2017 21:15:06 +0000

I have been coding for 4 years.

You can find me on Twitter as @vinneycavallo and on my site (which has any other links on me you'd need).

I live in New York City (but moving to Providence shortly).

I work for Myself! Currently building WalkUp.io with a business partner.

I mostly program in these languages: Ruby, bash, front-end web stuff as needed.

I am currently learning more about discipline.

Nice to meet you.