Back in the day, Laravel 6 came out-of-the-box with an `app.js` file that auto-wired up Vue components. After including `app.js` in your root Blade template, you could use Vue's web component syntax _anywhere_ to drop Vue components on your Blade templates, and they would resolve to the Vue component. Here's the relevant snippet from Laravel 6 that made the magic happen:

```js title="https://github.com/laravel/framework/blob/6.x/src/Illuminate/Foundation/Console/Presets/vue-stubs/app.js#L11-L20"
/**
 * The following block of code may be used to automatically register your
 * Vue components. It will recursively scan this directory for the Vue
 * components and automatically register them with their "basename".
 *
 * Eg. ./components/ExampleComponent.vue -> <example-component></example-component>
 */

const files = require.context('./', true, /\.vue$/i)
files.keys().map(key => Vue.component(key.split('/').pop().split('.')[0], files(key).default))
```

Using the two lines above, one could drop
`<example-component></example-component>` anywhere you wanted on the page and
achieve reactivity. This allowed you to get moving quickly without thinking too
hard about marrying JavaScript to the server-rendered parts.

While Laravel has since abandoned the above in favor of Inertia or Livewire, the auto-resolution convention is a great fit for sprinkling reactivity on older applications. So when my company decided to pull React into our 10-plus year old application, I remembered my experience with Laravel 6 and created the proof-of-concept [Inline JSX][inline-jsx] to suggest an improvement to our developer experience.

[inline-jsx]: https://github.com/dstrunk/inline-jsx

## What does this solve?

Inline JSX is meant to provide a way to add React to an existing application. A full rewrite of the application into a single-page application is off the table. The application does not have a dedicated API, so creating new endpoints just to support React is beyond the scope of the React addition. The application has a capital "V" View layer that allows for providing server side data, which can be used to hydrate the React application with initial data.

If this sounds like an application you're working on, Inline JSX may be for you!

## Before Inline JSX

Adding React to an existing application is pretty straightforward--the React documentation covers it in the ["Getting Started"][react-getting-started] section. It's fine, but filled with boilerplate. It also leaves the question "how do we hydrate data?" unanswered... do we:

[react-getting-started]: https://reactjs.org/docs/add-react-to-a-website.html#add-react-in-one-minute

1. Instantiate a global `window` object in the template and reference it after the React component mounts?
1. Make a `fetch` call within the React component after the component mounts?

For this example, let's assume a global `window` object. First, the template:

```php
<html>
  <head>
    <script src="js/react.js"></script>
    <script src="js/react-dom.js"></script>
    <script src="js/add-to-cart.js"></script>
  </head>
  <body>
    <div id="add-to-cart"></div>
    <script>
      // instantiate a global `product` that can be used to hydrate the React component.
      // Alternatively, a `fetch` could be done in the React component itself.
      window.product = <?= json_encode($this->getProduct()); ?>;

      // Create the React component
      const addToCartRoot = ReactDOM.createRoot(
        document.getElementById("add-to-cart")
      );

      // Mount the component to the `#add-to-cart` DOM node
      addToCartRoot.render(<AddToCart />);
    </script>
  </body>
</html>
```

Then, in the component:

```jsx
function AddToCart() {
    let product;

    // Instantiate the product on mount
    useState(() => {
        product = window.product
    }, [])
}
```

## After Inline JSX

Using the inline JSX approach, things become a lot easier. After adding `app.js` to your page, all of React's boilerplate is replaced with a `<web-component></web-component>` style DOM element. Instead of wondering if we should add a `window` global or `fetch` call, you add an HTML attribute containing any data needed to hydrate the React component after mount:

```php
<html>
  <body>
    
    
    <add-to-cart product="<?= json_encode($this->getProduct()); ?>"></add-to-cart>

    
    <script src="js/app.js"></script>
  </body>
</html>
```

The data passed to the component via HTML attributes can be destructured from the React component as you would normally expect:

```jsx
// `product` is an HTML attribute in the above example
function AddToCart({ product }) {
    // ...
}
```

## Caveats

This approach comes with some challenges. Some are limitations with the HTML parser, while others are architectural decisions that should be considered.

### Case insensitivity

HTML tags and attribute names are case-insensitive. This means any PascalCase component names or camelCase prop names need to be converted to kebab-case equivalents.

The Inline JSX proof-of-concept accounts for this conversion, but to hammer the point home, here is how you can expect the HTML components to be converted to JSX:

```html
<my-react-component html-attribute="hello world"></my-react-component>
```

Note the PascalCase for the React component, and the camelCase for the html attribute:

```jsx
function MyReactComponent({ htmlAttribute }) {
    // ...
}
```

### Self-closing tags

The HTML spec only allows a few specific elements to omit closing tags. For any other elements, if the closing tag is omitted, the HTML parser will think the tag was never closed. The browser will attempt to close the tag itself, and you may run into errors. For example:

```html
<example-component />
<span>hello world</span>
```

The above may be parsed like the following:

```html
<example-component>
    <span>hello world</span>
</example-component>
```

### Communicating with other components

Since each component is technically a standalone React application, communication between _different_ applications needs to be solved. Say, for example, you have a `MiniCart` component that needs to update once a user adds a product to the cart? In the `inline-jsx` repo, my solve for this was an event bus pattern:

```js
const events = {}
let eventId = 0

const publish = (event, ...args) => {
  const callback = events[event]
  if (!callback) return console.warn(`${event} not found`)

  for (let id in callback) {
    callback[id](...args)
  }
}

