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.

Oblige me for a moment while I divert this conversation with a brief, personal side-story…

For my entire software development career, I’ve worked on mature, well-established platforms (Oracle, ColdFusion, .NET, etc). I’ve often told myself that, sooner or later, I would need to try to get ahead of the curve and learn/master a new technology or platform early on in its lifecycle so that by the time it became more mainstream, and widely used, I would have the experience with it that is needed to be marketable. Maybe this is that opportunity…with Node.js. Or am I too late?

OK…enough of that…I digress…

So I started poking around in the Node.js documentation, read through the Node Beginner Book and browsed through some of the available modules. One of the first things I noticed was that the modules I’ve needed to implement a side-project I’ve wanted to write for quite a while now were available for Node…modules that I’ve not been able to find on any of the other platforms I’ve worked with recently. That got me pretty excited to start playing.

The next big thing that I was excited about was the fact that its based on the JavaScript language, which I’ve been enjoying more and more lately. The dynamic nature of the language makes it incredibly flexible and powerful. The more I’ve learned about it, the more I like it. The really exciting thing about Node.js is that it allows for the development of both server-based and client-based applications, all with the same language.

For as young as the platform is, there’s already a thriving and growing community thats developing around it, with the Node Package library approaching (or did it pass already) 10,000 packages developed and contributed by the community, all for a platform that hasn’t even reached version 1.0 yet. The fact that its open source makes it nicely accessible and easy to get up-and-running with, and if you want to fork out a little bit of cash, there’s also some decent IDEs and debuggers for it as well (I’ve heard good things about Webstorm). Double-bonus: it runs on all of the major platforms as well (at least, mostly…I’ve run into some modules that won’t install on Windows…which is having the bittersweet side-effect of forcing me to start to learn Linux a little better).

Anyway…I’m at risk of being long-winded here again. I’ve really only dipped my toes in the pool of Node.js so far…but the water was warm and inviting…I’m looking forward to learning more about it. Anyone have any suggestions for moving forward? Am I about to get run over?

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?

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?

The implications

Evolutionist William Provine of Cornell University suggested that if Darwin’s theory is true, then there are five inescapable implications:

• There’s no evidence for God
• There’s no life after death
• There’s no absolute foundation for right and wrong
• There’s no ultimate meaning for life
• People don’t really have free will

The facts about evolution and natural selection

Someone once said (and countless people have since reiterated the idea) “the more I learn, the more I realize how little I know.” The research that has gone into Darwin’s theories has often resulted in a similar sentiment for many.

The place where the theories of evolution and natural selection break down is ultimately at the heart of the problem: the origin of life (also scientifically referred to as Abiogenesis). Darwin’s theories are based on the idea that simple lifeforms could develop over long periods of time into increasingly complex creatures, but it never seeks to explain how those simple life forms came to be in the first place. Much scientific research has been dedicated to answering this question of, where or how did life originate, but all of it to the present has failed to produce a viable, scientific conclusion. In fact, more and more scientists are conceding the fact that scientific research is increasingly providing evidence of an intelligent designer as the source of the origin of life.

Assembling life

The origin of life appears to be almost a miracle, so many are the conditions which would have to be satisfied to get it going.

A living system must do at least three things: 1) process energy, 2) store information, and 3) replicate.

Non-living things do not do these things.

A single-celled organism has been described in the following way:

a high-tech factory, complete with artificial languages and decoding systems; central memory banks that store and retrieve impressive amounts of information; precision control systems that regulate the automatic assembly of components; proof-reading and quality control mechanisms that safeguard against errors; assembly systems that use principles of prefabrication and modular construction; and a complete replication system that allows the organism to duplicate itself at bewildering speeds.

There are eighty different types of amino acids, but only twenty of them are found in living organisms. In order to produce the protein molecules that can support a living organism, you would have to assemble a collection of roughly one hundred of these twenty types and link them together in precisely the right sequence, with precisely the right kind of chemical bonds (peptide bonds) in the correct places in order for them to form a protein capable of folding in a specific three-dimensional way in order for it to be able to support life. That is simply one protein capable of supporting life…this is only the first step.

It would take roughly two hundred of these protein molecules with precisely the right functions, assembled together in a very specific way, to produce a typical living cell.

