Find rest in other mediums

Last week was one of those weeks we all have occasionally, where the schedule is full, your mind is engaged all week, and yet somehow you're not dead at the end of it. Through a long hard week, I came out of it encouraged and satisfied. It was good, and I think there is a lesson in it for all of us creative types.

This weekend Lindsey and I were able to spend plenty of time together, and spend it immersed in the arts. Thursday night drove down to the historic Greune Hall to see local songwriter David Ramierez open up for Patty Griffin. It was a great night. David is one of the best songwriters out there. Period. If you've never heard him, you really should give him a listen. Patty Griffin was amazing, but that's more Lindsey's jam than mine. But it was a beautiful night. The weather was great, the venue classic, and both performances were outstanding.

Saturday morning we had our quarterly training session for the Austin Stone Story Team, and it was just as filling as it always is. To spend time with our artists, to sit under teaching about the gospel and creativity, and to consider where God has called me to use my talents was such a good, good thing.

Then, Saturday night we went to the Austin Symphony and saw our good friend Joseph play. Joseph is a great violinist and a dear friend. The program was outstanding, with a great variety. With a beautiful contemporary piece, Mozart and Strauss, it was really fun. We finished the night with burgers at Hopdoddy's with Joseph, as has become our tradition.

Spending time with Lindsey and great music was exactly what I needed. After a week of writing and editing for work, technical work and discussions there, I needed to immerse myself in art, specifically a form that I don't deal with every day. Sure, I am always listening to music, especially when I work, but it's not the same as live music. Live music is something special.

So, next time you need to refill, go find a medium that speaks to you, and isn't your own. Go experience new art. Hang out with other creatives. Talk about the things that inspire you. Dream a bit.


→ JavaScript as assembly language for the web?

Scott Hanselman quotes Eric Meijer:

JavaScript is an assembly language. The JavaScript + HTML generate is like a .NET assembly. The browser can execute it, but no human should really care what’s there.

Yeah, this feels right to me. I know many folks had problems with this observation and this post from Scott, but I think it’s dead on.

Honestly, who likes plain JavaScript? Actually, since the advent of Prototype and jQuery, who even writes vanilla JavaScript? I bet the number is lower than you’d think. And there is a simple reason: like assembly was for early computers, the language is an efficient and effective language for the web, while being hard to read and hard to write.

I know, I know, hard is relative. I’m sure it might be easy for you because you’ve been writing it since 1996, but it’s not that easy for everyone. And honestly, wouldn’t you rather write in something like CoffeeScript instead?

The beauty of new tools and language like CoffeeScript and its ilk is in the layers of abstraction and personal choice they offer for developers who still have to work with the universal scripting language of the web. Just like languages that compile to machine code, we are now compiling other languages into JavaScript. And I think that’s a great thing.


→ Microservices architecture

Martin Fowler on the evolving practice of developing Microservices:

In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.

He goes to describe this new this evolving approach at length, and I strongly recommend it.

The most interesting part about this piece may be the most basic. His definition of a ‘component’, the building blocks that comprise a microservices architecture, is “a unit of software that is independently replaceable and upgradeable.” Why is this so interesting? Because in my experience, most enterprise software systems do not think in units this small. In fact, many cannot think this small. Which is why so many are behind the curve in so many ways.


Why I chose a static site for my blog

When I decided to launch code.brianlundin.com I had some firm requirements in mind for the site and blog engine I’d use. Things like:

  • It must be responsive
  • It must be fast
  • It must be cheap
  • It must have an easy to use workflow for writing and publishing posts in Markdown
  • I must have full control over the layout, design and code of the site, and use the responsive framework of my choice
  • It must be fun to develop and maintain

I don’t think this list is the same for most bloggers on the internet, but I bet other developers’ lists would look pretty similar. Of course, the real question is how I decided on a static site, and Jekyll as the engine.

Choosing a static site was easy. I’ve ran several WordPress blogs in the past, both self-hosted and on Wordpress.com, and overall I was happy with them. The amount and quality of features you get for a low price is a great deal. Plus, there are so many plugins and community tools for the platform that if you are choosing a blogging platform from scratch, it’s the easy choice.

But I didn’t want to take the easy choice with this site. The first reason is that it would be overkill. This site is simple. It’s a blog, a few pages, and an RSS feed. All of the features of the Wordpress platform are great, but they would go unused for this site. That’s too much unhelpful complexity.