const subscribe = (event, callback) => {
  if (!events[event]) {
    events[event] = {}
  }

  const id = eventId++
  events[event][id] = callback

  return {
    unsubscribe: () => {
      delete events[event][id]

      if (Object.keys(events[event]).length === 0) {
        delete events[event]
      }
    }
  }
}

export default { publish, subscribe }
```

The above is the entire event bus... but for something more full-featured, feel free to reach for Redux.

Once the event bus is added, you can publish events anywhere you want to communicate to an outside component:

```jsx
import { v4 as uuid } from 'uuid'
import eventBus from '../eventBus'

function AddToCart({ product }) {
    const addToCart = (product) => (e) => {
        e.preventDefault()

        eventBus.publish('MINICART_ADD', {
            product,
            quantity: 1,
            message: {
                id: uuid(),
                type: 'success',
                title: `Product added to cart`,
                body: `${product.title} has been added to your cart.`,
            }
        })
    }

    return (
        <button onClick={addToCart(product)}>Add to Cart</button>
    )
}
```

Then, any components that need to act based on the published events just subscribe to the published event:

```jsx
import eventBus from '../eventBus'

function MiniCart() {
    const [items, setItems] = useState([])

    useEffect(() => {
        const addItemsSubscription = eventBus.subscribe('MINICART_ADD', ({ product, quantity }) => {
            const item = { ...product, quantity }
            const oldItems = [...items]
            const itemIndex = oldItems.findIndex((i) => i?.id === product.id)

            if (itemIndex < 0) {
                setItems((i) => [...i, item])
            } else {
                const updatedItem = items[itemIndex]
                updatedItem.quantity++

                setItems((i) => [...items])
            }
        })

        return () => {
            addItemsSubscription.unsubscribe()
        }
    }, [items])

    // Return an actual minicart ...
    return <></>
}
```

### Data grids

To be honest, there's not really a solve for this using the inline JSX approach. While it's easier to add simple React components to the page without having to introduce new API endpoints, hydrating a component that has the potential to have hundreds of thousands of rows begins to be a performance and memory concern from a server perspective. In this case, an API endpoint coupled with a `fetch` call would be a better approach.

## Summary

Writing this proof-of-concept was fun--I got to work on something that I'm a big fan of improving, Developer Experience (DX), and I learned more about the some of the inner workings of React's boot process. I hope people find it useful!

For a more thorough example of some use-cases of the inline JSX approach, check out the project's `index.html` page: https://github.com/dstrunk/inline-jsx/blob/main/public/index.html

Easily add React root components to your HTML templates using web component syntax.

Inline JSX for React


My career trajectory has been quite average, all things considered. I started
working in 2009 as an in-house graphic artist before quickly transitioning into
a more technical role, kicking off my career in web development. In 2015, I moved to a new company as a Magento developer, where I worked until
January 2022.

In both cases, I worked in-office. Commuting, wearing uncomfortable clothes, sitting in noisy open-office environments that distracted me, for almost thirteen years. Thirteen years!

My first brush with remote work is similar to other peoples' stories: with the pandemic. In 2020, almost overnight, I went from in-office work to remote. And I loved it so much, I decided to continue doing it.

In January of this year, I got my first remote-only job, and I plan on continuing with remote work indefinitely.

I mention my career history only to point out that there was no dedicated effort to transition to remote work. There are, however, things that I've done to set myself up for continued success with working remotely.

## Have a schedule

This is one of those obvious tips that every blog post in this vein touch on. With good reason: if you aren't diligent in sticking to a schedule, you'll slip into working later and later, ending the day earlier and earlier, and losing your coveted remote job faster than you can say "nine to five."

With regards to having a schedule, there's an important one that speaks to me personally: unplugging.

### Unplug

This may be easier said than done--I have to make a conscious effort week-by-week. When the day is done, stop working!

This is especially hard when you work on a distributed team. My team, for instance, spans multiple time zones: Pacific, Central, Eastern, and Central European. That last one throws things for a loop, eh? So product or design questions may not come through Slack until 19 or 20:00 EST, while development questions from our European friends will begin around 3:00 EST. You have to use discretion here, because it's certainly up to the culture of the company, but **if you can**, log off when _your_ day is finished.

Slack and emails are meant for **a**synchronous communication, not synchronous. Also? Slack allows you to schedule your messages ... I suggest applying liberally.

## You should have an office

... or at least a work area that affords you peace and quiet. Between standups, retrospectives, one-on-ones, pair programming sessions, and other ad-hoc meetings, I tend to be on video at least three to five times a day.[^1]  Without a dedicated area to field these calls, I would have quickly given up on remote work.

[^1]: What, you thought remote work meant not working with people?

I've been low-key setting myself up for remote work for years. By the time the pandemic rolled around, I'd already set up a dedicated office in my house with a sit-to-stand desk, multiple monitors, a comfortable chair and a nice camera. It was a pricey investment, for sure. But it ended up paying dividends--I now have a nicer office than I _ever_ had working in-office.

I'm not saying you need this same investment, but consider this, at least: if you were to go remote today, would you be 100% happy physically working where currently work? If the answer is "no," you may need to re-evaluate.

## Try to get some exercise

From March of 2020 until January of 2022, I gained almost thirty pounds. Part of this weight gain was due to pandemic-related stressors. The biggest source of weight gain, however, was mindless snacking and decreased overall mobility due to working remotely.

In 2022 I've fought back: scheduling walks into my work day, relegating food consumption to meal times, and working out. In addition to the physical health benefits of these newfound habits, I've (annoyingly) found exercise to improve my mood, anxiety, and overall mental well-being.

I didn't grow up in a household that prioritized good fitness or nutrition, so this "common" knowledge came far too late for me: get daily exercise and eat well ... you'll do your body a world of good, and you'll set yourself up for a longer life.[^2]

[^2]: This advice fits regardless of in-office or remote ... work out! It sucks, but it's good!

## Be comfortable being alone

You'll be physically alone most of the day. **Take stock of yourself**: how does that hit you? Keep in mind, you'll still be working with other people--over Slack, on Google Meet or Zoom, etc.--but there's a physicality that's lost, for sure. Are you okay with that?

## ... but still be social

Being physically alone doesn't mean you have to be a loner. In fact, it's more important than ever to build rapport, both at work and outside of work--via Slack, texts, etc. Your mental health will take a hit otherwise.

This advice is especially salient for those of us that are introverted. Your initial inclination may be to lean into your introversion; it was initially mine. But as time goes on, you may find yourself feeling more anxious, struggling with feelings of self-doubt, etc. We are not meant to live alone, so make sure you take steps to avoid that. Socialization doesn't even have to be pointed ... just _being_ around people is enough for me. Activities that fill my "social" cup:

- Go to the gym
- Go to the pool
- Go grocery shopping
- Weekends with friends

They may not seem like much, but these small social interactions are enough to "bring me back into the social fold" 😛

## Conclusion

I'm no expert at remote work. Again, I've only been doing this for three years (with one by choice). And the above is by no means exhaustive. Entire books could be written on "How to Remote Work Well."[^3] Entire blog posts dedicated to effective, constant communication up and down the chain of command. I like the idea of revisiting this blog topic yearly, to see if I feel the same from year-to-year.

Until then, however, that's all I've got; see you next time 😊

[^3]: I purchased [Effective Remote Work][remote-work] as soon as it was released.

[remote-work]: https://pragprog.com/titles/jsrw/effective-remote-work/


Tips and tricks that worked for me while transitioning from in-office work to remote work ... one year in.

What I've learned working remote


Using ES2015, it's possible to initialize objects using computed property names. This is handy for dynamically setting the state in React, for example:

```js
// App.js
import React, { Component } from 'react';