Living systems acquire the information they need about how these amino acids and proteins need to be arranged from DNA and RNA. The sequencing of the amino acids necessary to create the proteins for each cell is encoded in its DNA. The challenges posed by the idea of composing a single DNA molecule have been described as “beyond our imagination”.

This defines the challenge that science is faced with when considering attempts to answer the question of the origin of life…

The theories

Of the research that has been done concerning the origin of life, six common theories have emerged as the most popular…

Random chance

This theory proposes that on the early earth, given the right combination of chemicals interacting with each other in “warm little ponds”, given enough time (science has verified that the earth is less than five hundred billion years old), they would eventually produce some form of life.

Scientists simply don’t seriously consider this theory a realistic possibility at all anymore. Scientific research has concluded that, even under optimal conditions, and given a billion years, the chances of chemical evolution on this level to be successful are less than 1:10000000000000000000000000000000000000000000000000000000000000 (1:10^60).

The odds for all practical purposes are zero. That’s why even though some people who aren’t educated in this field still believe life emerged by chance, scientists simply don’t believe it anymore.

Chemical affinity

This theory proposes that there must be some inherent attraction that would cause amino acids to spontaneously link up in the right sequence to create the protein molecules out of which living things are made; a sort of, “biochemical predestination”, if you will, the result of chemical bonding preferences.

Research involving computer algorithms to analyze all of the 250 known proteins resulted in conclusive evidence that sequencing had nothing at all to do with chemical preferences.

Self-ordering tendencies

This theory is officially titled “non-equilibrium thermodynamics”, and suggests that under certain circumstances, when energy is passed through a system at a fairly high rate, the system becomes unstable and will rearrange itself into an alternate, more complicated form. An example of this theory would be the way water molecules organize themselves spontaneously and form a vortex as they are drained from a bathtub. This tendency of molecules to “become more orderly” under given circumstances is the basis of this theory.

Energy itself is capable of creating patterns of simple order, but not anywhere even remotely close to the order required to arrange molecules of any kind in patterns as enormously complex as those required for the creation of a living organism. For example, a person could observe ripples on the sand at a beach and know that they were created by the action of waves, but if you saw the words “John loves Mary” and a heart with an arrow drawn in the sand, you know that energy alone didn’t create that.

Seeding from space

This theory proposes that the building blocks for life on earth came from somewhere else in space. Support for this theory arose from the discovery of amino acids on meteorites that had fallen to earth.

This theory does not answer the question of the origin of life, it simply moves it to another place.

Vents in the ocean

This theory proposes that exotic, hydrothermal vents discovered on the ocean floor could have provided an environment sufficient to facilitate the beginnings of life on earth.

This theory fairly ends at its suggestion. Like the seeding from space theory, it doesn’t address the assembly process of putting the right amino acids together in the appropriate sequence required to create a lifeform.

Life from clay

This hypothesis proposed that “life somehow arose on clays whose crystalline structure had enough complexity to somehow encourage prebiotic chemicals to assembly together.”

Crystalline clay might possibly be capable of providing some form of orderly information, but it would be very little, and it would be redundant; nothing anywhere close to that required to form life. The information it could provide would be analagous to a book filled with the words “I love you, I love you, I love you…” over and over and over again. It is orderly, but provides very little information.

Contrasting implications

In contrast to the implications of Darwin’s theory being true, the implications of God as the Intelligent Designer would be…

• There is overwhelming evidence (even beyond the Bible), even as observed and acknowledged by prominent figures in the scientific community, to support the theory of an intelligent designer (God)
• God, who inspired the authoring of the Bible, which in its entirety points to life after death, with Him, in paradise, by His grace, through faith in His Son, Jesus Christ
• God himself establishes the foundation for absolute truth and sin (right and wrong)
• The meaning of life is salvation…
• …for those who choose it (through free will)

Conclusions

Today it takes a great deal of faith to be an honest scientist who is an atheist.

I build molecules for a living. I can’t begin to tell you how difficult that job is.

I stand in awe of God because of what He has done through His creation. Only a rookie who knows nothing about science would say science takes away from faith. If you really study science, it will bring you closer to God.

These are just a couple of conclusions that two of the leading scientists in the field of origin of life study have come to as a result of their research. What do you think?

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 problem

