Bottom-Line-Up-Front: Going the Distance with Babylon.js is the name of the book I've been working on, available for pre-order now. The book is aimed at beginner to higher-level intermediate developers, is being reviewed by members of the BJS team, and will demonstrate how to build a simulation-game hosted within a web application that can be installed and published to app stores.

Pop Quiz: Do you consider any of the following to apply to yourself?

1. You are a designer of some variety or another interested in learning how to create your own 3D applications
2. Web Development and JavaScript have been your jam but you want to take your skills up to the next level and dabble with 3D
3. Being familiar with game engines like Unity, Unreal, Godot, etc., you are interested in taking your content to the web using JavaScript
4. 3D stuff looks super cool - what's going on and how do I get in on that?
5. I'm a bit intimidated by how complex 3D programming seems to be but I'm willing to learn if I can get a helping hand

Congratulations, there's something for everyone!

Babylon.js is an Free-and-Open-Source JavaScript library which provides an elegant, cross-browser (and cross-platform!) wrapper around the WebGL and newer WebGPU API's. In addition, BJS exposes cutting-edge browser capabilities such as WebXR, a standard used for writing web-based VR and AR applications. Just because it's cutting edge tech doesn't mean you have to bleed for it. The Babylon.js team is fanatically committed to maintaining backwards compatibility, meaning that code written for BJS 5.0 will still run (with perhaps minor tweaks) on BJS 7.0, whenever that may happen!