class App extends Component {
  constructor() {
    super()
    this.state = {
      username: ''
    }

    this.handleChange = this.handleChange.bind(this) // Don't forget this!
  }

  // ...

  handleChange(e) {
    this.setState({
      [e.target.name]: e.target.value
    })
  }

  // ...

  render() {
    return (
      <>
        // ...
        <input type="text"
          name="username"
          placeholder="username"
          onChange={this.handleChange}
          value={this.state.username} />
        // ...
      </>
    )
  }
}
```

Note the `handleChange()` method. This method uses a computed property name, `[e.target.name]`, to set the value. This means you can reuse the method to bind multiple elements to state changes with minimal effort.

To add another element, you'd do the following. First, in the `constructor()`:

```js
this.state = {
  // ...
  email: ''
}
```

And in the `render()` function:

```js
<input type="text"
  name="email"
  placeholder="user@example.com"
  onChange={this.handleChange}
  value={this.state.email} />
```


Add two-way binding for arbitrary values using computed property names.

Easier data binding in React


This week I decided to dive into learning a frontend technology that's been gaining serious traction in the Magento crowd: React and Progressive Web Apps (otherwise known as PWAs). [GatsbyJS][gatsby] seemed like a great lower-barrier entry into both React and PWAs, with its fantastic documentation, strong community and abundant tutorials. I have previous experience in [Vue][vue] from building a larger Laravel application in my spare time, so picking up React has largely been a matter of learning syntax. I am **not**, however, familiar with single page application architecture, so there was a bit of a learning curve.

[gatsby]: https://www.gatsbyjs.org
[vue]: https://vuejs.org

To learn Gatsby, I decided to revamp my blog. It's a prime candidate for this type of project: it's already built on GitHub Pages using Jekyll, which means all pages are flat files. Gatsby also has a plugin for deploying to GitHub Pages, which means I can continue hosting there and not worry about finding a new host and updating DNS. I can continue writing in Markdown with the [gatsby-transformer-remark][remark] plugin, which parses markdown files.

[remark]: https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby-transformer-remark

Below are some of my thoughts on the whole experience.

## Gatsby

Gatsby is magic, pure and simple. It's easy to grok at a glance--dedicated pages go in the `src/pages` directory, components get broken out into `src/components`, and there are some out-of-the-box helpers Gatsby provides so you enjoy best practices regarding SEO and PWAs.

It has a huge plugin ecosystem, which I think is really interesting. For example, you could have a Gatsby site published on GitHub Pages that is backed by content served through a headless CMS somewhere, be it Contentful, Craft CMS, WordPress … pick your poison.

I can't say enough good things about Gatsby, though I imagine some won't like it due to how opinionated it is.

## React

To be honest, I'm more a fan of Vue, though I admit it's more a matter of familiarity at this point. Vue feels a bit more declarative, which I dig. Vue's shorthand directives for methods (e.g. `@click`) and model binding (e.g. `:model`) lets me build out complex reactive functionality without exposing the inner workings of how it's handling things. In React land, having to explicitly bind values, write methods for handling changes and setting state is probably *safer*, but also a bit more boilerplate and annoying. I'm sure that boilerplate pays off when introducing Redux for state management, but I haven't built a complex enough app to warrant needing a dedicated state management library.

I *am* coming around, however, after learning some patterns. In particular, this one gets me pretty much the same model binding as Vue:

```js
// App.js
import React, { Component } from 'react';