I’m using the most excellent Dapper micro-orm for data access in this app, and when selecting a timestamp field from the database into a C# object, it sets the C# type of the field to a byte[] (byte array). When that object then gets passed to the web client, it gets passed as a JSON object, in which the property is just an array of integers. This didn’t seem like it would be a problem, until we tried coming back the other way with it to update the record.

When that JSON object was PUT (see also) back to the server, the ASP.NET MVC model binder wasn’t serializing the named property from the array of integers that had been sent to the client, back into a byte[] as I would’ve expected it to, the property was just null after model binding occurred, even though a valid integer array was present in the property on the return trip (as observed through Fiddler).

So the question at this point was, how do I get a byte array back and forth to and from the client in tact so that when it gets sent back to SQL Server on the backend, it will give me an accurate concurrency check? The answer actually turned out to be fairly simple…

The solution

The solution ultimately ended up being to just create our own, very simple (yet manual) byte[] to string serializer. Here’s what it looks like.

This converts the byte[] to a string before converting to JSON to send to the client:

1
2
3
4
5

public static string ConvertToString(this byte[] source)
{
    string hex = BitConverter.ToString(source);
    return hex.Replace("-", "");
}

And this converts the string back to a byte[] after model binding, when it gets back to the server, before sending it off to SQL Server for a concurrency check and/or update:

1
2
3
4
5
6
7
8
9
10

public static byte[] ToByteArray(this string source)
{
    int length = source.Length;
    byte[] bytes = new byte[length / 2];
    for (int i = 0; i < length; i +=2) {
        bytes[i / 2] = Convert.ToByte(source.Substring(i, 2), 16);
    }

    return bytes;
}

So far its working pretty well for us and we haven’t run into any problems with it.

Anyone else run into an issue like this before? Is there a better way to handle this?

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…

The module pattern

Some of the big things that I found myself longing for as the JS I was writing started to get more and more complex, was encapsulation, reuse and statefulness. The searching I did (check out the link above) quickly showed that the module pattern would give me all of that and more. I highly recommend starting with the first link in those results, its a fantastic article by ben cherry that covers how to implement the module pattern with JS in very simple and understandable terms (seriously, if this subject interests you at all, go read it…this page isn’t going anywhere…you may not even want to come back after reading it…).

I started slowly with this pattern to support a few web applications that required some semi-complex client-side interactions, and have been very pleased with how it has worked out so far. Here’s a stripped down sample of the format that the modules I’ve been writing have taken:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

// pageModule.js
var pageModule = (function () {

// Private members
  var selectors;

// Public operations
  return {
      Init: function (params) { return init(params); },
      AnotherFunction: function () { return anotherPrivateFunction(); }
  };

// Private operations
  function init(params) {
      selectors = params;
      // ...
  }

  function anotherPrivateFunction() {
      // ...
  }

})(); // pageModule

A particularly appealing feature of this approach to writing JS is that it is totally isolated and easily testable using a JS unit test framework like QUnit or JsTestDriver.

Pulling it into a web page

I’ve found this approach to support interactive client-side functionality in web applications very nicely as well, though, this is an area where I admittedly have some questions as to my approach. I’ve been wondering if I sense a slight code smell with the following approach, and would appreciate some feedback. But anyway, here’s how I’ve been using it.

Being the .NET developer that I am, the following is an example of a razor view from an ASP.NET MVC app, that uses the above module, but this same approach could be used with any web frameworks view engine.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

// page.cshtml
@model PageViewModel

@{ ViewBag.Title = "Page Title"; }

@section PageHeadContent {
  ...
}
<div id="PageContent">
  <ul class="some-list">
      <li>...</li>
  </ul>
</div>
@section PageScripts {
  ...
  <script src="http://bob.yexley.net/js/pageModule.js"></script>
  <script>
      var pageModuleParams = {
          PageContentContainer: '#PageContent',
          ListOfStuff: '.some-list'
      };
      pageModule.Init(pageModuleParams);
  </script>
}

See what I did there? So, the idea here is that the JS module itself knows absolutely nothing at all about the page that it is supporting. But, it can still fully support and manipulate DOM elements on the page, because the page feeds it the selectors it is (obviously) fully aware of by passing the pageModuleParams object into the module through the publicly exposed Init operation, which sets the internal selectors variable. From that point on, the module itself, internally, can wire up internal operations (event handlers, ajax calls, etc) that can act on elements of the page through selectors that were passed in from the page, and yet still remain totally decoupled from the page.

