jmmcduffie.com

Nodevember 2015

Fri, 20 Nov 2015 00:00:00 GMT

Last weekend I had the privilege of being able to attend Nodevember 2015 with several of my fellow team members. It was a great experience overall and I’m grateful that I went. Since I’ve been wanting to be better with writing on my blog, I decided to take this opportunity to type up my thoughts and share them.

One big thing that stands out is how well organized Nodevember was. Registration was simple and the signage was perfect. I never felt lost (except when trying to remember where the car was parked—but that’s my fault).

The conference swag, both from the organizers and the sponsors, was awesome. I was very pleased with the stickers, tee shirts, and socks that I picked up. And there was a ton of other cool stuff that I didn’t get.

The food was unbelievable. Instead of the usual conference fare we were treated to high-quality meals that represented some of Nashville’s food culture. (Hot chicken? Heck yes!)

There were also a lot of great things about the format. The low ticket price and weekend schedule make it very accessible. The 30-minute sessions felt just right to me—long enough to get at least a few nuggets but short enough to keep everything moving at a good clip throughout the day. The breaks in between were perfect for getting to the next session and even networking a little in between, although the lunch break felt just a tad too long to me.

It is, of course, the content that really makes or breaks a conference. And with two days and multiple tracks there was plenty of it.

To be honest, the opening keynote by Yehuda Katz was a huge disappointment. What started out as an interesting discussion of the merit of frameworks turned into an extended sales pitch for Ember. The “live-coding” video that made up most of the talk was almost impossible to read from where I was sitting. I really wish he had spent more time talking about frameworks as empowerment and skipped the Ember demo. It felt less like a keynote and more like what should have just been an Ember session at the conference.

There were a couple of other “sour notes” as well. Some of the speakers badly ended what was otherwise a good session by continuing to take questions after their allotted times instead of dismissing the group and sticking around to answer questions one-on-one. Another speaker changed his topic but didn’t tell anyone until his time began, which was too late to make it to another talk.

Fortunately, those (mostly) minor annoyances were more than made up for by the rest of the content. Here are a few of my highlights:

Rey Bango’s openness and vulnerability about struggling to learn Node.js were very encouraging and engaging.
Robert DeLuca’s concept of “accessibility debt” was brilliant.
Soledad Penadés’s second-day keynote about “Healthy Egotism” was a much-needed reminder for everyone about the importance of taking care of yourself.
Kyle Simpson’s talk about async programming and specifically CSP was mind-bending. I was excited to hear him speak in person.
Aimee Knight’s talk about lessons learned since graduating from NSS was awesome and plenty useful for all skill levels.
Laurie Voss from npm gave an excellent overview of SOA that was useful whether you’re working with Node or not.

This has been an interesting year for conferences in Middle Tennessee. With the demise of both DevLink and Coderfaire (at least for now) and the start of Music City Code, the landscape has really shifted. Fortunately, Music City Code came out of the gate strong—in fact, it was so polished that it didn’t really feel like a first-year conference to me. And this year’s Nodevember was truly impressive, both compared to what they did last year and to what anyone would have reasonably expected for a second year. I think we’re very fortunate here in Nashville and I’m excited to see how our community continues to grow.

Ruby on Rails on OS X Yosemite

Wed, 28 Jan 2015 00:00:00 GMT

Recently I decided to replace my nearly seven-year-old MacBook Pro with a brand-new one. As I sometimes do in situations like this, I decided to set everything up from scratch rather than restoring from another device or a backup. Since I was running Mavericks on my old laptop, this meant getting a development environment going on a new version of OS X. It was a straight-forward process but I decided to document it for my own reference and share it in case someone else can benefit from it.

General Setup

The first thing you need for development on a Mac is the Xcode command-line tools. Fortunately, installing them is quite easy these days:

xcode-select --install # then click “Install”

Using a package manager makes everything a little easier (in my opinion), and I always reach for Homebrew:

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
brew doctor # and then follow the instructions (if any)

I ran into permission errors the first time I tried to install any packages so I had to chown the /usr/local directory to clear those up.

# You might need to do this too
sudo chown -R $(whoami) /usr/local

Once Homebrew is in place you can install Git and Node.js. Even though I develop in Rails, I constantly find myself in need of Node for front-end work. Also, if you plan on using GitHub’s Atom editor you’ll want Node to enable its command line tools. (For whatever reason, installing node didn’t expose npm to the $PATH, but installing it as npm did.)

brew install git npm # not ‘node’