class App extends Component {
  constructor() {
    super()
    this.state = {
      username: ''
    }

    this.handleChange = this.handleChange.bind(this)
  }

  // ...

  handleChange(e) {
    this.setState({
      [e.target.name]: e.target.value
    })
  }

  // ...

  render() {
    return (
      <>
        <input type="text"
          name="username"
          placeholder="username"
          onChange={this.handleChange}
          value={this.state.username} />
      </>
    )
  }
}
```

Specifically, the `handleChange` method sets the state using computed property names, so as long as your element is named the same as your state key, using `onChange={this.handleChange}` should just work for most use-cases.

## GraphQL

I didn't get to heavy into GraphQL with this experiment. Most of the GraphQL on this blog is in `gatsby-node.js`. This file handles preprocessing and creating static files for all of the blog posts using the Remark markdown Gatsby plugin. But even that is easy to understand. The experience has largely been, "Ask for data in this shape, receive data in this same shape".

I did get tripped up a couple of times with having to explicitly ask for the correct data to return. That usually got cleared up pretty quickly when I ran the query in the GraphQL Playground that ships with Gatsby.

I expect I'll have more opinions on this once I get into pagination. Concepts like edges, cursors, and fragments will start to make more sense in that context. Also, mutations are an unknown entity for me at the moment. So far I have only queried GraphQL data, never manipulated it.

## Takeaways

You may have gathered this from the above, but I'm a fan of magic--syntactic sugar that handles my implementation details in the background. Some people enjoy the minutiae of what's going on, but I'd rather spend my time planning architecture and solving problems. Gatsby hits all of those dopamine receptors for me--it Just Works when you need it to, but is open to extensibility. React does that less so (over other libraries such as Ember or Vue) but is still miles above manually doing it myself, so I'm ultimately alright with it. Honestly I never had many issues with REST over GraphQL, but I dig the asked-and-answered future of GraphQL.

## Next week

I'm either going with …

### Advanced React with Wes Bos

This foray into React and GraphQL barely scratched the surface. Learning the two in more depth has been on my radar for some time, and not just because of Magento 2's recent choice to use it.

I purchased [Wes Bos's Advanced React][advanced-react] as soon as it was released, but have not fully completed it. In Advanced React, Wes uses the popular GraphQL client [Apollo][apollo] alongside Gatsby to create a fully-functional PWA storefront. It's pretty clear that Magento is going all-in on GraphQL and React (which I consider a good thing for the most part), so it's in my best interest to stay ahead of the curve by really grokking the concepts introduced in Wes's Advanced React course.

[advanced-react]: https://advancedreact.com/
[apollo]: https://www.apollographql.com/

### Firebase

Firebase is a cool idea to me--billed as a "Backend as a Service", Firebase is a decentralized data store by Google. It kind of blows my mind that I can create a React app hosted on GitHub Pages that has database-level functionality (including authorization) for free.

Thanks for reading, until next week!


GatsbyJS and GitHub Pages


## Hello, world!

I originally started blogging at the end of 2012, with a post titled "My front-end development workflow". In that post, I detailed some of the tools, languages and frameworks I was using at the time (if you're interested in a trip down memory lane, you can [check it out here][front-end-workflow]). In July 2018 I decided to revamp my site by cleaning up the structure, use some new tech I've been interested in, and give the site an overall refresh. Keeping with the theme of the first post I decided to create a new post touching on my workflow. I'm a sucker for process, and I'm sure others out there might be interested in refining their workflow or looking for some new recommendations. So, without further ado, here is my updated development tools focused on getting things done.

[front-end-workflow]: /blog/2012/my-front-end-development-workflow/

## Languages / Frameworks

- [Laravel][laravel] - I love Laravel for the simple fact that it abstracts away the monotonous parts of building an app. 99% of the apps I've ever built have needed authorization, authentication, and other sensible defaults that end up being boilerplate. I appreciate that I can switch from app to app and expect the same conventions. Bonus points for being in the same language I use in my day-to-day, PHP.
- [Vue][vue] - This is the first frontend framework that really "clicked" for me. React might be more practical from a developer mindshare perspective, but I never really dug JSX or the tooling.\* For my personal projects, Vue has been a fantastic way to quickly add reactivity to my frontend. By using Laravel Mix as my build pack of choice, Vue is pretty plug-and-play.
- [Tailwind][tailwind] - I've fought in the past to maintain a CSS design system long-term, and have **never** been able to make one portable enough to bring over to a new project. Tailwind alleviates me of that responsibility. Using a utility-first approach, I can build out the UI iteratively, and extract components if I ever find myself repeating clumps of classes on elements. See examples of that on this site&mdash;much of the site is built using straight utility classes, but some things, like the "Originally posted on \<date\>" string, or categories, are repeated, and have been pulled out into their own classes for repeatability's sake.
- [Laravel Mix][laravel-mix] - I've used Laravel Mix on Elixir Phoenix projects, Magento stores, Laravel apps, and this blog, which is a Jekyll install. I love its ability to provide the power of Webpack in a wrapper that more closely resembles Gulp, which I used previously.
- [Magento][magento] - Here's one that might not be on others' lists. I got hired as a Magento developer two and a half years ago, and have been working in it ever since. Learning it was a chore to be sure, but now that I know what's going on, it's not so bad. The dangers of Magento are also its strengths--It's incredibly extensible, allowing you to create anything you can imagine. I tend to think of Magento modules as discrete Laravel apps acting as microservices. Just make sure you don't use that extensibility to paint yourself into a corner.

\*Note that my experiments with React's ecosystem were very early … Things have changed since then 🙂.I actually used React on an app at work, and the ecosystem has gotten quite pleasant.

[laravel]: https://laravel.com
[vue]: https://vuejs.org
[tailwind]: https://tailwidcss.com
[laravel-mix]: https://github.com/jeffreyway/laravel-mix
[magento]: https://magento.com

## Tools

First, a disclaimer: many of these tools are Mac-only.

- [Neovim][neovim] - Love my Vim. I've been using Vim since I began learning backend development using Ruby and Rails. The Ruby community is pretty thoroughly on board with Vim, so there are tons of resources out there for customizing the editor. Somewhere along the way I switched to PHP, Laravel and Magento development, but my love of Vim stayed. NeoVim is a fork of original Vim, meant to update the editor when the Vim maintainer decided not to accept certain PRs. NeoVim's killer features are an embedded terminal and async support (though Vim 8 has this now, as well). I don't personally use the embedded, but am interested in setting up my testing environment to run directly to a NeoVim terminal instead of relying on tmux so heavily. Speaking of …
- [Tmux][tmux] - I use tmux as an augment to my vim usage. Running tests in Vim opens a tmux split that I can then focus to view the test output. I'll also have a couple of splits open in a new tab that run build processes such as `npm run watch` or `php artisan serve`. I use different tmux sessions to switch between projects without losing my terminal layout. It's become a pretty indespensible part of my workflow.
- [Sketch][sketch] - Sketch superceded Adobe's suite of products for me when Adobe switched to a subscription-based payment system. Which is ironic, since Sketch is kind of doing the same thing now. I enjoy Sketch for prototyping sites and creating SVGs, and find that I can do 90% of what I previously used Illustrator for at a fraction of the price.
- [Table Plus][table-plus] - I use several different databases in my daily work&mdash;MySQL, Postgres, and MSSQL, as well as a couple of Redis servers. Table Plus can handle all of these, no problem. It's a newer app, so it's not _completely_ bug free, but I haven't run into any issues in my day-to-day.
- [Things][things] - I've used a ton of to-do apps in the eternal quest for Getting Things Done&trade;. Omnifocus, Things, Asana, Todoist, Evernote … you name it, I've likely kicked the tires on it. I've stuck with Things the most of all of these, because it's simple. Create a list, check them off, done.
- [Bear][bear] - Though Mac's Notes app has gotten better, Bear beats it (and Evernote), hands down. I can write in markdown, which I'm comfortable with (I've been using markdown for this blog for six years now). Pay the $14 a year to sync across Mac and iPhone and support this great app.
- [1Password][1password] - Best password manager I've ever used, no contest. Better UI than LastPass, great integration with Mac / iPhone … 'nuff said.
- [Expressions][expressions] - This is a cool app&mdash;Add a list of strings in one panel, add a regular expression in the other pane, and Expressions will highlight the strings that match the regular expression. This is great for testing (and learning) regular expressions, something I have been historically bad at.
- [Dash][dash] - Dash is an app that downloads (and keeps current) documentation for any languages or libraries you choose. I use it for offline reference, and to do quick searches on the current word under my cursor in vim using [dash.vim][vim-dash].
- [Spectacle][spectacle] - I briefly used Arch Linux with i3 window manager. One thing I absolutely loved was moving and resizing windows using the keyboard. Spectacle gives me a similar level of control with windows on the Mac, and I can't see going without it anytime soon.

[neovim]: https://neovim.io
[tmux]: https://github.com/tmux/tmux
[sketch]: https://sketchapp.com
[table-plus]: https://tableplus.io
[things]: https://culturedcode.com/things/
[bear]: http://www.bear-writer.com
[1password]: https://1password.com
[expressions]: https://www.apptorium.com/expressions
[dash]: https://kapeli.com/dash
[vim-dash]: https://github.com/rizzatti/dash.vim
[spectacle]: https://www.spectacleapp.com

## Honorable mentions

### Languages / Frameworks

- [Elixir][elixir] / [Phoenix][phoenix] - I've done a few tutorials to wrap my brain around functional programming concepts, but have had to hold off on using Phoenix and Elixir on new projects in favor of focusing on my daily work. I am looking forward to diving deep into the Elixir world, however&mdash;from its compiling code down to the battle-tested Erlang VM, to its high concurrency promises, and its familiar syntax (as a former Rubyist), Elixir and Phoenix are on my short list for using.

[elixir]: https://elixir-lang.org
[phoenix]: https://phoenixframework.org

### Tools

- [Parallels][parallels] - Many of our internal tools are .NET, so I've been learning C# development after hours to better-support our other teams. While C# is possible on any platform (hello, .NET core), it's definitely easier on Windows. To that end, I installed a small Windows 10 partition on my laptop. I installed Parallels to switch between OSes, and found that Parallels comes with a mode called "coherence". Coherence mode is a way to run Windows applications on the Mac, as though they are native Mac applications. In my limited experience opening up IE11 for browser testing or Visual Studio for C# dev, it has been insanely seemless. I highly recommend Parallels, but it didn't make my list because it's just not used that often.

[parallels]: https://www.parallels.com


Multi-language development tools I use to focus on Getting Things Done

My Development Tools of the Trade


Erlang is a first-class citizen of Elixir. This isn't a surprise; Elixir compiles down to BEAM, Erlang's VM, which means we get to leverage the power of Erlang for free.

We can see this functionality demonstrated in translating an Erlang library function into Elixir code. First, a look at the Erlang version:

```erlang
client() ->
    SomeHostInNet = "localhost", % to make it runnable on one machine
    {ok, Sock} = gen_tcp:connect(SomeHostInNet, 5678,
                                 [binary, {packet, 0}]),
    ok = gen_tcp:send(Sock, "Some Data"),
    ok = gen_tcp:close(Sock).