So what do you think? This approach has been working fairly well for me for a while now, but it wouldn’t surprise me a bit to know that there are much better ways to handle this. Any suggestions or recommendations? Learning new and better ways of doing things (especially if they make my life easier) is something I love…so I’m totally open to feedback here. Was this useful?

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.

A good foundation

When we first had our stove installed, obviously, the first fire we built was in a bare metal box. That fact alone can add to the challenge. One of the things that I’ve learned can definitely help to get things started, and keep things going, is having a good bed of ashes to insulate the fire from underneath. This is helpful all the time, but especially if/when you’re trying to start a fire several hours after having let one go out. That bed of ash will serve as an insulation layer for coals and embers from the previous fire that can make it a breeze to get another one going. Ultimately, the point here is, don’t be too eager to shovel all of the ash out of your stove or fireplace. Keeping a bit of it around in there can be a big help.

Structure and airflow

Another thing I’ve learned the hard way is that just throwing some wood in there and chasing it with a match or lighter is not gonna get you a fire. The way you stack your wood is critical to your success…or failure. I’ve lost track of the number of times I’ve struggled to either get a fire going, or keep one going after getting it barely started, because of the fact that there was no space around the wood for airflow. Stacking or arranging your wood in such a way as to allow for airflow around it is essential.

The picture here illustrates the way I’ve come to stack my wood when I’m starting a new fire. Its always a little different of course, depending on the pieces of wood that I have available at the time, but the concept behind what I try to achieve with it is the same every time. Two smallers pieces of wood on each side, allowing me to stack another piece across the top of them. This forms a perfect space to get things started underneath, and allows for the needed airflow around the piece across the top as the kindling takes off.

Start small and build up

This is probably actually one of the more obvious and well-known factors, but its worth reiterating. Starting with realistic expectations can help with this. Don’t expect to have a blazing fire going within anything less than 20 or 30 minutes (and even that might be a bit of a stretch) unless you’re gonna throw some lighter fluid in there (which is NOT a good idea in a stove or fireplace…by the way).

I typically start with some paper, and throw a handful of very small pieces of kindling on it. My favorite kindling so far is a good piece of knotty pine, or some cedar (this is particularly nice if I can come across some, because it makes the room smell nice as it burns). I light the paper and it ignites the small kindling. Once the small kindling starts burning, I follow it…slowly…remember, getting over-zealous at this point can smother the fire quickly…with some gradually larger pieces of kindling.

Occasionally, as the fire builds, the flames will increase and decrease in intensity, and I find that I nearly always have to help things along by blowing on the flames a bit…sometimes more than others, but typically not all that much. I’ve gotten to the point now that, by using this approach, within about 30 minutes I’ve gotten things going well enough that the main piece of wood that I set across the the original stack has taken off, and I can just start maintaining things. Which brings me to my last tip…

Keeping it going

Once the fire is going well, and your big logs are burning nicely, eventually you’ll have to toss in another piece (or two…three…). If you’ve held off long enough, the main wood in your fire has been reduced to nothing more than coals and embers. I’ve found that, by using a good poker, you can push those coals around and pile them up on either side of the stove/fireplace, forming something of a “ditch” or trench through the middle of them. By placing another log on top of those coals with that “ditch” between them, you get a perfect path for circular airflow around that piece of wood, and it will take off within seconds. I make this point because I did have some trouble at times with logs not taking off and burning as well as they should have, and in a handful of extreme cases where I didn’t have a good bed of ash and coals beneath the fire I even snuffed the fire by not allowing sufficient airflow around the wood. Its worth driving the point home again about the importance of airflow. Without sufficient airflow, even the best of fires will die.

Enjoy the warmth

Crys and I have REALLY enjoyed our wood stove this past year. I think we would both agree that so far it has been our best home investment…or at very least, the one we enjoy the most. Its taken some time to get the hang of getting the most out of it, but I think we’re finally starting to nail it down to where we’re doing less fighting with it and more enjoying it.

Its worth noting here that many of these tips will be more applicable to the use of a wood stove, but many of these or similar concepts have been used with success even out in the open woods when I’ve been camping. The point to keep in mind is, your mileage may vary, depending on your situation. I hope some of these tips are helpful to someone at some point, and I’d love to hear about anything that I might myself be missing out on. What are some of your best wood-burning or fire-starting tips?

