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

Flynn + DigitalOcean


import Gist from './src/components/Gist.jsx';

_This walkthrough assumes you have a Gmail account. If you are using another
email provider that utilizes SMTP, skip to the bottom of this tutorial for a
list of files that will need to be updated with your provider's SMTP
information._

Occasionally you might need to test PHP email functionality from your local
development environment; if that's the case, this is for you.

First up, I created a shell script that quickly sets up a Vagrant Ubuntu box
with Postfix; this script downloads and updates CA Certificates, installs
Postfix and all required dependencies, updates the Postfix configuration, and
finally reloads the service:

<Gist id="ff6301609bdbbcb3057d27812f8630e6" />

## Let's get started

First thing's first: let's create an application password for Gmail. Follow the
steps below:

1. Visit your [App passwords][app-passwords] page.
2. At the bottom, click **Select app** and choose the app you're using.
3. Click **Select device** and choose the device you're using.
4. Select **Generate**.
5. Follow the instructions to enter the App password (the 16 character code in
the yellow bar) on your device.
6. Select **Done**.

[app-passwords]: https://security.google.com/settings/security/apppasswords

Once you are finished, you won't see that App password again. However, you will
see a list of apps and devices you've created App passwords for.

Now that you've got an applciation-specific password, SSH into your VM. From
your VM's directory, run this command:

```bash
vagrant ssh
```

Now that you're in the VM, edit `/etc/postfix/sasl_passwd` by running following
command:

```bash
sudo vim /etc/postfix/sasl_passwd
```

The file contains one line: the SMTP information for Gmail, and a placeholder
for your gmail address and application-specific password. Input these now
(formatted as such: `username@gmail.com:password`), then save the file.

After saving the file, run the below command:

```bash
sudo /etc/init.d/postfix reload
```

Now, you should be good to go! If you'd like to test sending out an email, you
can run the below command:

```bash
echo "it works!" | mail -s "Test email from Vagrant" username@gmail.com
```

You should receive an email in short order.

## Alternatives

### I don't use Gmail; what should I do?

As long as your email provider has SMTP support, updating your Postfix config is
relatively straightforward. Googling for '[your-email-provider] smtp' should
yield their address and port number needed (e.g., a quick Google search for
Yahoo's information yielded `smtp.mail.yahoo.com` and port 465).

From there, you will need to edit `/etc/postfix/main.cf` and
`/etc/postfix/sasl_passwd`. In main.cf you're looking for the line containing
relayhost. You will update this line to have your email client's SMTP settings
within the square brackets, and the port after the colon (e.g.
\[smtp.mail.yahoo.com]:465).

In `/etc/postfix/sasl_passwd` you will need to do the same thing.

**Also of note when working with a non-Gmail account:** you might not have the
ability to create application-specific passwords. So, you'll need to put your
actual email password inside `/etc/postfix/sasl_passwd`.

### How about using an external mail provider (Mailgun, Mandrill, etc.)?

Go for it! If that's the case, you don't need this at all. You will, however,
need an understanding of your respective email provider's API, as well as how to
integrate this API into whatever you're building. Please see their documentation
for more details.


Send emails from your local Vagrant box using Postfix and Gmail

Configure Vagrant to test emails


For the [last couple of months][learning-emacs], I've been attempting to adjust
my workflow to Emacs. The Elixir community seems really on board with Emacs,
with some notable vim users switching over (Chris McCord, developer of Elixir's
Phoenix framework, among others). And I really, honestly tried. But... I just
couldn't do it.

Below are some things I just missed _too much_ that made me ultimately switch
back.

[learning-emacs]: http://danielstrunk.me/blog/2016/02/09/emacs/

## Tabs

Tabs are probably the number one reason I switched back. I use tabs in both tmux
and in vim, and my workflow is incredibly dependent on then in both programs.

### in tmux

In tmux, I'll use tabs to keep a separate window for running a headless
JavaScript server and a Rails or Phoenix server. That way I can edit files in
one tmux tab, and if anything goes amiss with an acceptance test, I can tab over
to the servers to see exactly what the stacktrace error was.

### in vim

In vim, it's nice to have tabs for context switching. Especially when
refactoring, I'd like my tests to be alongside the class I'm refactoring in one
tab, perhaps a configuration file and my routes in another, etc. I'm sure
there's a way to simulate this behaviour in Emacs (the editor is incredibly
extensible, I know), but I'd rather not have to install a plugin or write elisp
to mimic the functionality I'm used to.

## Terminal emulators vs a terminal

Perhaps my favorite thing about my configuration is its full integration with
Tmux, which allows me to create splits to have my editor on top and a
full-blown terminal on the bottom. Emacs has a terminal emulator, but it's just
that--an emulator. My terminal is a bit customized, so things not running
natively tend to run a little strangely.

And I like doing a lot of things in the terminal, to be honest. Though I have
[tpope/vim-fugitive][fugitive] for running Git commands within vim,
[vim-test][vim-test] for running tests within Rails or Phoenix projects, and
[tpope's vim-rails][vim-rails] for running Rails generations and migrations
within vim, I'll also jump into the terminal for more intensive work, such as
running pry to test out a block, or doing some heavier git commands to blame or
praise those who came before me :).

80% of the time the emulator works fine, but that last 20% is enough of an
annoyance to give me pause.

[fugitive]: https://github.com/tpope/vim-fugitive
[vim-test]: https://github.com/janko-m/vim-test
[vim-rails]: https://github.com/tpope/vim-rails

## Multiple workspaces

Tmux makes it easy to create multiple workspaces. With [this line in my tmux
dotfiles][switch-workspaces], I can press `C-s C-j` to bring up a list of all of
workspaces. Typing will present a fuzzy finder that filters results, which I can
further navigate through by pressing `C-p` or `C-n` (up or down--those emacs
keybindings come in handy sometimes :).

[switch-workspaces]: https://github.com/dstrunk/dotfiles/blob/master/tmux/tmux.conf#L72

## Summary

In the end, things basically came down to muscle memory; my vim + tmux
configuration is tested and true, and it's been hacked to my preferences for
about two years now. Jumping into another editor brought out some pain
points I'd previously ironed out that I just didn't feel like working through
again. In this case, tried and true beat out new and shiny for me.

If you're interested in my vim configuration, check out [my
dotfiles!][dotfiles] The parts I'm most fond of reside in the `vim/` and `tmux/`
folders.

[dotfiles]: https://github.com/dstrunk/dotfiles


Switching back to vim after a brief affair with emacs...

My old friend, Vim


# Electron

## Create native cross-platform applications using HTML, CSS and JavaScript

If the idea of creating native applications using the same tools you're using for front-end developement sounds up your alley, [electron][electron] is for you. Electron is a relatively new development offering by [GitHub][github] which allows you to create serious desktop applications using HTML, CSS and JavaScript. I know this post reads like a product push, but I'm seriously enamored with how easy this is. Architecting an application using frameworks or libraries such as React, Ember or Vue, then bundling said applications into binaries that can be utilized by Linux, Mac and Windows is an immensely powerful skillset.

[electron]: https://electron.atom.io
[github]: https://github.com

## A little history

A couple of years ago, GitHub decided to open source a new editor, named Atom, into the world. This editor was built on front-end technologies, was extensible and "hackable to the core". A cool idea, to be sure. At Atom's core was something literally called 'Atom Core'. This was, basically, an API for interacting with core desktop operating systems. When it started, it was pretty sparse--only offering APIs that made sense for Atom. But, people began using Atom Core for other reasons--Slack built their Windows and Linux applications with it, Microsoft used it to build Visual Editor Studio--and GitHub saw the use in extracting out the foundation and renaming it to something more generic.

## Fast forward

Most recently in May of 2016, Electron reached 1.0. In that time, people have pushed out cool projects such as [hyperterm][hyperterm]: an extensible terminal, [mojibar][mojibar]: a searchable reference for emoji, among other things. As a matter of fact, this post was written in [Simplenote][simplenote], an electron note taking app that features tags, markdown preview, and syncing across devices!

[hyperterm]: http://hyperterm.org
[mojibar]: https://github.com/muan/mojibar
[simplenote]:https://simplenote.com

I've only just started playing with Electron, but it seems a fantastic addition to a skillset you probably already have. Using my knowledge of HTML, CSS and JavaScript to bundle an application that can be used by members of all operating system ecosystems? Sounds good to me!


Create native applications using HTML, CSS and JavaScript

Electron


Today I was working on a new Magento 1.x install. A new install workflow usually goes like this:

- Download a zip of the newest Magento 1.x release
- Extract the contents into the folder of choice
- Update `app/etc/local.xml` to point to the correct database
- Add a new virtual host in my vagrant box pointing to the Magento 1.x folder of choice
- Install as necessary

That usually works fine, but today I was running into some issues. Everything looked fine, but the virtual host was throwing up 403 forbidden errors, leading me to think that there was some sort of permissions issue. Following the reference guides, I ran the following to make sure:

~~~bash
find . -type f | xargs chmod 400
find . -type d | xargs chmod 500
find var/ media/ -type f | xargs chmod 600
find var/ media/ -type d | xargs chmod 700
chmod 700 includes
chmod 600 includes/config.php
~~~

After that, reloaded the page, and ... nothing. I then ran `ls -la` inside the folder of the Magento install to make sure the `chmod` changes occurred, and noticed:

~~~bash
---snip---
-rw-r--r--@   1 dstrunk  staff    2329 Oct 27  2015 index.php.sample
---snip---
~~~

What's that `@` symbol? I'd never seen that before. Looking it up, I found that the `@` symbol represents a file or directory that has extended attributes. If you run the command `xargs -l <filename>`, you will see these attributes in the form of a reverse domain name; something like `com.apple.attribute`.

In my case, all files in my unzipped directory contained the attribute `com.apple.quarantine`. This is a feature that flags the content as having come from a potentially untrustworthy source. That's all well and good, but how do we remove this attribute? Pretty simple, it turns out. Simply run the following within the folder you're looking to unquarantine:

~~~bash
xattr -dr com.apple.quarantine .
~~~

All that said, my issue ended up being an improperly configured Vagrant configuration... but that was a good learning experience :).


Troubleshooting weirdly specific mac permissions issues

Removing com.apple.quarantine


As part of my ongoing "Operation Switch to Emacs" initiative, I've tackled handling resizing splits without touching the mouse. Of course, to create a horizontal split you'll press `C-x 2`, and to open a vertical split you'll press `C-x 3`.

From there, the default Emacs functionality for resizing splits gets ugly. To enlarge the window you can press `C-u 6 C-x ^`, where the number 6 is the row size you're looking to resize to. To shrink, you'll put a negative before the number: `C-u - 6 C-x ^`. Pretty gnarly, to say the least. Instead of this, I've mapped Ctrl + Meta + hjkl (vim direction mappings) to resize accordingly. It's a bit wonky since it resizes according to the window you opened from, but it's a lot easier to remember than the aforementioned key combo:

~~~lisp
(global-set-key (kbd "M-C-h") 'enlarge-window-horizontally)
(global-set-key (kbd "M-C-j") 'enlarge-window)
(global-set-key (kbd "M-C-k") 'shrink-window)
(global-set-key (kbd "M-C-l") 'shrink-window-horizontally)
~~~


Resizing splits in Emacs


My [dotfiles config][dotfiles] is my baby. In its year of active development, I've switched jobs, setup a work laptop, and setup two laptops at home to work on special projects with. I've tested the waters with switching from vim to emacs, and I've bounced between Ruby on Rails, Magento in PHP and, most recently, Phoenix and Elixir work.

It can be argued that spending too long on configuration is not a good use of productivity, and that is a fair point... to a point. For me, though, I feel that comfort with your configuration allows you to stay in your editor longer, which makes you more productive in the long run. Plus, it's fun!

Here are some tactics I use to maintain my dotfiles.

## Git submodules

While most of my dotfiles are hand-crafted, there are some parts that I'd rather leave to those more involved. For example, within the `emacs/` folder, I use Harry Schwartz's very handy [sensible-defaults.el][sensible]. These sensible defaults take care of things like ensuring files end with newlines, enabling syntax highlighting, defaulting the line-length to 80 characters, and other things that you would expect / like to have in an editor.

**Another example:** I use [dotbot][dotbot] to handle the actual act of symlinking my dotfiles folder into capital DOT `.dot files`.

To that point...

## Dotbot

[Dotbot][dotbot] is fantastic for maintaining my dotfiles configuration. It expects a manifest of sorts, called `install.conf.yaml`, that symlinks your files to their expected location in your home folder. Using dotbot to manage the symlinking has allowed me to better separate my dotfiles repo based on concerns. It also allows you to run post-install hooks, like `git clone`ing a repo or running other shell commands after the symlinking is complete.

## To Do lists

I've found maintaining a to-do list for my dotfiles beneficial to ramping up my productivity within editors. If I'm not pleased with how something is working, I'll make a note to either learn how to do it better, or to setup something to fix it. For example, in emacs I want to resize splits similar to how I manage them in tmux (either shift + arrow keys or ctrl + arrow keys). I made a note of this, then came up with the below script a little later:

~~~ lisp
    (global-set-key (kbd "M-C-h") 'enlarge-window-horizontally)
    (global-set-key (kbd "M-C-j") 'enlarge-window)
    (global-set-key (kbd "M-C-k") 'shink-window)
    (global-set-key (kbd "M-C-l") 'shrink-window-horizontally)
~~~

This allows me to resize windows using Ctrl + Meta + hjkl (using `evil-mode`, this combination feels very familiar).

[dotfiles]: https://github.com/dstrunk/dotfiles
[sensible]: https://github.com/hrs/sensible-defaults.el
[dotbot]: https://git.io/dotbot


Using dotfiles to maintain parity between workstations

My dotfiles


Normally when you're pushing to a remote repository, you want it to reflect the
name you specified locally. In some fringe cases, though, you'll need a
different name to explicitly state that this branch is a "scratch" branch that
shouldn't be used.

To push to a remote branch that needs to be a different name than your local
branch, separate your local and remote names with a colon:

```bash
git push origin local:remote
```


How to push to a remote branch with a different name than your local branch

A branch by any other name


I recently decided to force myself into an immersion program with both
[Emacs][emacs] and [Elixir][elixir]. I reformatted the machine I was using to
learn [Arch Linux][arch], reinstalling with only the necessities--Emacs, Elixir,
Phoenix, Node and Git.

Instead of falling back on trusty Vim, I'm slowly accepting that I know nothing
on this machine and diving in. First up is Emacs--I can't expect to get around
in Elixir if I can't move around in the text editor!

At their cores, Emacs and Vim have one thing in common: users don't know how to
exit them when they first open them. For Vim, it ends up being `:q`, and, as I
have now learned, for Emacs, it's `C-x C-c`, or control + x, control + c. Emacs
is all about key chords, or two keys pressed simultaneously.

With the idea of chords in mind, let's get moving in Emacs. In Vim you'd use `h`,
`j`, `k` and `l` to move left, down, up and right respectively. In Emacs, the
idea is similar enough (the right way isn't arrows, and if you do it wrong we
will all laugh at you). Here are the key combos:

``` bash
C-p # up, or PREVIOUS
C-b # BACK
C-f # FORWARD
C-n # down, or NEXT
```

[emacs]: https://www.gnu.org/software/emacs/
[elixir]: https://elixir-lang.org
[arch]: https://www.archlinux.org


Learn basic chords for moving around in Emacs

Get moving in Emacs as a Vim user


Automatically tweeting after posting a new blog entry with Jekyll doesn't need
to require complicated development scenarios full of git post-commit hooks, API
keys or registering apps with Twitter. It might feel a little low-tech, but all
you need is [IFTTT][ifttt] and some knowhow.

First, get a link to your RSS feed. If you don't have RSS set up for your Jekyll
instance, you can grab a sample from [snaptortoise/jekyll-rss-feeds][rss-feeds].
Next, sign up for IFTTT and create a new recipe. You'll need to link your
Twitter account as an action for the recipe, and you should have default values
to add the title and the URL of the post. Activate the channel, and your good to
go on that front.

Now, when you post an article to Jekyll, a few moments later the RSS feed should
be picked up via IFTTT and your post will kick off on Twitter.

[rss-feeds]: https://github.com/snaptortoise/jekyll-rss-feeds
[ifttt]: https://ifttt.com


Learn how to automatically post from Jekyll to Twitter

Autopost from Jekyll to Twitter


I'm learning Emacs. There, I said it. After being a Vim user for about a year
and a half, I'm going to try out the dark side. Here are some of the resources I
am using to get my editor setup so it's not so much "oh my god I don't know how
to exit out of this program" and more "okay, evil mode will save me if I get too
in the deep end, but I'm giving this a shot".

- [How to Use Emacs, an Excellent Clojure Editor][braveclojure]. Great resource
  that walks you through setting up your editor to resemble theirs. Borrow code,
  omit other parts, whatever. Fun note: Emacs is technically a Lisp interpreter,
  with all of its editing functionality written in its own Lisp dialect, Emacs
  Lisp. Perhaps this is why it's intriguing to Clojurists as an editor...
- [Magit][magit]. Billed as "a git porcelain inside Emacs". Comparing diffs is
  easy, and Magit has an interface for staging patches that is better than git's
  own (self-proclaimed).
- [Helm][helm]. Helm is a completion engine that matches anywhere in a name,
  instead of just the beginning (similar to CtrlP for us Vim users). Emacs
  ships with a default similar package called [Ido][ido] as of version 22, but
  many users prefer helm. Research both and see which one you like.
- [Evil-surround][evil-surround]. So I don't go completely crazy, evil surround
  is there to ease my transition. I heavily use [surround.vim by tpope][tpope],
  and evil-surround mimics that functionality.
- [Evil-args][evil-args]. Another package to ease me into the water, evil args
  sets up motions and text objects similar to how Vim views method arguments.
- [Sensible Defaults][sensible]. [Harry Schwartz][hrs], of
  [thoughtbot][thoughtbot] ilk, while probably the only Emacs user in the
  thoughtbot company, follows thoughtbot's standards of goodwill towards the
  open source community. He's open sourced sensible defaults for Emacs which
  make the user more comfortable with this new and wonderous and frightening
  editor.

## Miscellany

\* I've been a pretty heavy Vim user for the last year and a half or so. Using Vim
and Tmux (or a similar terminal multiplexer, e.g. screen), it's possible to
achieve a very fast workflow with a good testing feedback loop necessary for
TDD. By working alongside the videos provided by the good folks over at
[Upcase][upcase], my editor has become home, a place where I feel comfortable
making changes and seeing my results near-instantly. Check Upcase out today to
level up your TDD, Vim, Git and Rails skills.

\*\* The Vim and Emacs camps are largely divided on which is the best editor. Vim
users joke that Emacs is a great operating system, lacking only a decent editor.
Emacs users jest that Vim has two modes: "beep repetedly" and "break
everything". As two of the oldest continuously updated programs, it's
understandable why each editor has its zealots.

\*\*\* This post was written in Vim. Whoops, maybe next time :)

[braveclojure]: http://www.braveclojure.com/basic-emacs/
[magit]: http://magit.vc
[helm]: http://tuhdo.github.io/helm-intro.html
[ido]: https://www.emacswiki.org/emacs-test/InteractivelyDoThings
[evil-surround]: https://github.com/timcharper/evil-surround
[tpope]: https://github.com/tpope/vim-surround
[evil-args]: https://github.com/wcsmith/evil-args
[sensible]: https://github.com/hrs/sensible-defaults.el
[hrs]: https://github.com/hrs
[thoughtbot]: http://thoughtbot.com
[upcase]: https://upcase.com


Some good plugins for getting started with Emacs

Emacs


Today I set my computer up with [Homestead][homestead], a [Vagrant][vagrant] box
that sets up a development environment. Specifically, as of this post, it comes
with:

- Ubuntu 14.04
- Git
- PHP 7.0
- HHVM
- Nginx
- MySQL
- Sqlite3
- Postgres
- Composer
- Node
- Redis
- Memcached
- Beanstalkd

## Prerequisites

Setting up homestead is easy: first, download [Vagrant][vagrant] and a virtual
machine environment such as [VirtualBox][virtualbox]. After downloading, add the
Vagrant box `laravel/homestead` by running the following:

~~~ bash
vagrant box add laravel/homstead
~~~

## Installing Homestead

After those are setup, install Homestead by cloning the repository in your home
directory. Run the following:

~~~ bash
cd ~
git clone https://github.com/laravel/homestead.git Homestead
./Homestead/init.sh
~~~

Setup for Homestead doesn't take long. You'll find its setup in the
`~/.homestead/Homestead.yaml` file. This file defines folders to be synced from
your computer to the vagrant box--folders that contain your apps:

~~~ yaml
folders:
  - map: ~/Code
    to: /home/vagrant/Code
~~~

You then define sites:

~~~ yaml
sites:
  - map: homestead.app
    to: /home/vagrant/Code/Laravel/public
~~~

Finally, you need to remember to edit the `/etc/hosts` file on your local
machine. Add the following to map the above domain, "homestead.app", to the
vagrant box:

~~~ bash
192.168.10.10 homestead.app
~~~

That's it! Once all that is setup, run `vagrant up` inside the `~/Homestead`
directory. Vagrant will provision your machine with all the defaults you set in
your yaml file. I like this approach better than using tools like [MAMP][mamp] or the
like; it feels more portable, and I like the idea of being able to version
control an environment in case other developers need to jump on the project.
Tools like this and [Docker][docker] bring a level of parity between development
and production environments that is quickly approaching 1:1, which is a great
thing.

That's certainly not all you can do with Homestead; you can have a homestead
configuration per project, setup HHVM for some projects, use NFS file systems,
among other things. [Check out the full Homestead documentation for a full
rundown.][homestead].

[laravel]: https://laravel.com
[homestead]: https://laravel.com/docs/5.2/homestead
[vagrant]: https://vagrantup.com
[virtualbox]: https://www.virtualbox.org/wiki/Downloads
[mamp]: http://www.mamp.info
[docker]: http://www.docker.com


Setting up Homestead for Laravel development

Homestead for Laravel development


I'm taking a two-pronged approach to learning Elixir and Phoenix. The first is
educational: I've got books on both subjects from [The Pragmatic
Bookshelf][pragprog], and most recently, have been watching
conference talks. Specifically, this one here presented by Chris McCord, creator
of the Phoenix framework:

[RailsConf 2014 - Workshop - All Aboard the Elixir Express! by Chris
McCord][elixir-express]

On the other end of the spectrum, the practical: I'm working through all the
tutorials I can. This approach lent itself well to Ruby--a combination of
well-authored books and the Rails tutorial got me comfortable enough to figure
out how to stumble forward to the right answer. Which is 95% of what programming
is.

[pragprog]: https://pragprog.com/
[elixir-express]: https://www.youtube.com/watch?v=5kYmOyJjGDM


A good conference talk on Elixir, featuring @chris_mccord

All Aboard the Elixir Express


I've been watching Jeffrey Way's [Laracasts][laracasts] recently--more
specifically, Object-Oriented Bootcamp--and became interested in a macro he used
to automate rote tasks such as adding properties to constructor methods. I
believe he was using Sublime Text to handle his snippets and macros, but I
replicated (more or less) the same tasks with vim.

First, install the vim plugin [UltiSnips][ultisnips]. Next, create a snippet in
`~/.vim/UltiSnips/php.snippets`:

~~~bash
snippet _c "Constructor"
public function __construct(${1})
{
}
endsnippet
~~~

Now, add the following to your `.vimrc`:

~~~bash
let @a='lyF${iprotected ;^C^CPo^C^Cjjo$this-> = ;^C^CPlybbbblp'
let @b='lyF$k?protected^Moprotected ;^C^CPjjj%O$this-> = ;^C^CPlybbbblp'
~~~

Now, when you are in a PHP file, you can type	`_c` then `<tab>` to create a
constructor function. To add your first property, add your first argument to the
constructor then press `@a`. To add more properties, add them to your
constructor and press `@b`. For those interested, the second macro ensures that
your properties are ordered as expected.

Looking for more? Check out [my dotfiles][dotfiles] for other efficiency boosts
in your vim productivity.

[laracasts]: https://laracasts.com "Laracasts"
[ultisnips]: https://github.com/SirVir/ultisnips "UltiSnips"
[dotfiles]: https://github.com/dstrunk/dotfiles "my dotfiles"


Automate tedious object-oriented PHP tasks with vim

PHP constructor macros

Over the last couple of days, I've been prototyping a web application that I've
had an idea for ever since jumping into Rails. It was on the backburner for a
while until I could figure out how to handle such a dynamic UI... Then
[React][react] came out. React is providing exactly the functionality I'm
looking for—able to use components in a web application without hijacking the
entire view (a la Ember), and with a cleaner separation of concerns (looking at
Angular here).

It's been a while since I've dabbled in the front end, though—and the landscape
has changed. [Webpack][webpack], [Babel][babel], widespread adoption of ES6... I
was a bit overwhelmed for a couple of hours catching up. Because of this, I put
together a webpack starter kit to easily pull down when prototyping new React
projects:

[https://github.com/dstrunk/webpack-react-starter-kit](https://github.com/dstrunk/webpack-react-starter-kit)

[react]: http://facebook.github.io/react/
[webpack]: http://webpack.github.io/
[babel]: https://babeljs.io/

To get started with this project, clone it or download the zip from GitHub.
You'll need a couple of things from NPM, so run the following commands:

```bash
npm install -g webpack
npm install -g webpack-dev-server
```

After installing webpack and webpack-dev-server globally, run the following to
install package dependencies:

```bash
npm install
```

From there, you can simply run `npm run start`. This command (seen in our
`package.json` file)

- starts an `http-server` running our local directory on port `8080`
- starts `webpack-dev-server` on port `8090` which serves the
  `webpack-dev-server` runtime and our `app.js` file

... and that's it! Once setup, you'll have an environment that allows you to get
started quickly with prototyping React applications, and keeps productivity high
by watching files and refreshing when necessary.


A webkit React starter kit

Over the weekend, I decided to take a page out of [thoughtbot's][thoughtbot] playbook and create a laptop script for provisioning a new development machine. [Their script][tb-laptop] is a shell app that installs common utilities for web development, including [homebrew][brew], [rbenv][rbenv], [git][git], [postgres][postgres], and [redis][redis], among others. I love the idea of [automating all of the things][automate-job], so I decided to piggyback onto their idea and create a laptop script of my own.

[thoughtbot]: //thoughtbot.com
[tb-laptop]: //github.com/thoughtbot/laptop
[brew]: //brew.sh/
[rbenv]: http://rbenv.org/
[git]: https://git-scm.com/
[postgres]: www.postgresql.org/
[redis]: //redis.io/
[automate-job]: //dstrunk.com/2015/06/04/automate-yourself-out-of-a-job/

[Grab the script here][ds-laptop]

[ds-laptop]: //github.com/dstrunk/laptop

My laptop script is extremely similar to thoughtbot's version, with some minor differences. For example, thoughbot uses zsh for their shell, but I prefer bash. There are some other command line programs I neglected to include, as I don't use them, and I added in some minor tweaks to how the command line programs were installed. Honestly I could have just forked thoughtbot's script and edited it to fit, but I find I learn more if I'm not mindlessly copying or editing somebody else's programs.

Also available is my [local laptop script][laptop-locals]. This script makes use of homebrew's [cask][cask] to install applications (Evernote, Dropbox and Chrome are notable examples). In addition to these apps, my local script clones [my dotfiles][dotfiles] and installs them via [rcm][rcm].

[cask]: http://caskroom.io/
[laptop-locals]: https://github.com/dstrunk/laptop/blob/master/laptop.local
[dotfiles]: https://github.com/dstrunk/dotfiles
[rcm]: http://thoughtbot.github.io/rcm/rcm.7.html

With all of this automation, a new computer can be setup with my familiar defaults within minutes. Simply download the laptop zip file from GitHub, `cd` into the unzipped folder, and run the following:

```bash
./laptop
```

Automated provisioning is great. This script takes the worry and dread out of setting up a new computer and hoping everything was taken care of, and allows for quickly getting started from scratch.


Automated laptop provisioning using bash

Recently somebody at work came to me with a scenario:

"Daniel, at least once a week I have to take screenshots of movies and upload them to a proprietary server. I also have to take these screenshots and make thumbnails that are 150 pixels wide. Do you know of any way to automate this?"

My thoughts screamed "HELL YES I CAN AUTOMATE ALL THE THINGS!" while my more politically correct mouth served up a "Sure, let me look into that for you." Ten minutes later, I had a rudimentary script up that could do in less than a minute what normally would have taken him almost two hours. Let that sink in for a bit. Two hours per week spent on a project. Eight hours a month. 96 hours a year. **2.2 work weeks a year saved with less than 100 lines of bash scripting.** The benefits might not be felt immediately, but two weeks saved is nothing to sneeze at, in my opinion. With a bit more work, I'd automated this process further, allowing him to simply drop files into a folder, cutting me out of the equation completely.

In 1969, a computer no more powerful than a graphing calculator took three men 356,000km into space and plopped them down on the moon. Even more amazing than these men making it to the moon with that technology is the converse: millions of workers manually running processes using computers 100 times more powerful than the Apollo 11 that could easily be automated! The sheer number of man-hours wasted per work week either because nobody has questioned the status quo, or nobody has been properly trained is astounding (and more than a little scary).

If you're reading this and find yourself thinking, "I'm sure *insert job here* that I do could be automated," do it! It's a lot easier than you think. With today's technology, the answers are a Google search away. And if you're scared of **actually** automating yourself out of a job, don't be! Can you imagine how good your resume would look? "I completely automated this job at my previous place of employment, saving untold man-hours and a considerable cost savings."

## The script

For anybody interested in the technical bits of the story above, here's a link to the script I wrote:

[Screenshot and resize script][screenshot-resize]

[screenshot-resize]: https://gist.github.com/dstrunk/7f0e5d2561ae50d1282a

It's written for bash v. 3.2.53, which is a UNIX shell and command language that comes standard on all Macs.

To run, save the gist as something (mine is named `convert.sh`). Follow the instructions at the top of the file, including installing [brew][brew], [ffmpeg][ffmpeg] and [imagemagick][imagemagick] if you haven't already. Then, create a folder, `cd` into said folder, and drop your `convert.sh` file into there.

To run, type `./convert.sh` into your terminal. The script will then wait for you to drop any movie file into the folder. From there, the script will take a screenshot at 00:00:03 timestamp and drop it into the `/screenshots` folder, take a 150px wide screenshot and drop it into `/screenshots/150` folder, then move the movie into the `/completed` folder.

After 24 hours, the script will remove the files so your file system doesn't get too cluttered. This part is accomplished by utilizing bash jobs, which will run a delete script after 24 hours without blocking the rest of the script.

If you run into any problems, look at the logs! The script will output all of the log info from ffmpeg and imagemagick to a .log file.

[brew]: http://brew.sh/
[ffmpeg]: https://www.ffmpeg.org/
[imagemagick]: http://www.imagemagick.org/


Automate yourself out of a job


I haven't blogged in a while, and there's a reason for that: I'm working on combining my portfolio and blog into one site over at [danielstrunk.me][danielstrunk]. Recently, however, I was working on a WordPress layout, and built out something that could help others in my situation... and I couldn't wait to publish it on the new platform!

[danielstrunk]: http://danielstrunk.me

When building themes, I like to use [Advanced Custom Fields][acf]. It is a fantastic plugin that allows for custom meta fields to be quickly defined while easily retaining that WordPress look. It's quite a powerful plugin that I like to use in conjunction with custom post types such as portfolios, as they usually have a lot of bespoke needs.

[acf]: http://www.advancedcustomfields.com/

**Advanced Custom Fields Pro**, ACF's newest update, has some great features like [flexible content][flex-content]. I'm able to build a theme that feels like a powerful CMS while still retaining relatively tight control over the layout. First, check out the flexible content's [awesome documentation][flex-content] to understand the below code.

[flex-content]: http://www.advancedcustomfields.com/resources/flexible-content/#template-usage

With ACF's flexible content, I defined a series of layouts for a portfolio. The portfolio would allow for text, single images, image galleries, callout text, and quotes. With these six content areas defined, I created my first pass at a portfolio layout:

~~~ php
<?php if (have_rows('section')) : while (have_rows('section')) : the_row(); ?>
  <?php if (get_row_layout() == 'text') : ?>
      <?php get_template_part('templates/portfolio/text'); ?>
    <?php elseif (get_row_layout() == 'single_image') : ?>
      <?php get_template_part('templates/portfolio/single-image'); ?>
    <?php elseif (get_row_layout() == 'image_gallery') : ?>
      <?php get_template_part('templates/portfolio/image-gallery'); ?>
    <?php elseif (get_row_layout() == 'callout_text') : ?>
      <?php get_template_part('templates/portfolio/callout-text'); ?>
    <?php elseif (get_row_layout() == 'quote') : ?>
      <?php get_template_part('templates/portfolio/quote'); ?>
    <?php endif; ?>
<?php endwhile; endif; ?>
~~~

Look at all that duplication! There has to be a better way. There's repetition galore, and if I add another flexible content section on the backend, I'd have to add yet another conditional to my layout in addition to a new template. We developers are a lazy bunch, so I knew there was a better way. And there is: through [polymorphism][wiki], we can define a generic function and have it Just Work&trade; with any number of new layouts.

[wiki]: http://en.wikipedia.org/wiki/Polymorphism_%28computer_science%29

First, I borrowed heavily from [Rails for parameterization][parameterize] (virtually a one-to-one Ruby to PHP translation, in fact):

[parameterize]: http://apidock.com/rails/ActiveSupport/Inflector/parameterize

~~~ php
<?php
function parameterize($string, $sep = '-') {
  $parameterized_string = preg_replace("/[^a-z0-9\-]+/", $sep, $string);
    $parameterized_string = preg_replace("/$sep{2,}/", $sep, $parameterized_string);
    $parameterized_string = preg_replace("/^$sep|$sep$/", '', $parameterized_string);

    return strtolower($parameterized_string);
}
...
~~~

I place this function in `functions.php`, or wherever you need to define your helpers. This function allows me to take any string and return a dash-separated version of said string, with all spaces and special characters removed (`aren't regular expressions fun?!` turns into `arent-regular-expressions-fun`).

From here, I revisited my conditional-heavy layout:

~~~ php
<?php if (have_rows('section')) : while (have_rows('section')) : the_row(); ?>
  <?php $layout = parameterize(get_row_layout()); ?>
    <?php get_template_part('templates/portfolio/' . $layout); ?>
<?php endwhile; endif; ?>
~~~

**MUCH** better. The only thing I have to worry about now is making sure the flexible content I've defined has the same (parameterized) name as my template partial. This makes it easy to add new flexible content areas, and ensures my template partials are named in a logical manner.

Hope that helps somebody that finds themselves in a similar situation... Do your part to decrease duplication in the WordPress community! :)


Replace conditional with polymorphism in WordPress themes and Advanced Custom Fields

While trying to drag a WordPress install into the 21st century for the last week or so, I've been working with [Vagrant][vagrant], among other things, to bring parity to a development-vs-production environment. But Vagrant was kind of a black box to me... it worked (and nicely, I might add), but I had no idea how it did what it did, and why *exactly* I should use it instead of just downloading MAMP.

[vagrant]: //vagrantup.com

So, I Googled. Extremely literally: "What is Vagrant?" And one of the first results was what really got my brain to click:

http://24ways.org/2014/what-is-vagrant-and-why-should-i-care/

Instead of rehashing 24 ways' content, I'll leave it up to you, dear reader, to check out the above link to learn more about Vagrant (oh no, my bounce rate!). Truth is, the author Darren Beale groks Vagrant better than my two-week old experience, and the article has a great primer / tutorial on getting started (with downloadable files to boot!).

**Sidenote:** [24 Ways][24ways] is a great site with topical UI/UX, front- and back-end developer content, self-described as an "advent calendar for web geeks." Highly recommended.

[24ways]: //24ways.org/


What is Vagrant?

If you've ever done work for a government, financial or B2B organization, you might find yourself needing to support Internet Explorer 8. I know, I know: you've made your case for dropping support, pointing out that [large][salesforce] [SaaS][zurb] [companies][google] are dropping support (or dropped support years ago), Microsoft itself is [dropping support soon][microsoft], development time could double, etc. But higher ups point out that 10+% of users are locked into IE8, and until corporate IT is able to justify OS upgrades, we're stuck.

[salesforce]: http://www.zdnet.com/article/salesforce-to-drop-ie7-and-ie8-support-in-may-2015/
[zurb]: http://zurb.com/article/1265/ie8-is-going-the-way-of-the-dodo-so-why-s
[google]: http://thenextweb.com/google/2013/09/16/google-analytics-to-drop-internet-explorer-8-support-at-the-end-of-2013/
[microsoft]: http://www.techtimes.com/articles/12722/20140811/17-months-until-ie8-support-ends.htm

Don't fret too much. It's still possible to create a modern site and provide a pretty decent user experience on these older browsers, with some caveats. It probably won't be a completely 1-to-1 experience from IE8 to a modern browser, but it should be enough to allow you to develop using best practices going forward while creating a not-completely-hideous result in IE8. Here are some of the tools you'll need in your toolbox:

* [HTML5 Shim][html5-shim] - Adds browser support for HTML5 elements, including `header`, `footer`, `aside`, `main`, and others.
* [jQuery 1.x][jquery] - the 1.x versions of jQuery have promised support for Internet Explorer 6, 7 and 8. This gives us the jQuery we're all used to with a guarantee our JavaScript should Just Work.
* [Selectivizr][selectivizr] - adds CSS3 selectors for IE. This can be important if you're using a grid framework that makes use of `nth-child` to clear elements, for example.
* [RespondJS][respond-js] - a polyfill for CSS3 media queries. This is important if you're building a mobile-first website, as IE6-8 don't support media queries.
* [ES5 shim (and optionally ES5 sham)][es5-shim] - **ES5 shim** monkey patches JavaScript to contain ES5 methods that can be faithfully emulated. **ES5 sham** monkey patches other methods as closely as possible, or allows them to silently fail instead of causing runtime errors. *Use ES5 sham at your discretion.*

[html5-shim]: http://www.paulirish.com/2011/the-history-of-the-html5-shiv/
[jquery]: http://jquery.com/download/
[selectivizr]: http://selectivizr.com/
[respond-js]: https://github.com/scottjehl/Respond
[es5-shim]: https://github.com/es-shims/es5-shim

The next two links are especially handy. They allow for some nicer CSS decoration techniques that we've become used to that otherwise wouldn't be possible on legacy browsers.

* [CSS3 PIE][pie] - This polyfill adds support for `border-radius`, `box-shadow`, and `linear-gradient`. Yes, you can still have depth and detail in your IE8 designs!
* [Background cover][background-size] - Useful for full-container images. This will ensure your `background-size: cover` or `background-size: contain` behaves as expected.

[pie]: http://css3pie.com/
[background-size]: https://github.com/louisremi/background-size-polyfill#readme

In addition to the links above, you'll most likely have to make consessions for IE8 in your CSS. Things like a margin not working will have you climbing up the walls! Here are some common ones that I've come across:

* [Top margin doesn't work in IE8][top-margin] - This is a [known bug][top-margin-bug], and a pretty easy fix. Just add `overflow: auto` to the clearing div.
* **I want to add a transparent div / blur / shadow!** - Here's a fun one. IE CSS has a property called `filter`. This property accepts several attributes, all noted [here][ms-filter]. A good reference I found for transparent backgrounds in particular is on [CSS Tricks][css-tricks]. These will definitely muck up your stylesheets, but if you want to provide a better user experience for your IE8 users, this is one of the ways.

[top-margin]: http://stackoverflow.com/questions/13911010/top-margin-doesnt-work-in-ie-8
[top-margin-bug]: http://www.inventpartners.com/ie8_margin_top_bug
[ms-filter]: https://msdn.microsoft.com/en-us/library/ie/ms530752%28v=vs.85%29.aspx
[css-tricks]: https://css-tricks.com/rgba-browser-support/

I'm working on a rather large project redesign that needs IE8 support, so I'm sure I'll find more issues in the future. But for now, the above tips and hacks have definitely kept me sane as I build out a modern experience that needs to support outdated browsers.

Now, you might have no real choice in supporting IE8 if you're in the public sector or financials. But if you're a freelancer? Make the same case for dropping support at the top of this article, and also charge double for IE8 support and testing :)


Polyfills and shims for IE8 support

I'm working on an updated version of our company's online styleguide at work, and wanted to modernize it by introducing [Bower](//bower.io/) and [Gulp](//gulpjs.com) into the build process. This will make it easier to update and share with other developers as our team grows.

Early in the process, I ran into a problem: I wanted to include [normalize.css](necolas.github.com/normalize.css/) via bower, then include that in the Sass stylesheet. The issue with this is, normalize is a CSS file. Including this file in Sass results in a CSS `@import 'normalize.css'` at compile time, which is not a best practice in most cases\*. We need the file to end with `.scss` or `.sass` to properly integrate it with our other Sass files.

After looking around a bit, I found a rather large [GitHub issue](https://github.com/sass/sass/issues/556), opened in October 2012, that is still pretty much unresolved. There are dozens of comments in the issue from people in similar situations as mine—using bower to import assets but not wanting the curent behavior.

Since the issue is now going on 3 years without any official fix, there were a couple of commenters showing how they approached a fix. I liked one of them, and now here it is!

## The fix

Say you're installing normalize.css like me. If you install via bower, the file will returned will be `normalize.css`. In order to add this asset to your sass file and have it compile correctly, you'll need the final file to be called `_normalize.scss`.

Knowing this, let's start. You'll need to create a `.bowerrc` file to configure Bower. Add this to the file:

~~~
{
    "scripts": {
        "postinstall": "./.bower-postinstall"
    }
}
~~~

Now, let's create the shell script `.bower-postinstall` referenced in the `.bowerrc`:

~~~
#!/bin/sh

if [ -f "bower_components/normalize.css/normalize.css" ]; then
	mv bower_components/normalize.css/normalize.css bower_components/normalize.css/_normalize.scss
fi
~~~

The `if` statement is just for peace of mind so future bower installs don't make bower complain of `no such file or directory`. One last thing—we'll need to make sure this script is executable. In terminal, type `chmod a+x .bower-postinstall`.

Now, install normalize.css through bower as usual:

~~~
bower install normalize.css
~~~

If everything worked out, you should be able to browse to *bower_components > normalize.css* and see `_normalize.scss` in place of the normal `normalize.css` file.

There are pros and cons to this approach. The good: you should be able to upgrade via bower with no problems as usual. The bad? This approach assumes knowledge of the folder structure of whatever component you're installing. This doesn't seem like a huge deal with one or two components, but if you have a lot of modules and / or the folder structure / file name on any of those modules changes, you'll have to deal with those in the `.bower-postinstall` script. This isn't normally a problem, but it's something to watch out for.

Hope that helps anyone in a similar position!

<small>*Occasionally you might see imports used in something like media queries, for instance, but it's usually a bad idea. CSS imports don't download concurrently, so if you **really** need to use an import, you might just want to stick to using two `link` tags instead.</small>


Changing CSS to Sass in Bower dependencies

The prevailing mantra with git, or any version control system for that matter, is "commit early, commit often." For the last year, I've been doing so, which is a Good Thing. And if I were to continue working as a team of one developer, that might be fine. But if you're looking to commit to an open source project like I am, you'll probably want to learn how to clean up your git commits so entries don't include "forgot to add file" or "stupid mistake". That's where squashing comes in.

Squashing commits, in simple terms, is pretty much what it sounds like—squashing together multiple commits into a single commit. That allows you to commit early and often (with mistakes, as things sometimes go), while still enjoying a clean, respectible git repository when you finally push your changes to master. How do you do it? Glad you asked.

Let's say you've made a few small commits, and want to make a larger commit out of them. You can use interactive rebasing to take care of this:

~~~
git rebase -i HEAD~4

pick 000001a Add files
pick 000002b Oops! Forgot to add files
pick 000003c Added external library to make changes easier
pick 000004d Large code changes that actually matter

# Commands:
# p, pick = use commit
# e, edit = use commit, but stop for ammending
# s, squash = use commit, but meld into previous commit
~~~

This command will tells git that you want to rebase the last four commits from where `HEAD` is to `HEAD~4`. From there you're taken to an editor with text in it, and an explanation of what can be done. Change your file to look something like the below:

~~~
pick 000001a Add files
sqaush 000002b Oops! Forgot to add files
squash 000003c Added external library to make changes easier
squash 000004d Large code changes that are worthy of a longer commit.
~~~

This essentially tells git to combine the all of the commits with the first in the list. Once saved, another editor pops up:

~~~
# This is a combination of 4 commits
# The first commit's message is:
Add files

# This is the 2nd commit message:
Oops! Forgot to add files
...
~~~

This file shows all of the previous commits, and allows you to modify the message of the squashed commits based on the rest of the commits involved. Edit the message as necessary, and [be explicit](http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message). Save the file and quit, and your commits will be successfully squashed!

If you run into conflicts during the rebase, they're usually pretty painless. Git is solid at leading you through: display the conflicting files, allow you to edit the files, `git add`, then `git rebase --continue` to resume the squashing process.

If you take a look at your `git log`, you'll see the history reflects your squash. Pushing to master will display to users only the history you want them to see—the meat of your commits, and not your mistakes.


Squashing git commits with rebase

I haven't worked with WordPress in quite a while. After working with Rails for the last year, I grew to dislike my WordPress deployment process—it was nonstandard, hard to manage separate instances, and perhaps worst of all, didn't utilize a VCS to the best of its ability.

Recently, however, I came across the [Bedrock WordPress Stack](http://roots.io/wordpress-stack/) from [Roots](http://roots.io). Bedrock follows the [12-factor app methodology](http://12factor.net/) (and specifically Roots' own brand of 12-factor, [Twelve-factory WordPress app](http://roots.io/twelve-factor-wordpress/)). Bedrock bakes in best practices for WordPress deployments, it allows for easy versioning of plugins or themes, and, thanks to Capistrano and Git, allows for easily rolling back any updates. Though it's not currently in Bedrock as of this writing, database management can be added easily as a Capistrano + WordPress CLI task. Using these tools, WordPress sites can enjoy a similar process to a modern development cycle: fork, commit, pull request, code review, merge.

Looking through Bedrock, I like what I see: development of WordPress as a web application framework instead of a one-off site. Things are repeatable, automated, and most importantly, versioned. Need to roll back a deploy? No problem. Want to merge changes after reviewing your staging deploy? Go for it! Instead of whiteknuckling a plugin or WordPress update, update everything via composer and run `composer update`. Push changes to the server, and if something breaks, roll back to the previous version!

Most important for me is onboarding time. Onboarding for my previous site at work would have involved several steps, different programs and a confusing review process. Now with a simple `setup` script, onboarding can take minutes of setup, allowing for more time familiarizing oneself with the codebase. So long, technical debt, hello productivity!

I've already begun migrating the work website to Bedrock's Capistrano + Composer + WP CLI stack, and development has been pretty painless. Perhaps the largest time sink has been migrating plugins to the `composer.json` file. Luckily, thanks to [WPackagist](http://wpackagist.org/), most of the plugins exist as composer packages, and only two premium plugins required additional configuration.

Bedrock is doing a huge service to the WordPress community, and I can see it being adopted as the standard for WordPress development. Hopefully as more people adopt it, the developer community at large will view WordPress sites on similar footing as more "professional" platforms.


Bedrock for modern WordPress deployment

At work I'm always looking for opportunities to work smarter, not harder. To cut out repetitive tasks that keep me from getting meaningful work done. That's what computers are for, right? Most recently, I grew tired with a gap in how we managed and tracked projects, and decided to do something about it.

## The impetus

Our old ways of working were driving me crazy. The workflow went:

* A customer wants a new project initiated.
* An email is sent to our division, stating the constraints: deadline, life of the project, etc.
* A member of our team sets up the project, and notes on their calendar when the project is nearing end-of-life.
* Once the project reaches EOL, we archive the project and begin again.

Obviously, emails between parties is not the most efficient means of communication, and it makes going back through past projects a nightmare. We could use an issue or project tracker, but we're currently in between systems and I couldn't wait that long. So, last weekend I decided to create an app that both provided visibility to managers and made coworkers' jobs more streamlined.

## The accidental state machine

The app was pretty simple; basic CRUD functionality, a couple of relationships, and a form that allowed users to submit new requests. There needed to be an admin area for managing the projects, as well as a dashboard for managers to see how many projects were live and their timelines. Along the way, I also wanted to store the status of a project: pending review, accepted, rejected, live, or archived. For this last part, edge Rails had me covered: `enums`.

Enums, or enumerated types, are a data type consisting of a set of named values of said type. You deal with them every day: For an `enum` WEEK, the named values are SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY and SATURDAY.

Newer versions of Rails have baked-in support for enums, which makes for easy creation of simple state machines:

~~~
class Project < ActiveRecord::Base
	enum :status, [:pending, :accepted, :rejected, :live, :archived]
end
~~~

with the `enum` attribute, you can now do things like this:

~~~
project.pending!
project.pending? # => true
project.status # => "pending"

project.accepted!
project.status # => "accepted"
~~~

To work with an enum from the database perspective, use an integer column. You can set a default status in the database as well (recommended for persistence):

~~~
create_table :projects do |t|
	t.column :status, :integer, default: 0
end
~~~

Now every project initialized will have a default status of "pending" unless otherwise specified.

**On to state machines:** I had no idea this is what I was creating... I simply saw a need, and enums looked to fit the bill. But as I dug deeper into my app, I realized I'd need mailers that triggered upon switching from one state to another, and some sort of history of the state switching. And of course, while searching the web I found that this is one of the oldest problems in the book.

There are plenty of gems that handle this much more elegantly than my stumbling about: [aasm](https://github.com/aasm/aasm), [workflow](https://github.com/geekq/workflow), and [statesman](https://github.com/gocardless/statesman). All are solid (though aasm is quite long in the tooth), but I decided to go with Go Cardless's statesman for my project.

I'm currently refactoring my app to work with statesman, but this was a good learning process for me. The app makes it easy to manage projects from the backend, it provides visibility to those-that-need-to-know, and, once the refactoring is complete, it will tidy up a once-cumbersome task.

[Check out the code that inspired this post!](https://github.com/dstrunk/tombstone)


Accidental simple state machine with Rails 4

Over the weekend I completed version 0.6 of my gem, [roboparts]. Roboparts is a command line tool that piggybacks on the Rails engine to create custom defaults that I use a lot when setting up new projects. To use, run `roboparts your-project` to build a customized rails framework with RSpec, FactoryGirl, and some other goodies already set up for you.

[roboparts]: https://rubygems.org/gems/roboparts

When setting up new Rails projects over the last couple of months, I realized I was spending a lot of time setting up a lot of boilerplate: installing gems,  generating the same scaffolds, adding test dependencies, and adding CSS or shared application layouts. Taking a page from one of my favorite development agencies, Thoughtbot, I decided to create a similar gem to their [suspenders].

[suspenders]: https://github.com/thoughtbot/suspenders

This was a huge learning experience for me. Writing a gem is something I'd always wanted to do, but found too daunting. I referenced the HELL out of suspenders, but am refining the gem as I learn more about the process.

If you're interested, check out [the source] for an idea of everything involved.

[the source]: http://github.com/silentpost/roboparts


Roboparts: configuring the Rails framework


http://jeffarchibald.ca/false-hustle/

This is a great article that hits home for me. It's easy to justify administrative tasks as Getting Things Done, when really we're just spinning our wheels.

Last year, I made an unofficial goal to hit 365 continuous days of GitHub commits (I have a similar goal this year). Initially, commits were dedicated to completing feature specs and finishing up an app. Towards the end, however, I became more focused on hitting the continuous commits, and not the reason for starting the goal in the first place: to complete apps!

A good way to avoid the "false hustle" is to look at your time from the standpoint of a developer. As developers, we look at a large problem, break the problem into smaller steps, and complete each step one at a time. These same principles should be applied to time management as well. Look at your day, break it down into manageable chunks, and attack it from that perspective. From there it becomes a simple matter to keep on task. Just ask yourself, "Is what I'm doing beneficial to the immediate chunk I'm working on?" If it's not, stop doing it, add it as a  feature spec to a different chunk of time, and get back to work!


Link: False Hustle

Hey everyone! It's a little late, but Happy New Year. Nothing too technical in this post, but I'd like to go over some of my goals for the new year.

## 2014: A retrospective

Last year, I began my journey into Ruby and Rails development.\* After learning the basics and going through tutorials for the first couple of months, I created my first basic app: A URL shortener. The app was/is riddled with errors, and suffers from no tests whatsoever, but I learned a lot of valuable information that carried over into other projects (namely, handling state, more interesting uses for writing to the database than simple CRUD apps, and dynamic redirects).

After creating this simple app, I began attempting a bear of a project. This project, while uncompleted, took me down the rabbit hole of form objects, service objects, proper testing practices, big O notation, and front-end JS frameworks. While the app itself never saw the light of day, it opened my eyes to a lot of computer science fundamentals that my graphic design background never would have introduced me to. I ended up with a lot of programming books, and reading more than I have since college.

## 2015: onward and upward

This year is more of the same in some ways. Of course the common resolutions are on my list (lose weight, go to the gym, etc. I'm basic)—but I'm also looking to build on last year's goal of diving deeper into web development. Here's the long and short list:

* I have a couple of apps that I **know** I can complete from my current skill level (TDD best practices included)
* I plan to rewrite my URL shortener, this time also employing TDD best practices.
* While freelancing, I plan on landing a client for which Ruby will be a good fit.
* My "bear of a project" will get some work—I want to create this app and nothing will stop me, no matter how long it takes :)
* Potentially apply to either a bachelor's or a master's program in computer science.

So there you go—onward and upward to 2015 and beyond! What kind of resolutions do you have for yourself?

\*<small>Note I said Ruby **and** Rails, not Ruby **on** Rails. While I love Rails, too many people ignore the fact that Rails is a framework, not a language. Perhaps it's a good sign that the framework is so strongly supported by the community that Ruby is ubiquitous with Rails, but I felt the distinction was necessary. **You are not your framework.**</small>


Happy new year!

I recently installed [Hub](https://hub.github.com/), a command line wrapper for git that pairs nicely with GitHub. Hub makes it easier to fetch repositories, navigate project pages and fork repos from the command line.

For Mac, installation is simple; if you have [Brew](http://brew.sh/) installed, it's as easy as typing `brew install hub` in the command line. From there, type `alias git=hub`, then test it out:

~~~
git version
=> git version 1.7.9
=> hub version 1.11.0
~~~

If you see anything like the above, then it works!

## Playing with Hub

Hub makes managing GitHub through the command line a LOT simpler. Take a look at some ways Hub can improve your workflow:

* Say you want to clone one of your projects (dotfiles, for instance). Instead of `git clone git://github.com/YOUR_USER/dotfiles.git`, you can simply type `git clone dotfiles`. If you've already configured git, Hub already knows who you are, so it smartly fetches your dotfiles repo from the server.

* If you want to clone somebody else's project, add the user's name before the project like this: `git clone another_user/dotfiles`.

* Say you want to look at all of the current project's issues... Just type `git browse -- issues` while in a project.

## An example workflow

"How will this help me as an open source contributor?" you might ask. Good question! Here's an example workflow:

~~~
git clone github/hub
cd hub

# create topic branch
git checkout -b ds-feature
  # making changes...
git commit -m "feature complete!"

# fork the repo
git fork

# push changes to remote
git push YOUR_USER ds-feature

# open pull request from your branch
git pull-request
~~~

That was easy! There's a lot more that Hub does, so I'd suggest reading the documentation neatly laid out at https://hub.github.com. In my opinion, Hub not only saves keystrokes, but makes understanding a typical GitHub workflow a lot easier to wrap your brain around. Try it today!


Hub for a better GitHub experience

One of the good (and bad) things about moving from shared hosting to a VPS is that I have full control over server settings. It might feel a little intimidating, but it's a much more rewarding experience when everything is working properly.

Today, I decided to set up a Jekyll blog for another site I'm cooking up. Not wanting to shell out for another droplet on Digital Ocean, I decided to set up a server block via Nginx using the same server this blog is hosted on. I'll reserve how I set up Capistrano and Jekyll to automatically update my site for another day... Instead, read on for what was most difficult for me.

### A crash course in nginx server blocks

Server blocks are pretty easy to understand once you get used to the syntax; here's an example of what one looks like:

~~~
server {
        listen 80 default_server;

        root /usr/share/nginx/html;
        index index.html index.htm;

        # Make site accessible from http://localhost/
        server_name localhost;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ /index.html;
                # Uncomment to enable naxsi on this location
                # include /etc/nginx/naxsi.rules
        }
}
~~~

This file can be called anything; for our purposes, we'll call it `example-site.com`. Typical nginx installs expect this file to be located in `/etc/nginx/sites-available/`. From there, you'll create a symbolic link to `/etc/nginx/sites-enabled/` to make the server block active:

~~~
ln -s /etc/nginx/sites-available/example-site.com /etc/nginx/sites-enabled/
~~~

You don't *need* to understand everything that's going on, I'll just focus on the relevant parts.

* First up is the `listen` line. `listen 80 default_server`, does pretty much what you might expect: Listen on port 80 for incoming connections, and let the server know that this is the default configuration. When having two server blocks, note that only one of these blocks can have the `default_server` part.

* Next is the `root [...]` line. This line tells the domain where your physical files are stored. Personally, I like to host my files in `var/www/example-site.com/`, where `example-site.com` is our target directory.

* Finally we've got the `server_name` line; for this one, you'll want to put in your domain address, something like this: `server_name example-site.com;`.

### A tale of two sites

It'll be easier to visualize this if you have two sites to work with. I like to host my sites in `/var/www/`, so let's set up two sites in this directory now. Create two directories under `/var/www/`, called `example.com/` and `test.com/`.

* Under `example.com/` directory, create a file called `index.html`, and put the following: `<h1>Example.com works!</h1>`.
* Similarly, under `test.com/` directory, create a file called `index.html`, and put the following: `<h1>Test.com works!</h1>`.

Now that your pseudo sites are set up, let's move to the server blocks to make sure everything gets wired up correctly.

#### Example.com block

Under `/etc/nginx/sites-available`, create a new file called `example.com`. In this file, paste the following:

~~~
server {
        listen 80 default_server;

        root /var/www/example.com;
        index index.html index.htm;

        server_name example.com;
}
~~~

Save your file, and create a symbolic link of this file to your `/etc/nginx/sites-enabled/` directory:

~~~
ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
~~~

#### Test.com block

Under `/etc/nginx/sites-available`, create another new file called `test.com`. In this file, paste the following:

~~~
server {
        listen 80;

        root /var/www/test.com;
        index index.html index.htm;

        server_name test.com;
}
~~~

Save your file, and create a symbolic link of this file to your `/etc/nginx/sites-enabled/` directory:

~~~
ln -s /etc/nginx/sites-available/test.com /etc/nginx/sites-enabled/
~~~

### Testing our config and troubleshooting

Now that we're all set up, run `service nginx restart` to make sure Nginx picks up any changes.

Let's switch to our local computer now. We obviously don't own the **example.com** and **test.com** domains, so we'll need to be clever about how we test our server blocks. That's pretty simple by editing our `/private/etc/hosts` file (assuming we're on a linux-based computer). Open up the file in the editor of your choice and add these two lines (replace `your.server.ip` with your server's IP address):

~~~
your.server.ip example.com
your.server.ip test.com
~~~

Save the file, then navigate to **example.com** in your browser. You should see **Example.com works!**

Navigating to **test.com** should show you **Test.com works!**

If for some reason either of the above options doesn't work, you'll need to troubleshoot. Best guess would be a syntax error in one of your server blocks. Semicolons are imperative to terminate lines—if you're missing one, the block will never properly direct the browser.

You should be all set from here. More advanced configurations are obviously possible—for example, I've currently got a NodeJS app, a Rails app, and a static site blog all hosted alongside each other.

Until next time!


Setting up multiple server blocks in nginx

Part of my day job involves designing and sending out email campaigns for various customers. On the whole it's a pretty painless job, with one sticking point: getting a properly sanitized email list of subscribers is hard. Depending on the client supplying the spreadsheet, any number of things could go wrong:

* duplicate entries
* empty lines
* malformed email addresses
* ALL CAPS ENTRIES / lowercased entries

In addition to these problems, the data usually doesn't come in a format that I need to upload to our campaign manager (Yes I know a CRM would mitigate all of these issues, but that's beside the point). Being the <del>lazy</del> resourceful Ruby developer I am, I created a simple script to parse a .csv list and output the information I'm looking for. I'll post it first, then go through and explain what the lines do.

~~~
require 'csv'

unless ARGV.length == 2
  puts "Sorry, incorrect number of arguments."
  puts "Usage: ruby parse.rb InputFile.csv OutputFile.csv\n"
  exit
end

ET_HEADERS = %w(Email\ Address Subscriber\ Key First\ Name LastName).freeze

new_list = []

old_list = CSV.read(ARGV[0], "r:windows-1251:utf-8", headers: true, skip_blanks: true).reject { |row| row.to_hash.values.all?(&:nil?) }

old_list.each do |row|
  new_list << row unless row["confirmed"] == "yes"
end

CSV.open(ARGV[1], 'wb') do |csv|
  csv << ET_HEADERS
  new_list.each do |row|
    csv << [row["email"], row["email"], row["fname"], row["lname"]]
  end
end
~~~

So how does this script work, exactly? It's pretty easy: open terminal and run `ruby parse.rb inputfile.csv outputfile.csv` (all names are self-explanitory, hopefully). Now to break down the blocks.

~~~
require 'csv'
~~~

This requires the `csv` library that comes standard with Ruby. Don't worry; it's not a gem, you don't have to download anything. Just include it at the top of your file.

~~~
unless ARGV.length == 2
  puts "Sorry, incorrect number of arguments."
  puts "Usage: ruby parse.rb InputFile.csv OutputFile.csv\n"
  exit
end
~~~

Here's some simple error handling. This script expects two arguments after invoking it in the command line: an input file and an output file. If the script detects anything more or less, it will exit with a nice but stern explanation why.

~~~
ET_HEADERS = %w(Email\ Address Subscriber\ Key First\ Name LastName).freeze
new_list = []
~~~

Here I setup a constant and a variable I'll be using down the road. `ET_HEADERS` is a constant that holds the headers the campaign manager needs to be properly uploaded. `new_list` is a variable instantiated with a new array; we'll be injecting the parsed contents of our old list into this array.

~~~
old_list = CSV.read(ARGV[0], "r:windows-1251:utf-8", headers: true, skip_blanks: true).reject { |row| row.to_hash.values.all?(&:nil?) }
~~~

This is probably the most complex part of the script, but it's not so bad. We're creating a new variable called `old_list`. In `old_list`, we use the CSV library to open up `ARGV[0]`, the first argument in our command line. The gnarly `r:windows-1251:utf-8` is telling Ruby to transcode whatever file format the csv file is into something it can work with; `headers: true` tells the file to include headers; and `skip_blanks: true` tells the CSV reader to (surprise!) skip blanks. the `reject` block tells the CSV reader that, for each row, if all values are nil, remove them completely.

~~~
old_list.each do |row|
  new_list << row unless row["confirmed"] == "yes"
end
~~~

Once a list has been screened for blanks, we'll throw them into the new array (`new_list` variable set up at the beginning). Here's where I'll add my edge-case conditionals. Things like "If a user has confirmed or RSVPed," or "If a user hasn't responded within a week."

~~~
CSV.open(ARGV[1], 'wb') do |csv|
  csv << ET_HEADERS
  new_list.each do |row|
    csv << [row["email"], row["email"], row["fname"], row["lname"]]
  end
end
~~~

Now that we've got our "sanitized" list, it's time to open a new CSV file. We open a new CSV file as specified in `ARGV[1]`, and begin building our new file. First, we add the `ET_HEADERS` to the first row. Then, for each array entry in `new_list`, we append the necessary columns to our new document.

## Future plans

The script is pretty basic at this point, but it does its job well. One problem I have with the script is it requires knowledge of the input script, and requires modifying appended columns based on the input CSV file. In the future it would be nice to build out a prompt that reads the headers of the input CSV, and allow the user (me) to select which rows I'm looking for (as well as potentially any conditionals to the input list to look for).

As it stands, however, it works great. List digestion has gone from a 15-20 minute job down to a 1-2 minute job, and with the amount of emails that come onto my desk daily, that's easily a 3-4 hours a week saved on processing lists. Not bad for 17 lines of code!


Automating CSV parsing with Ruby

Here are some links that I've found helpful over the last year or so. I'll keep this page updated as I come across other resources.

* [Railscasts](http://railscasts.com/) - Largely abandoned. Worth a "subscription"—because it's unmaintained, I've never been charged more than $9 in the year I've been learning from there. Great for beginners or people looking to understand core concepts better.
* [Go Rails](https://gorails.com/) - Screencasts for learning Ruby on Rails. Meant to take over for Railscasts' absence from the scene.
	* [Setup Ruby on Rails on Mac OS X 10.10 Yosemite](https://gorails.com/setup/osx/10.10-yosemite)
    * [Deploy Ruby on Rails on Ubuntu 14.04 Trusty Tahr](https://gorails.com/deploy/ubuntu/14.04)
* [Upcase by Thoughtbot](https://upcase.com) - Subscription-based learning by the respected Rails development company Thoughtbot. Quality videos, access to the Upcase forums, trail-based learning and access to the very Rails app Upcase runs on.


Links

> [Rails Rumble Gem Teardown](https://www.dwellable.com/blog/Rails-Rumble-Gem-Teardown)

This is a great resource for learning what people are using to quickly get their apps ready for their 48 hour hackathons. There's not a lot of suprising information here if you're plugged into the community.

**But**: if, like me, you happen to be a lone Ruby in the rough, it's nice to see what teams are using for bootstrapping an app, what templating / JavaScript languages devs are gravitating toward, and what CI environments are being used.


Link: Rails Rumble Gem Teardown

Happy Friday! Today I'll touch on a major pain point for people first starting to learn Vim: navigating file structures! Let's get started.

## Splits

One of the frustrating things I first encountered when switching from Sublime Text to Vim was losing my beloved splits. But I didn't lose them of course, I just didn't know how to access them. Splits are just as easy (if not easier) as Sublime Text, we just have to know how to do it.

To do splits in Vim, use the commands `:split` and `:vsplit`. Using the commands by themselves, you'll open either a horizontal or vertical split within the folder structure of the other file you've got open. You can go straight to editing a file if you know what you're looking for by typing `:split <filename>`.

Of course as a Vim nerd, you'll want to save keystrokes. The industrious of you might have already found that you can just type `:sp` or `:vsp` to take care of the same window splitting.

### Moving around those splits

Well you've gotten the splits open, so now what? well, let's move from side to side (Or up and down. Whatever.). to move from split to split, type `ctrl-w <arrow key>`. Nice!

If you want faster keystrokes, you can edit your `.vimrc` as I have. This will allow you to press `ctrl + <hjkl>`, where `h` is left, `j` is down and so on. Just like we're used to with navigating Vim typically. Here's the setup for that:

~~~
" Quicker window movement
nnoremap <C-j> <C-w>j
nnoremap <C-k> <C-w>k
nnoremap <C-h> <C-w>h
nnoremap <C-l> <C-w>l
~~~

While we're editing our `.vimrc`, let's also make it so new splits open to the right and bottom. That seems more natural.

~~~
" Open new split panes to right and bottom
set splitbelow
set splitright
~~~

### Switching a split's position

If you're OCD like I am, you'll want your spec either below your model / controller, or whatever your preference. To switch your splits up, type `ctrl-w R`. That will immediately move your bottom split to the top and vice versa (or left to right; whichever is the dominant split).

## Conclusion

Of course that is the tip of the iceberg (as with all things Vim). Here are some other resources to help you move around Vim in a way you might be more used to with other editors:

* https://www.cs.oberlin.edu/~kuperman/help/vim/windows.html
* http://robots.thoughtbot.com/vim-splits-move-faster-and-more-naturally


Moving around in Vim

> [80,000 Plaintext Passwords: An Open Source Love Story in Three Acts](http://www.confreaks.com/videos/4183-rmr2014-80-000-plaintext-passwords-an-open-source-love-story-in-three-acts)

This is an entertaining talk given at Rocky Mountain Ruby Conference in Boulder, CO this year. Presenter [T.J. Schuck](https://twitter.com/@tjschuck), a developer at [Harvest](http://getharvest.com), goes over some poor choices/hopefully not-so-common mistakes developers make when handling authentication / passwords in general. **Spoiler alert:** The long and short takeaway is [use bcrypt](http://bcrypt.sourceforge.net/). I love this quote by Schuck:

> By virtue of the fact that I *have* users, I **have to be** [a security] expert. Ignorance is not an excuse.

The presentation explains how authentication used to be handled (Plain text, hashed, hashed + salted, and finally bcrypt), and why bcrypt is a great choice for long-term maintained password protection.

I haven't watched the rest of the videos from Rocky Mountain Ruby Conf, but I'd suggest going through the library and picking out some other topics that interest you.


Link: 80,000 Plaintext Passwords: An Open Source Love Story in Three Acts

> [Rebuilding the Shopify Admin: Improving Developer Productivity by Deleting 28,000 Lines of Javascript](http://www.shopify.com/technology/15646068-rebuilding-the-shopify-admin-improving-developer-productivity-by-deleting-28-000-lines-of-javascript)

**The TL;DR:** Shopify created an internal JavaScript framework. This framework became unweildy, it became difficult to train new members of the team, and Shopify was forced to migrate back to a more traditional setup.

The above link speaks to me in so many ways.

While reading the article so many things made me want to pull out my hair. First was the creation of the internal framework in the first place. My contention is this: why, with so many [solid](http://backbonejs.org/), [battle-tested](http://emberjs.com/) [frameworks](http://angularjs.org/), is Shopify trying to reinvent the wheel in the first place? Furthermore, why, after finding that their internal framework didn't work out, would they go back and do it again?!

### Technical debt

Aside from those little quibbles, the actual message of the article is pretty good. Technical debt is a Big Thing&trade;. If management can't be concerned with fixing technical debt, it would be good to make them aware of the problems associated. Technical debt:

* Makes it harder to train new employees on said application
* Makes new features difficult to add
* Makes the app difficult to maintain
* Slows down development
* Usually has performance hits due to poor design choices

And those are just the cost-associated reasons to fix tech debt. Psychologically, technical debt can be draining. Imagine coming in to work everyday and working on a slow, unmaintainable, terribly-built application. It wouldn't be a big leap to imagine a company in this position having a high turnover rate and low morale. In short, technical debt is bad and you should fix it as soon as possible.


Technical debt must be paid

I've been on shared hosting for the better part of 10 years now. My first servers were on [1and1](http://www.1and1.com/), and more recently, [Dreamhost](http://www.dreamhost.com/). To their credit, both hosting providers did their jobs admirably, making it easy for me to setup and host WordPress sites with ease. However, their shortcomings revealed themselves as I began wanting to serve anything other than a PHP-based stack. Rails applications were possible, but tricky to setup. Ruby versions were out of date, with no way to update. Node apps were a no-go (unless you upgraded to their more expensive VPS services).

Over the weekend, I decided to finally take the plunge and move from shared hosting to a VPS—namely, [DigitalOcean](https://www.digitalocean.com/). Along with that move, I decided to forego WordPress and migrate everything over to [Ghost](http://ghost.org).

## First thing's first

To move from WordPress to Ghost, you'll need a plan of attack. Your checklist should include the following:

* Migrate comments to [Disqus](https://disqus.com/)
* Migrate images to [Cloudinary](http://cloudinary.com/) (using Cloudinary's WordPress plugin, this is dead simple)
* Generate a Ghost JSON file to import into Ghost (using Ghost's WordPress plugin this is easy as well)

DigitalOcean has handy one-click installs of common stack-related setups, as well as your run-of-the-mill WordPress installs, a Ghost install, etc. As I have a couple of different configurations necessary, I went with a **LEMP** stack—Linux, Nginx, MySQL and PHP.

Not wanting to [leave my visitors in the dust](http://dstrunk.com/2014/08/12/site-updates-301-redirects/), I went through the entire site and noted all of the URL changes that would occur with Ghost, creating a lengthy rewrite file for Nginx.

## Setup

After taking care of the preliminary work above, setup was pretty straightforward. One of the strongest things going for DigitalOcean is their community forums and tutorials. For setting up Ghost with Nginx, I followed [this tutorial](https://www.digitalocean.com/community/tutorials/how-to-host-ghost-with-nginx-on-digitalocean). As I'd already selected the LEMP stack provided by DigitalOcean, the only to-dos were installing [NodeJS](http://nodejs.org/) and configuring [Upstart](http://upstart.ubuntu.com/) to automatically start / restart if the server goes down.

The only place I really deviated from the tutorial: I am planning on hosting a couple of different websites on this server, so I decided to choose a different folder to install ghost to, and specified said directory in my Nginx setup.

## Sharing

One thing I missed from WordPress is its plugin support for auto-posting to Twitter / LinkedIn / whatever. No worries, though; we're a resourceful bunch, and we can figure that out.

What I did is set up a couple of [IFTTT](https://ifttt.com) recipes. Add a new recipe that says, "If a new RSS item is posted, submit a link to *social network of your choice*." Pretty simple!

## In summary

I'm very happy with my current setup. Linux + Nginx is very amenable to all sorts of configurations—Node, Rails, and PHP have all run side-by-side on my new server at one point this weekend.

Have any questions? Comment below!


Migrating from WordPress to Ghost


Back when I was first getting into front end development, I used [CodeKit](https://incident57.com/codekit/) to handle optimizing all of my assets. It was great; it compiled my Sass files to a single stylesheet, minified JavaScript, and optimized images. As I dug deeper into development, I decided to drop CodeKit in favor of new hotness: Grunt, Gulp, and all those CLI programs that handled the same things for free and with only minimal configuration. Grunt and similar tools are great because they allow for task runners that can be community submitted. Despite a full range of community-supported tasks, I found I was only running the common things: Sass compilation, minifiers, and optimizers. So while it was nice having the option of a broad range of features, I didn't really need them.

### Tedium sets in

 Almost two years later, I'm back to CodeKit. Last night, I was setting up a front end project, and was dreading setting up yet another project with Grunt. Installing and managing dependencies, making a Gruntfile, and dealing with an ugly user experience (IMO, of course). I remembered how painless CodeKit was in the past, so I decided to check out their site on a whim. And, well, it's gotten so much better! CodeKit 2 has been rewritten from the ground up with some great features. It's got Bower support for easy asset installation in addition to the usual minification, concatenation, and image optimization you'd expect. having a beautiful GUI is icing on the cake. Add to all that the fact that you get a discount if you've bought a previous version of CodeKit, and I was sold (again). I downloaded CodeKit, dragged my new project folder into CodeKit, and was ready to start developing. I'm certainly not knocking Grunt, Gulp, Broccoli, or [insert task runner of choice here]. And I'm certainly glad I gave them all a go—those experiences mean I will at least be familiar with the setup if I pick up a project somebody else has set up. But for the foreseeable future, I'm sticking to CodeKit, which makes front end development a breeze. [Check it out](https://incident57.com/codekit/)!


CodeKit 2 for front end development


Short on code or examples today, but this topic is just as (if not more) important than any code I could come up with. It's extremely easy in Rails to create a basic CRUD app that fulfils business needs or scratches a developer's itch. But I think that many people get so focused on the "I have an idea let's build it NOW" mentality, that the user's experience gets left in the dust. Sure, the code behind your app is incredibly important. But the design of your application is the **most** important thing; not just the look and feel of the app, but how it works.

### Have a roadmap

 Before ever getting started with building an app, it's important to have a roadmap, and design will help drive that. A storyboard of the critical path of your app will influence forms, URLs and relationships between your data. With a well-defined roadmap, the development of your app becomes almost trivial, as the design will mostly out any pain points you might come across. In my rush to learn Rails, I've been guilty of this more than a couple of times. It can fly when you're building out a simple URL shortener, or a signup / payment form for a physical event, but as the app grows in complexity, not having a roadmap will break you.

#### Plan your URLs

 This is a subheader in the whole design roadmap, but I think it's very helpful to think about in the beginning. Because your app probably doesn't need all of the resources available in a controller; maybe you just need an overall view, or maybe you just need a way to create and edit.

### Study existing codebases

 This is probably helping me the most right now. As I said before, I [recently subscribed to Upcase](http://wp.me/p3ERzH-jc). One benefit of that program is they share the code that powers the Upcase app. I've gotten great ideas and plans from studying their strategy. Studying a mature app ([Discourse](https://github.com/discourse/discourse), for instance) can be a great way to gain insight into how your app needs to work while in the planning stages.


Get a whiteboard! Sketch! Plan!


Things have been a bit more quiet around here than I'd like. I've got my reasons though, I swear. See, I recently subscribed to Thoughtbot's [Upcase](http://upcase.com). Upcase is a subscription-based service for training developers using their standards of vim, pragmatic TDD and object-oriented design. With a subscription to Upcase, you gain access to the Upcase app repository, tons of videos <del>and several books</del> that I'm finding to be invaluable to my studies as a developer. It's a great way to learn how one of the most well-known and respected Rails companies tests, develops, and just conducts themselves in general. I've been nerding out watching videos related to refactoring, improving vim speed, learning the Law of Demeter, and more. There are also exercises, which is probably the best part. The exercises are real-world projects that range from cleaning up controllers to creating page objects to handle different page interactions. After solving the problem, you push the solution to their servers and get the opportunity to have your code reviewed by members of the Thoughtbot crew. This is especially helpful if (like me) you aren't in a city that has a particularly budding developer community. I'll stop waxing poetic about my new toy, and urge you to check out [Upcase](https://upcase.com) today!


Thoughtbot's Upcase for sharpening programming skills


As a recent adopter of vim, I'll admit I fell into a trap. I removed arrow key support in an attempt to do things the "vim way", only to use `hjkl` the same way as I would have the arrow keys. I missed the point entirely, moving around the editor completely inefficiently. And I suspect others have fallen into the same trap. In an attempt to help others break out of the inefficiencies I'm also guilty of, I'd like to share a couple of ways to force yourself to adopt true vim proficiency.

### Tips before you get started

 One tip I've heard from vim experts is something that anyone coming from a traditional editor is a bit uncomfortable with: stay out of insert mode as often as possible. You should only enter insert mode when you need to type something; after that, escape back into normal mode as quickly as possible. There's a reason it's called "normal" mode; it's vim's normal state! Learning to navigate in normal mode, insert and jump back into normal mode is a quick way to remove dependence on either the arrow keys or `hjkl`. Another thing I did is turn on relative numbers in my `.vimrc` file. Relative numbering ensures that *every* line you are currently on is line 0, so you're never more than 16 or so lines above or below the line you're getting to. This is good for navigating, as instead of having to mentally count how many lines down from your cursor that next method you're shooting for is, you can just look at the line number and type something like `6j`, for instance.

### General tips

#### Use word-wise movements

 Navigating across words can be **much** faster than navigating via `h` or `l`. The basic word-wise movements are `w` and `b`: `w` moves to the beginning of the next word, and `b` moves to the beginning of the previous word. #### Use `f` or `t` to find in a line

 If you're already on a line that you need to edit, you can't do better than the `f` command. `f` finds the first instance of whatever you type next. So, if you're looking for an opening parenthesis, typing `f(` will do it for you. If you'd like to land on the character *before* the parenthesis, `t` is for you: `t(` will bring you to the character before the opening parenthesis.

### Tips not for the faint of heart

 These tips might be hardcore, but they aren't without merit. Both of these tips are designed to take you out of your comfort zone, but they also force thought. Because you're no longer *able* to navigate in a way you're comfortable, you'll naturally figure out more efficient ways of moving around in the editor.

#### Disable key repeat in your system settings

![Screen Shot 2014-09-26 at 01.10.03](http://res.cloudinary.com/dstrunk/image/upload/v1414083559/Screen-Shot-2014-09-26-at-01_10_03_iohzif.png) If you're used to holding down the `j` key to scroll down 20 or so lines, this one is for you. Disabling the key repeat feature on your computer means if you hold down `j`, it will only register as one press. When you hold your `j` button down this time, your editor will respond once, a lightbulb will go off and you'll say, "Oh yeah! I shouldn't be doing this."

#### Vim hard mode

 Hard mode is exactly what it sounds like. It not only disables arrow keys, but `hjkl` keys, page up/down keys, and other keys that depend on character-wise navigation. This forces users to push through their anti-patterns and navigate in a more vim-centric fashion. You can find vim hard mode [here](https://github.com/wikitopian/hardmode).

### Conclusion

 These tips are by no means exhaustive, and in fact barely even scratch the surface. I didn't even go into some of the plugins that extend vim's already powerful features (fuzzy searching, Rails integration, etc.). But even with this small handful of vim tricks you'll find that your productivity will increase a ton. And better yet, you'll find that your brain will stop treating vim as a text editor similar to what you've been used to and more as a productivity powerhouse that it has the potential to be.


Easier movements in vim


Over the last couple of days, I've been setting up my Macbook Air to dual boot into [Ubuntu](http://www.ubuntu.com/) for development. Why do that, when OS X is perfectly fine for Ruby / Rails development? Because I'm a nerd. There's also the fringe benefit of working on a similar development environment as your production environment... Because if you're using, say, [Digital Ocean](https://www.digitalocean.com/), they give you the option of running Ubuntu Server for your production environment. So there's that. For those unfamiliar, Ubuntu is a very popular, user-friendly distribution of Linux. I chose to install Ubuntu over [Debian](https://www.debian.org/) or [Fedora](http://fedoraproject.org/) because I didn't want to fuss around *too* much with configurations, but feel free to choose whichever distro you like. I'm not going to go into installing Ubuntu on your computer; depending on your need, you could do something as simple as allowing Ubuntu to automate that process via its live install process to something more involved like setting up your own partitions and using [rEFInd](http://www.rodsbooks.com/refind/) to dual boot (I did the latter). In fact, I won't even be going into my whole setup. Why do that, when it's documented perfectly well in my GitHub Dotfiles? Check them out: [dstrunk Dotfiles](https://github.com/dstrunk/dotfiles) I suppose I *could* touch on the particulars a bit. See, up until recently, I was using forks of other peoples' dotfiles, which resulted in a **ton** of really cool terminal configurations that *I never really used*. My development environment was also a bit messy, often installing things ad-hoc. Instead of going that route for my new partition, I decided to write everything "from scratch"; borrowing from other dotfiles, but never copying directly. There's a ton of influence from [Thoughtbot's dotfiles](https://github.com/thoughtbot/dotfiles), and some from [Mathias Bynen's](https://github.com/mathiasbynens/dotfiles/), but mostly my focus was on only adding things if I used them regularly. Hence a tiny repository containing only Vim and `bash` configurations. Here's a quick summary:

- Install Homebrew, rbenv, and any databases that need installing (usually Mysql / Postgresql).
- Symlink `.vim`, `.vimrc`, `.vimrc.bundles`, and `.bash_profile` into the home directory.
- Open up Vim and run `:PluginInstall`.

As stated in the dotfiles under **Future plans**, I'd eventually like to streamline this processes to decouple my setup from totally overwriting system files. However, even without that, I'm more inclined to this method over, say, using [Thoughtbot's rc file manager](http://robots.thoughtbot.com/rcm-for-rc-files-in-dotfiles-repos). While Thoughtbot's way of automatically setting up your system is nice (and I especially understand when it comes to setting up multiple computers for a mid-sized business where environments must be similar), I rather enjoy manually setting up my system and understanding the *why* behind the *what*.


Nerding out: setting up Ubuntu for Ruby development


It's a big day today... Apple's September 9th event, this blog's 100th post, and perhaps most importantly, my dog Carl's birthday! To celebrate, we'll be talking about cleaning up nested forms in Rails with **form objects**.

### Form Objects

 As your application grows, your models might tend to get messy. Some people subscribe to the "fat model, skinny controller" viewpoint, but I think that our entire codebase should be easily digestible, and that means refactoring certain functionality out of a catch-all model and into plain ol' ruby form objects, service objects et al. If you have a form that updates several ActiveRecord models with one submission, you've got a good candidate for a form object. Form objects can significantly clean up models that use `accepts_nested_attributes_for` *ad nauseum*. Before I get started, I should note that I'll be dealing with Rails 4 for this example. In Rails 4, it's easy to add ActiveRecord-like attribute functionality to objects by including `include ActiveModel::Model` in your class. That allows you to enjoy AR methods like validation, etc. One thing that tripped me up was getting strong parameters to work with this method. After learning how Rails expects its parameters however (hashes), everything started to Just Work&tm;. In this example, we're going to deal with a form that updates both a `User` model that has one `Profile` model in a signup form. First, the models (basic stuff):

~~~
class User < AR::Base
	has_one :profile
	end

	class Profile < AR::Base
	belongs_to :user
end
~~~

- My `User` model has the following fields: `:username` and `:email`.
- My `Profile` model has the following fields: `:github` and `:twitter`.

Now, instead of going the traditional Rails way with an `accepts_nested_attributes_for :profile` in our User model, we'll extract out the entire form details into a separate `signup` object:

~~~
class Signup
	include ActiveModel::Model

	attr_accessor :username, :email, :twitter, :github

	validates :username, presence: true
	validates :email, presence: true, email: true
	validates :twitter, presence: true
	validates :github, presence: true

	def register
		if valid?
		create_user
		create_profile
	end

	private

	def create_user
		hash = {}
		hash[:username] = "#{username}"
		hash[:email] = "#{email}"
		@user ||= User.new(hash)
		@user.save!
	end

	def create_profile
		hash = {}
		hash[:twitter] = "#{twitter}"
		hash[:github] = "#{github}"
		@profile = Profile.new(hash)
		@user.profile = @profile
	end
end
~~~

#### Quick notes:

- Include `ActiveModel::Model` to gain access to traditional AR methods. Quack, quack
- `attr_accessor` for the fields we'll be using
- validations just like we're used to
- A `register` method that we're using in our `SignupsController` (called below)
- Our user and profile creation methods

Let's take a look at our form. It's standard stuff, but note that we're using the object `@signup` given to us by the `SignupsController` (posted below the form):

~~~
<%= form_for(@signup) do |f| %>
	<% if @signup.errors.any? %>
	<div id="error_explanation">
	<h2><%= pluralize(@signup.errors.count, "error") %> prohibited this user from being saved:</h2>
	<ul>
	<ul><% @signup.errors.full_messages.each do |message| %>
	    <li><%= message %></li>
	</ul>
	</ul>
	<% end %>

	</div>
	<% end %>
	<div class="field"><%= f.label :username %>

	<%= f.text_field :username %></div>
	<div class="field"><%= f.label :email %>

	<%= f.text_field :email %></div>
	<div class="field"><%= f.label :twitter %>

	<%= f.text_field :twitter %></div>
	<div class="field"><%= f.label :github %>

	<%= f.text_field :github %></div>
	<div class="actions"><%= f.submit %></div>
	<% end %>
~~~

From here it's a simple matter of updating the controller accessing the form:

~~~  
class SignupsController < ApplicationController
	respond_to :html

	def new
	@signup = Signup.new
	end

	def create
	@signup = Signup.new(signup_params)
	@signup.register
	respond_with @signup, location: some_location_path
	end

	private
	def signup_params
	params.require(:signup).permit(:user, :email, :github, :twitter)
	end
	end
~~~

This should look like something you're used to. A simple `create` method passing in strong params, then calling the `register` method on the `@signup` object.

#### The end

 That's all for today! If you'd like to learn more about cleaning up your fat models, check out this great (if a bit dated) posts from codeclimate: [7 Ways to Decompose Fat ActiveRecord Models](http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/). It's got great ideas that you should be able to update to work with Rails 4 pretty easily. I'll close with a picture of Carl, hard at work building out a complex airbnb-type app for dogs: ![Carl, hard at work.](http://res.cloudinary.com/dstrunk/image/upload/v1414083560/2013-09-07-14_24_53-2_sqptrn.jpg) Happy birthday Carl!


Cleaning up nested forms with form objects in Rails 4


Nothing much code-wise this week, except ... RIP my [GitHub streak](http://github.com/dstrunk). When I started this Rails journey, I made a personal commitment to tackle a full 365 days of developing, using GitHub's contribution graph to track my progress. Well, while I did work on some projects last night, I either forgot to push my progress or didn't merge a branch. Whatever the reason, my streak is caput, and I'll be starting over at 0 today: ![RIP in peace, GitHub streak](http://res.cloudinary.com/dstrunk/image/upload/v1414083560/github-history_azibyh.png) Oh man, it hurts. My OCD almost can't handle it. I'll get over it, though. This is just the thing needed to rededicate myself to Rails, I suppose—if I'm being completely honest, after the first two months I was pretty much bouncing around on projects and treading water. And it's by no means the end—just another opportunity to start over. Keep an eye out on this blog next week—I'll be writing about something I've been working out for the last week; namely, **form objects** in Rails.


The end of my GitHub streak


A consequence of the ease of picking up a framework such as Rails, Django, or Laravel means that outsiders to the Computer Science realm are now able to create applications with relative ease. I am certainly counted in the majority in that respect. But if you want to hang with the big boys and continue your career past creating a one-off idea, sooner or later you'll need to learn database design. Database design might seem like a tedious topic, but if you're expecting your idea to gain traction and get picked up by a large audience, it's imperative. First up is a link: [Using indexes in rails - index your applications](https://tomafro.net/2009/08/using-indexes-in-rails-index-your-associations). Indexes (indices) will speed up performance of commonly queried table columns and are important as your application grows. Next is a book that I recently purchased that's been well-rated in the CS realm: [Database Design for Mere Mortals](http://www.amazon.com/Database-Design-Mere-Mortals-Relational/dp/0321884493/). You might notice the dates on both the book and the link; they're old! But that doesn't mean they're outdated. Fact is, relational database design is near-timeless in the CS world. For starters: did you know that the relational database was [first defined in 1970](http://en.wikipedia.org/wiki/Relational_database#Terminology)? The idea of relational databases have been around for 45 years, and with good reason—it fits with the majority of structured data. Sure, nowadays people will tout the wonders of [NoSQL](http://en.wikipedia.org/wiki/NoSQL) (see the [MEAN stack](http://mean.io/#!/)) as the successor to RDBMSes, but even now, after all these years, relational databases are a great fit for modern day applications. But I digress. Back to the topic: DB design goes beyond the speed at which your database responds to a query. It also touches on the way your queries themselves are built, and (more importantly) the underlying architecture of your database itself. As your application grows, you might not be able to continue to rely on queries via an object relational mapper such as ActiveRecord, and you will be in a world of hurt if the integrity of your DB architecture is flawed from the start. We won't even begin to touch on the task of moving a monorails application out into services. For these reasons (and more!) it's important that you understand the *why* behind ActiveRecord's ORM magic, and do your best to plan for the future of your application by first understanding the basics.


Using indices in rails

I always wondered about the difference between `:belongs_to` vs `:references` when running ActiveRecord migrations, always chalking it up to a quirk in the framework. They do the same thing, right? Well yes, they do **exactly** the same thing, as a matter of fact; take a look at the Rails source:

~~~
def references(*args)
	  options = args.extract_options!
	  polymorphic = options.delete(:polymorphic)
	  args.each do |col|
	    column("#{col}_id", :integer, options)
	    column("#{col}_type", :string, polymorphic.is_a?(Hash) ? polymorphic : options) unless polymorphic.nil?
	  end
	end
	alias :belongs_to :references
~~~

But while they do the same thing, they might make your code a lot more readable to others ... or at least help you to understand why you're doing the association in the first place. Consider these two examples:

### Answers belong_to Questions

Say we have two models, `Question` and `Answer`: 	

~~~
class Question < AR::Base
	has_many :answers
end

class Answer < AR::Base
	belongs_to :question
end
~~~

In this case, when creating the `answer` AR migration, it would make sense for me to use `t.belongs_to :question`. From a vernacular standpoint, it's obvious that an answer instance belongs directly to a question.

### Questions reference Topics

But in a relationship that isn't strictly "parent and child" per-say, it might make more sense in your brain to use `references`. Again, this is purely from a vernacular standpoint; there are no differences once the table is created. My example uses `Questions` and `Topics`:

~~~
class Question < AR::Base
	belongs_to :topic
end

class Topic < AR::Base
	has_many :questions
end
~~~

There's no difference in the model, but if I were creating the table, I'd use `t.references :topic`. This would help make my migration more readable, and I'd know that `Topic` is probably a more adjacent table that `Question` just happens to need a reference to, instead of being a more "connected", "parent-child" relationship that might directly affect the child models. I tend to use `belongs_to` most when I'm using models that accept nested attributes for another model. `reference` is more for tenuous relationships that just need to "talk" to another table, or are related via a `has_many through`, personally. Notice all of the qualifiers in this post! The reason for all of the "personally" or "I tend to" is because doesn't really matter which you use: `belongs_to` or `references`. It might help make your migrations more readable, however. It certainly helps me! Have anything to add? Want to correct me on something? Let me know below!


"references" vs "belongs_to" in ActiveRecord migrations


On July 31, 2014 Yukihiro "Matz" Matsumoto, the creator of Ruby, gave a talk at Ninefold in San Francisco. It's a very enlightening talk about the future of Ruby (if that wasn't obvious from the title), as well as Matz's new creation, **mruby**, an embedded lightweight Ruby comparable to the programming language Lua. Check it out: [Video: Yukihiro "Matz" Matsumoto - The future of Ruby](https://ninefold.com/blog/2014/08/07/ninefold-presents-yukihiro-matz-matsumoto-live/)


Link: the future of Ruby


Something's ... different. If you've been reading for a while, you might have noticed a not-insignificant update made to the site over the weekend. I decided to separate concerns a bit, adding dedicated sections for portfolio pieces and resume entries. No, I'm not looking for a job! I just felt the need to utilize WordPress more as a CMS and less like I was (blank pages in WordPress with all of the copy updated in a custom page through the theme—I don't want to talk about it.) Though the front-end changed significantly, most of the heavy lifting was accomplished on the back-end with custom post types, custom taxonomies, and a completely new structure built on [Underscores](http://underscores.me/) and [Bootstrap](http://getbootstrap.com/). But I won't bore you with details on that (in this post). What I really want to talk about is 301 redirects. See, since the front page is no longer my latest posts, my site structure changed url-wise. Changing urls from a WordPress standpoint is trivial, but if you want to do something like this, you better do it right. 301 redirects will help you accomplish this correctly so your page rank doesn't suffer much on search engines. First, for the uninitiated: HTTP 301 is a response status code meaning "Moved permanently". It lets users and search engines know that they need to update their old urls to the new one. The search engine bit is key; you don't want all current search engine results to point users to 404 pages! Google's got a great video detailing changing urls with 301 redirects, and what they expect from a search engine standpoint: https://support.google.com/webmasters/answer/93633?hl=en If you're looking to add a redirect to your site, you're going to be working with your `.htaccess` file. The correct syntax for adding a 301 redirect looks like this:

    redirect 301 /oldpage.html http://site.com/newpage/

 Now that you know the syntax, open up the `.htaccess` file in the root directory of your WordPress installation. You should see something like this:

```bash
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index.php$ - [L]
...
```

 Above the `#BEGIN WordPress` comment, add your redirect lines:

```bash
redirect 301 /oldpage.html http://site.com/newpage/
redirect 301 /oldpage2.html http://site.com/newpage2/
```

That's it! This could probably be accomplished with a WP Plugin, but it's easy enough that I'd rather not install a plugin for it. 301 redirects might seem tedious to implement, but if you're worried about your page rank, or your users in general (read: you should be), they are imperative.


Site updates and 301 redirects


Firefox 31 was recently released on July 22, 2014. It's largely bug fixes and minor tweaks, but one mildly interesting development is their addition of support for native CSS variables without enabling experimental features. If you're in the 15% of web developers that have yet to adopt [Sass](http://sass-lang.com), [Less](http://lesscss.org/), or [Stylus](http://learnboost.github.io/stylus/), this might be exciting news for you! Read on for more.

#### The bare essentials

To declare a CSS variable, you declare your **element**; the variable within that element is available to all styles that inherit this element. Within your **element** brackets, declare your variable like so: `--my-variable: #fc0;`

To use your variable, use that ol' familiar functional notation:

~~~
main {
	color: var(--my-variable);
}
~~~

One more thing: if you want a variable to be available to **all** elements, use `:root` as your element. Since variables can be declared globally, cascading down to other elements, it's not hard to imagine being able to dynamically change variables via JavaScript and completely generate a new stylesheet. That could be cool, but with past timelines for CSS vendor support, who knows when we'll be able to do something like that. You might be saying to yourself, "This whole thing looks hideous!" I agree. All in all, it feels a bit like a hack release in general. I'm sure the release cycle is looking to eventually mimic the functionality of one of the CSS preprocessors, but for now I'm unimpressed. For the time being, I'll stick to Sass with its mixins, variables, helper functions and calculations.


CSS variables land support in Firefox 31


**updated on Aug 23, 2016**

*This article previously referenced Amazon, and had some issues that might have
broken for some users. The post has been updated to ensure it works as of Aug
23, 2016.*

If you're building a site that compares data from different sources, chances are you might find yourself dealing with a couple of sites that don't have an API. But us web developers, we're a resourceful bunch, and we won't let a little thing like a lack of accessible information stop us, right? Right! Before APIs were the norm, an easy way to grab information on the interwebs was through web scraping. If you're using Ruby, a great library for web scraping is [Nokogiri](http://nokogiri.org/). After reading this article, if you're interested in a deeper dive through web scraping, I'd suggest reading the Nokogiri documentation; it supports selecting web elements using CSS selectors or XPath, and is pretty robust.

## Getting started

To start, let's first install Nokogiri. Run the following:

```bash
gem install nokogiri
```

This command will install Nokogiri on your system. It's better to use a Gemfile
for installing Ruby libraries, but for this example, installing on our system is
fine.

Now we're going to search through New York's Craigslist for some results of some
pets in need of adoption. By digging around a bit, we've found a URL that will
return the results we're looking for:
`http://newyork.craigslist.org/search/pet?s=0`.

## The scrape

So, we've got Nokogiri installed, and we've got our URL. Let's get started.
First, create `craigslist-scrape.rb`, then add the following to this file:

```ruby
require 'open-uri'
require 'nokogiri'

url = 'http://newyork.craigslist.org/search/pet?s=0'
doc = Nokogiri::HTML(open(url))

pets = doc.css("a.hdrlnk").map { |pet| "#{pet.text} - #{pet.attribute('href').to_s}" }

puts pets[0..9]
```

After adding this to your file, you can try running `ruby craigslist-scrape.rb`.
The terminal should output the text of some links, as well as some relative URLs
that accompany it so you can save them to a spreadsheet for further tracking:

```bash
Please adopt or foster a dog or cat from the NYACC kill list today!! - /jsy/pet/5746473654.html
Poor kitten needs your help - /brx/pet/5746472508.html
Please help my kitten in need - /fct/pet/5746469771.html
Please help my kitten - /wch/pet/5746466978.html
6 month old Holland lop needs home today - /brx/pet/5746451660.html
2 month old kittens - /brx/pet/5746420056.html
House Call Veterinarian - /que/pet/5746418041.html
Tiny pure breed Yorkie/Maltese available - /brk/pet/5746441804.html
Pythons & Monitors!!! - /mnh/pet/5730797572.html
looking to place my pocketpit plus her pups - /mnh/pet/5746399334.html
```

Here's a quick line-by-line of what's happening.

```ruby
require 'open-uri'
require 'nokogiri'
```

This requires the libraries we'll be using to scrape Craigslist. Open-URI is
part of Ruby's standard library that is used for opening http, https, or ftp
URLs as if they were files.

As noted before, Nokogiri is the scraper that parses the HTML DOM to find the
elements we're looking for.

```ruby
url = 'http://newyork.craigslist.org/search/pet?s=0'
doc = Nokogiri::HTML(open(url))
```  

The `url` is given our ugly URL as a string. The `doc` variable utilizes the Nokogiri library to open the url variable.

```ruby
pets = doc.css("a.hdrlnk").map { |pet| "#{pet.text} - #{pet.attribute('href').to_s}" }

puts pets[0..9]
```

The real magic happens in this one-liner. First is `pets`: Nokogiri uses familiar CSS selectors to traverse the DOM. By calling the method `css` on `doc`, and passing in "a.hdrlnk", we get a list of all elements that fit this pattern. Next we add these values to an array, adding the text of the `a.hrdlnk` element and the href attribute of the `a.hdrlnk` element. From there it's a simple matter of printing the first ten links out to our terminal via `puts pets[0..9]`! Pretty straightforward, right?

### Conclusion

Web scraping can get pretty ugly, having to traverse the DOM via xpath or CSS. It highlights an inherit problem with web scraping, and one you should note if you're thinking about depending on an external site's structure for your content: everything is dependent on how the site exists at the present moment. If for whatever reason Amazon decided to change how its sorting was done, or built its keywords using a different POST variable, we'd have to adjust our web scraper to accommodate. As long as we understand this, however, and don't build a program dependent on another website's structure, we should be okay.


Web scraping with Ruby and Nokogiri


Welp, if my Github contributions graph is to be trusted, I'm now sitting at a half a year of web development. For better or worse, here's what I've picked up so far.

### The good

As I look back on the last couple of months, I feel pretty confident that I have the basics down. I'm comfortable with the asset pipeline, various model associations, and validations. Writing a basic model or controller from scratch is trivial, and I'm finding that I think about problems in terms of steps to achieve a goal instead of seeing just the forest. That especially was a hard step for me; it's also the thing that has aided me most in other areas of my job responsibilities at my current job. **Proper planning and breaking a large problem into digestible parts are the greatest tools a developer can have, in my opinion.** I've grown extremely comfortable with version control, frequently having to backtrack or branch a repository to try out new ideas. And it's not just being comfortable with it; It's a step that I automatically do (commit early, commit often). In the beginning I'd knock out a couple of hours of work before the "oh crap, commit!" thought came up. Not so much anymore.

### The bad

While I know test driven development is important, I never felt like I was actually DOING anything other than writing tests when truly following TDD. So, to feel more productive I kind of eschewed the traditional TDD route and created apps with little testing. I feel like it was necessary for me to get a quicker grasp on back-end development, but my test skills are definitely something I need to improve on if I'm to be a well-rounded developer. For the last couple of months I felt like I was just spinning my wheels. There's definitely such a thing as "learning too much and doing too little". My app idea (the whole reason I started this Rails journey in the first place) deals with some complex database design, and I suppose I felt more comfortable creating toy apps and picking up new tricks. While I think learning more about front-end frameworks such as AngularJS and Backbone are important for continued development, I'm realizing now that I was using these technologies as an excuse to delay creating my app. This idea of learning everything before starting directly opposes that "F it, ship it" mentality.

### The future

It's time to renew focus; get back to building an app supported by TDD, and iterate on a finished idea like a traditional dev team instead of expecting my version 1 to be the first and last version shipped. Looking back, I feel pretty confident that I have the basics down. And I can't help but feel like I got sucked into the trap of learning too much and doing too little. But one thing I know for sure: the last half year of development has only cemented my interest in continuing in this field for a long time to come.


Learning Rails: half a year in


In the rush to learn Rails (or any framework, for that matter), one thing that might get overlooked is security. Thoughts of "security is already baked into framework x" might be the reasoning, who knows. I'm guilty of it, and I'm sure others are in the same boat. But security of basics, like keeping your API keys and secrets *actually* secret is incredibly important, not just for the integrity of your app, but for the safety of your users. It's also important if you're looking to open source your app on GitHub or the like. In the past, a Rails developer might have saved their API keys and secrets in a file above the Rails app directory. Others might have hardcoded it into the app itself (bad dev!). Still others could have used the [Figaro gem](https://github.com/laserlemon/figaro), meant to secure API keys and make deploying to Heroku with said keys easier. I opted for the Figaro route until recently. Rails 4.1 seems to take a page from Figaro's book: it comes equipped with `config/secrets.yml`. **Currently, this file is not in `.gitignore` by default, so you'll need to add it.** Afterwards, however, simply add your API keys and secrets as below:

	development:
	  secret_api_key: SOMEKEY

 According to the [4.1 release notes](http://edgeguides.rubyonrails.org/4_1_release_notes.html), secrets configured in `secrets.yml` should be accessible via `Rails.application.secrets`. For example: `Rails.application.secrets.secret_api_key` should return SOMEKEY in the development environment. Cool! You might be thinking to yourself, "that's all well and good, but this need for secrecy has predated Rails 4.1 by a LONG time." And you're right. Because of this need in the past, the de facto standard for utilizing secret keys has been environment variables: `ENV["secret_api_key"]`, for example. This standard has persisted because of services such as [Heroku](http://heroku.com) and documents such as [12factor](http://12factor.net). Luckily, since YAML files get processed through ERB, you can still use environment variables. Instead of using `Rails.application.secrets.secret_api_key`, you can simply continue to use `ENV["secret_api_key"]`. Sure, this way isn't technically the "Rails way", but it's a solid middle ground between the "Rails way" and using gem dependencies.


Keep it secret, keep it safe: Using secrets.yml in Rails 4.1 to secure API assets


Last night I decided to install [Redmine](www.redmine.org/) on one of my subdomains to help track my projects. Redmine is a fantastic (free!) project management app built on Rails. It's highly customizable and enjoys all of the features that the big boys offer. It's a great piece of software, and I highly recommend it; not only to budget-conscious outfits, but even bigger companies looking to improve their workflow. Back to last night, though. Seeing as Redmine is a Rails app, I could have run it as a Heroku app and wiped my hands of it, but I wanted more control. I've also had a shared hosting account on Dreamhost since forever, so I decided to test their Rails support. I'd read some horror stories in the past, but after some initial stumbling around, it wasn't so bad.

## Getting started

### Step 1

First I had to set up my subdomain. Pretty standard on Dreamhost's end. Think up a name, configure some options (or leave them at default, which is what I did). One gotcha: Dreamhost has support for Passenger, which is typically used for Ruby or Python apps. **Don't select this for Rails apps.** Dreamhost's Passenger version is pretty much unmaintained. We're going to go with FastCGI instead.

### Step 2

After your subdomain is configured, things start go get a little non-standard (at least from my typical Dreamhost experiences). First, `ssh` into your server, and `cd` into the folder that you're installing the app under. For Redmine, it was pretty easy to install the latest version—using Mercurial, I typed in `hg clone --updaterev 2.5-stable https://bitbucket.org/redmine/redmine-all redmine-2.5` into the terminal and watched Redmine get installed automatically.

### Step 3

From there it's a typical Rails install (for the most part). `cd` into the installed folder. Open up `config/database.yml` and configure the database settings for your production environment.

### Step 4

Run `bundle install --without development test` to get the required gems for your production Redmine. I had an issue with installing RMagick on Dreamhost, so I installed gems using `bundle install --without development test rmagick`.

### Step 5

Almost ready: generate a secret token for redmine: `rake generate_secret_token`

### Step 6

Time to instantiate the database! Run `RAILS_ENV=production rake db:migrate`.

### Step 7, in three parts

 Here's where things tripped me up a bit. Dreamhost doesn't allow webrick to run on shared hosting accounts, so I had to figure out an alternative. Luckily, it's pretty easy to get setup once you know what to look for. In the root directory of the domain you're looking to install Redmine / your Rails app into, create a `public` folder. You'll be creating two files here: **dispatch.fcgi** and **.htaccess**. Here's what your dispatch.fcgi should look like: 	

~~~
#!/usr/bin/ruby

# Dreamhost clears environment variables when calling dispatch.fcgi, set again
ENV['RAILS_ENV'] ||= 'production'
ENV['HOME'] ||= `echo ~`.strip
ENV['GEM_HOME'] = File.expand_path('~/.gems')
ENV['GEM_PATH'] = File.expand_path('~/.gems') + ":" + '/usr/lib/ruby/gems/1.8'

require 'rubygems'
Gem.clear_paths
require 'fcgi'

require '../your/app/config/boot.rb'
require '../your/app/config/environment.rb'

class Rack::PathInfoRewriter
	def initialize(app)
		@app = app
	end

	def call(env)
		env.delete('SCRIPT_NAME')
	    parts = env['REQUEST_URI'].split('?')
	    env['PATH_INFO'] = parts[0]
	    env['QUERY_STRING'] = parts[1].to_s
	    @app.call(env)
	end
end

Rack::Handler::FastCGI.run
Rack::PathInfoRewriter.new(YourApp::Application)
~~~

Things to note about this file:

* The top of your file should point to the version of ruby you're using. If you're unsure where ruby is located, run `which ruby` in your ssh session.
* As noted on line 3: Dreamhost clears environment variables that Rails will need. You'll need to set these according to your host credentials.
* Make sure that your required files are the correct paths.
* In the bottom line, replace **YourApp** with the name of your app.

And now, your .htaccess:

~~~
 <IfModule mod_fastcgi.c>
	AddHandler fastcgi-script .fcgi
</IfModule>
<IfModule mod_fcgid.c>
	AddHandler fcgid-script .fcgi
</IfModule>

Options +FollowSymLinks +ExecCGI

RewriteEngine On

RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ dispatch.fcgi/$1 [QSA,L]

ErrorDocument 500 "Rails application failed to start properly"
~~~

I didn't make any changes to this configuration, it "just worked".

### Troubleshooting

You should be pretty much finished from here. If you open up the domain you installed to, it should either work or display "Rails application failed to start properly". If you got the latter, no worries. You're still ssh'd into your server, right? `cd` into `public/dispatch.fcgi` and type in terminal `ruby dispatch.fcgi`. That will run dispatch manually and tell you any errors encountered if there are any. More common issues are improper paths (for me, at least).

### Pros

Dreamhost's admin page. I'm biased here, but in all my time working with cPanel or other admin dashboards, I think that Dreamhost's is the most user-friendly. It's easy to set up users, domains, and databases. Ease of setup (kinda). Since Dreamhost manages servers for the most part, you don't have to worry about apt-get apt-update linux stuff. I don't know about you, but I'd rather focus on creating apps than being a sysadmin.

### Cons

Documentation. Pretty terrible—written by customers of Dreamhost that detailed their experiences in getting apps running. I found more help on Redmine forums and StackOverflow. Fast CGI vs Passenger. Passenger would have been a lot easier to set up, but Dreamhost's shared server version of Passenger hasn't been updated since 2010. So using Fast CGI was a bit of a learning curve. Not the fastest solution.

## Conclusion

Setting up Rails with Dreamhost was not as painful as I'd first thought. Seeing as the majority of my domains are registered at Dreamhost, it gives me a sort of OCD piece of mind knowing I can run my Rails apps alongside WordPress sites without worring about buying a VPS\*. If you're feeling extremely motivated, I bet you could write set up a remote git repository and set up a cron job that detects changes and autodeploys, something like a poor man's Heroku. But that I leave up to you, dear reader.

<small>*For now. I will definitely need one down the road.</small>


Configuring Rails projects with FastCGI for Dreamhost shared hosting


As a newer Rails developer, I can wrap my head around smaller, less complex projects. But as a project grows in complexity, I get more and more reluctant to even begin to attempt to understand it—backing away slowly, then finally turning and running for dear life. Recently, however, I came across [RailRoady](http://railroady.prestonlee.com/), a gem billed as "dirt simple UML generation for Rails 3 and 4 applications." For the uninitiated, UML stands for "Unified Modeling Language," a specification that models application structure, behavior and architecture. As a visual person, I've found that generating UML diagrams is helpful in understanding more sophisticated Rails apps. Using Railroady is easy. First, include railroady as a development dependency in Rails:

```ruby
group :development, :test do
  gem 'railroady'
end
```

 After a quick `bundle install`, run railroady's rake task: `rake diagram:all`. This will generate four svg files under doc/*.svg.


Studying existing Rails projects with Railroady


[This post by Si digital](http://sidigital.co/blog/disconnect-your-frontend-from-wordpress) recently detailed their company's process for using WordPress in a pretty cool way. See, they wanted to continue using WordPress's admin backend, because it's user-friendly, people are familiar with it, and existing systems might depend on it. But they found that WordPress's frontend left something to be desired—they frequently needed more information than [The Loop](codex.wordpress.org/The_Loop) could provide, and in a more succinct manner. I went ahead and went a bit further with Si digital's idea—incorporating PHP's [Slim framework](http://www.slimframework.com/) into Si Digital's class, allowing for custom routing completely independent of WordPress's permalink structure. I'm calling the marriage of these two ideas (all tongue-in-cheek punnery intended) **WP Loupe.**[![loupe](http://res.cloudinary.com/dstrunk/image/upload/v1414083562/loupe_jncexu.png)](https://github.com/dstrunk/loupe) WP Loupe is an extremely simple bit of code that hijacks the WordPress initialization with its own similar init, instantiating a class that can be used to call any function outside of traditional WordPress functions. The folder structure is similar to a more opinionated framework (*ahem* Rails *cough*), for ease of maintenance. I've got some ideas moving forward, including incorporating a more robust controller and including a PHP templating framework. If you enjoy the WordPress admin structure, but find using the loop a bit painful for some of your more nontraditional WordPress projects, check out WP Loupe: [WP Loupe](https://github.com/dstrunk/loupe)


Custom frontend routing and loop options for WordPress


What a terrible title. This week I've been working on some more business-oriented development—purchasing plans and dealing with recurring billing through [Stripe](https://stripe.com/). Stripe is billed as "payment processing for developers" which I think is a fantastic niche to fill. Sure, Paypal is easy for end-users, but who actually builds the checkout forms? IMO it's smart for Stripe to target developers like they are. But you didn't come here to here me wax poetic about a company's business model. To get started with Stripe and Rails, Stripe has a handy guide to set up your controller and add all information for a static charge: [https://stripe.com/docs/checkout/guides/rails](https://stripe.com/docs/checkout/guides/rails). This got me going through most of the setup, and Railscasts' episode [Billing with Stripe](http://railscasts.com/episodes/288-billing-with-stripe) helped out with the rest. Have I mentioned how great a resource Railscasts is? I highly recommend signing up for an account if you haven't done so yet. In unrelated news, I feel like I'm finally starting to internalize the whole "MVC / way the internet works" deal. A large amount of credit goes towards a local hackathon I went to this weekend. Supporting the [National Civic Day of Hacking](http://hackforchange.org/), we worked for 36 hours to create a service to better Columbus, GA. My partner built a backend API while I attempted to build out a front-end Single Page Application using [BackboneJS](http://backbonejs.org/). **Note to self:** attempting to learn and implement a new framework in 24ish hours is not the best idea. But working with a proficient back-end developer really helped me understand better why I was doing the things I was doing. Instead of just, "Oh, it's done this way because ... that's the way it's done," my understanding is now "It's done this way because of this reason." Which is nice. Took long enough! :)


Payment processing for profit

I was recently tasked with developing assets for an email campaign for work. The design was already finalized, and just needed to be built out as a Mailchimp template. These types of requests frequently hit my desk, and they're usually fine, but this one was tricky—having background images under dynamic copy. Anyone that has done email templates might understand what a potential problem this is. Email clients are finicky, requiring developers to revert to development standards 15 years ago (which is to say, no standards at all). Tables, inline CSS, etc. are the norm. But even inline CSS wasn't solving my problem–in initial tests, adding a background image to the table cell yielded poor results across devices. So, after a bit of research (and pulling of hair, gnashing of teeth, etc.) I came across this fantastic little hack via Campaign Monitor: [http://www.campaignmonitor.com/blog/post/3192/add-a-background-image-to-individual-table-cells/](http://www.campaignmonitor.com/blog/post/3192/add-a-background-image-to-individual-table-cells/). Here are the steps:

- Replace `<html>` tag with `<html xmlns:v="urn:schemas-microsoft-com:vml">`
- Add the following style in the `<head>`: `v:* { behavior: url(#default#VML); display: inline-block; }`
- In the table cell you're looking to add the background image to, add this code:

~~~

~~~

According to Campaign Monitor's blog post, this technique has been tested and works in most major mail clients, Which is great. Is it hacky? Absolutely. But anybody building an email campaign should expect no less at this point.

Background images in individual table cells in email

Been busy! I just now realized I missed last week's check-in. That's not to say there hasn't been progress. I've been busy juggling different projects: a foray into [Django](https://www.djangoproject.com/) (Python's Rails equivalent), dabblings in [Laravel](http://laravel.com/) (PHP's answer to Rails), writing [a gem](https://github.com/dstrunk/tonic-wp) for generating Sass scaffolding for new WordPress themes, and a [breakable toy](http://wp.me/p3ERzH-gn) that tests recurring billing using Stripe. I'll briefly touch on each in a bit, but I want to explain a bit why I'm working with so many different frameworks. In an ever-changing technical landscape, if you aren't constantly sampling bits of all technologies, you'll quickly become out-of-date. My main personal focus for the forseeable future is Rails (strengthened by these forays into other frameworks), but there's no denying that Rails won't be around forever—to think otherwise is naive. Languages and frameworks come and go, and it's our job as web professionals to evaluate and adapt accordingly.  Now, on to some quick thoughts on some of the things I've been busy with. First up, Django.

## Django

Django is pretty nice! I'd initially evaluated Django when deciding which framework to dedicate myself to. Hearing good things on both the Rails and Django camps, I jumped in on both. Django was nice, but I favored "[convention over configuration](http://en.wikipedia.org/wiki/Convention_over_configuration)" instead of "[explicit is better than implicit](https://docs.djangoproject.com/en/dev/misc/design-philosophies/#explicit-is-better-than-implicit)". I also enjoyed the expressiveness of Ruby; though Python is easy to read, it reminds me too much of a stuffier language like Java or the like (I know, not fair, but I can't help my feelings!). This time, I worked through the sample app on the [Django Project homepage](https://www.djangoproject.com/). Here's what I liked about Django:

- **How modular everything felt.** With Django, you can create a blogging app, then port that app to another project with ease. Rails projects don't feel that portable.
- **Knowing what a model looks like by looking at the model file.** In Rails, if you want to know what the database structure looks like, you need to look in `schema.rb`. In Django, just look in the `models.py` file.
- **I18n.** I usually don't worry about this feature too much, but I know it's important downstream. And Django does it nicely, with `ugettext` and a command-line call to `python django-admin.py makemessages -a` to generate a file for each language you want to translate to.
- **Out of the box user auth and admin modules.** Rails has these as gems, but Django has them as part of core. I can't remember an app that didn't need some sort of user authentication or backend management at some point, and the developers of Django must have felt the same way.

And, what I didn't like:

- **Migrations feel more permanent.** This is probably not the case, but I like being able to visually see which migration I should roll back to like in Rails.
- **Regex'd routing.** Just feels risky to me. I don't trust myself around regex, to be honest. I can imagine accidentally allowing for a large security hole somehow. I'd rather let Rails intelligently determine routes for me.
- **Clunky views.** How scientific! I honestly don't know why I don't like Django's controller and view implementation, but Rails feels much more user-friendly. Sure, Rails views allow for newer developers to put a LOT more application logic code than should be in a view (which is bad), but they feel more powerful, and feel like a "truer" View than Django views, if that makes sense.

## Laravel

I haven't gotten too far into a Laravel application, but I have to say I'm impressed. The developer obviously borrowed a lot of key concepts from Rails, and it actually makes PHP not such a pain to work with. Along with the Eloquent ORM for easily managing database objects (I really hated writing SQL queries when dealing with PHP in the past), Laravel is definitely a contender on the framework front. After considering that most servers serve PHP with little-to-no configuration, and the majority of the web uses PHP (around 70% last I checked), I think a developer should at least have Laravel on their radar.

## Tonic-WP

My Ruby gem is in its infancy, but I've got some big plans for it. I'd like to create a Sass scaffolding command line tool similar to [Bourbon](http://bourbon.io) or [Neat](http://neat.bourbon.io), whereby a command will generate all necessary files to get started with the chosen framework. That's step one in my quest for ~~world domination~~ creating a full-featured Yeoman generator that will create a fully namespaced starter WordPress theme using [underscores](http://underscores.me) and my preferences for folder structure.

## Job board

My breakable toy is a job board app, though that's not the main focus. The main focus is creating a recurring billing system that accepts payments through Stripe. I just got started with the app, so not much technical information. I will say, however, that Stripe is truly a payment processor service for developers, by developers. Their documentation is robust, featuring examples for every major programming language. Over the next week, I'm looking to test building an API and incorporate some sort of front-end framework into it (Angular, Ember and Backbone are my self-imposed choices). Until then!


Juggling


Up until relatively recently, Facebook's mantra was "Move fast and break things." As a smaller startup, that seemed like a cool or trendy catchphrase, suggesting that they were an agile company that could adapt and afford to leave older functionality in the dust in favor of new hotness. But you and I, most likely, don't work at facebook. And we all know that breaking things isn't sexy to our employers, and definitely not to our clients.  With that in mind, I think it's important to have "breakable toys". Little applications that are created that demonstrate proofs of concept but aren't integral to business processes. Programs you're okay with completely destroying, because you're learning an important concept that could revolutionize your bigger idea. Such applications are ways to "move fast and break things" without actually doing so. They allow you to embrace failure as a learning process instead of as a sticking point with a client. I've been embracing this concept of breakable toys for the past year—my [GitHub](https://github.com/dstrunk) serving as the cutting-room floor for concepts, failed experiments and new technology ventures. It's helped me push forward as a developer, learning important concepts such as polymorphism, join tables, nested forms and lower-level SQL queries—important concepts that older / more "classically-trained" developers might take for granted. At their hearts, breakable toys force you as a person to step beyond your boundaries. But I think the most important part of this idea is the word "toy". These projects should be fun! They should remind you of why you started creating in the first place. Discovery should be an exciting prospect, not a word that fills you with dread at the beginning of a project sprint.


Breakable toys


[Frank Chimero](http://frankchimero.com) is a prominent designer, illustrator and writer based in Brooklyn. His book, *The Shape of Design*, was funded on Kickstarter and focuses on storytelling, co-dependency and craft in the design profession. You might be saying to yourself, "That's great and all, but ... What does that have to do with your weird title?" Well, Frank recently spoke at the School of Visual Art's Thesis Festival, and his talk (read: transcript) spoke volumes about the issues we face in the creative industry and beyond. I'll save the metaphors (read: obscure title) for your perusal of the talk, but the gist is: as a designer or developer facing a new problem, do you attempt to completely eradicate your problem, scorched-earth style, or do you accept that the problem is chronic and instead attempt to alleviate the related issues? In my opinion, the hacker mentality is borne from the second way of dealing with problems—accepting problem constraints, then finding novel solutions to circumvent these constraints. I tend to lean toward this approach most often, as it's less disruptive while still being effective. But the scorched earth policy is necessary at times as well; sometimes a way of doing things is so archaic and cumbersome that a complete reboot is warranted. As you approach your next design or development problem, ask yourself: does your solution need a complete reimagining of the current product? Or would it best be served by rearranging existing infrastructure to let the problem take care of itself? **Only Openings:**[http://frankchimero.com/talks/only-openings/transcript/](http://frankchimero.com/talks/only-openings/transcript/)


Shooting wolves and managing bears


In developing my company's website, I'm attempting to be as modular as possible. Following this methodology, I'm making heavy use of `get_template_part` to abstract out the WordPress loop and make downstream changes to code easier to understand. Recently, however, I ran into an issue with attempting to use a global variable with `get_template_part`. The issue is pretty easy to understand, and is more a PHP deal than a WordPress one: variable scope. Variables are *mostly* global in PHP; variables defined can be referenced most anywhere else, including `required` or `included` files. However, user-defined functions have their own local function scope. Any variable used in that function is limited to that function only. Here's an example:

```php
	<?php
	  $a = 1;

	  function test() {
	    echo $a; // will not return anything
	  }
	?>
```

 This threw me for a second; I'm used to global variables being accessible everywhere. But in PHP, functions have their own scope, and won't have access to higher-level variables unless they are passed to the function in an argument, or declared with `global`. I didn't want to declare a global variable within my template, and passing variables through `get_template_part` is exceeds the limitations of the WordPress function, so I had to find a different way to make sure my variables were accessible. To get around my problem, I opted to use the WP function `locate_template()`. locate_template is similar to `get_template_part`, except `locate_template` doesn't return the results of the arguments passed. It does exactly what it sounds like, which is locating templates. From there, I did a simple `include` to add the template. Here's what the final result looked like:

```php
include( locate_template( "template-part.php" ) );
```

 It honestly feels a little hack-y to me, but it gets the job done. No more worries about function-level scoping, all the benefits of `get_template_part`, and a modular website back-end. For more information about how scoping is handled in PHP, check out the documentation here: [http://www.php.net/manual/en/language.variables.scope.php](http://www.php.net/manual/en/language.variables.scope.php)


Variable scope and get_template_part


What a sensationalist title! Sorry, all those BuzzFeed articles are getting to me. It does speak to what I've been doing for the last week, though (and heartily recommend others do the same to better understand how dynamic web apps, and websites in general, are built). "Reverse engineering" sounds so official, but it basically entails viewing the source of websites and looking at Header information in Google Chrome developer tools. Using these tools on known, successful Rails applications, you can get a better idea of how the big boys structure their models and process requests. As far as viewing the source goes: because of how Rails structures forms, it becomes pretty easy to guess what the Embedded Ruby looks like, if there are nested models, etc. For example, one hidden input field might suggest a `fields_for` helper nested in a `form_for` helper; multiple hidden fields with the value ***_id** probably suggests a model that belongs to a lot of other models. By using **Inspect element** in Google Chrome, you can change values around, submit the form and predict which values change. I think that "real world" homework is just as, if not more, important than traditional book learning / armchair development. Why not stand on the shoulders of giants to get a better view? Until next time, stay curious!


Reverse engineering Rails sites for fun and profit


I've been a big fan of [RVM](http://rvm.io) for a while now. I started using it when I first began developing Rails apps my first go-around (not this 100+ day streak, but about six months prior). It is great for getting up to speed quickly, and it does its job well. I even backed it on Bountysource! But it does too much (for me). That might sound ridiculous, but a core tenet of the UNIX philosophy is for tools to do one thing, and do them well. Following this ideology, RVM is too powerful—maintaining Ruby versions in addition to installing Rubies and maintaining gemsets. In an attempt to better follow this idea, I took this weekend to switch from RVM to [rbenv](http://rbenv.org). To keep the functionality provided from RVM, I also made sure [Bundler](http://bundler.io) and [ruby-build](https://github.com/sstephenson/ruby-build) were installed to manage gemsets and installing Rubies, respectively. There were a couple of hiccups along the way, but I managed to clean up my file system and get everything back to where it needs to be for continued development. Rather than rehash other peoples' work, here are some great guides to get people interested in Ruby on Rails development up to speed. The first link details how to set up a Rails environment from scratch, and the second link details how to switch from RVM to rbenv (what I needed):

- [http://www.createdbypete.com/articles/ruby-on-rails-development-setup-for-mac-osx/](http://www.createdbypete.com/articles/ruby-on-rails-development-setup-for-mac-osx/)
- [http://robots.thoughtbot.com/using-rbenv-to-manage-rubies-and-gems](http://robots.thoughtbot.com/using-rbenv-to-manage-rubies-and-gems)

Another thing that might interest users looking to get started with Rails development, but might not be tech-savvy enough to fool with the command line: [Tokaido](https://github.com/tokaido/tokaidoapp). Tokaido is a Kickstarter-funded project created by developer heavy-hitter [Yehuda Katz](http://yehudakatz.com/). I haven't personally tried it out yet, but the app is aimed at making the development setup of Rails painless for new users.


Switching from RVM to RBenv (and other miscellany)


**First up:** I updated my portfolio! The base, anyway. Projects still need to be added. You can view it here: [SILENTPOST](http://silentpost.io/) It's built with [GitHub Pages](https://pages.github.com/), which use [Jekyll](http://jekyllrb.com/). More detail on that in a future post. Now that that's out of the way, on to my Ruby update. I've crossed the threshold! It's a completely arbitrary threshold I set for myself, but it feels pretty good. This post will be a reflection of everything I've learned over the last 100 days. A bit serendipitous that I'm wrapping up these 100 days on the eve of RailsConf 2014. Perhaps next year I'll be going? To be honest, I thought I'd have more completed projects to show, but I really should know myself by now. Projects have been schizophrenic and varied–jumping from a URL shortener to an image to ASCII art converter and a storefront–because I get bored easily. The good news (for me) is, most of these projects are looking to wrap up at the same time. The [image to ASCII art converter](https://github.com/dstrunk/img-2-ascii) (lovingly called "imgii") I started is wrapping up. I'm developing a gem from the proof of concept, and will be using it in a couple of dumb projects I have some ideas for. Publishing a gem is a pretty cool feeling. The url shortener is pretty much finished; it just needs a facelift from the front-end. While I usually enjoy that sort of thing, I really want to focus on Rails and not developing a UI, so it's been put off for a while. The storefront is riffing off of the *Agile Web Development with Rails 4* book I got a couple of weeks ago. Instead of following closely with the book, I'm deviating pretty seriously in an attempt to complete a large-scale app with only light handholding. GitHub's contributions calendar has been a great version of [Jerry Seinfield's "Don't break the chain" system](http://lifehacker.com/281626/jerry-seinfelds-productivity-secret) for getting better at development in general. Even if I didn't feel like working on anything, I felt compelled to keep up my contributions streak. That obligation grows stronger the more entrenched I get, which I think is a good thing from a "get better" standpoint. That's all for now. Looking forward to continuing development, and here's to the next 100 days!


100 Days!


Happy Good Friday! I realize I missed my update last Friday, and with only a partially good reason: I'm swamped! Day work has been particularly taxing these last couple of weeks, but you'll note that I've still found time to work after hours as evidenced by an [ever-growing GitHub contribution streak](//github.com/dstrunk). Sleep is for the uninspired :) Despite a busy work load, time marches on in Rails land. I recently picked up [Agile Web Development with Rails 4](http://pragprog.com/book/rails4/agile-web-development-with-rails-4) and began working through it. I'd recommend this book before picking up similar popular books like **The Rails Tutorial**. It not only teaches best practices for Rails development, but also teaches Agile development—something that will help manage development in the face of an ever evolving set of use cases and help control client expectations. Because what good is a developer if they can't talk to their client and parse their idea into an application? I'm looking to finish my image to ascii art converter within the next week; after that, refactoring, and perhaps extracting the code into a gem? That's the plan, at least.


Good Friday


I know what you're thinking ... "A WordPress post?! I thought this guy drank the Ruby on Rails Kool-Aid." Truth is, I never really stopped WordPress development, I was simply looking to expand my horizons a bit. I still use WordPress daily for personal blogs and work-related activites. It's good at its job, which is either as a blog or an easily extendable CMS-like solution. Anyways ... in developing my WordPress themes, I try to keep everything as modular as possible. Here's my general file structure for anything not WordPress-centric:

	|- assets/
	  |- img/
	  |- inc/
	    |- functions/
	    |- templates/
	    |- vendor/
	  |- js/
	  |- sass/

 This is of course a high-level overview, but let me explain a bit: - the **assets** folder holds all theme-related images, includes, JavaScript and Sass files. - the **img** folder holds all images
- the **inc** folder holds all PHP includes
- the **functions** folder holds all theme-centric functions. More on this folder in a bit.
- the **templates** folder holds all theme-centric templates to keep everything DRY
- the **vendor** folder holds all plugin / framework related things that I've accumulated over the years to help with development (WPAlchemy, etc)
- the **js** folder holds all JavaScript
- the **sass** folder holds all Sass files, again, to keep everything modular

The functions folder
--------------------

 Here's where things get a little more in-depth. First, everyone reading this will know that WordPress requires a **functions.php** file in the top level of a theme directory. Usually, people will add all of their theme configuration options to this file, resulting in a file hundreds of lines long. I'd rather write code than dig through it, so I extracted everything out into its own relevant file placed in the aforementioned **functions** folder. That said, here's my functions.php: ![folder setup for WordPress functions.php](http://res.cloudinary.com/dstrunk/image/upload/v1414083567/Screen-Shot-2014-04-17-at-8_15_13-PM_krqjsg.png) I won't be going over the screenshot in depth, but the gist is simple: first, I define any constants I'll be using a lot in my theme. Next, I have a series of includes that hold relevant code for their name. So, if I create any custom posts? In **custom-post-type.php** it goes. That ensures I always know where my code lies, even if I come back to the project 6 months down the road. I know this was a quick and dirty post, but I hope it helps anyone struggling to maintain a clean directory structure in the face of an ever-evolving theme!


How I structure WordPress themes


This one's a two-fer—comprising interesting features rolling out with Rails 4.1. Though it's a relatively minor release, there are some great details rolling through the pipeline. These guys do a great job detailing the release, so without further ado:

- [http://www.reinteractive.net/posts/177-my-favourite-things-about-rails-4-1](http://www.reinteractive.net/posts/177-my-favourite-things-about-rails-4-1 "My favorite things about Rails 4.1")
- [http://blog.plataformatec.com.br/2014/04/3-features-from-rails-4-1-that-im-excited-about](http://blog.plataformatec.com.br/2014/04/3-features-from-rails-4-1-that-im-excited-about "3 features from Rails 4.1 that I'm excited about")


Link: My favorite things about Rails 4.1


... in a couple of my apps, at least. While I absolutely LOVE building "pure" Rails applications, I don't think anybody in their right mind would ever discount the validity of using a client-side MV* JavaScript library to build a single-page web app or complicated user interface. I believe integrating libraries such as [Backbone](http://backbonejs.org/) or [Angular](http://angularjs.org/) is not only beneficial from a user experience standpoint, but can serve to help maintain a more scalable architecture down the road (shots fired to all those detractors saying Ruby on Rails isn't scalable). To that end, I've been focused on incorporating **BackboneJS** into two types of my applications: a single-page, simple flash card application, and a more robust application. One issue I've found is finding up-to-date tutorials on Backbone and Rails integration. With JavaScript MV* libraries being relatively new, there are constant versioned updates that sometimes break backwards compatibility. For example, RailsCasts has an episode dealing with [backbone on rails](http://railscasts.com/episodes/323-backbone-on-rails-part-1), but some initialization functions are defunct which tripped me up somewhat. But, barring that issue, everything is going well! The flash card application overview is extremely simple: to create as much of a one-page application as possible. I'm planning out multiple flash cards that have questions and answers, all belonging to a set. Rails will be used primarily as an API for the whole app, existing pretty much only to help with data validation. There are plans to integrate a spaced repetition algorithm down the road, but for now I'm only interested in getting the MVP up. The other application is ... undisclosed ... at this point in time, but I'm interested in applying backbone principles to the user interface much like [Fitocracy](http://fitocracy.com) has done. They have a very slick interface that feels very snappy and responsive, and after looking under the hood it appears much of that is achieved with Backbone. Coming up on 11 weeks now, I've decided to attempt to increase my Github contributions. I've stuck to contributing at least once a day for the last 80 days, but if we're being completely honest, a handful of those contributions were README amendments due to my not being in town. Time to refocus and make sure the contributions are meaningful, instead of just another light green square!


I've got Backbone!


In my role as a developer, I'm often asked to provide analytics on current product offerings; daily, weekly, monthly, and even hourly reports that better show what kind of audience the company is attracting and maintaining. Which is all well and good—analytics can support a decision to pivot to another product offering, or drop support for an outdated and underrepresented subset of users. But I've noticed that some companies get so caught up in analytics, so enamoured with measuring success, that they forget why they're in business in the first place—to provide a service to people.  If a company isn't careful, following trends in analytics—shooting for that lowest-possible bounce rate, higher conversion or tip-top search engine ranking—can lead to a very reactive business. One that struggles to maintain a cohesive voice in the face of unanticipated changes. One that chases trends instead of setting them. My very nonspecific advice: use the numbers, but don't let them define you. It reminds me a lot of the (over)emphasis of high school standardized testing. Teacher roles are reduced to preparing an entire student body for a test that will take two days instead of focusing on individual learning styles and out-of-the-box thinking. Because the numbers of a school district are what ultimately matter there, not one child in a classroom. In that same way, businesses become laser focused on optimizing for a search engine instead of paying attention to the actual user's experience. Here's another purely opinionated, targeted example: popup newsletter subscription boxes. I'm sure all of you are familiar with them. Reminiscent of the popup ads of the early internet, they interfere with the website you intended to visit, forcing you to close the dialog or fill out a form to remove it from your field of vision. They're awful, and I have yet to meet a person that enjoys seeing them. Yet some studies show that these modal dialog boxes [increase conversion rates](http://www.problogger.net/archives/2008/10/23/how-to-drastically-increase-subscriber-numbers-to-your-email-newsletter/). As a result, it's A Thing To Do™ from a marketing standpoint, and these dialogs flood the web. But these dialogs don't focus on providing an actual *service*, only pandering to a conversion rate number. Bottom line? Focus on providing the best service you can. Focus on making people satisfied with your project. Conversion rates and analytics should reflect that focus, not drive it.


Forget the numbers, focus on people


I'm still here! What, after 9 weeks of weekly progress updates, did you think I was just going to stop? This week has been a bit daunting, to say the least. I've decided to start moving from simple CRUD apps with limited models into a more complex app with user-controlled nested forms and complex data relationships. Because of the complexity of the app itself, I'm relying as much as possible on gems to allow me to focus on development of the architecture of the app itself. Gems such as [Devise](https://github.com/plataformatec/devise) for handling user authentication and [CanCanCan](https://github.com/CanCanCommunity/cancancan) (a continuation of the Ryan Bates's now-defunct CanCan gem) for easily handling authorization are great. This app has been good for me for a couple of reasons, but I think the most important benefit to tackling a large problem is the planning it's forced me to do. With this project, it's not possible to add a couple of scaffolds and call it a day. I'm anticipating this app to start off pretty complex, and only grow as time goes on, so it's important to plan models and structure from the onset. Some people use white boards to help plan their models, while others might use notecards; I'm using the latter. In addition to helping me to visualize the overall app structure, the notecards can serve as milestones of sorts—as a feature is completely implemented and tested, I can check it off the list. I find it to be a nice way to document progress and prevent scope creep in my own projects. In the intro, I briefly mentioned user-controlled nested forms in my app. This was perhaps the hardest thing to wrap my brain around. For this feature, the [Railscasts](http://railscasts.com) website has been great. There are railscasts dedicated to [dynamic form storage via hashes in a database column](http://railscasts.com/episodes/403-dynamic-forms), as well as ones focused on [using hstore as a storage strategy](http://railscasts.com/episodes/345-hstore) (NoSQL structure within a single database column). It's relatively early in the app's development, but having a resource as well-documented as Railscasts makes me feel confident I'll be able to figure out what's needed without **too** much stumbling around. In addition to everything covered in the previous three paragraphs, I'm continuing to refine my simpler app (the URL shortener). I'm designing and refining the UX, reconfiguring parts of the app to interact via Ajax so generating a short URL is a more pleasant / seemingly quicker experience. Whew! That was a lot to go over. Luckily we're finished—until next week!


Surprise! Week 10


No rest for the driven. I recently picked up *The RSpec book* from [The Pragmatic Bookshelf](http://pragprog.com/). I'm excited to jump into it; being a "wild west" developer for so many years, I've found it difficult to switch from a "shoot first, test later" approach. Even after following tutorials for days, I can't seem to wrap my head around writing my own tests without referencing other apps. Which is fine... but I'd like to understand what exactly I should be testing instead of following a "put the puzzle pieces together" approach. So far, the book is very enlightening. It's written by the author of RSpec himself, with contributions from the developer that wrote Cucumber, and proves to be enlightening stuff. If you didn't read yesterday's post, my first app is live-ish! Check it out here: [http://psst.fm](http://psst.fm). Note that it is completely bare bones; the main thing with hosting this app was testing out how to publish an app via Heroku and overcoming any troubles that brought. Long term goals for this app include hosting a fully functioning URL shortener with user authentication and pretty graphs for hosted link analytics. Even longer term, I plan on including an API and potential WordPress plugin to replace the JetPack plugin I'm currently using to share links across social networking sites.


RSpec, Heroku, and nine weeks in


*This post is alternatively titled, "Why I will always hate Flash," and details some issues I had with adding a Flash file to my asset pipeline in production.* My first non-tutorial Rails app is live! Well, technically live... Which is the best kind, if you ask me. There's still a ton to do before it's completely ready for production, but I'd like to touch on a hiccup I encountered when deploying the app to Heroku. One important part of the URL shortener I'm creating is the ability to automatically copy the URL generated to the user's clipboard. After researching the matter a bit, I decided on the same method GitHub uses for their site—[ZeroClipboard](https://github.com/zeroclipboard/zeroclipboard). I wanted to do things cleanly, so I added a flash folder to the asset pipeline. I then made sure to add the `flash` folder to my asset path: `config.assets.paths << Rails.root.join('app', 'assets', 'flash')` After following the simple example on their GitHub's README, I got ZeroClipboard working flawlessly on my local server. All good, right? Then came Heroku. I knew I'd have to configure a bit more to get static assets served with Heroku; [their documentation](https://devcenter.heroku.com/articles/rails-asset-pipeline) says as much. I took care to add the `rails_12factor` gem into my Gemfile to make sure all assets were added, but no dice; the ZeroClipboard flash file couldn't be found when the app started. To troubleshoot, I fired up the Heroku bash console with `heroku run bash`. I listed all public assets with `ls public/assets` and ... saw ZeroClipboard! Okay, the file was there, time to troubleshoot further. Next, I fired up the Heroku rails console via `heroku run rails console`. Within the production Rails console, I tried to list the helper path for ZeroClipboard: `puts helper.asset_path("ZeroClipboard.swf")`. That one gave me **nil**, so I knew it was an issue within Rails itself and not just a missing asset. Finally, I headed to StackOverflow to see if others had found similar issues. I found a thread where a person had problems with Heroku [serving images](http://stackoverflow.com/questions/18324063/rails-4-images-not-loading-on-heroku). Among the solutions, the OP found that a combination of adding the gem `rails_12factor` (I'd already added it), and making sure `config.assets.compile` was set to true in production. Such an easy solution, but this proved to be the thing that made loading my Flash file load on Heroku. Hopes that helps anybody in a similar situation!


Serving uncommon assets on Heroku


Short "Road to Rails" update today. This might be the longest I've ever stuck to a New Year's resolution. [A documented 58 days](https://github.com/dstrunk) as of today. I think I pinpointed the secret to sticking with them though: you have to actually enjoy doing them! To be honest, working on Ruby on Rails has been an extremely pleasant experience; the community is great (in my experience, the <abbr title="Matz is nice so we are nice">**MINSWAN**</abbr> concept is still in full effect), the language is expressive, and there are tons of resources available if you get hung up on something. I'm almost finished with my first Rails project of a URL shortener. I've implemented the URL generation, I've added simple analytics to see browser information, time, etc., and I'll be adding user authentication and authorization next. After that I'll clean up the front-end some, focusing on making a pleasant user experience, then we "ship"! When I first started learning back-end web development, I didn't really have clear projects that sprung to mind. My idea was, "I'll pick up the skills necessary to create a social network since social networks are a thing that is popular now." Now that I've been at it for a solid two months, that viewpoint has evolved into "AUTOMATE ALL THE THINGS!" Every day presents challenges that make me further realize just how pragmatic learning a language is, even if you don't plan on "building the next Facebook". From [watermarking images](http://wp.me/p3ERzH-eX) to parsing a CSV and generating reports based on the data, there are tons of reasons why picking up a language would benefit your workflow in most any job.


Two months


Last Friday I attended my first ever Hackathon, and I had a blast! Let's back up a bit. I was recently made aware of a monthly hackathon called [First Friday Hackathon](http://firstfridayhackathon.com/), a four hour event taking place simultaneously around the state of Georgia. Normally, an event like this would be reserved for a larger city such as Atlanta, but surprisingly Columbus was one of the host cities! A friend of mine was going and invited me, and I thought, "Sure, why not." Walking in, I'll admit I was pretty nervous; I didn't know what to expect. Although I only knew my friend, I was quickly introduced to a bunch of people from all walks of life: students, web professionals, DIY-enthusiasts, and hardware and software hackers. The host of the Hackathon, Lucas of [Stand and Stretch](http://standandstretch.com/), gave everyone a brief overview of what could be expected: work on a project of your choosing in four hours, and at the end you will demonstrate your project to everyone, who will then vote on the most innovative project. Other attendees projects ranged from creating an augmented reality game using Unity to developing an automated [USB rocket launcher](http://www.thinkgeek.com/product/8a0f/) that fires based on facial recognition. I was struggling to find a project worthy of a hackathon. In the end, I settled on creating a simple watermark generating script using command line tools and [ImageMagick](http://www.imagemagick.org/) as a proof of concept for future projects. Not the most "wow"-worthy project I admit, but it was something I'd been interested in doing. Here are the steps I took:

- I started by installing ImageMagick and Ghostscript, which honestly took longer than the actual command line scripting did. Those libraries are HUGE!
- After installing, I `cd`ed into the target directory with terminal. Using ImageMagick's suite of features, I determined the target's dimensions using `identify target-image.png`.
- Next, I created an image with a transparent background that was the same dimensions as the target image: `convert -size WIDTHxHEIGHT xc:transparent -pointsize 25 -fill Red -draw "text 230,375 'WATERMARK TEXT HERE'" watermark-text.png`.
- Finally, I used ImageMagick's `composite` command: `composite -dissolve 50% -quality 100 watermark-text.png target-image.png output.png`. Here's the breakdown for those commands: - `composite` combines the images
- `-dissolve 50%` makes the overlay image 50% transparent
- `-quality 100` keeps the quality at 100%
- `watermark-text.png` is the image with text
- `target-image.png` is the original image
- `output.png` is the merged images

Et voila! A watermark for your images. Now that I know how to do this with the command line, my next steps are to use the **rmagick** and **rghost** Ruby libraries (Ruby implementations of ImageMagick and Ghostscript) to develop a web app that can batch process and add watermarks to images. And the use-cases don't end there; theoretically, it would be possible to create a full-featured web-to-print system, where a user inputs information into a form, the form information generates a PDF and the PDF is sent to a printer. Using a service such as [Lob](https://www.lob.com/), even the printing and shipping could be automated via their API, resulting in a potential passive income stream. Perhaps that will be my next hackathon project :)


My first hackathon


It's now week ... I don't even know any more! Week 6, I think. Maybe week 7 officially—my [GitHub contributions log](https://github.com/dstrunk) is showing 51 days now, so there's that. It's been a busy week, day-job-work-wise. That's my excuse for the lack of blog posts (and a somewhat schizophrenic blog post) ... but there's never an excuse for not continuing my Ruby on Rails quest! This week I continued my [URL shortener project](https://github.com/dstrunk/shorter), writing my first unassisted unit and integration tests. The thing I really love about TDD is just how gratifying it is. I'll admit I cheated a bit—creating a model and doing some light validation beforehand—but writing those first tests and seeing no errors made me almost giddy. Next up on that front is collecting analytics for links clicked; browser information, number of clicks, and so on. Oh! Here's one reason why I enjoy Ruby so much: it's so *expressive*. Check out this code for a random upper / lowercase / number generator that is building URLs for the URL shortener:

```rb
def random_string(var_length)
  o = [("a".."z"), ("A".."Z"), (0..9)].map { |i| i.to_a }.flatten
  (0..var_length).map { o[rand(o.length)] }.join
end
```

with that extremely simple two-line method, I'm able to add all letters (both upper and lower case) and numbers, combine them into a single array, and select a random string of any length. Pretty cool huh?\* I also tinkered a bit more on the [Typist](https://github.com/dstrunk/typist) project. It's pretty close to where I want it to be as a boilerplate, but I'd like to make it a bit more modular so parts can be removed / added a bit easier. Welp, that's all this week; have a good weekend and until next time!

<small>* Yes I'm aware I could use [SecureRandom](http://www.ruby-doc.org/stdlib-1.9.3/libdoc/securerandom/rdoc/SecureRandom.html); but creating this method was good practice for me :)</small>


Some clever train-pun title


They say the best way to learn something new is to jump headfirst; immerse yourself, fail early and fail often. Inspired by [this post on 24 ways](http://24ways.org/2013/levelling-up/), I decided to forego tutorials for the week, opting instead to see what I've learned so far. I started two new projects: a type framework (front-end) and a URL shortener in Rails. Learning this way might *feel* less directed / more frustrating at first, but there's a certain satisfaction in completing a project with (little to) no outside help. **On the front-end:** Grid frameworks like [Bootstrap](https://getbootstrap.com) are fine and all, but I personally find the typography to be a bit generic. To that end, I've been working on an internal framework of sorts for easily testing typography for new sites. The project is called [Typist](https://github.com/dstrunk/typist), and it's free to modify as suites your needs. It's built using Sass for easy extendability via variables, mixins and the like, and uses GruntJS to compile CSS with a simple `grunt watch` command in terminal. In addition to that, it has best practices for web typography (including rem support with a pixel fallback for [older browsers](http://theie8countdown.com/)). You can either use it to build your own type framework with the included Sass files, or just use the `index.html` file, dropping in your stylesheet and see how the page is rendered. I believe having a styleguide of sorts for all new projects will help manage an evolving scope, and this project is the result of that belief. **On Rails:** a URL shortener seemed like a relatively easy and practical first project; it can be handy as part of a larger application for facilitating social sharing, and it doesn't have a ton of moving parts. [I previously built a simple one](https://github.com/dstrunk/shorthorse) with Ruby and Sinatra, but wanted to try one in Rails so the option for extendability was there in the future (advanced analytics, user logins, etc). This is an ongoing project, and my first attempt at completing a non-directed project. In keeping with the Rails Way®, a focus on TDD and DRY concepts are important, especially for a non-directed approach by a semi-beginner. In keeping with the "fail early, fail often" mantra, there have been a couple of false starts, but once I got over the mindset of "It has to be perfect the first time," work is moving a little faster. **Other miscellany:**[This is a fantastic post](http://zachholman.com/posts/only-90s-developers/) about how web development was in the 90s. If you ever had gifs on your site that looked like the below, the points Zach talks about will probably resonate with you. <marquee>![remember the 90s? animated quake gif.](http://res.cloudinary.com/dstrunk/image/upload/v1414083568/Avatars_Gaming_Quake_Animated_cdcmi8.gif)</marquee> Until next week!


Off the beaten path


Details are scant at this point in time, but it looks like [Github's](http://github.com/) looking to release a text editor very soon. I was tipped off by a tweet by Addy Osmani earlier this morning:

> Exciting! It looks like [@github](https://twitter.com/github) may be working on a new code editor called Atom: [https://t.co/6E35BS2MXu](https://t.co/6E35BS2MXu) Preview: [pic.twitter.com/rseFQlfVc9](http://t.co/rseFQlfVc9)— Addy Osmani (@addyosmani) [February 26, 2014](https://twitter.com/addyosmani/statuses/438637505500282881)

<script async="" charset="utf-8" src="//platform.twitter.com/widgets.js"></script> Github doesn't seem terribly concerned about keeping the text editor under lock-and-key; the organization [Atom](https://github.com/atom) has been made public with full view of all of the "secret" text editor's repositories. Oh right—by the way, the text editor's code name / real name is Atom. [Here's the website](https://atom.io), though it hasn't been turned on yet. There's also a Twitter account, [@AtomEditor](https://twitter.com/AtomEditor), which, despite their exactly 0 tweets as of this article, has already garnered over 880 followers. After doing a bit of digging, it looks like the editor will be web-based (similar to Adobe's [brackets](http://brackets.io/)?), and looks to work similarly to Sublime. Personally, I'm looking forward to some sort of deep Github integration (why else release a text editor in a saturated market?). I'll leave you with a gif of the editor in action (from their repository): [![85e69ff2-6a93-11e3-89ac-31927f604592](http://res.cloudinary.com/dstrunk/image/upload/v1414083569/85e69ff2-6a93-11e3-89ac-31927f604592_azzv1v.gif)](http://res.cloudinary.com/dstrunk/image/upload/v1414083569/85e69ff2-6a93-11e3-89ac-31927f604592_azzv1v.gif)


Github's new text editor


Have I mentioned how much I love the asset pipeline? Seriously, it's great. For the uninitiated, the [asset pipeline](http://guides.rubyonrails.org/asset_pipeline.html) is a core feature of Rails. At its most basic, it provides a framework to concatenate and minify JavaScript and CSS files. The cool feature that gets me excited about developing within the Rails ecosystem is its ability to write JavaScript or CSS assets in other languages such as CoffeeScript, Sass and ERB. You say, "Okay, okay—but I can do that same kind of thing with a [task runner](http://gruntjs.com)*!" That's true, but that requires configuration, additional dependencies, etc etc. If you want to do the same thing with the asset pipeline, all you need to do is append the desired file extension to your target. For example, if you'd like Rails to parse your CSS with Embedded Ruby (ERB) first, simply append .erb to the file name you're targeting (example.css.**erb**). The asset pipeline will compile the last file extension and work its way inward to the last file extension. A more in-depth example: Say you have a model called `Group`. Group has two attributes, `background` and `color`. Let's also say you have an undefined number of instances for `Group`; these instances can be created and modified by users of your application, and the users can change the `color` and `background` attributes. Now, to take care of applying these attributes, you could either muck around in your view, adding inline styles to your code to take care of the user-generated colors. Or, you could head over to the asset pipeline, append a file extension and have your code compile in a much cleaner way. Here would be your file `group.css.erb`:

```rb
<% Group.all.each do |group| %>
  .group_<%= group.name.parameterize %> {
    background: <%= group.background %>;
    color: <%= group.color %>
  }
<% end %>
```

 Now, when your app fires up, the asset pipeline will compile the ERB, adding any available `Group` instances to your css automatically. Easy, right? And that's just CSS. You can also handle JavaScript in the same way, which one might argue is more powerful and impressive. Also available is the ability to "chain" extensions. For example, **example.css.scss.erb** will compile ERB, then take care of Sass, ending with CSS. Cool, right? That's it for this (brief) overview. Have any more tips or tricks about the asset pipeline? Let me know in the comments! *I'll save task runners for another post :)


That asset pipeline tho


Hiya! Hope your week's treated you well. I received the MEAP version 13 of *Rails 4 in Action* on Monday night. It's very well-written (despite some grammatical errors that I'm sure will be taken care of in the final version), and I'm antsy for the authors to complete it so I can receive my hard copy! I got to working on the newest completed chapter. Needless to say, jumping back into the codebase after a month off felt like this: ![I have no memory of this place](http://res.cloudinary.com/dstrunk/image/upload/v1414083569/Z9rfG_lpcm5c.gif) After the initial "wtf is all this" feeling wore off, I knocked out the new chapter pretty quickly. I'll write a full review of *Rails 4 in Action* in the future (there's a pretty comprehensive review in my drafts now; I'm just waiting for the final book), but I'll share my initial opinionated impressions here: I like this book's approach to Rails dev **a whole lot more** than the Ruby on Rails tutorial by Hartl. Git commits are quicker, tests are a bit more basic (and are truly focused on writing a failing test before generating models, controllers, etc), and the overall writing style is easier for me to understand. That's not to take anything away from Hartl—I'm going through his tutorial in tandem, and it's very well done! It's just, well, different strokes and all that. I've been continuing my work on building the development site I talked about last week. I'm playing with extending layouts a bit more via YAML and Liquid (to a newbie it sounds a lot harder than it actually is). So, for instance, my about page has this additional information in the YAML front matter block:

	---
	layout: about
	title: about

	profile_img: /images/profile.png
	profile_name: Daniel Strunk
	profile_title: Developer
	profile_email: daniel@silentpost.io
	profile_twitter: dstrunk
	profile_fb: silentpost
	profile_instagram: silentpost
	profile_github: silentpost
	---

 From there, I can dynamically insert all of those values with Liquid, and let Jekyll take care of compiling the correct information:

~~~
<div class="about">
	  <img alt="{{ page.profile_name }}" src="{{ page.profile_img }}" />
	  {{ page.profile_name }}
	  {{ page.profile_title }}, Silentpost
	  ...
~~~

That's an extremely simple example of what Jekyll can do. As you can see, **very** simple stuff, but it's really turning me on to the Jekyll ecosystem. I haven't even touched the cool parts yet—things like what it can do with categories and tags. Jekyll's smart enough to group similarly named categories and tags together, and build a site based on that category structure for you. That's a terrible explanation, so I'd recommend [checking out the docs](http://jekyllrb.com/docs/frontmatter/). Until next week!


Captain's log, week 5


Happy Valentine's Day! Today marks a full month of working with Ruby and / or Ruby on Rails! Crazy how time flies. At moments I feel like I haven't [learned anything](http://en.wikipedia.org/wiki/Impostor_syndrome) ... then a question comes along and I find I'm able to explain the concept of [polymorphism](http://en.wikipedia.org/wiki/Polymorphism_(computer_science)) to a fellow Rails traveler. Then I feel a bit better :) It feels good to quantify your work. For me that means looking at my [github profile](https://github.com/dstrunk), where I've racked up 30 continuous days of commits. I'm hoping to continue that streak far into the future.* This week I've been focusing more on alternative frameworks and the Ruby language in general. I started development of a blog / portfolio-type deal hosted on Github Pages in [Jekyll](http://jekyllrb.com), a Ruby static site generator. Github Pages handles most (all) of the heavy lifting in Jekyll on their end, but I had to set up a similar environment on my local server for development purposes. I've been plugging away on *The Well-Grounded Rubyist*; not too many in-depth programs so far there, but it's nice to see the inner workings of Ruby that make the "magic" of Rails possible. *There are no previous commits in my history because of a mistake I made in transferring ownership of my account to a new email address. C'est la vie! In a way it was liberating to start fresh again ...


A full month of coding


So Facebook's [Paper](http://facebook.com/paper) app for iOS is pretty amazing. If you haven't used it yet, I highly recommend it—it's a UX nerd's dream. One thing I particularly enjoyed was the menu button. It's the standard "hamburger" style menu icon, but clicking it transitions the icon into an "X" icon by way of a pleasing little "bounce". After playing with it for a couple of minutes (I was seriously entranced) I thought to myself, "Self? I bet you could do that with some CSS animations and the tiniest amount of JavaScript. So I made this: [codepen_embed height="268" theme_id="4296" slug_hash="hFxIG" default_tab="result"]See the Pen <a href='http://codepen.io/dstrunk/pen/hFxIG'>Facebook Paper menu icon</a> by Daniel (<a href='http://codepen.io/dstrunk'>@dstrunk</a>) on <a href='http://codepen.io'>CodePen</a>.[/codepen_embed] Feel free to use it on your site ... If you're using Bootstrap like so many people these days are, the HTML is pretty much the same (and can be modified to fit perfectly fine). It's only been tested on modern browsers, so some additional CSS *might* be needed to make it gracefully degrade. Enjoy!* * **Note:** the CSS in the Codepen includes `animation-play-state: initial !important;` on the top and bottom bars. This is to override Codepen's insistence on pausing the animation after 5 seconds (despite my embedding the code with "animation should run forever" ???). If you want to use the code in your website, you can remove these lines of CSS from your stylesheet.


Emulating Facebook Paper's menu animation


My first post-Dreamweaver text editor for web development was [Espresso](https://macrabbit.com/espresso/) by MacRabbit. It was (and is!) a wonderful program, featuring visual tools for editing CSS, code folding, Zen coding, the works. It ignited my interest in effective workflow management with regards to development. A few months later, I learned about [Sublime Text](http://www.sublimetext.com/); a workhorse of a text editor that seemed to be endlessly customizable via plugins. Most fantastic thing about Sublime (I think) is the keyboard support—instead of that oh-so-cumbersome mouse, I began to learn how to navigate Sublime projects via keyboard shortcuts only. That, coupled with linting, code-completion and endless theme options saw me using Sublime for the next two years. For this, I'll always have a special place in my heart for Sublime Text.  But lately in my quest for learning Ruby on Rails development, I've decided to attempt a switch from Sublime Text to [Vim](http://www.vim.org/). Don't get me wrong—Sublime Text is a fantastic editor, and with its myriad plugins, Rails development has been a breeze. But personally? I like the nerd factor associated with Vim. Becoming efficient with its commands and never having to take your hands off the keyboard (possible in Sublime Text, I know). The fact that, if I have to SSH into a development environment, that environment will most likely have vim (or some vi-derivative) installed. Past the nerd factor, there are other great reasons to switch to vim. Instead of rehashing, I'll direct you, dear reader, to this article: [Why Vim?](http://www.terminally-incoherent.com/blog/2012/03/21/why-vim/)

## The start of the journey

First I had to learn the basics: how to navigate, how to copy lines and become somewhat proficient in a text editor created almost 25 years ago. I used several resources for this:

- [http://vim-adventures.com](http://vim-adventures.com)
- [http://www.openvim.com/tutorial.html](http://www.openvim.com/tutorial.html)

After learning the basics, I found that the fine Boston Rails outfit [Thoughtbot](http://thoughtbot.com/) uses vim in their everyday dev lives. They posted their [dotfiles](https://github.com/thoughtbot/dotfiles) on Github which have been invaluable in setting up a solid workflow for vim-rails development.

## The scary future

 I'm finding vim to be just as extendable as Sublime Text, though it'll be a while before I'm as proficient in vim as I am there.


Writings on web development, process, and unrelated miscellany.

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