All of these are cool bits of info to know, but where this applies to me (and presumably yourself, since you're reading this) is that after using BJS for fun and games for a bit I started thinking about how I might be able to participate and contribute back to a community that is so incredibly supportive, passionate, and talented. While I am passionate about technology and things like BJS, I sure don't have the talent! Maybe there was something I could to in the way of helping to support others who actually do have the talent for these kinds of things...

A series of events related to this noodle about contributing to Babylon.js happened in the Summer of 2020 that have ultimately led to this post and everything contained herein. For the past year and a half or so, I've been working on this, and I've really been excited to share with the community. There's just so much work that needs/is still needed to be done, and it's never going to live up to my impossible standards, and that's just one reason why it's a good time to get this out into the open! Some folks [Ed: really, anyone following me on Twitter] are already aware of at least some of the machinations and rumblings going down with this project, and others may merely have suspected. Today however it's finally time to bring everything out into the open with a good old fashioned Book Announcement!

Pre-Order Now

Through 14 chapters in three separate sections, the book will take readers on an end-to-end journey of building an entire application - a video game - from start to finish. Starting with a BJS refresher and ramp-up and continuing on from how to set up WebPack to handling input, managing state, writing shaders, and packaging into a Progressive Web App (among other topics). Although the Amazon listing currently lists a publication date in October, I can assure folks that it will most certainly be done before that time - I'm expecting a July or August at the latest date for its' availability.

Space-Truckers: The Video Game! is currently in a sort of final preview stage in preparation for this weeks' hush hush thing hush hush. The game itself is Open-Sourced with the repository being available here with the intention of serving as a BabylonJS reference/full stack testing architecture - in addition to hopefully giving a smidge of enjoyable experiences.

That's where you all come in! There are a whole swathe of GitHub issues in the Space-Truckers repository that are both awaiting creation and/or awaiting someone to come along and fix/build them. If you've been wanting to contribute to the BJS v5.0 launch event here's your opportunity!

Why Do This?

A couple of years ago, I took up woodworking as a side hobby. There are a number of reasons that I decided to focus primarily on hand tools instead of power tools, but one reason is that hand tools require a two-way communication between the artificer and artifact. There's no brute-forcing the wood to your whims, it'll either break on you or laugh in the face of your flailing efforts. Paying attention to the direction of the grain, feeling the scraping vibration of a plane's blade across a face, taking in the tones coming from the interface between metal tool and wood piece are all ways of listening to the material. It doesn't hurt either that it's a good excuse to be and stay physically active!

Until I'd started down this path, it had been a long time since the last time I'd really done any serious wood or carpentry work. There's so much to explore and learn, but where to start?

Watching and Learning

It shouldn't surprise anyone reading this that YouTube was a great resource. In particular, YouTube was the gateway for me to discover the work of Paul Sellers. Mr. Sellers describes himself as a "Lifestyle Woodworker", but that's not really an accurate nor complete description of the man.
With a gentle voice and with a soft-spoken tendency, Sellers positively radiates passion and enthusiasm for not just his craft, but for sharing it with the world. His YouTube channel is an incredible fount of woodworking knowledge - much of which is increasingly difficult to discover anywhere else. To avoid making this entire post about Mr. Sellers, I'll complete the establishment of his bona fides by noting that his work has been includes a White House commission from President Obama for the Cabinet Room, so I think it's safe to say this guy knows his stuff.

Garage Workshop Woes

Back home in my much more mundane tale, I was starting to build out my tiny little garage workspace when I realized that I was in dire need of a stable work surface - a workbench. I had picked up a cheap portable contractors' workbench from my local hardware store, but it wasn't built for the things I needed it to do and it was clear that if I wanted to get serious about using hand tools I would need a better work surface. I had been watching Sellers' How to Make a Workbench video series and I felt inspired by him - I could do this!

Except... I couldn't, really. While I never really doubted that I could eventually build the workbench I wanted, one thing became apparent that first summer: I needed to do some serious levelling up before I would be ready to take on this project. Summer gave way to Fall and Winter, then back into another yearly cycle of seasons as I practiced and learned.

The Project Begins in Earnest

Coming up on this past Summer and Fall of 2020, I had had a very productive Spring, and was feeling confident enough that I wanted to try again to build this workbench. Why was I so confident? It wasn't because I felt my skills were superior to the task, it was because I was going to build it as part of a class taught by the great folks at the Rebuilding Exchange! The access to material, tools, and knowledgeable instructors offered by their their classes are perfectly justifiable reasons to be feeling optimistic. Fortunately though, my initial, pie-in-the-sky optimism was quickly given a well-needed dose of reality.

Reality Check

As I started communicating my plans and ideas to the instructor, it became apparent that I hadn't thought through a great many aspects of the design and construction process. It was clear that there wouldn't be nearly enough class time to complete the work needed. I needed to split up the work - minding dependencies and priorities - to make best use of my class time in the shop. This was one of the areas I actually felt well equipped to handle - a lifetime of Civ games along with a professional career involving resource allocation and scheduling was finally of some practical use in the world! I came up with a work plan that fit the schedule and went to work. In addition to that, I found the choice of wood (Cedar) tended to splinter and crack very easily if care wasn't taken (guess how that was discovered?). Practical concerns like this weren't always avoidable since I had to work with what I had, but neither was that an excuse for recklessness.

This was one of the parts of the process where I learned some very key lessons, made possible by the excellent teaching staff in my class. There was technical learning on how to use tools, techniques, etc. I learned how to the understand - and accept - that you are going to make mistakes, and that it is okay - anything is fixable. Understanding that sometimes the best way to fix a mistake is to do nothing and accept that it happened. [NB: This may sound familiar to any tech folks out there in the audience.]

Learning How to Change

Ironically, the lesson that stands out the most to me from the experience has nothing to do really with woodworking. Being unfamiliar with the workbench plans, there was resistance to the design from the teaching staff. For example, one area of pushback was for wanting to form the benchtop by laminating the wide faces together. The reasoning behind the resistance was understandable, but I knew that this was something I couldn't change if I wanted to achieve my vision of a Paul Sellers-style workbench. Without the contrast of this with later compromises made in construction, I wouldn't have had the perspective to know not to push back at proposed changes.

Some Assembly Required

After weeks of labor, dozens of hours of reviewing YouTube videos, countless splinters, and at least a few cuts, the workbench was finally completed. In the final reckoning, I constructed the workbench top, the wellboard, and the two side aprons in my class, building the legs and performing assembly and finishing in my garage workshop. Although it can be disassembled with a few bolts and screws, the castors I installed in the legs have so far precluded the need to do so. After installation of a 9" Yost woodworking vise, I gave it a new set of extension panels and leather cover, turning it into an 11" vise. A few coats of clear water-based polyacrylic finish for protection and that was that.

Final Thoughts

I'm incredibly happy with how the workbench turned out. It has its imperfections - like anything in this world - but as I run my fingers over the scarred but smooth surface of the benchtop, I recall (now with fondness) each individual struggle those marks represent. There are so many things that I look forward to doing better (or simply differently) the next time I build this bench or really anything involving similar techniques, it just illustrates how far I've come along the way to making it.

I hope you've enjoyed reading this along with the pictures of the workbench's construction. It's taken a couple of years, but I can finally and at long last say it:

I DID IT!

Photo by Wil Stewart / Unsplash

Is not the name of my Stevie Wonder cover band! :)