The Problem

I probably don’t really need to spend too much time here, do I? I mean, xcopy (with manual configuration, etc…yuck) is far too brittle and error-prone, MSDeploy/WebDeploy is just too much friction, third party installers and Wix are too much work (seriously, who has time for that?), and in enterprise/corporate environments, who really has the option of handling deployments through Visual Studio? What other options are there?

Well now, there’s Octopus.

A Cephalopod to the rescue

I first heard about Octopus on twitter, I think it must’ve been about six months ago. Ever since then I’ve been looking for an opportunity to try it out to see if it was as good as it appeared to be. I’m getting pretty close to wrapping up an initial release of a new product at work right now, so I thought this would be a perfect opportunity to try it out.

Getting up-and-running

Installation and configuration of a product is critically important, in my opinion. This is where customers/users get their true first impression of a product beyond just reading about it, seeing a few screenshots or watching a demo video. This is a users first actual use of the product. It was the first place that I found Octopus to truly shine. The installation and configuration was super easy, and I got through the entire thing without a single hiccup. I was really impressed with how easy it was.

There are two main components (well, actually three, sorta…but we’ll get to the third a little later) to setting up and using Octopus: the web portal, and the tentacles. The web portal is where you handle your environment configuration and deployments. From there, once you’ve established your environment configuration, and the portal is aware of your envirnonment, it interacts with tentacles when you actually execute a deployment. Tentacles, are like…”agents”, if you will…that run as background services on target servers, and execute the “installation” of deployment packages when instructed to do so by the web portal.

Here’s how it all works.

Making it happen

Don’t be intimidated by this diagram. It looks complicated, but it’s really not all that bad. Several of the components of the diagram are most likely already a part of your daily workflow and setup anyway. You do have source code right? If not, why are you even reading this? Also, if you’re reading this, you probably have target environments that you deploy to as well. If you don’t have a build server, that’s OK too, I can help with that (I’ll get to that in a minute) (I don’t have a functional build server at work either…yet). The NuGet repository? Well, that’s easier than you might think too…and again, I’ll get to that in a minute. With all of the pieces in place, with a little bit of simple configuration, Octopus just helps connect the pieces together, and makes it really easy to get things from one place to another, and makes it easy to get everything into the state it needs to be in once it gets there (things like handling different connection strings and configuration settings per environment…really simple).

Once you have all of the piece in place, there’s just a handful of easy steps to go from the raw source code on your desktop, to up-and-running live in a target environment.

When you want to deploy a package to a target environment with Octopus, you have to queue a deployment. Queuing a deployment involves:

• Selecting the package you want to deploy. Octopus provides you with a dropdown list of package version numbers to choose from.
• (Optionally) entering some release notes in a provided text area (accepts markdown).
• Click the “queue deployment” button.

Yes, it really is that easy. Once a package has been queued for deployment with its associated release notes, it can then be deployed with a click of a button. Clicking the deploy button prompts you with a dialog to select which of your configured environments you wish to deploy it to. Click submit and your deployment is off-and-running to the target environment.

That being said, lets talk about how Octopus gets the deployment packages it makes available for deployment.

Feeding the Octopus

Octopus uses the NuGet package format for its deployment packages. You need to provide and configure Octopus with a NuGet package feed for each project you wish to automate deployment for. So to provide packages to Octopus for deployment, I had to do two things:

1. Creating NuGet Packages

   I had to figure out a way to generate NuGet packages based on the compiled output of my web application. Eventually our goal is to get to the point where we have an automated build (continuous integration) server that generates our packages as part of its build, and serves up a NuGet package feed. We’ll soon be able to do just that with TeamCity. But…we’re not quite there yet, sooo… My immediate solution was to generate them myself. Last week I wrote about Pyke, a .NET build module that I wrote. As I was writing that module, I added functions for generating NuGet packages. As I mentioned in that post, we don’t currently have a functional build server in our organization (to reiterate the point…yet), so I currently run our build script locally, from my desktop. Our script currently has three main steps: 1) compile the app, 2) generate a NuGet package, and 3) copy that package out to a shared directory on our network, which also happens to be the source folder for the applications NuGet package feed…