# Go ahead and do this if you know you’ll need Grunt
npm install -g grunt-cli

You might elect to install Postgres with Homebrew as well, which I have done in the past. This time, though, I decided to give Postgres.app a try. After downloading and dragging to the Applications folder, I updated my $PATH to enable command-line usage:

# in ~/.bash_profile
export PATH=$PATH:/Applications/Postgres.app/Contents/Versions/9.4/bin

Ruby Setup

Ever since I started learning Ruby and Rails I’ve used RVM. It’s also what my box at work is running. But this time I decided to give rbenv a shot instead. I know other devs who use it, and it’s actually what the Rails team recommends, so I figured it wouldn’t be a bad idea to try it.

Setting up rbenv is quite simple. I recommend using Homebrew to install it, and unless you plan to manually compile your Ruby versions from source I’d recommend the ruby-build plugin:

brew install rbenv ruby-build

# in ~/.bash_profile
export RBENV_ROOT=/usr/local/var/rbenv
if which rbenv > /dev/null; then eval "$(rbenv init -)"; fi

I elected to install a few additional plugins as well:

mkdir $RBENV_ROOT/plugins

# gem-rehash
git clone https://github.com/sstephenson/rbenv-gem-rehash.git \
$RBENV_ROOT/plugins/rbenv-gem-rehash

# default-gems
git clone https://github.com/sstephenson/rbenv-default-gems.git \
$RBENV_ROOT/plugins/rbenv-default-gems

# binstubs
git clone https://github.com/ianheggie/rbenv-binstubs.git \
$RBENV_ROOT/plugins/rbenv-binstubs

Regardless of whether you do that or not, you should be all set up to install and run a version of Ruby. I downloaded 2.1.1 for this blog, created .ruby-version, and generated a binstub for Jekyll.

rbenv install 2.1.1
rbenv local 2.1.1 # creates .ruby-version

bundle binstubs jekyll

That’s it! It seems like getting up and running with Rails gets easier all the time. And that’s certainly a good thing. Happy coding.

Shameless Plug: Are you a Rails developer? Are you interested in work that matters? We’re hiring!

Git Tips: Setting the Stage

Thu, 10 Jul 2014 00:00:00 GMT

Sometimes when I’m working on a project I’ll realize that I’ve bitten off too much code at once. My preference is to keep each commit as small as possible while still providing some kind of value, i.e. deliver working software frequently. But occasionally I will have already started into another feature before getting the first one committed. Or worse, sometimes I’ll be in the middle of one task and notice a bug or opportunity for enhancement that I just go ahead and address. In either case, now my working copy is a mixture of what should really be two separate commits.

Savvy Git users already know that you can stage everything or just specific files using git add <pathspec>. But what if you’ve made multiple changes within the same file and you don’t want to stage all of them? Fortunately, there is a way to stage only the changes that you want to commit.

The git-add command accepts a --patch (or -p) flag that allows you to review each diff and decide whether to stage it or not. Stepping through the file(s), at each point where there is a diff you can choose to either skip that change, stage it, break it down into a smaller hunk, or a number of other actions.

Changes that are in separate parts of a file work especially well with patch mode—Git has a harder time separating diffs that are very close together. In those cases you have to make a call about whether the changes really need to be separate, and require manual editing, or if it’s logical for them to be released together.

With features like patch (just one part of git-add’s interactive mode), Git makes it possible to set up each commit exactly the way that you want.

Progressively Enhanced Single-Page Navigation

Mon, 30 Jun 2014 00:00:00 GMT

A common pattern on the web today is that of navigation within a single page. One sees this technique used frequently on marketing landing pages, where a larger amount of content will be contained within one page. Each link in the nav links to a spot on the page, and usually that spot scrolls smoothly into view when the link is clicked.

Recently a new developer asked me how to make a nav like that. While my suggested implementation is certainly not complex, my approach might be instructional as an example of progressive enhancement. People don’t talk much about progressive enhancement anymore but it is still my preferred and recommended methodology.

Progressive enhancement is all about layers. The idea is to break the implementation into its simplest, most bulletproof form and build that first. I call this the “baseline experience.” From there, one layers additional style or behavior on top of that foundation to achieve the desired effect. If any layer above the baseline experience fails, the implementation will still stand.

With something like in-page navigation, there is a very clear starting point. HTML already provides a way to link to a specific region of the page using a fragment identifier. For example, given that the page has a <section> element with an ID of “features,” one can link to that <section> with the HREF “#features,” i.e. <a href="#features">Features</a> will move the viewport to <section id="features">.

