Beware the ides of March. But, also beware the dangers of snowboarding without having slept. Late in February I took a trip to Vermont but, it all went downhill after stepping in without enough rest. Needless to say I injured myself. Pretty badly as a matter of fact.
The final diagnosis remains to be determined although I have seen all too many doctors, paid all too many copays, and observed a variety of opinions and I've since exhausted my patience. Bottom line: I don't need surgery. Yippee. But I'm not zipping around just yet. Seems like it'll be a few months before I'm fully operation.
This has given me a lot of time to study when I might have otherwise been busy enjoying walking around or picking up a beer with my right hand. With seemingly endless idle time I figured it was a good idea to start working on one of my new year's resolutions. Which was to get a stronger understanding of Rails.
What makes this especially difficult is the fact that Rails is just a framework (an awesome one no doubt). But, that means it's fare to assume a proficiency in Rails is dependant on a proficiency in Ruby. Being a noob with Ruby and knowing nothing at all about Rails you might expect me to start by reading a book or two. Maybe attend a workshop and watch some videos... After a couple days or weeks of immersing research perhaps I might try coding something simple to start like a blog, or possibly a todo list manager. But if you know me at all you might have picked up on the fact that I can't stand to wait for anything. I was feeling like I should have learned this years ago and there was absolutely no time to waste.
So, I decided to give myself a one week time frame outside of business hours whereby I create a production ready application with modern deployment techniques into a virtual private server. Pretty heavy for a first app. Oh, not to mention it would be used as an internal tool for my employer where by everyone has an individual account, preferences, and role based capabilities. One week... no knowledge of Rails. My colleagues gave me some helpful advice:
"Sir, the possibility of successfully navigating an asteroid field is approximately 3,720 to 1."
I found their lack of faith disturbing. I read and watched and listened and tried and failed and read some more and tried again and eventually I did it. I followed convention and the things is pretty damn performative. Even better it's actually useful. But holy shit did I complicate it. Git based deployment is one thing if you have no callbacks fired after a post-receive hook. But if you're bundling and precompiling assets from the pipeline after checking out a Gemfile, well damn, the permissions better all be in line. All difficulties aside I thoroughly enjoyed the process and have since built several other Rails apps.
I Linux. But my day to day OS is OS X. That may change with time but, for now that's how it is. One of things that suck about developing on a Mac is that there's no package manager. This typically comes up during app development and mostly web based apps. Xcode and its command line tools only take us so far. And since most web apps run on a Linux we inevitably have to install additional software so that OS X can have access to packages we run on Linux. Manually compiling software can lead to dependency hell . Something no one in their right mind actually deals with nowadays. Instead we use package managers and for a long time we all used Macports . Today I want to talk about another option, one that I've come to love, Homebrew. I know what you're finking about. There are more than just two. This is true, but the first two I mention have the largest community support.
"If you're going through hell, keep going." - Winston Churchill
There are plenty of flame wars going on about which is the best and why others aren't as good. I won't get into that. I can tell you that for mobility's sake I became frustrated with Macports and decided to Homebrew a chance. Sorry Winston, but I don't like to continually struggle. If there is a viable alternative, with less headaches, and equal results I'll take it. And I have yet to find a package I need that is not available on either. But Homebrew gets it to you faster. However, making the switch was intimidating. You know, I had a LAMP stack installed and configured, Ruby and gems going, databases, a mail server... Reconfiguring that looks painful. Guess what, it is. But, it's worth it. Do it, and don't look back.
I didn't have any local databases that weren't copies of live servers. So I didn't back them up, I opted to recreate them from the production environment. Other than that, if you have some incredible ini/config files you can't live without go ahead and back them up. But there's something to be said for clean slate. We all love a fresh start, it polls well across the board. Give yourself a chance. Here's how:
Kill running lamp processes or restart. After that Macports is gone. You should feel vulnerable at this point. You have nothing. Rise from the ashes of the phoenix and meet your make file. Right, so now you want to install Homebrew. Prerequisites include the latest Xcode and command line utilities.
God damn that was easy. Too easy in fact. There may be a little tidying up to do. Follow the prompts given by the following command. There may be existing packages you've compiled manually, and modifications to your path, or permissions problems, all of which were already problems but Macports never mentioned them. Take the time, clean house, feel good.
After that's done. You're ready to get all the brew you want. But I'll hold your hand a little longer and outline an AMP stack. To start use Mac apache, its fine. Autostart it now.
Get a better PHP though, the default doesn't have a lot going on. Jose Gonzales is running an excellent repo that contains a multitude of packages for a number of different versions. Choose the one that's right for you, which should be 5.4 at the time of writing this. But, if you need backwards compatible support do what I did.
brew tap josegonzales/php
brew install php53 --with-debug --with-imap --with-tidy
You can add as many additional packages as you like, such as
Get MySQL and follow the instructions on screen. Be sure to update you MySQL socket to match what you've chosen during the installation. To configure it, edit the /etc/my.cnf file. Yes go ahead and create it if it's not there.
brew install mysql
Andddddd we're done. If you find yourself needing more packages look for them without leaving your terminal. Fire at will.
brew search imagema
brew install imagemagick
For Ruby management I'd suggest RVM , a powerful little tool that makes jumping from one Ruby version to next less painful.
An old friend of mine used to like to say that recursion is divine. A recursive process is a process that repeats itself which is a very powerful ability in computing. But while impressive I was draw to other aspects of the science. For a long time I clung to the fact that computer science is mainly logic. To this day I very much appreciate that fact. However, I've come to appreciate the creative side of this field more and more with experience. I've diligently studied languages, math and computer science for many years. Although I'd be hard pressed to call myself a mathematician, or a master of linguistics, I do consider myself a polyglot and computer scientist without a doubt.
"Numbers rule the universe." - Pythagoras
It's easy to find the beauty in languages. And while math is commonly referred to the universal language it's fair to say that it's beauty can be overshadowed by it's complexity. Before learning a strong understanding of the language itself I found myself obsessing over the grammar, syntax and semantics of math. Dissecting how things were said seemed more interesting than what things were said, or at least easier to grasp.
Consider for a moment that there are varying degrees of infinity. Don't take my word for it, read up on Cantor. To say it plainly, there are infinitely many infinities greater than infinity. English just isn't well suited to articulate these sorts of things. Part of the beauty of math is that you don't need English to explain it.
for any set A, |P(A)| > A
Basically, the set of all subsets or powerset of a set is greater than that set. The explanation of the proof while very interesting is a bit outside the intended scope of this post. Before having an understanding of the proof of this theorem consider how eloquent the line above is. It's the concise manner in which this complex concept is articulated, its brevity. That's what's so fascinating about linguistics. It's efficiency embodied. This is one of the artistic sides of computing. So, while it seemed like a logical field to pursue it turns our I'm sticking around for it's beauty.
Before we understand our native languages we speak words in that language. Eventually, we're not just mimicking and we start to actually articulate concious thought. It's the difference between the ability to concatenate isolated words and the ability to articulate fluid expressions. Whether writing C#, Python, French, or Chinese, the learning processes is occurs in this manner. To my surprise I found that the beauty in learning math or computer science is that it is a means of expression, a creative outlet. And, for that reason I'll strive to remain teachable and open minded.
So I'm at a bar not too long ago, when a confused gentlemen walks in. Behind the bar tender was a wall of whiskey. No less than several hundred different kinds were available. The place, On the Rocks, very clearly specializes in whiskey. It's a whiskey bar. This guy asks for a "whiskey on the rocks." I think it's a safe bet that most bars have a least two kinds of whiskey on hand. My knee-jerk reaction:
What the hell man? Can't you see where you are? Why don't you just leave and stop wasting this man's time. SMH
But, it's not necessarily a stupid question despite how poorly it was posed. So the Bartender replies:
"Sure what kind would you like?"
"Oh I don't know a brown one, I know Jameson but if you can show me maybe..."
They both look at a wall of whiskey. Although maybe only one guy really looked.
"Tell you what, if you like Jameson you'll really like this."
Surprised by how cool the bartender was – even with a full house – I tried to relate. Following status quo, or meeting the bare minimum just isn't enough. At least not enough for the bartender, and not enough for me. But the bartender excelled where many of my colleagues in tech might have failed, and where I know I have failed many times. Sharing knowledge is the key although sometimes not appropriate.
In this scenario the gentlemen clearly had no understanding of whiskey, yet had placed an order and expected service. The bartender could have explained to him that whiskey is a type of distilled alcoholic beverage made from fermented grain mash. And that different types of grain are used for different types of whiskeys. And then polled him further to find out what kind of flavors he likes to compare it to the types of grain used in some of his available stock. Instead, he created his best proposal for his client based on what he already knew about this person.
It's my job to not only design and develop new technology for our clients, but to explain to them why it tastes better – even if to them it tastes the same. If they need to have an understanding of HTML before moving to sever side, that's my job too. Knowing when to explain the origins is a difficult part of this task. Here's an example.
Let's say I've taken an archaic system that writes new form entries directly into a text file as a means of storing information. Now let's say I just replaced that system with a relational database that backs itself up daily and includes a web based reporting interface that requires no programming knowledge to operate.
What is a relational database, how does this improve me life? Can I scan it with my QR reader? Can I download it?
Remember, the client didn't know whiskey was made of grain. In order to prove this tastes better I find it's easier to accentuate the improvements through demonstration – an actual use case. It's hard enough to write the code, now to explain it in English...
The guy was ultimately dissatisfied. Apparently he didn't like whiskey at all. Another drink down the drain. But we'll continue to concoct more, whether they appreciate it or not. Because no one prides themselves in fixing the same drink everyday.
This is the fifth blog I've built for myself and the only one that still lives. Although this site is in its infancy I have a strong feeling this will take me far. The most difficult part of maintaining a blog, for me anyway, is surprisingly enough not actually writing the post. There will be grammatical errors, spelling mistakes, a lack of clarity in thought... that doesn't bother me. I'm not overly self-conscious about the quality of the writing found here. These days, I'm first and foremost a programmer. Some of my best writing is never actually read by a human but only experienced. I like that about my work. But I enjoy having another creative outlet and means for expression. That being said, even though I hope non-developers will find something interesting here I imagine most of the posts to be relating to my work in some way. Unfortunately, for the members of the aforementioned group this first post is entirely technical. The reason I have a good feeling about this go-around is because of the way the site is constructed.
Of the previous four, the only blog I had written in with any extended period of dedication was a blog completely unrelated to my professional life. It was about music and it was entirely for amusement. It was built on a notorious platform, Wordpress. It was my first blog, I designed a simple theme, I coded it, and got my first hosting account, and I put it together myself. That part too was fun. At the present time, I couldn't tell you how many Wordpress sites I've built. At some point the Wordpress UI became so bloated with features it became difficult to to write a simple post. For example, in most posts there are a paragraphs and possible an image. Shouldn't require a lot of though. But, with the introduction of custom fields, post-types, menu items, etc. etc. I found myself spending more time working on the site than actually writing content. It's not that I found the features overwhelming, just unnecessarily complicated for the average blogger. I tried several other platforms and they all just felt dirty. In looking for a new alternative I had only one requirement, easy publishing.
I choose to host this blog freely on Github, where publishing is managed through a distributed versioning control system called Git, and where I most easily could write entries via VIM. Probably doesn't sound too easy to most people and I guess it's not really. Here's the thing about me, I love the terminal. I like a black screen, white letters, no mouse, no buttons. I like seeing everything happen on a lower level. Things like Microsoft Excel literally frighten me. I like having greater control. As such, my comfort zone is in the terminal. I wrote this post with a text editor that was first released in 1978. Guess what... it's still the best. We can talk about it some time but, the point is that it is was easier to write an article this way. Even easier than writing an article in Microsoft Word thanks to a markup language called Markdown.
But Matt, I don't understand how learning yet another language could be easier than using a WYSIWIG, or even some simple HTML.
If you used a WYSIWIG for an extended period of time, you know it does some absurdly annoying things. Puts line breaks where you don't want them, throws empty div tags in randomly, alignment pft... yeah. No fun there. Simple HTML is fine, if you prefer HTML, that is all valid is Markdown. But, seriously, take the 15 minutes to learn markdown. It's easily worth it the time it takes.
Ok so let's say I learn Markdown and yes, its amazeballs. Why is publishing so easy?
The publishing part should be straight forward for anyone considering themselves to be a developer. Have you ever heard of Linus Torvalds? If not you probably already stopped reading. Here's my publish button:
$ git commit -m 'Post: Form V. Function' && git push
Github not only offers free hosting, but allows users to publish Jekyll based blogs on a push and runs the auto-generation of the site converting it to static HTML. Pretty cool stuff, geek out and read the documentation . The point is, with this setup it's actually fun to write again. One of the awesome parts about using Jekyll as my platform is that I can easily change the design and layout of the site. So if this does keep my interest it won't be too difficult to change. Yay! Hope you enjoyed this a bit, there's more to come.