2. Creating and updating a NuGet Package feed

   The next step in figuring out how to deliver NuGet (deployment) packages to Octopus, was to create and source a NuGet package feed that I could provide to Octopus. This turned out to actually be a LOT easier than I expected it to be. The NuGet team has done a fantastic job all the way around that project, not only in implementation, but in documentation. I did some poking around in the NuGet docs, and found and followed these instructions on how to create your own remote (or internal) NuGet feed. They’ve created their own NuGet package that you add to an empty ASP.NET web application, deploy it to an IIS server, and boom…you’re done. That package is configured to look in a folder for packages to serve up in its feed. I followed their instructions, and shared up the package folder as a network share, and that’s where I copy my generated packages to from my build script, and the feed is automatically updated immediately. It literally took me about five minutes to get up-and-running with a functional NuGet package feed for Octopus to work with. It doesn’t get a whole lot easier than that.

Putting it all together

So, yeah…there’s a lot of words here, which probably makes it seem like a lot more work than it actually was. But ultimately, when all was said and done, this was all I had to do to get everything setup…

1. Install the Octopus web portal. I had no issues with the installation at all, it took less than five minutes.
2. Install the Tentacle on my target web server. That too went without issue, and took less than two minutes.
3. Create a NuGet package feed hosted in IIS. As I just explained, it literally took about five minutes to put that together.
4. Run my build script to generate a package so my feed had something to serve up.
5. Configure my environment in the Octopus web portal. That was pretty straight-forward, and consisted of
   1. Pointing it to my NuGet feed (where it found a package waiting to be deployed)
   2. Pointing it to my target web server (where it discovered that there was a tentacle running, waiting for a package to install)
   3. Creating a project, to which I added the above configured target server and package feed.
   4. Done.

All total, if I had been able to perform all of those actions in sequence (I was putting all of this together in my “spare time” while doing my day-to-day development work), it would have taken me about an hour, tops, to get everything in place. The beauty of it is that, now that it is all in place, deploying new features and fixes to any of my environments takes a grand total of about two-and-a-half minutes.

THAT is a beautiful deployment process. If you haven’t yet, you really owe it to yourself to check out Octopus for handling your deployment if you’re doing .NET development. For a relatively low-friction setup and configuration, it will save you immeasurable time and hassle.

Not invented here syndrome?

Yeah, I’ll admit it, I have a tendency to be an opinionated developer. Maybe even a little more than most. But having worked with both NAnt and MSBuild more than I’d care to admit in the past, I have no desire at all anymore to willingly drown myself in angle brackets just to automate a few simple tasks. I tried my hand at using Rake with Albacore a time or two as well, and for one reason or another, I was never able to actually get it working for the simplest of tasks…my guess would that it was because I was trying (heaven forbid) to actually use Ruby on Windows. The two just don’t seem to get along.

When I started this little project, I actually inteded and attempted to write it in Powershell. I don’t know if its just me (I kinda doubt it, because I’ve talked about this with others who agree with me), but the documentation and available examples on the internet leave much to be desired with regards to just getting started doing some incredibly basic tasks like file I/O (walking directory structures recursively, creating/updating/deleting files, etc), and I just couldn’t get going with it. After two to three hours working with it, I wasn’t even able to get basic function to walk a directory working.

So I decided to give Python a shot…

Learning something new

As a professional software developer, its a fairly widely held belief that its important to expand your skills by learning a new language each year. I’ve agreed with that sentiment ever since I first heard it, but I’ve never embraced it seriously enough to actually follow through and do it. I decided this (and another prospective side-project) was potentially a good opportunity to try to learn Python. One of my best friends has been a Python fanboy for quite a while now, and has often encouraged me to give it a shot, so I figured I would at least have one good resource to turn to if I got stuck on anything, but it turned out I didn’t need to. The online documentation for Python is really good, with lots of good examples available as well. Overall it has taken me a total of probably around 10 hours work time to get Pyke to the state its in now, which I’m pretty happy with (though it still needs some work).

Also, I’m hosting the project on Github, so it has had the additional bonus of being a great opportunity to get to learn git better, which is cool.

What does it do?

Another part of the reason why I decided to just roll my own was because my needs were really fairly straight forward. I don’t really need all that much from a build tool. My immediate needs were pretty simple:

• Generate a version number: I just needed something that could automate the generation of a unique version number.
• Apply the version to assemblies: Find all of the AssemblyInfo files in a given directory structure, and create new ones with a set of custom assembly metadata applied.
• Compile to a custom output directory: Pretty simple, just compile a given solution or project, and push the output to a given directory.
• Generate a NuGet package: I wanted it to be able to build a NuGet package and upload it to an internal Nuget package feed (which, since its internal, really just means copying the generated package to a network share).
• Utility functions: I also need it to have a few basic utility functions for build cleanup and moving things around.

Told ya…not really all that much to it. There are obviously a few more things that I’d like it to do when all is said and done (see the TODO list on the github page), but for now, its suiting my needs nicely. I’ve been actively working with it for the past week and it has done exactly what I asked of it, and given me no problems at all so far.

How does it work?

I’m working on getting some comprehensive usage samples put together for all of the features, but here is a stripped-down example that should at least give you a quick taste of how to use it.

First, you’ll need to download pyke.py (see the “How can I get it?” section below) and drop it in the folder that your build script will be in. No installation necessary, just stick it in the same folder, and reference it in your build script. Then, a build script (I call mine build.py) would look something like this.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

import pyke, os, shutil

p = pyke.pyke(basedir = os.curdir)
projectFile = "YourApp.csproj"
version = p.getVersion()
assemblyInfo = {
  "ClsCompliant" : "false",
  "ComVisible" : "false",
  "Title" : "Your assembly title",
  "Description" : "Some description for your assembly",
  "Company" : "Your company here",
  "Product" : "Your product name here",
  "Copyright" : "Your copyright information here",
  "Version" : "1.0",
  "InformationalVersion" : version,
  "FileVersion" : version
}

# Build the web project in release configuration
p.build(projectFile = projectFile, configuration = "release", assemblyInfo = assemblyInfo)

# Create a clean directory, with everything where it needs to be, in preparation for packaging
packageSourceDir = os.path.join(p.basedir, "PackageSource")
if not os.path.exists(packageSourceDir) :
  os.makedirs(packageSourceDir)
else :
  p.cleanDir(packageSourceDir)

# Build Nuget package
deploymentPackagesFolder = os.path.join(p.basedir, "DeploymentPackages")
if not os.path.exists(deploymentPackagesFolder) :
  os.makedirs(deploymentPackagesFolder)

nb.packageNuget(targetDir = packageSourceDir, specName = os.path.splitext(projectFile)[0], version = version, outputDir = deploymentPackagesFolder)

# Cleanup
p.cleanDir(p.buildOutputDir)
p.cleanDir(packageSourceDir)
os.rmdir(p.buildOutputDir)
os.rmdir(packageSourceDir)

Like I said, that’s a fairly basic example, and there are other options as well, but that’s a decent summary of the basics. Also understand that, build.py is obviously just another python script, so you can do anything you want/need in it to support your build process. Pyke just makes some of those things a little easier (at least I think so anyway).

How can I get it?

Pyke is hosted on github, so you can either clone the project, or just download the zip, whichever you’re more comfortable with.

Enough already…

Yeah, I really need to wrap this up, I know. This ended up being a bit more long-winded than I had expected it would be…if you made it this far…congratulations…YOU HAVE NO LIFE! :) No, seriously…thanks for taking the time to read about Pyke, and if you happen to have any more time…

One last thought…I’ll share the same disclaimer here that I added to the README on the project page: Pyke is literally the first python code I have ever written. I’m nearly 100% positive that there is a LOT of code in it that could probably be done better. Constructive feedback is always welcome.

The more important consequence of the port is going to be the impact on current feed subscribers (are there any? really?) and search engines, as some of my older content will go away, and my URL structure will end up being at least a little bit different. Different enough that people that find links to posts from my old blog through search engines may not find what they’re looking for immediately. I’ll do my best to get as much of my older content that generated interest ported over here as soon as possible, and maybe more importantly, get a good 404 page setup as soon as possible too.

Ultimately my hope is that some of the things that it (Octopress) brings to the table will make it a little bit less painful for me to actually get on the ball and write some of the things I’ve been dying to write about (though I’m fairly certain that it won’t buy me any more time…which is ultimately one of the biggest hinderances to my writing). I’ve been working on and with some really fun stuff at work, and learning a lot from it, and I’d really like to share some of it and get some feedback on it from people I know are smarter than I. I’d like for my blog to be a two-way street where I can share and learn at the same time. Hopefully I can share enough to be able to make that happen.