So the first step is to build a navigation menu using the built-in semantics of a <nav> element and an <ol> of links:

	<nav role="navigation" class="Navbar">
	<h2>Primary Navigation</h2>
	<ol>
	<li><a href="#features">Features</a></li>
	<li><a href="#how-it-works">How It Works</a></li>
	<li><a href="#pricing">Pricing</a></li>
	<li><a href="/signup">Sign Up</a></li>
	</ol>
	</nav>

	...

	<section id="features">
	...
	</section>

view raw markup-1.html hosted with ❤ by GitHub

That implementation alone will meet the requirements of in-page navigation. Clicking one of the links using a fragment identifier will move the viewport to that section. But although technically correct, this approach leaves something to be desired. The links need an additional behavior added.

Web development has come a long way since the days of inline JavaScript and CSS. My current thinking with binding JavaScript behaviors to HTML is to use data attributes to extend the semantics of the element. By adding data-behavior="foo" to an element, I can communicate that it has additional metadata and add a way to bind JavaScript functionality to it.

Step two is to use data attributes to declare that some of these links have an additional behavior:

	<nav role="navigation" class="Navbar">
	<h2>Primary Navigation</h2>
	<ol>
	<li><a href="#features" data-behavior="scrollTo">Features</a></li>
	<li><a href="#how-it-works" data-behavior="scrollTo">How It Works</a></li>
	<li><a href="#pricing" data-behavior="scrollTo">Pricing</a></li>
	<li><a href="/signup">Sign Up</a></li>
	</ol>
	</nav>

view raw markup-2.html hosted with ❤ by GitHub

The final step is to write a little JavaScript to define what the scrollTo behavior actually does. My implementation uses jQuery, but obviously that is not a requirement. I add an event listener to the body to detect clicks on links with the data-behavior="scrollTo" attribute, verify that a fragment identifier is present, scroll to the identified element, and prevent the fragment from being added to the URL:

	// Add an event listener to the document
	$(document).on( "click", "a[data-behavior='scrollTo']", function(event) {

	// Check for a fragment on the clicked link
	// `this.hash` = the fragment identifier
	if ( this.hash !== "" ) {

	// Animate the viewport's scroll position
	$("html, body").animate({ scrollTop: $( this.hash ).offset().top }, 500);

	// Prevent the fragment identifier from being added to the URL
	// This at the end in case the script fails before this point
	event.preventDefault();
	}
	});

view raw behaviors.js hosted with ❤ by GitHub

Now clicking one of the links will smoothly scroll the viewport to the right spot on the page. And should the JavaScript fail to run because of an error or a slow connection, the links will continue to point to the right spot on the page. In fact, if JavaScript breaks during the execution of that event handler it will degrade gracefully because the call to preventDefault is at the very end.

There are obviously many other enhancements that could be made, such as automatically updating as the user scrolls. But again, at this point any additional layers are just gravy. The meat of the interaction is a plain old HTML link with a fragment identifier. And in an nutshell that’s what progressive enhancement is all about: layers of added functionality; JavaScript on top of CSS on top of HTML on top of HTTP.

jmm

Forward Thinking for Backwards Compatibility

Mon, 24 Jun 2013 00:00:00 GMT

My first gaming console was an SNES given to me as a Christmas gift by my aunt and uncle. Later, they gave me their own Sega Genesis when I got hooked on a game after playing it at their house. And several Christmases after that, they got me a Playstation. The GameCube was the first console that I saved up for and bought myself.

I remember each of those moments vividly. I look back on the hours I spent playing games like Super Mario World, Shining Force (I and II), Spyro the Dragon, and Super Smash Bros. Melee (my primary motivation for getting the GameCube) with that warm, fuzzy feeling of nostalgia. My SNES and Genesis consoles and cartridges are long gone, and my Playstation and GameCube have been passed on to younger siblings (though I kept some of the games), but I will always cherish those memories.

Great franchises like Zelda, Rayman, and Sonic the Hedgehog have lived on to see new installments on the latest and greatest technology, and for that I am abundantly grateful. However, I was almost as excited to download Shining Force again from the Wii Virtual Console as I was to buy Super Smash Bros. Brawl. Those old games still hold a certain charm. Resources like the Wii Virtual Console and the PSN Store have not only enabled me to enjoy games from my youth again, but they have also given me the opportunity to play games that I missed out on, like Super Mario RPG and Metal Gear Solid. Even with all of the newer games on my “must-play” list, sometimes nothing hits the spot like a retro game.