In my last post, I introduced GravWell and talked through some of the concepts at a high level. In this post, I want to share a detailed background context of one of if not the biggest factors affecting GravWell's design and implementation. This post won't get into any code or detailed design, but rest assured future ones will certainly dive into the gory details!

Intuiting the maths

GravWell is a game that places an emphasis on exercising a player's inherent mental ability to work with structured, patterned system. Through navigating their craft around the star system, players perform incredible and complex mathematical feats of calculus right in our heads with nary a calculator or slide rule to be found! With the right information, a bit of guidance, and sprited persistence, players can make more-or-less accurate predictions regarding their ship's orbital mechanics. Predictions like these:

• Is the craft in a stable orbit?
• Am I currently heading towards apoapse/periapse (highest or lowest altitude/slowest or fastest speed segment of an eccentric orbit
• Roughly how eccentric is my orbit?
• Where, when, and how much deltaV do I need to burn in order to change my orbit?

The Human GPU

The human brain devotes a lot of its' overall processing power to vision and image processing.1 This makes sense if you think about the amount of sensory information that is visual compared to the data density of other senses: in computer terms, a 1 minute long video shot in 4K@60fps will have a far larger file size than the equivalent length audio sample; simply put, the video has a higher information density. This information is sort of aggregated with other sensory data and presented to more recently evolved (e.g., "higher") areas of the brain that integrate that data with similar experiences and memories, which surfaces that data to the decision-making cognitive functions that calls itself "me".

Data integration

One might say that this all sounds interesting, but why am I talking about neuroscience in a post about a video game? The digression is important in understanding how GravWell makes something "hard" (e.g. orbital mechanics, gravity) and turns it into something that is accessible, challenging, and most importantly FUN. The secret is in the presentation. Through interaction with our everyday world, we build a detailed internal model, a simulation, of the world. Often, when engaged in rational decision-making, we will query this internal simulated world to examine various potential outcomes of a scenario. For efficiency's sake, our brains are very good at creating shortcuts and abstractions that simplify the simulation - there are a lot of cognitive biases based on those simplifications, as are most optical illusions. This ability to use abstract concepts tied together with familiar experiences is the key to the Gravity Map.

Photo by Natasha Connell / Unsplash

Spinning up a VM in your head

Through interaction with the world, we learn and internalize the basic behaviors of physics - a ball tossed upwards will eventually fall back to the ground, water flows downhill, etc. Our further experiences extend that model - making a tight turn in a car pushes you outwards, trucks take longer to stop than small cars, and jumping from a swing at the top of the arc imparts greater leap, etc. Those basics are pretty common to folks' everyday life, but as a person pursues more specialized activities, their models are augmented by long hours of study, training, and practice. Airplane pilots work to gain an intimate knowledge of the relationships between lift, drag, and angles of attack, whereas a SCUBA diver might internalize a model of water pressure, depth, and O2 saturation. The common factor here is that people can train themselves and their brains to deal with situations and input completely different from any condition that might naturally be encountered.

Gravity Training

The easiest way to connect someone with an unfamiliar concept is by relating the unfamiliar to the familiar. We use tools such as simile, metaphor, and comparative description to communicate these concept maps to other people, but similar techniques can be used to propagate information via other means than language. The Gravity Map visually represents the gravity field of a star system, aggregating and transforming experiential input data from a form unsuitable and unfamiliar into one readily consumable.

Let's pretend that we wanted to "manually" create a gravity map of the environment around low-Earth orbit (LEO). How do we do this? Well, we'd get into our spacesuit, climb into a rocket, and blast off into orbit. As our rocket falls around the earth in its' orbit, we periodically measure the gravitopotential-metric at our current position in space. To make this measurement, we must float very still at the center of our craft and measure the very small resulting tidal effects in the microgravity by feeling the acceleration with our bodies. We note the direction and magnitude of the force along with the coordinates identifying the location of the measurement, but it is only by taking a large number of these measurements and then comparing them in aggregate that we are able to assemble an actual map of the LEO gravwell. This is where our mental models break down; we simply can't hold enough information in our minds to create this map on the fly!

Chunking Gravity

No, that isn't the name of my cover band - although it would be a pretty rad name for one - who would that band cover? Rather, it's a reference to the process by which our mind organizes, references, and uses learned information. A person's primary cognitive process - their "attention" - can only hold a finite number of items in its' "stack". A given item on this so-called "stack" can reference or represent almost anything, from a single detail to a broad abstraction. The way this is most typically described is that as a person's knowledge/experience grows, concepts, principles, practice, etc. are "chunked" and indexed with each other.^*

Our minds internally make use of these chunks and their properties in otherwise unfamiliar by iterating against a set of potentially relevant chunks, testing them against observations, and tweaking the model based on those results. This is the concept that I want to leverage with GravWell.

Neuro-plastic Chunking Hacks

Also not the name of my cover band (although again, I would want to hear a band with a name like that out of principle...). So what does all of this chunk stuff mean, and why are we spending so much time and pixels on it? And why are we trying to hack our chunks, anyway?

To bring this back full circle, people have lots of image processing juice and they already have chunks describing/modeling how objects tend to behave kinematically in the everyday world. Gravity is at once a familiar force at the everyday scale of apples falling from trees, but is insensible at larger scales - no one standing on Earth's surface could claim to feel the gravitational pull of Jupiter, no matter what the astrologers say. By mapping the insensible into the realm of the sensible, we can engage, enlighten, and entertain a players' mind by opening up to them a completely new world.

Photo by Glenn Carstens-Peters / Unsplash

^* - Here's an example: a beginner at chess might struggle to maintain knowledge of the board's current state at the same time she is attempting to run internal simulations of potential moves and opponent counter-moves because she must constantly juggle the positions and sequences of moves for each piece on the board. In contrast, a chess champion has internalized - "chunked" the same information - into entire groups of strategies, gambits, and the like which may span dozens or more turns into the future. This highly-experienced player isn't necessarily smarter than the beginner, but it is her ability to efficiently process the chess board information that allows her to actively use more complex thought processes - spinning up more VM's to run more detailed simulations of her opponent's predicted behavior. This can also be known as thinking for the long-term, grand strategy, "getting into your opponent's head", etc. An important property (for our purposes) of these chunks is that they can be hacked (in a good way!).

Back in Februrary of 2019, I decided to embark on a little side-project. I wanted an excuse to learn how to use the fabulous BabylonJS game engine along with gaining proficiency in TypeScript, I had been avidly reading through Winchell Chung's amazing Atomic Rockets website (seriously, if you have any enthusiasm about space travel, science fiction, rockets, etc. you need to check this out!) when I came across the gravity maps section. In a flash of inspiration, I came up with GravWell.

Original post image by Josh Elster based on artwork by H.K. Wimmer

Picture a patch of space somewhere in our Solar system. According to Einstein, mass tells that piece of space how to move, and space tells mass where to move. Mass - i.e. the distribution of matter in space - gives objects their gravity, which in turn dictates the shape of space-time around that mass. The analogy most often used to describe this is as a rubber sheet, with marbles or balls of different weights causing the rubber to dimple in various ways. A star makes a deep dimple in the sheet that the far smaller and less massive planets endlessly circle, but it's important to remember that though they are less massive, those planets do have enough mass to affect the shape of space around them. The dimples are a 2-D representation of our 3-D space, but it's a good enough analogy for our purposes.

In GravWell, players must navigate their ship around a stellar system while avoiding unplanned "lithobraking" - crashing - contact with any of the celestial bodies. At all times, the celestial spheres tug at the players' ship with the force of their gravity. The ship has powerful engines, and armed with a map of the gravitational potential, players are given the tools to escape from their gravitational prison. This map (a form of height map) is computed by dividing up a 2-dimensional world map up into "chunks" of what I call "grav units", measured in meters. Due to some quirks of the underlying framework, this unit must be some power of 2 - 2, 4, 8, 16, 32, 64, 128 etc. The value this parameter takes dictates the resoution capability of the physics simulation - if the grav unit is set to 128m that means the world map is divided into chunks 128 meters in size. Each chunk is treated as a single point for purposes of computation, which when combined with the world size parameters figures the absolute minimum memory requirements for a given world size because the height map array storing this data must contain an entry for every single point on the map. This is represented as a 3-Vector (x, y, z) giving the point's location in world space. Because we are simulating a 2-D environment however, we can use the unneeded y- axis scalar to store the value for the magnitude of gravity at that point. The player's ship follows the contours of gravity as it is pulled around the system by the planetary bodies comprising that system - a central star along with 1 or more planets. When the simulation updates, planets orbit their star in pre-determined orbital paths controlled by the parameters of the primary and the planet. In other words, the planets are "on rails", and unlike the player's ship they are not (at this time) affected by masses other than the star.

As a game, GravWell isn't dissimilar from a half-pipe snowboarding type of game. Players will have points added or subtracted from their scores based on various factors such as:

• Total time to completion
• Delta-V expended (i.e., how much fuel was used by propulsion by the player)
• Number of times player corrected their course
• Orbits completed around planetary bodies

I want to be able to see the different Lagrange Points - points where the gravitational forces between two bodies cancel out - as their ships are taken along by the flow of gravity. I want players to be able to enter orbits around planets or even those L- points by intuitively using the fabulous computational power of the human mind to read a real-time gravity map. Players complete scenarios by achieving and end goal, like achieving system-escape velocity. Each scenario can have a different set of starting conditions for its' stellar sytem, with different numbers of planets, theirs and the star's mass, radius orbital distances, etc..

This is a good time to mention the performance characteristics of GravWell. Computing the gravitational field of any point in the world is a relatively light-weight operation in terms of CPU cycles. This is a good thing because as discussed above, this computation needs to be performed for every point in the height map. Every frame. There are some optimizations in place, such as skipping points inside of a planetary body or short-circuiting calculations for points extremely far from the camera, but that isn't near enough to get to a minimally desired frame rate on most hardware. JavaScript's inherently synchronous nature is naturally the reason why this is such a bottleneck to performance, and of course the easy answer to this is to perform the height map updates someplace else.

Eventually, I'd like to allow height map data to be streamed from sources external to the game - whether it's a browser worker process, a Blazor webasm, or a server-based API endpoint. This would allow for some potentially exciting simluations and scenarios that would go far beyond what GravWell is currently capable of today. For example, it's currently very difficult to balance performance above ~10fps with world sizes larger than about 9600m x 9600m. The inverse square behavior of gravity along with its pathetically weak Gravitational Constant place some constraints on the minimum mass, orbital radii, which produces some indirect constraints on the overall world and thus the height map size which then leads to poor framerates and OOM problems, etc. I've got a whole swathe of features planned for GravWell, and eventually I'm thinking about open-sourcing the whole thing and making the repos public. What do you think? Is this something you're interested in contributing towards? I'm interested in feedback - please feel free to @ or DM me on Twitter with your thoughts!

You know how some projects never seem to find their strides? A promising start shows quick progress, but work quickly gets mired down in building "all the other things" that a good piece of software needs but which aren't directly related to the problem which the software is intended to solve. Every little piece of this type of functionality that doesn't have to be built (either bespoke or integrated) is more time left for you to focus on your product. Here are some things that I've found can help take your software infrastructure to the next level.

1. Azure Durable Functions (serverless computing)

Serverless computing is so cool. Forget about the days of fiddling with IIS and various other OS and framework settings - just code and go! Durable functions take this to the next level by allowing long-running, stateful orchestrations to "just work" without additional management on your part. Part of the magic is how Durable Functions make use of Event Sourcing to do their thing. Your costs are easier to keep under control with Consumption-based pricing, while traditional App Service Plans can still be leveraged to offer consistency in performance and pricing. You can pretty much use the programming language of your choice to work in, whether it's C#, JavaScript, or even Powershell! Iteration can be quite rapid when working with CSX (C# script) or other non-precompiled language options.
Azure Functions

2. Azure Active Directory (AAD)

If you're developing a solution, service, or software that requires authentication and authorization functionality, what are you waiting for? Azure Active Directory has a whole host of features and capabilities that incorporate seamlessly with most Azure resources. Role-based access controls (RBAC) give a consistent and powerful way to control access levels at a very atomic level, whether the user is a human making use of 2FA or a service storing secrets in an Azure Key Vault. App Services, in particular, use something called easy auth to make federated identity and claims across multiple identity providers (e.g., AAD, Google, Facebook, Twitter, etc.) well, easy. Tight integration with the Office 365 suite of products seals the deal for anyone looking to connect different sets of building blocks into a functional whole.
Azure Active Directory

3. Office 365 with Flow

This entry could just as easily have been entirely about the O365 suite and that would have been enough. The Office 365 product suite is comprised of far, far more than just the traditional Word, Powerpoint, etc. applications. Flow is the real game-changer here, with hundreds of connectors to different apps and services, it's never been easier to "automate all the things". Not confined to only integrating with other O365 apps, Flow is one of the best attempts at realizing true, generic consumer-level workflow software that is quite eminently usable by almost anyone with any degree of technical competence.
Office365
Microsoft Flow

4. Docker and Docker for Windows

For many developers, their knowledge regarding Docker and containerization technologies starts and ends with knowledge of their existence. Don't even have that base? Here's an overview. If you're one of those developers, I would highly recommend putting some time into learning about Docker, containers, and related technologies - I can guarantee that it will not only you more valuable as an employee, you will find ways that it can ease your day-to-day aches and pains on the job. Feature support for Windows Containers increases on a regular basis, but there's still some work to be done (follow the team's progress) when it comes to running Windows and Linux -based containers side-by-side.
Docker for Windows

5. Container orchestration with Kubernetes

Kubernetes puts the Ops into DevOps. An easy way to think about it is that Kubernetes (or k8's for those in the know) is the macro- to the Docker container's micro-. As an orchestrator, Kubernetes manages the lifecycles of groups of containers and their dependent infrastructure. Groups of containers work together to comprise a multi-variate, highly available, scalable, and robust microservices application infrastructure for your code. The advantage of this is that you write more code relevant to the business domain (and less housekeeping types of logic). The disadvantage is that Kubernetes and microservices orchestration can be a fiendishly complex topic, giving it a bit of a high learning curve.
Kubernetes

Summary

Right now is a very cool time to be in the business of making software. I don't think there's any other time in my professional career where I've felt more empowered by the available tools and services. So many of the tedious, fault-prone, and risky components involved but not directly related to the software's core goal used to have to be built, bespoke, every time a new software project was launched^[1]. The latest set of tools are more powerful and accessible than ever, allowing more people than ever before the power to make their dreams a reality.

If you've been to the previous incarnation of this website, you'll notice that it suddenly looks a bit... different. That's because I'm in the process of moving over to the Ghost publishing platform hosted up in my Azure subscription.

I didn't have a problem with Orchard CMS, I simply needed to make a change in my website to save on hosting costs and the like, and at the same time I wanted to expand my horizons a bit - ghost fits the bill on both fronts.

Over the next few weeks I'm going to be moving old content (probably to a new archives section) as well as posting some curated and updated posts from my blog over at InRule.

Infestation is the first release for Liquid Electron.

Meet the crawling horrors of Infestation

(Click headers to view a description)

Cockroach

The cockroach is a bottom feeder. Nothing is off limits to its' mandibles! Muffins, steak, and even the shattered corpses of other insects you've destroyed are all tasty treats for this disguting horror. The cockroaches' slow movement speed is offset by its' heavy carapace which can absorb a great deal of punishment. A consequence of this robust physique is that cockroaches won't grow very much from munching on your food.

Spider

Spiders are dangerous. They're fast, they're tough, and worst of all, they're merciless. Occassionally, a spider may decide that another insect makes for a tasty incubator for a smaller swarm of like-minded horrors. Make sure you take the spider out before it can make your troubles worse!

Fly

Annoying and seemingly harmless, the fly can buzz straight over any and all the painstakingly constructed barriers you've erected to keep unrulies away. Their low health is compensated by high speed, so watch out to make sure one - or more - don't slip through your defenses.

Ant

The shock-troopers of the insect world, ants make up for their slow speed and moderately weak armor by attacking in large packs. Ants have no sense of self-preservation, and will cheerfully crawl over the broken bodies of fallen comrades to reach their goal.

When I go on vacation to different places, I snap a lot of photos of scenery – mountains, rock formations, etc. When I got into playing Skyrim, I so enjoyed the landscape that the first few hours of the game saw more screenshots captured than monsters defeated!

A few weeks before my virtual hiking excursions began, the ASP.NET Web API was released in beta form along with a whole bunch of other beta-bits goodness. These different bits enable developers in ways that would otherwise require a lot of effort to create bespoke. These two otherwise unrelated events enjoyed a confluence when they met in my brain, forming what would eventually lead to the conception (perhaps an Inception?) of this project.

A Combination of Ideas

One evening of play, I was positioning my ‘camera’ for a particularly stunning sunset shot when I had a sudden image of that picture on a postcard along with a pithy catch-phrase in bold coloring extolling the virtues of some vacation spot. My concentration slipped, causing my unfortunate hero to plunge to his death from the top of a mountain, but good thing for him that’s he’s a plucky fellow. His long fall gave me time to ponder: the name PostcardApp flowed naturally, as did ‘Postcards From Skyrim’. Great, but what about it? I ended up purchasing the domain just in case while I pondered the what, how, and why of my idea. It didn’t take long to merge the idea of making a postcards web application with my desire to share and learn how to make use of all the shiny toys available to a modern developer.

Story First

Thinking about what I wanted the app to be able to do, I brainstormed some goals and stories to help sharpen my focus.

Overall Goals

• Simplicity. Only use what’s needed to satisfy the stories, and keep it simple. Did I mention that I wanted this to be simple? Yeah, more an ideal than a likelihood, but a worthy aspiration nonetheless!
• Useful. It has to be able to accomplish some actual task, regardless how contrived that task might be.
• Explore how to leverage different technology pieces together, including Windows Azure, MVC, and Javascript
• Serve as a reference guide for myself and for other developers looking to Get Things Done

User Stories

Though the concept is relatively simple, I could always use practice in identification and authoring of user stories. Here are a few I came up with:

1. [As a user,] I want to be able to choose a background and salutation for the front of my postcard so that I can create a custom postcard.
2. [As a user,] I want to be able to write on the back of the postcard so that I can taunt my envious friends with how awesome my virtual vacation is going.
3. [As a user,] I want to be able to save and share the postcards I create so that other people can be bedazzled by my creativity and wit.

Coming up next, we dive into the site’s layout and how iterating the design in short increments yielded superior results.

Click here to go to the next part