To add the .less extension as a valid MIME type to IIS express follow these steps:

1. Open a windows command prompt
2. Switch to the directory that IIS Express is installed in (on my 64 bit Windows 7 system, it was installed in C:\Program Files (x86)\IIS Express)
3. Execute the following command:

1

appcmd set config /section:staticContent /+[fileExtension='.less',mimeType='text/css']

Boom. Works great. Now I’m rollin’ with Less CSS in my ASP.NET MVC project developing on IIS Express. Sweetness.

So, as you can imagine, we spent a good amount of time Googling to try to figure out what might be the problem with IE. Somehow, one of my co-workers stumbled on an article (I actually think it was a StackOverflow thread, but I can’t be sure) that mentioned that the issue might have something to do with browser caching. So, we gave it a shot and disabled caching on the controller action, and everything started working fine in IE. St00pid IE.

So, here’s what we ultimately ended up with for the working solution. I realize, (as it seems so many things I do) it kinda feels like a bit of a hack, but it works. As always, feedback is welcome…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88

// BatchStatus.js
var pending = 0;
var percentComplete = 0;

$(function () {
  $('.status-messaging').hide();
  UpdateProgressBar(percentComplete);
  GetStatus(statusUrl);
});

function GetStatus(url) {
  $.ajax({
    type: 'GET',
    dataType: 'json',
    url: url,
    success: function (results) {
      percentComplete = results.PercentComplete;
      pending = results.Statuses['Pending'] != undefined ? results.Statuses['Pending'] : 0;
      UpdateProgressBar(percentComplete);
      UpdateCounts(results);
    },
    complete: function () { GetStatusComplete(); }
  });
}

function GetStatusComplete() {
  if (pending != 0 || percentComplete < 100) {
    GetStatus(statusUrl);
  }
}

function UpdateProgressBar(percentComplete) {
  $('#progressbar').progressbar({
    value: percentComplete,
    complete: function () { $('.status-messaging').fadeIn(); }
  });
}

function UpdateCounts(results) {
  var currentPending = results.Statuses['Pending'] != undefined ? results.Statuses['Pending'] : 0;
  var currentComplete = results.Statuses['Succeeded'] != undefined ? results.Statuses['Succeeded'] : 0;
  var currentFailed = results.Statuses['Failed'] != undefined ? results.Statuses['Failed'] : 0;

  $('.attributes-table tr.status-normal td:nth-child(2)').html(currentPending);
  $('.attributes-table tr.status-completed td:nth-child(2)').html(currentComplete);
  $('.attributes-table tr.status-failed td:nth-child(2)').html(currentFailed);
}

// StatusController.cs
[HttpGet]
[NoCache]
public virtual JsonResult GetBatchStatus(long id)
{
    var result = new BatchStatus();
    var status = _batchServiceClient.GetBatchEditProgress(id);

    foreach (var batchResult in status)
        result.Statuses.Add(batchResult.Status, batchResult.Count);

    var total = result.Statuses.Sum(r => r.Value);

    if (result.Statuses.ContainsKey("Pending"))
        result.PercentComplete = Convert.ToInt32(System.Math.Round((float)((total - result.Statuses["Pending"]) * 100) / total));
    else
        result.PercentComplete = 100;
    return Json(result, JsonRequestBehavior.AllowGet);
}

// NoCacheAttribute.cs
public class NoCacheAttribute : ActionFilterAttribute, IActionFilter
{
    public override void OnResultExecuting(ResultExecutingContext filterContext)
    {
        filterContext.HttpContext.Response.Cache.SetExpires(DateTime.Now.AddDays(-1));
        filterContext.HttpContext.Response.Cache.SetValidUntilExpires(false);
        filterContext.HttpContext.Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches);
        filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
        filterContext.HttpContext.Response.Cache.SetNoServerCaching();
        filterContext.HttpContext.Response.Cache.SetNoStore();

        base.OnResultExecuting(filterContext);
    }

    public override void OnResultExecuted(ResultExecutedContext filterContext)
    {
        base.OnResultExecuted(filterContext);
    }
}