I dredge up all of that (probably boring) history to make a point: good games are timeless. Like in film, our modern achievements are standing on the shoulders of the classics. I think that any gamer can understand this. What I don’t understand is why the game companies don’t really seem to value their own art form.

Ever since the XboxOne was announced, the hot topic in the gaming world has been Microsoft’s draconian DRM restrictions. Even with their subsequent reversal, the discussion rages on. But while Sony and Microsoft have both announced consoles without backward compatibility, no one is really talking about it.

One exception is this excellent article from Gameological Society. As I read that, it deeply resonated with me. I was truly disappointed to see it drowned out in the cacophony of “Microsoft Sux!” and “Sony Won E3” headlines.

While certainly not a poster child for modern gaming at this point, I think that Nintendo is the only one to have gotten this right. The Wii supported GameCube discs (at least originally) and the Wii U supports Wii discs. They have provided one generation of backward compatibility, with older games delivered through an online store–although the extremely limited selection in the Wii U’s Virtual Console is disheartening. I haven’t purchased a Wii U yet, but when I do I’ll still be able to play all of the Wii games that I have accumulated over the years.

Why couldn’t Sony and Microsoft have done the same? I have invested a significant amount of money in PS3 games, even in the short time that I’ve owned the console. I plan to purchase many more PS3 games as I work my way through everything I’ve missed and stellar new titles like The Last of Us. If I buy a PS4, I’ll have to keep my PS3 around to play those games.

The stock answer for this conundrum is that it isn’t possible for new hardware to support legacy games, that it would be too expensive. Basically what we’re saying is that backward compatibility isn’t compatible with forward-thinking.

I strongly disagree with that sentiment. I also strongly agree with this one from the aforementioned Gameological Society article:

Shunning support for older games isn’t just bad for players—it denigrates the entire art form.

Yes, I understand that to take the XboxOne and PS4 and make them able to play discs from the previous generation would be expensive and technologically challenging. That obstacle is not lost on me. But what if we were having this discussion at the beginning of the product’s development cycle and not at the end? What if the console had been engineered from the beginning to be backward-compatible?

In my opinion, the problem here is not a technological one. The problem is one of ideology and of culture. If Sony and Microsoft held backward compatibility as a core value, it would have informed their design choices with the next generation. It would have changed the way that they approached it.

Wouldn’t that have held us back? I don’t believe it would have. Creativity is by definition born within constraints. I am not knowledgeable enough about the domain of console development to speak authoritatively on the matter, but as a software developer I do know that design is always about compromise. “A thousand no’s for every yes,” like that Apple video says.

Backward compatibility matters. Current consoles should play at least the previous generation’s games, and games older than that should at least be made available digitally. Ideally, we shouldn’t have to buy those games again either. What if Sony or Microsoft (or Nintendo) “moved the industry forward” not by cutting off support for current and classic games, but allowed us to digitize them and play them on our next-generation consoles (a la iTunes Match, for example)? That’s a future I could get excited about.

The problem is that we are allowing good things like better hardware (or foolish things like integrating with TV service) get in the way of the most important things. I for one care about the timeless experience of a well-crafted game far more than about hardware specs. And I care about sharing those experiences with others far more than “social gaming” features.

I think we need to remind the game developers and console makers what really matters. We have been very loud about DRM–and people are still talking about it. We should be just as loud if not louder about the issue of backward compatibility. Let’s talk about the meaningful experiences we’ve had with our games. Let’s celebrate gaming as the art form that it is and not allow its history to be ignored.

Using Turbolinks with Typekit and Google Analytics

Fri, 02 Nov 2012 00:00:00 GMT

This week I decided to try out Turbolinks here on my blog in advance of its inclusion as a part of Rails 4.0. With as simple as my site is, I didn’t expect there to be much of an impact overall. But I was mistaken.

After adding Turbolinks, I saw a huge increase in the speed of my site. Page loads felt almost instantaneous upon clicking a link, and got even faster as Turbolinks cached requests. The documentation claims that Turbolinks will increase speed by 2-3 times, and though I don’t have any hard numbers I can attest to the noticeable zippiness.

The only problems I encountered were when trying to get Turbolinks to play nicely with Typekit and Google Analytics. Typekit was causing Turbolinks to invalidate its asset cache and do full page refreshes instead of using pushState. And Google Analytics was not tracking page views after the initial one.