```

Probably most important to note is the syntax for calling an Erlang library in Elixir: `:gen_tcp` (note the colon). This lets Elixir's compiler know that a call to a native Erlang libary will be performed. Now, in Erlang:

- **Functions are indented until the end of the call**. Functions in Elixir are wrapped in a `def <functon> do, end` block.
- **Multiline functions have commas, and the end of the function is terminated with a dot**. Elixir doesn't need any of these. Note that this is simplified for our example, but [this Stack Overflow question][stack-overflow] has a good explanation of when to use semicolons, commas or periods in Erlang.
- **Variables are capitalized**. Elixir variables are lowercase and snake case, so `SomeHostInNet` becomes `some_host_in_net`.
- **Comments start with a %**. In Elixir comments use `#`
- **Tuples look the same in Erlang vs Elixir**. But looking at the first tuple in our Erlang function `{ok, Sock}`, `ok` is a symbol. In Elixir we prefix symbols with a colon, so `ok` becomes `:ok`. Note that the variable `Sock` will again become lowercased `sock`.
- **Library methods are called with the colon, e.g. `gen_tcp:connect`**. In Elixir methods are called with the dot, or `:gen_tcp.connect`.

[stack-overflow]: https://stackoverflow.com/questions/1110601/in-erlang-when-do-i-use-or-or