In fact, the only thing that the Wordpress option had going for it in my mind was the tremendous SEO capabilities of Studiopress’s Genesis Framework, which I have used and recommend. But, after some time playing with Google’s Webmaster Tools and reading the specs at Schema.org, it was apparent that I could easily optimize my own HTML.

The second reason I did not want to go with Wordpress, or its competitors, is a reason that I suspect only other developers will understand. Simply put, I am disconnected from the code that runs my other current site. While I am not familiar with PHP, it’s not that hard to pick up. But sorting through the Wordpress code, and then the Genesis Framework theme code, is just too much for a side project. I could learn it, but it’s so far outside of my wheelhouse that even if I developed a good child theme, I wouldn’t be happy. For this project I want to be more directly involved. I want the site my readers see to be my site, my code.

Which led me to my first effort, creating my own CMS in Rails. A Rails app would satisfy most, if not all, of my requirements. Ruby and Rails are fun, and I know I can make a performant app. Obviously the code and design would all be mine. I started working on the project, and had a good time with it.

For a few hours.

Then I realized the downside of this plan. I have a job, and it’s not building a blog engine. Sure, it’s fun and a great way to learn and find some cool ways to solve new (to me) problems, but it was clear I would never finish on a reasonable timeline, much less when I wanted to.

Additionally, I did not want to run a server somewhere in the cloud. Cloud VPS providers make life easy, and I’ve had good experiences, but that’s not how I want to spend my time just to run a blog. Heroku could make that much easier of course, but that still felt like a bit too much. So in the end I passed on building my own.

All of this left me with Jekyll. After a short bit of time googling for hosting options I saw how easy it was to host a static site on Amazon S3 and use Cloudfront. With this solution in mind, Jekyll had several key things going for it:

  • Jekyll is written in Ruby, so if I need to hack away at it, I can
  • The code runs on my machine, not the server. If I want to make a bunch of changes, tear apart the site and rebuild it, there is no adverse affect on my site. Most blogging engines cannot say the same thing without a whole lot of work and configuration
  • Backing up both my site code and my content would be a snap with Github
  • Integrating responsive frameworks, JavaScript libraries, and anything else would be easy
  • I control the published site code 100%

This list of benefits won the day. The fact that I can host it on S3 and cache my content globally with Cloudfront for next to nothing was just a bonus.

This choice proved to be very good for me. Setup and configuration time was minimal, with the majority of work going into the design and development of the site—which is exactly how I wanted it. Honestly, it’s been a breeze, and fun.


How to be a writer

We use the word 'writer' as a noun, as a job description, but really we use it as an honorific title. Those of us who love the written word struggle with how to bestow this title. We look at that word, 'writer', and see so many things. We see books on shelves, we see interviews in The Paris Review, we see a mythic figure, from whose mind springs whole new worlds. For many of us, we see a writer as one who has written, and one whose work was read and approved of by those who matter.

But, there are big differences amongst those who we could call writers. From the New York Times best-selling author, to the humble self-publisher who no one reads, we naturally see authors on a spectrum and only deem those above a certain point to be "writers." And the ones who are the worst about this, who judge success—or lack thereof—most harshly, and hold back the title most stingily are the people who aspire to the title themselves. I don't think we should look at the word that way.

I'm not suggesting that the title 'writer' is something that anyone should be able to lay claim to. Far from it. I think it should be a slippery handhold at the top of a long climb. I think it should be hard to lay your hands on, and hard to hold on to. I think it should be earned.

But if I do not think the title should be bestowed on only the well-reviewed, the best-selling, or the academic darlings, then on what basis would I commission by fellow artists with that precious word? By looking back to the meaning of the word.

A writer is one who writes. We shouldn't use it as a noun, but as a verb—as a description of action.

That should be the ground on which we claim our title, because writing is a practice. A writer must write every day. It is a muscle that withers easily, it is a skill that fades. And if you aspire to be a 'writer', then on that ground you should judge yourself. Are you writing each day? Or most days? Are your projects moving forward? Do your word counts continue to increase? If yes, then count yourself amongst the ink-stained wretches who seek to make their living with just their words and wits.

This post is motivation for me, even in writing it. Because I'm not a writer unless I'm writing. And lately, I haven't been writing. The circumstances don't matter, in these things they hardly ever do. My pen needs to meet paper more. My fingers need to touch the keys each morning. Because that is how you really become a writer.