To compound the issue, I experienced a “Google drought” when searching for possible solutions. Fortunately, I was able to piece together a solution for both problems myself using what I did find. I hope by documenting them here I’ll save someone else that trouble.

As far as I can tell, the key is to make sure that Turbolinks is included after any other referenced JavaScript files but before any inline JavaScript. Otherwise Turbolinks will do full-page reloads every time because it thinks that the assets have changed.

In the case of Typekit, their snippet involves two components: an included file from their server and an inline script to load the fonts. The former should come before application.js (which is where Turbolinks will be loaded if you’re using the asset pipeline) and the latter should come after, like so:

%script{ src: '//use.typekit.net/<your_id_code>.js' }
= javascript_include_tag 'application'
%script try{Typekit.load();}catch(e){}

The Google Analytics issue is also simple to solve. Since their asynchronous snippet is inline JavaScript which dynamically generates a script tag, make sure to include it after Turbolinks. Then, to track page views whenever Turbolinks updates the page, add the following line to the Google snippet:

document.addEventListener("page:change", function () {
  _gaq.push(["_trackPageview"])
})

This hooks into a custom event that Turbolinks fires each time the page is updated (page:change) and ensures that Google is called each time as well. Fortunately, since every browser that supports pushState supports addEventListener as well, you don’t have to worry about cross-browser event handling.

That’s it. By getting everything in the right order and adding one simple event listener, I was able to reap the speed benefits of Turbolinks and still use the external libraries I needed. I hope this post saves somebody a little time and frustration.

Bible Study: 1 Peter 4:12–5:14

Sun, 22 Apr 2007 00:00:00 GMT

This is the application essay from a Bible study that I was assigned to for my Spiritual Formation class.

In 1 Peter chapter 5, Peter instructs elders as their fellow elder and witness of the sufferings of Christ, and a partaker also of the glory that is to be revealed, (1 Peter 5:1) clearly establishing his authority but also setting up his next topic: being an example.

He gives the elders one instruction: shepherd the flock of God among you, and then lays down how they are to carry that out (5:2). He instructs them that they are to exercise oversightin three ways; not under compulsion, but voluntarily, according to the will of God (5:2); not for sordid gain, but with eagerness (5:2); and not as lording it over those allotted to [their] charge, but proving to be examples to the flock (5:3).

In the preceding passage, Peter draws out the idea of setting an example but applies it to the entire body of believers. He urges the church to do what is right, saying, “Make sure that none of you suffers as a murderer, or thief, or evildoer, or a troublesome meddler (4:15).” This is a point that he has been making throughout his letter. He then gives instructions for those who suffer as Christians, saying that they are not to be ashamed, but [are] to glorify God in this name (4:16) and that those also who suffer according to the will of God shall entrust their souls to a faithful Creator in doing what is right (4:19, emphasis mine).

Why does Peter say these things? His reason is in verse 17: “For it is time for judgment to begin with the household of God.” Even—perhaps especially—in the midst of suffering it is the church’s responsibility to set an example by doing good. Peter goes on to say, “[A]nd if it begins with us first, what will be the outcome for those who do not obey the gospel of God? And if it is with difficulty that the righteous is saved, what will become of the godless man and the sinner?” (4:17-18). Peter seems to be saying that if the church cannot even set a godly example, how then will the unsaved come to know the gospel?

Peter writes these things to his first century readers, but they are just as applicable to the body of Christ today. Though persecution, for the most part, is something that we are unfamiliar with, there are other kinds of suffering that we face. To some extent, even our responsibility to deny ourselves the pleasures of our sin natures can be painful though it is for our good. Peter calls the believers to live lives of conformity to the example of Christ, setting His example forth for those who are unsaved so that they may see your good works, and glorify your Father who is in heaven (Matthew 5:16).

*All Scripture quotations come from the New American Standard Bible unless otherwise noted.

Thoughts on 2 Timothy: Chapter 1

Wed, 18 Apr 2007 00:00:00 GMT

I know I’m long overdue for an update and I plan to give one soon. But I wanted to share some thoughts from my personal Bible study for today.

In my Spiritual Formation class today we talked about the divine inspiration of the Bible. A seminal passage for this doctrine is 2 Timothy 3:16,17: “All Scripture is inspired by God and profitable for teaching, for reproof, for correction, for training in righteousness; so that the man of God may be adequate, equipped for every good work.” Dr. Gombis talked about the phrase “inspired by God” literally meaning “God-breathed,” produced by His creative breath; His very Word. This is the same terminology used in Genesis 2:7 to describe God breathing His life into man, and in Psalm 33:6, which says, “By the word of the LORD the heavens were made, / And by the breath of His mouth all their host.” This is a powerful image. The very same breath of God which created the spark of life in you and me also breathed life into the Scriptures.