After converting the above, here is the Elixir implementation:

```elixir
def client do
  some_host_in_net = "localhost" # to make it runnable on one machine
  {:ok, sock} = :gen_tcp.connect(some_host_in_net, 5678, [binary, {packet, 0}])
  :ok = :gen_tcp.send(sock, "Hello, World!")
  :ok = :gen_tcp.close(sock)
end
```

Once you understand some of the nuances of Erlang's syntax, you can see that it's a relatively straightforward exercise to convert methods between the two.


A quick demonstration of using a native Erlang library in Elixir.

Using Erlang in Elixir


Occasionally I'll pick up smaller development jobs outside of work. Usually
these jobs follow a standard template: WordPress on shared hosting with a theme
already in place. And up until now, my workflow for these jobs looked similar:
spin up a new WordPress instance, download their theme, create a child theme,
then copy the result to the shared server via FTP. But it's 2017, we can do
better than that! For this most recent job, I decided to utilize git's hook
features to automate deployment using a better (and safer) workflow.

After reading, you will be able to update your website with a simple `git push
production master`!

## Prelinary setup - shared hosting SSH access

First, you'll need to have SSH access to your shared hosting environment. This
is available on most sites under "Home > Security > SSH Access" in cPanel.
You'll need to add a new key; I won't go over that here, but GitHub has a great
how-to on [generating a new SSH key][genssh].

[genssh]: https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/

After following the how-to on generating a new SSH key, add the public key to
cPanel's SSH Access. If you're on a mac, here's an easy command to copy your
newly generated SSH key to the clipboard:

```bash
cat ~/.ssh/id_rsa.pub | pbcopy
```

Now that the key is copied, in cPanel, click "Import key", and paste the public
key into the appropriate text box. Note that you don't need the private key for
this deployment. I'd also recommend naming the key something like "id\_rsa.pub"

## Server setup

For this part, we're going be working with these two directories on our server:

- Server site: `$HOME/public_html/site.com`
- Server git repository: `$HOME/vcs/site.git`

Now that you've got SSH access, you should be able to connect to your shared
hosting server via the command line. try it now; connect to the server using
your login name and the server's IP using SSH:

```bash
ssh name@1.1.1.1
```

### Creating the repository

On the command line, type the following:

```bash
cd $HOME
mkdir -p vcs/site.git && cd vcs/site.git
git init --bare
```

Using the git command `--bare` means the folder will only contain version
control about our site.

### Creating the hook

Git provides hooks to run commands after certain tasks have been completed. Its
documentation isn't that great, but DigitalOcean have done a great job of
documenting things on [using git hooks to automate development and deployment
tasks here][do-git]. The git hook we're interested in is `post-commit`.

[do-git]: https://www.digitalocean.com/community/tutorials/how-to-use-git-hooks-to-automate-development-and-deployment-tasks

On the command line (assuming we are still in the `/var/vcs/site.git` folder),
run the following command:

```bash
cat > post-receive
#!/bin/sh
git --work-tree=$HOME/public_html/site.com --git-dir=$HOME/vcs/site.git checkout -f
```

