Node.js is a platform built on [Google] Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

We’ve been using the Less CSS pre-processor at work recently, but we’ve only been using the JavaScript parser/generator for it, which is really only intended for development/debugging purposes…not a live, production environment. I’m not sure it really hurts much to use the JavaScript parser/generator, other than performance…It does it all dynamically on the client…on every page load, so it could be a little slow. Anyway, having a couple of hours of downtime at work recently while we were upgrading our VCS, I took the opportunity to start looking into pre-compiling and minifying our stylesheets using the server-side compiler for it, which is a Node.js module. That forced me to get Node.js installed and running on my workstation, and get the Less module installed. I was pleasantly surprised and impressed at how easy it was to get up-and-running with it…that prompted me to start exploring Node.js further.

This is (hopefully) the first of a series of posts that I’ve wanted to write for a long time now. If I recall correctly, I think I actually already wrote this very post a while back on a previous version of my site, and never got beyond this first post, so, I’m hoping I can stick with it this time and actually follow through and finish it. This is a subject I believe in very strongly and am very passionate about, so I’m looking forward to the opportunity to think through it in more depth as I write it all down.

I plan to take an in-depth look at the passage of Ephesians 6:10-18. My goal with this series is to learn more about the subject on a personal level, and if it interests or helps someone else, so much the better. More than anything, I pray that it reflects honor and glory on God and is something that He will be proud of.

The outline

Here is a rough outline of how I plan to approach the subject (at least for now…subject to change):

1. Reality: This is not a metaphor, this is real, and we need to take it seriously and deal with it like every other reality in our lives.
2. Call to action: This requires an active, daily discipline in practice. There is nothing passive about battle.
3. The belt of truth: keeping it all together
4. The breastplate of righteousness: guarding our vitals
5. The Gospel as shoes? Sharing the love
6. The shield of faith: self defense
7. The helmet of salvation: the brain bucket
8. The sword of the spirit: fighting back
9. Prayer: suiting up

The format

This is the typical format that I was planning to use for each section in the outline:

1. The spiritual principle: discuss the spriritual principle for the section (truth, righteousness, faith, etc.)
2. The analogy: discuss the conceptual analogy that Paul uses in the passage to help us understand the principle (belt, breastplate, shield, etc.)
3. The enemy’s perspective: what is the enemy’s approach and tactics against us with regard to the subject? What are we fighting against?
4. The application: what can we do? What action can we take? How do we apply this to our own personal battle?

This is the outline for a discussion that I’ll be leading for our small group, and is my attempt to put my thoughts together in a logical manner. Much of the content for this piece was sourced from chapter three of The Case For Faith by Lee Strobel. Much of the content of that chapter is based on an interview he did with Dr. Walter Bradley, so much of the content can be attributed to them, but has been summarized for the purposes of this document. It should also be noted that the book was published in 2000. Certainly much could have changed in the course of the past twelve years. In the short bit of time I took to research for this document, I found little to refute the information found in the book and from this field of research, but I am certainly open to education and learning, so please let me know if any of this information is inaccurate. To the best of my knowledge the information presented here is still relevant and accurate.

The positions…

Creation

The original bringing into existence of the universe by God

• God created man in his own image - Genesis 1:27
• God is the same yesterday, today and forever - Hebrews 13:8

Evolution

The process by which different kinds of living organisms are thought to have developed and diversified from earlier forms during the history of the earth.

Charles Darwin’s theory of natural selection suggests that naturalistic processes could account for the increasing complexity and diversity of living things.

Darwin’s “greatest accomplishment” was to show how the development of life is “the result of a natural process, natural selection, without any need to resort to a Creator.”

As far as Christianity was concerned, the advent of the theory of evolution…was catastrophic…The decline in religious belief can probably be attributed more to the propagation and advocacy by the intellectual and scientific community of the Darwinian version of evolution than to any other single factor.

So which perspective is right? Can they both be? Does one of them have to be wrong? What do the facts say? Does science, by its nature, automatically have to be correct and accurate? Can it be wrong? Much of it is, after all, theoretical/hypothetical in nature, right? What do you think? Can both evolution and creation be right?

For some reason, whenever I think of or discuss the idea of serialization, my brain associates it with the concept of transformation…which always makes me think of Transformers. Is that weird?

Data serialization can be a sticky wicket sometimes. Things don’t always get passed back and forth between a client and server the way you think or expect they will. Which means, sometimes you have to take matters into your own hands.

I was recently working on implementing some concurrency checking into an app, and we decided to use SQL Server timestamp fields to check against before updating data being passed back to the server from the web app. Seemed straight-forward enough initially…but that was before that field started getting transformed into different datatypes and formats as it was passed through the different layers of the application. All of the different players involved (the various components of our app) apparently didn’t feel like playing nicely together with the timestamps. We ultimately came up with what I think is a fairly simple and straight-forward solution to the problem…

The web has evolved and the standards for browser applications have been raised to new levels over the past five years. People just expect more (and rightfully so) from web applications. It used to be that whenever I used any kind of JavaScript (to which, from this point forward, I will refer to as simply, JS, thankyouverymuch) in my web apps that I would pretty much just reference a .js file and randomly jam a bunch of functions in it, and hope someone (a team member, perhaps) didn’t notice them closely enough to attempt to use one in a way in which it wasn’t intended to be used. Knowhatimean? Ever been there, or done that? Perhaps you’re there now.

At some point…not sure exactly when…I guess it was probably about six or eight months ago or so…I finally got to a point where I said to myself, “self…there has GOT to be a better way.” So I did some Googling…and as it turns out, I was right…

About a year-and-a-half ago, Crys and I invested in a new wood burning stove for our home. Last winter and this winter so far, we’ve been burning wood to keep us warm. During that time I’ve built dozens of fires, and if there’s one thing I’ve learned for certain its that building a good fire is easier said than done. I’ve learned a handful of tricks that has made the task easier over time, and I can consistently get one going much better than I could last year when we started this. Most of what I’ve learned has been through bits and pieces from conversation over time, and more than anything, trial and error.

Building a good fire is a skill that I feel every good man should possess, but as time rolls on, fewer and fewer have it. Its a skill that I certainly intend to pass on to my sons. There are handful of things that I’ve learned are important for starting and maintaining a good fire. I thought I’d share some of what I’ve learned here. If you know of anything that I might be missing, share your ideas in the comments.

Every .NET developer I know has war stories about past horrors of deployments gone wrong. My theory is that’s because there’s not a good, universally accepted way to handle deployments of .NET apps on windows. Octopus steps in and offers a solution that, in my recent experience, dramatically simplifies the .NET deployment problem with a really elegant solution.