Paul has a lot to say in 2 Timothy about the gospel. What is the gospel? Paul describes it three ways: “the testimony of our Lord” (1:8), “the standard of sound words” (1:13), and “the treasure which has been entrusted to you [Timothy]” (1:14). Each description comes with an instruction: “do not be ashamed of the testimony of our Lord or of me His prisoner, but join with me in suffering for the gospel” (1:8), “Retain the standard of sound words which you have heard from me” (1:13), and “Guard… the treasure which has been entrusted to you” (1:14). Paul takes the gospel very seriously and expects Timothy to do the same.

The gospel is the testimony of our Lord and Savior Jesus Christ, through which He “brought life and immortality to light” (1:10). For this gospel, Paul was appointed “a preacher and an apostle and a teacher” (1:11); and for this gospel Paul is suffering (1:8,12,15). He calls Timothy (and by application, us) to do the same. Paul draws a sharp contrast with this instruction: “do not be ashamed… but join with me in suffering” (1:8, emphasis mine). He makes this contrast again, speaking of himself, in verse 12: “For this reason [the gospel] I also suffer these things, but I am not ashamed” (emphasis mine). And later in the chapter he talks about two different reactions to the gospel and Paul’s suffering for it: those who “turned away” (1:15), and Onesiphorus, who “was not ashamed of [Paul’s] chains” (1:16). Paul seems to be drawing a picture that suffering for the gospel and being ashamed of the gospel are mutually exclusive: they are polar opposites. Later in 2 Timothy, Paul says, “Indeed, all who desire to live godly in Christ Jesus will be persecuted” (3:12). We believe an unpopular message and we have to choose either to be ashamed of it and turn away or to suffer for it when the time comes.

Paul’s other instructions regarding the gospel show how it is to be treated. He instructs Timothy to retain it and to guard it. Retain, according to the dictionary, means to keep possession of, to continue to use or practice, and to keep in mind or remember. The gospel is the standard for how a man (or woman) of God is to live. But he must keep it in mind, or as Paul says in 1 Timothy he must be “constantly nourished on the words of the faith and of the sound doctrine” (4:6). To guard speaks of protecting and watching over something and it also involves holding something close. Protection works in two ways. To protect something, you must keep outside influences from damaging it, but you must also not allow it to slip away. In applying this to the gospel, the man of God must not allow the gospel to be tainted or warped, but he must also keep it in mind so that he will not forget it. Paul is describing the gospel as a precious gift that has been entrusted to Timothy and that he must diligently guard “through the Holy Spirit who dwells in us” (2 Timothy 1:14). We as men and women of God are to do the same.

A final thought: In chapter 1, Paul gives five instructions, or four instructions and a reminder. The four instructions I have already mentioned. The reminder is in verse 6, where Paul says, “I remind you to kindle afresh the gift of God which is in you through the laying on of my hands.” What is this “gift of God” which is in Timothy? It could be a host of things, and the emphasis seems to be that Timothy is to approach his ministry with renewed intensity as Paul is passing him the baton. I think that part of this “gift” is the gospel, because 1) each of the other four instructions refer to the gospel, and 2) Paul spends a great deal of time in both letters to Timothy establishing the importance of being “absorbed” (1 Timothy 4:15) in the word of God. Kindle, being an analogy related to fire, evokes the idea of passion. Paul is instructing his protégé to renew his passion for the gospel so that he will be able to “preach the word; be ready in season and out of season; reprove, rebuke, exhort, with great patience and instruction” (4:2). This is what I pray for myself. God has placed a new passion in me for His Word this semester, and I pray that I will continually renew that passion for the rest of my life, so that I might be “a good servant of Christ Jesus” (1 Timothy 4:6).

*All Scripture quotations come from the New American Standard Bible unless otherwise noted.

A Second Chance (Original Poem)

Wed, 31 Jan 2007 00:00:00 GMT

A stirring
An awakening
A rebirth.
But at the same time
A death
A relinquishment
An abandonment.

A fire
Both cleansing
And strengthening.
A light
Both shattering darkness
And showing the way.

A voice
A call
A song.
My soul rises up and
An answer
A cry
A charge.

Life renewed
Empowered
Given new purpose.
A second chance.