After writing this, press "Control-d" to save. Now set proper permissions so the
git hook can be executed:

```bash
chmod +x post-receive
```

This `post-receive` hook does all the heavy lifting for our deployment. It is
run every time files get pushed to the `/var/vcs/site.git` repository, and
`work-tree` defines where the files will be transferred to. The `checkout-f`
command ensures our old files will be overwritten on successful push.

## Our local site

Locally, the only thing that needs to be done is add the remote path of the
production website to our repository. I'll assume you've already got a local
folder for `site.com`, and all files are checked in and committed. On the
command line, after `cd`ing into the correct directory, run the following:

```bash
git remote add production ssh://name@1.1.1.1/~/vcs/site.git
```

Notice the `~` tilde; we have to specify that we want the home folder for our
user in the SSH path so we can get to our repository correctly.

From here, it's business as usual. Run the following command:

```bash
git push production master
```

Your changes will be pushed up to the shared hosting server, and your files will
be added to `$HOME/public_html/site.com`!

## Conclusion

This is pretty handy, and is by no means the only thing you can do with git
hooks. For example, you could write a local `post-merge` hook that SSHes into
the production server, creates a database dump, copies it locally and updates
your local database, so your local environment is always up-to-date with
production.

Perhaps the biggest shortcoming of these git hooks is that they cannot be stored
in version control and shared with teams. This is understandable as they have
the potential for remote code execution, but it would be lovely to store an
entire project's build process into a tool that's already being used... I
suppose that's what Jenkins CI is for :)


Using git hooks to automatically deploy sites

Auto deploy with git


Happy New Year! Let's get 2017 started right with some Vim tips to increase your
productivity when refactoring code on projects. Today we're focusing on finding
and replacing across your project directory.

Vim doesn't have built-in commands for project-wide search and replace, but it
_does_ provide the building blocks for us to compose our own.

## Easy mode: greplace.vim

Of course somebody's already tackled this problem in the vibrant Vim ecosystem;
Yan Pritzker has modified an original plugin by Yegappan Lakshmanan to create a
full-featured solution in [greplace][greplace]. I'm basically rehashing
greplace's readme, but to use:

[greplace]: https://github.com/skwp/greplace.vim

1. Type `:Gsearch` along with your search term, hit enter and get a buffer
   window full of your search results.
2. Make replacements inside this buffer using vim's familiar
   `%s/search/replace/`.
3. Call `:Greplace` to make changes across all files.
4. Save changes across all files with `:wall`

This solution is great for me, and somewhat replaces the one thing I miss most
about emacs: dired.

If you're a glutton for punishment, and are looking for the manual way to find
and replace across a project in Vim, look no further than below.

# Hard mode: full manual

Honestly, hard mode isn't too hard nowadays. Before, [vimcasts][vimcasts] had an
entire episode dedicated to find and replace across projects, with the best
option involving a bit of vimscript to allow for writing only to files that
contained the search results (instead of writing to every file within the
project).

[vimcasts]: http://vimcasts.org/episodes/project-wide-find-and-replace/

With the introduction of Vim 8, we now have the ability to iterate over our
quickfix window and make changes (essentially what `greplace` was doing above).
Here's an example to show what I mean:

```bash
:arga **/*
:grep! /Old/g ##
:cdo %s/Old/New/ge | update
```

The first command, `:arga **/*`, adds every file in the directory to the
arguments list. The next line, `:grep! /new/g ##`, adds every instance of our
search term, "Old", into the quickfix (I'm using `grep!` with the bang at the
end so the first instance of the search doesn't get opened). Last we have the
new `:cdo %s/Old/New/ge | update`. `:cdo` acts on every file in the quickfix;
the `%s/Old/New/ge` searches through these files and replaces globally (the `e`
at the end supresses errors resulting from not matching in some files), and the
update saves all files found.

This isn't too big of a hassle, and can be further simplified with
[ack.vim][ack]:

[ack]: https://github.com/mileszs/ack.vim

```bash
:Ack foo
:cdo %s/foo/bar/ge | update
```

Not bad at all!


Using buffers to search and replace across your project in Vim

Search and replace across files in Vim


*First, the TL;DR: check out [asdf][asdf]!*

[asdf]: https://github.com/asdf-vm/adsf

I first began web development as a "PHP" developer (if it could be called that):
editing and creating new WordPress themes and writing the ugliest procedural
code you could imagine. There were no worries of object-oriented programming
(OOP), no opinions formed about which framework or language was the best or worst, no
editor wars, nothing. Sometimes I miss those days :)

Since then I've sampled lots of languages. Wanting to finally learn OOP, I tried both
Python and Ruby before settling on Ruby. Interested in functional languages, I
tried my hand at Scala and Haskell before landing on Elixir and Erlang. And of
course, I've always had to deal with front-end development, so Node is
perpetually installed on all machines. One thing all of these languages have in
common? Your world can quickly fall apart when dealing with different language
versions, packages and libraries between versions, and permissions among the
lot. I can't count the number of times permissions have tripped me up with gems
and front end dependencies.

If you aren't a fan of firing up VMs for every single project or language
you want to sample, `asdf` is most likely for you.

## Introduce asdf into your workflow

`asdf` is the easiest package manager you'll ever have to type (look ma, one
hand!). If you are interested in sampling languages as I am, are working on a
machine that is less amenable to running a ton of VMs (whaddup macbook 12"?), or
are working on several different frameworks across different language versions,
check out asdf. Installing is simple:

```bash
# Clone to $HOME/.asdf
git clone https://github.com/asdf-vm/asdf.git ~/.asdf --branch v0.2.0

# For Ubuntu or other linux distros
echo '. $HOME/.asdf/asdf.sh' >> ~/.bashrc
echo '. $HOME/.asdf/completions/asdf.bash' >> ~/.bashrc

# OR for Mac OSX
echo '. $HOME/.asdf/asdf.sh' >> ~/.bash_profile
echo '. $HOME/.asdf/completions/asdf.bash' >> ~/.bash_profile
```

After installing asdf itself, you can begin installing plugins, which are then
used to then install different versions of languages. For our next examples,
I'll be using Elixir as our language of choice. Assuming asdf is already
installed, let's install Elixir:

```bash
# Add Elixir
asdf plugin-add elixir https://github.com/asdf-vm/asdf-elixir.git

# Add Elixir v. 1.3
adsf install elixir 1.3.4
```

... And so on and so forth. If you want a global Elixir version, set it!

```bash
asdf global elixir 1.3.4
```

Running this command will add the version to `$HOME/.tool-versions`.

## Add a local version to your project

Adding a language version to your project is super easy as well:

```bash
asdf local elixir 1.3.4
```

This will add a `.tool-versions` file to your root directory. Inside the file is
the name of your language and the version (super easy, right?). This is great
for back-end languages, but I think it's so much more necessary for front-end
development (nodejs, I'm looking at you).

## What about my language-specific package managers?

Look, rbenv is great. I used it for years! And, though not familiar, I'm sure
pyenv is great as well. As are others.

... But ...

Why not one to rule them all? Not only does asdf have a ton of languages
supported already, but it has an API to allow for easily creating a new language
of your choice.

If you're in a bind and can't build out a new language implementation in
time, asdf's got you covered as well. If you create a `.asdfrc` file your home
directory with the following:

```bash
legacy_version_file = yes
```

asdf will attempt to use your previous version manager's defaults (if it is
supported as a language within asdf ... which means you *do* have to add the
language before attempting this step). This means your `.ruby-version` files for
`rbenv` will be supported in addition to asdf's.

If you're still not convinced that asdf can replace rbenv / rvm / pyenv / exenv,
consider asdf's ballad (which might not do much to convince you, but is great
prose by the plugin's author):

```
Once upon a time there was a programming language
There were many versions of it
So people wrote a version manager for it
To switch between versions for projects
Different, old, new.

Then there came more programming languages
So there came more version managers
And many commands for them

I installed a lot of them I learnt a lot of commands

Then I said, just one more version manager
Which I will write instead

So, there came another version manager
asdf version manager - https://github.com/HashNuke/asdf

A version manager so extendable
for which anyone can create a plugin
To support their favourite language
No more installing more version managers
Or learning more commands
```

I am *obviously* a fan of adsf, if only because of how many times I've been
burned by this problem in the past. If you're in a similar boat, give asdf a
try!


Use asdf to manage different versions of every language you know

asdf version manager


I've written several toy apps over the years, created in Rails, Sinatra,
Laravel, and, most recently, Phoenix + Elixir. Though I think it's a great
exercise getting your app running on a production server somewhere, for apps
like mine which are, in most cases, prototypes or portfolio examples, something
like [Flynn][flynn] might be more up your alley.

[flynn]: https://flynn.io

Flynn is an open source Platform-as-a-Service (PaaS) for running applications in
production (similar to Heroku, but on a server of your choice). Out of the box,
it supports:

- Different buildpacks, which means all of my above applications are supported.
- Routes and load balances traffic for each app on the platform
- Includes built-in support for Postgres, MySQL and MongoDB

Perhaps my favorite feature, though, is Flynn's [cloud installation][flynn-cloud].
After installing Flynn, run `flynn install` on your local machine, and your
browser will fire up with steps to install via either Amazon AWS, DigitalOcean,
Microsoft Azure or SSH. Since I run my portfolio apps on DigitalOcean, the only
thing necessary for me to do was:

[flynn-cloud]: https://flynn.io/docs/installation/cloud

1. Select DigitalOcean from the first step
2. Add credentials, which includes generating an API key from DigitalOcean
3. Install

From there, you're taken to a dashboard containing a barebones Flynn install on
a newly provisioned DigitalOcean server. But the coolness doesn't end there;
After connecting your GitHub account to this new Flynn installation, you're able
to one-click spin up any applications that happen to follow [12 factor
app][12-factor] guidelines.

[12-factor]: https://12factor.net

After discovering Flynn, I went from nothing to a host of apps running in
separate processes on a machine provisioned on DigitalOcean in literal minutes!

Though my example was just for portfolio apps, Flynn is **far** more than just a
prototyping tool--it can fully replace Heroku, providing both horizontal and
vertical scalabiltiy quickly through their web interface. Give it a try!


Configure a platform for running apps in seconds on your own servers using Flynn

December 28, 2022

Inline JSX for React

November 21, 2022

What I've learned working remote

February 3, 2019

Easier data binding in React

February 2, 2019

GatsbyJS and GitHub Pages

October 7, 2018

My Development Tools of the Trade

July 29, 2017

Using Erlang in Elixir

January 23, 2017

Auto deploy with git

January 9, 2017

Search and replace across files in Vim

November 25, 2016

asdf version manager

October 20, 2016

Flynn + DigitalOcean