After weeks and months of planning, it is finally time to bring your idea to life. Are you ready to hire a developer? How do you know when you are ready to hire a developer? Moreover, what do you need in order to be ready for a developer? What follows is a description of the software development process, as well as things one should consider in order to better attract competent and experienced developers.

Budget Phase: Budget discussions are hard because it often involves a complex range of emotions. Some individuals are strongly against providing a budget ahead of time, feeling if they provide an amount which is too high, an unscrupulous person will take advantage. While this seems reasonably cautious, the truth is that potential developers will use the budget to gauge whether or not the client has done their homework.

If one looks through online ads for developers, one can see a pattern. One will see proposals such as: “We will do this for $500. Please email specifications, and a date when you are ready to start.” Now, nobody who wants to stay in business is going to commit to a price without understanding the scope of the project. Let me phrase this in another way: Even in the absence of project specifications (or a budget), developers will still submit offers.

Pro Tip: Take the time to research what it costs to develop a website. Sites like Amazon, Pinterest, and Facebook spend hundreds of thousands of dollars in development. If one wants a site like Facebook, one should have a budget to reflect that goal.Experienced developers are attracted to clients that are informed and realistic. For example, $100- $500 budget for an E-Store is completely unrealistic. $16 - $20 per hour is unrealistic.

If you are uncomfortable providing a fixed number for a budget, provide a range. If you really have no idea for a range, then state in the advertisement that you are unsure what the budget needs to be. Seasoned developers will be able to describe the approximate cost of development. If the cost of development is more than the budget, expectations will need to be revised.

** Yes, there exist incredibly talented developers in less prosperous countries who can work for much less. However, the hidden costs associated with outsourcing are often unexpected — and substantial. A good Product Specification can mitigate expense due to miscommunication, however it cannot help with issues which arise from cultural differences.

Expectations Phase: As when building a house, there are a myriad of details that can serve to derail and sideline your project. And like building a house, one of the first things needed is a list of requirements. To continue with the building analogy, the list might look like this:

• 3 bedrooms
• Main floor laundry
• 2 bathrooms
• Cabinet color and style
• Outlet covers
• ...and so on.

A list of building requirements and design decisions could go on for many pages; likewise, it is no different for software, except the list of requirements looks different. Using an E-Store as an example:

• Display categories of products
• Integration of shopping cart
• Allow admins to add or remove products
• Allow users to create accounts
• ...and so on.

Pro Tip: Speaking as a developer, one of the first questions for any potential client is whether or not they have a clear list of expectations. When given a clear list of expectations, an experienced developer will be able to quickly understand the scope of the project. Not having a clear list of expectations is one of the leading reasons for cost overruns and project abandonment. Also, hurt feelings.

If the client's expectations are unclear, few developers will want to take their own unpaid time to figure out what the client needs. Further, when the stakeholders are viewing offers from competing developers, there is no way for them to compare with each other, since each offer is based on the developer’s own interpretation of the project. Imagine collecting estimates from home builders without telling them how many bedrooms you need.

If offers from developers vary widely in scope and price, it is generally a clue that not enough detail has been provided. If you find yourself in a place where you really have no idea what you need, it would be well worth hiring a developer/consultant for a few hours of consulting. In anywhere from two to ten hours (in general), the consultant can create a complete Product Specification which can be handed out to potential developers. In this way you can guarantee the estimates will be more consistent.

Design Phase: After expectations, any potential developers will want to know about design requirements. Some design requirements may be implied in the Product Specification (e.g., mobile development support), but there is no way to determine if a client has any strong feelings towards a particular design or color.

It cannot be over-emphasized how important design requirements are, as the entire success of your online presence lies in visitor engagement.

Visitor engagement depends on three important pillars: Appearance, Usability, and Clarity. A user will form an impression of your company or product in mere moments. This is why corporations spend tens of millions of dollars on branding and packaging. Entire departments are allocated for usability-testing to ensure the products are as easy to use as possible. Virtually everyone in the world has experienced the frustration of trying to find they want on a website; consequently, they can vouch for the importance of finding clearly-marked, accessible information.

The design phase of the development process can take anywhere from a few hours to dozens of hours. Armed with the Product Requirements, a designer can generate a professional palette, complete with wireframes and illustrations. While a design studio is one option, there are many talented designer/developers that can do this, too.

Pro Tip: The least favorite thing I hear from clients is ‘Make it like Facebook/Ebay/Reddit’. Aack. Right away I have to explain copyright infringement, which is not at all the way to start a relationship. It also raises concerns that the client may not have done all of their homework.

Quick Review: You are not ready to hire a developer until you have the following:

• Budget Specifications
• Product Specifications
• Design Specification

If it is not clear why each of these are critical to the success of the project, then leave it at this: Without proper specifications, one will not attract quality developers.

Hiring a Developer: As a developer, if I am provided with the specifications as described above, I will take the time to read them. In just a few minutes, I can easily discern whether I have the appropriate skillset; whether the budget is realistic for the project; and whether the client seems prepared.

Choosing a developer is ultimately a personal choice. Seasoned developers have many characteristics, with one of the most important abilities: communication. Moreover, a good developer will be able to completely describe how the product will be built—either in technical or non-technical terms. A good developer will also know which approach to use, and why.

Evaluating whether or not the developer has the skills needed is more subjective. For instance, one should notice when answers seem vague. However, it may just be that the developer has not figured out exactly how to do that part, which they should be able to explain. Software development is often nuanced, and implementation details are often not finalized until development begins. Experienced developers should be confident and forthright, not evasive.

There is some help. In this day, any developer worth their salt will quite likely have side projects they can show and describe. Github and Bitbucket are often used to share personal projects, and are a good way to open a line of discussion. Even if you are non-technical, you can ask overarching questions about the projects, such as what was learned, if there were any problems, and so on. If the developer you are interviewing is anything like me, they will become much more animated when talking about personal projects.

Some developers will argue they have no projects to show because everything they have done is proprietary. Personally, I think this indicates laziness. The talented and passionate developers spend their free time learning new things, and will always have projects to share. If the developer doesn’t have anything they can show, or they only have a few small projects, it may be a clue they do not possess the needed breadth of experience. Your project may not need someone with a lot of experience, but they should have a few samples of something.

That said, lack of a portfolio is not necessarily indicative of anything. A great majority of my own development experience is on internal corporate systems, and cannot be ‘demonstrated.’ Nevertheless, those projects are included in my resume, and would be discussed in the normal course of the interview.

Pro Tip: Aside from the obvious need for development skills, the developer one wants to hire will have a variety of other skills which can provide value in other ways. For example, they should be able to discuss how design decisions can affect viewer engagement; how developmental decisions contribute to maintenance costs over the lifecycle of the product; or how the ROI functions for the inclusion of a new feature. In other words, they should treat the product as a business, and should be equipped to apply a strategic approach to help you meet your goals.

Conclusion: While one may be tempted to jump right to development, make sure you have a budget, a product specification, and a design concept.

For any small business owner trying to compete on a global economy, a website is often the only opportunity to present one's business and values. As an important promotional tool, countless hours are spent in deriving a carefully chosen color palette, tweaking layouts, and crafting the right message until finally, the site goes live.

Let's assume that in spite of all of that, a visitor still manages to land on our site. We very much want them to spend some time, browse, and get to know our company. Some web sites have meeting notes, press releases, and videos. Some websites include a dizzying mix of everything¹. Like many other developer websites, Extant.Digital includes some technical content. However, this content was not translating into page clicks.

We decided on another proven tactic. David (intern extraordinaire) , has been working on a micro service that displays a small quiz in any web page by embedding a few lines of code. Simply put, it is a responsive slideshow² in which visitors are asked questions relevant to a particular business. We are a web app shop, so our questions related to web app development.

The questions are carefully chosen to reflect available services and value. For instance, a site for a defense attorney may have the following question, "How many people are wrongfully arrested for domestic violence each year?". The suggestion to site visitors is that the attorney is familiar with wrongful arrests and family law. On the Extant.Digital site, questions were chosen to highlight problems common to many websites. "What percent of websites have no call to action?" (70%, by the way)³

In an effort to be honest about the questions, it was decided that a source for each question and answer would be included. Since we are going through the effort, our visitors should at least be afforded the opportunity to go to the source. We want to educate, not mislead.

We are currently doing a limited pilot to see how things go, but initial testing is positive.

Notes:

1. This approach seems inefficient because the site trys too hard to serve multiple audiences. The purpose of a site should be expressed in just a few short sentences, and I don't think that can be done easily when trying to do too many things. Technical articles won't convert sales if the viewer is non-technical, and users subconsciously feel lost if there is too much content.
2. Slideshows in general are a bad way to display content. Too often, important content is hidden, and accessibility is hindered. In this case, either the visitor will interact with the quiz, or they won't. No important information is being hidden, usability is not hindered. In this case, we think that breaking the rules is acceptable in order to achieve our purpose, which is to encourage longer site visits.
3. Perhaps even more shocking, 6 of 10 websites fail to include a phone number.

One of the most frequent comments from new developers revolves around being able to demonstrate ability and experience to potentical employers. A frequent topic of conversation amongst new (and even experienced) developers revolves around successfully navigation a technical interview. While the obvious answer is to have a portfolio, I am often left with the impression that some do not fully appreciate the value of a personal portfolio as a marketing tool.

Since this is a presidential election year in the United States, and I happen to have a side project that is governemt related, I thought it may be a useful example of how one can control the narrative of an interview.

A couple of years ago, when researching the availability of large public data sets, I ran across www.govtrack.us, a web service that offers access to the voting data from congress. I, like many others, have opinions about our government, so finding this data was a small gold mine. There was a ton of data available, and the data aligned with my interests and my curiosity.

It turns out that govtrack.us provides an API, allowing third parties to access the data. I’m from South Dakota, so obviously I am most interested in how my elected representatives are voting. I thought it might be fun to use Twitter’s API to post that information to my Twitter account. Then I thought that it would make more sense create a public Twitter account that other South Dakotan’s could use.

I also decided that since I was going through the work to parse out the information for a single state, it wouldn’t be that much more work to parse out the data for all states. Instead of parsing out the data for a single Twitter account, I created fifty Twitter accounts, one for each state.

Coming up with clever domain names is hard, but since this was a personal project, a clever name was not of high priority. I picked up ushouldknow.us, and went about creating fifty Twitter accounts using a combination of the domain, and each state’s two letter abbreviation. The Twitter account for South Dakota is sdshouldknow, the account for Minnesota is mnshouldknow, and so on.

In broad terms, the program flow is like this:

• Several times a day, the application queries the govtrack site for all Congressional voting data.
• The application then filters through the data, and separates the data by state.
• The data is fed to each Twitter account.

Exactly how would one leverage this in an interview? In my experience, the the first interview is always to get to know each other, and the second (and maybe final) interview is the intial technical interview.

In the initial interview, one can count on any number of common questions. The first question is almost always "Tell me about yourself". My strategy at that point is to give a brief summary of my experience (which they would have from my resume anyway), and launch right into "One thing I have been working on in my spare time is,..", and then I provide a description of my project, much as I just did in the preceding paragraphs. Your mileage may vary, but it has been my experience that once I go down that path, the interviewer allows me to lead the interview. I can avoid the other sterotypical questions ("Why do you want to work here") by using up the allotted time talking about what you want to talk about, and asking questions of your own. "Why would I want to work here?"

In the technical interview, one can also count on any number of questions, one of which is going to be "Tell me about yourself". This leads again right into an overview of whatever side project that you want to discuss. But since this is a tecnhical interview, there will be natural places in the project description that you can elaborate on the technical aspects. For instance, I can talk about:

• APIs used to pull data from Govtrack, and push data to Twitter
• My introduction to Laravel, and what problems using Laravel helped me solve
• The issues I had deploying Laravel on a shared server.

Instead of being quizzed about what you know, you can show what you have done and let them infer what you know. If they have specific questions, they will ask. Again, I find in most interviews that the other parties are often content to let me dictate the interview. Not only are you able to dictate the interview, you will feel and appear more confident, and sound more authoritative while doing so. That alone will make you stand out, and at least leave a memorable impression.

I understand that my project in this example is much more complex than most will have, but it should not be a deterrent. My github account has a stupid little log on form that I leverage to discuss design experience. It doesn't take much of a project to stand out from your peers.

In conclusion, to those who think that side projects are not useful, my experience says otherwise. For those who think they cannot because they only do DB projects, or are only back-end developers: You are supposed to be problem solvers; figure it out. Otherwise you are missing out on a valuable way to market yourself.

I have been taking pictures as often as I can in hopes of scoring one or two that I can use in a website design.

I have been thinking some time about a simple little effect for creating a neat 'animated' text feature. It isn't terribly difficult, but it does provide some other ideas that I want to work out. It uses a simple JQuery function, and some simple JavaScript.

Here is the effect:

Here is the code:

<!DOCTYPE html> <html> <head> <title>&amp;Animated&amp; Background</title> <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.4/jquery.min.js"></script> <script> //http://jsfiddle.net/3tQsc/ var scrollSpeed = 70; // set the default position var current = 0; // set the direction var direction = 'h'; function bgscroll() { // 1 pixel row at a time current -= 1; // move the background with backgrond-position css properties $('div.content').css("backgroundPosition", (direction == 'h') ? current + "px -23px " : "0 " + current + "px"); } //Calls the scrolling function repeatedly setInterval(bgscroll, scrollSpeed); </script> <style> .content { background: #00688B url("http://extant.digital/images/clouds.png") repeat 0 bottom; width: 800px; height: 200px; margin: 10px; /*border: 2px solid #ccc;*/ background-size: cover; border-radius: 12px; border: none; /*box-shadow: 2px 2px 2px #000;*/ } img { height: 200px; width: 800px; position: relative; border-radius: 12px; } </style> </head> <body> <div class="content"> <img src="whitemask.png"/> </div> </body> </html>

The text is actually an image where the letters have been removed from the layer, leaving the letter portion transparent (otherwise known as a mask). The scrolling is accomplished with the tiny bit of JavaScript.

I am currently adding functionality to an existing web application that relies heavily on a stew of JavaScript plugins to do the most mundane of tasks. That's a great way to save time, but eventually one ends up with a mish-mash of libraries that no one person can ever understand, or ever hope to maintain. I think it is indicative of a dumbing down of skill-sets, especially when libraries and plug-ins are used where a few lines of code would suffice. I like to think the developers that come after me will be happy that they don't have to know anything other than JavaScript in order to understand my uploader. This code is based on code from www.matlus.com, and will only work on HTML5 compliant browsers. Of course if you have no idea how to use JavaScript, use a plug-in.

To start, we create a basic HTML template (Or use this one), and add some basic fields.

<!DOCTYPE html> <!-- Basic HTML5 template from extant.digital --> <html> <head> <title>Basic Template</title> <style> </style> <script></script> </head> <body> <button class='triggerUpload' onclick="triggerFileUpload()">Select Documents to Upload</button> <input type="file" name="fileToUpload" id="fileToUpload" onchange="fileSelected();" multiple="true" style="opacity: 0;"/> <div class="files"></div> <button onclick="uploadFile()"> Upload </button> <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script> </body> </html>

I am using html onchange listeners to eliminate a couple of JavaScript listeners, and adding simple style to make sure that the spans take up space on the page.

<style> .fileObject div span{ display: inline-block; height: 20px; min-width: 100px; } </style>

Now for the JavaScript. Since we are already using the built-in file selection capability of HTML5, all we really need to do is add some additional functionality to add a view for each of the files we want to upload. When the user selects some files, the fileSelected function is fired. It in turn calls fileToUpload, passing it a single file.
The 'file' is a File Object (reference) with various properties that we will use to make a simple view element.
Reviewing the html that is generated by the fileToUpload function, there is one thing important to note. The fileObject div id attribute is set to the name of the file, minus the period and extension. The id is used to know which view object will be updated during the upload process.

function fileSelected() { var files = $("#fileToUpload")[0].files; //append file info template for (var i = 0; i < files.length; i++) { $(".files").append(fileToUpload(files[i])); } } function fileToUpload(file) { if (file) var fileSize = 0; if (file.size > 1024 * 1024) fileSize = (Math.round(file.size * 100 / (1024 * 1024)) / 100).toString() + 'MB'; else fileSize = (Math.round(file.size * 100 / 1024) / 100).toString() + 'KB'; var html = '<div class="fileObject" id="' + file.name.split(".")[0] + '">' + ' <div>File Name: <span class="fileName">' + file.name + '</span></div>' + ' <div>File Size: <span class="fileSize">' + fileSize + '</span></div>' + ' <div>File Type: <span class="fileType">' + file.type + '</span></div>' + ' <div>Progress: <span class="progressMeter"></span></div>' + '</div>'; return html; }

At this point, the files should be staged and ready to upload. Clicking on the Submit button fires the uploadFile() function, which is a function that grabs the staged files for processing. The files are handed one-by-one to the singleUpload function.

function uploadFile() { var files = $("#fileToUpload")[0].files; for (var i = 0; i < files.length; i += 1) { var file = files[i]; singleUpload(file); } } function singleUpload(file) { var name = file.name, xhr = new XMLHttpRequest(), fd = new FormData(); fd.append("fileToUpload", file); xhr.addEventListener("load", uploadComplete, false); xhr.addEventListener("error", uploadFailed, false); xhr.upload.addEventListener("progress", function(e) { uploadProgress(e, name.split(".")[0]); }, false); xhr.open("POST", "upload.php"); xhr.send(fd); fd.append("fileToUpload", file); }

The singleUpload function is the most complex, but is nothing too difficult. This uses an XMLHttpRequest object, and a FormData (reference). We append our file that we passed in to the new form data object. This is simply a name-value pair.
Next, we add a load, error, and progress callback. Again nothing too difficult. The uploadProgress callback uses an anonymous inner function to update progress meter. This is where the file name as an id will come in handy, allowing us to update the correct progress meter for the correct file. Remember to remove the extension from the filename.

function uploadProgress(evt, name) { if (evt.lengthComputable) { var percentComplete = Math.round(evt.loaded * 100 / evt.total); $("#" + name + " div span.progressMeter").text(percentComplete.toString() + '%'); } } //Other callbacks function uploadComplete(evt) { /* This event is raised when the server send back a response */ console.log(evt.target.responseText); } function uploadFailed(evt) { console.log("There was an error attempting to upload the file."); }

That's about it. No real need for a plug-in.

When interviewing for a new position, there is always a little stress around asking the right questions so that both sides have a clear idea of expectations. One should ask about the onboarding process. Regardless of whether the new hire is a full time employee or a short term contractor, those first few days set the tone of the relationship. The answer to that question may bring some clues as to the preparedness of the employer, as well as how they treat new hires. When asked, do the interviewers provide a clear and concise plan with milestones, or do they stumble through an answer?

Onboarding is the series of tasks required to get the developer (or really any employee) set up on whatever infrastructure is needed to conduct business. For most, this means acquiring log in credentials for a workstation, development server, code repository, task reporting software, and any other number of systems. All in all, this seems like it should be a pretty straight forward process, but my experience so far is that it is not.

My onboarding experience is typically something like this:

1. Show up and get escorted to my desk by a lead developer.
2. On the way get introduced to an entire department, making faux pleasantries and shaking hands.
3. I finally get to my desk and dig out my bottle of hand sanitizer.
4. My escort leaves for a meeting, indicating someone named 'Hambone' would be by to help me with everything I need.
5. Flip on my assigned desktop and realize I have not yet been provided with credentials.
6. Wait for someone to show up.
7. Finally decide to bug the closest person to explain that I have no login credentials, and no idea how to get them.
8. Decide to go looking for 'Hambone'. He is in another meeting until late afternoon.
9. Secretary apologizes for scheduling mistake and hands me some log-in credentials.
10. System is unable to validate the credentials. Go in search of someone else that can help.
11. Eventually find out that the validation server is on a different internal domain, and the network guys just left for a 3 day conference.
12. After lunch, I am handed someone else’s credentials just so I can get logged into the system.
13. Of course the system has not been updated for nine months, so now you at least have something to do for the next several hours.
14. End the day finding someone to help check out code.

This is mostly hyperbole, but only barely. I have been in positions where it was three days before being able to touch the development and testing environments. A less ambitious person might enjoy being paid for doing nothing, and be delighted to discover that the company has low expectations as far as developer contributions. Personally, I feel a little icky when I go too many days with nothing to show, and a little discomfort when wasting resources.

This seems such an elementary process that I hesitate to call these suggestions.

First, have a discovery process to figure out exactly what is needed to onboard a new developer. Is the new hire a junior developer? Who will mentor? Is the new hire a senior architect? What systems do they need to access? What meetings do they need to be in? Is the new hire a contractor? Who is their point of contact?

Based on discovery, create a checklist that addresses each of those needs. If a mentor is required to help introduce the user to the system, enumerate the goals and responsibilities for the mentor. For example “The mentor is responsible for showing the user how to check code into our repository”. This process should be a concrete set of milestones to guarantee that the new hire has what they need to do their job.

For the love of all that is good, please, please, please have someone actually log into the various systems to verify that all credentials works like they are supposed to. Make sure your weird network setup for checking in code actually works from that machine. While doing that, make sure everything is updated to the latest and greatest.

Please do all of this some number of days before onboarding a new developer, not twenty minutes before they are due to show up.

Since things will go wrong, make sure there is support staff readily available, and that there are plans in place if things do go wrong. Make sure the developer has a list of people they can call if there is a problem.

Make sure the phone works.

I was recently browsing a post on r/javascript that asked how to create an autocomplete input field. I was a little bit disappointed that the only suggestions were for various JQuery plugins. This is a relatively trivial JavaScript exercise using vanilla JS, with a little help from JQuery. I consider this an intermediate-level exercise.

To start, we create a basic HTML template (Or use this one), and add a simple input field.

<!DOCTYPE html> <!-- Basic HTML5 template from sweeps-soft.com --> <html> <head> <title>Basic Template</title> <style> </style> <script> </script> </head> <body> <input id="myinput" value="" /> <div id="myselection"></div> <script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.3/jquery.min.js"></script> </body> </html>

To set things up, we want to add a simple style, and a JavaScript model containing some strings.

<style> #myselection{ display: none; width: 100px; height: auto; } #myselection div{ cursor: pointer; } </style> <script> //An array of strings to test our dropdown. var menuItems = ["Alpha", "Bravo", "Charlie", "Delta", "Echo", "Foxtrot", "Golf", "Hotel", "India", "Juliet", "Kilo", "Lima", "Mike", "November", "Oscar", "Papa", "Quebec", "Romeo", "Sierra", "Tango", "Uniform", "Victor", "Whiskey", "Xray", "Yankee", "Zulu"]; </script>

To wire in the Javascript, we need to do the following:

1. Wait for the page to load.
2. Once the page loads, add a listener to the input field.
3. When text is entered, search through the menu item list.
4. If the list has matches, add them to 'myselection'.
5. Add listeners to each of the elements.
6. When selection is clicked, fill in the input field

Waiting for the page to load is simple enough.

$(function(){ $("#myinput").keyup(function(){ getMatches(); }); });

The 'getMatches()' function is long, but not overly difficult to understand.

First, we loop through our array to see if there are any entries that match our search string. It there are, add them to the tempArray.

Next, if the tempArray has any matches, append those entries to the the selection div. Before we make the selection div visible, we want to add a click listener to each of the elements we added to the selection 'dropdown'.
When the user selects an element from the dropdown, we grab the text from the div, update the input field with that value, and hide the selection element.

function getMatches(){ var searchStr = $("#myinput").val(), //get input minLength = 0, //Set a minimum length for the search string tempArray = []; if( searchStr.length > minLength){ for(var i =0; i<menuItems.length; i += 1){ var str = menuItems[i]; if( str.indexOf(searchStr) > -1 ){ //Found a match. Add it to new temporary array tempArray.push(str); } } if(tempArray.length > 0){ //re-populate the list $(“#myselection”). html( appendEntry(tempArray)); $("#myselection").show(); //add a click listener to the new menu items $("#myselection div").click(function(){ //when a selection is clicked, we want to add its value //to the input field. $("#myinput").val( $(this).text() ); //now hide the selection window $("#myselection").hide(); }); } }else{ $("#myselection").hide(); } function appendEntry(tempArray){ var html = ""; for(var i=0; i< tempArray.length; i +=1 ){ html += " <div class='ir_gbl_entry'>\n" + " <span class='ir_gbl_label'>" + gbls[i] + "</span>\n" + " </div>\n"; } return html; }

That's pretty much all there is to it. The complete file lives on my github account. js-auto-complete

Yesterday I got a chance to listen to RadioLab via NPR. Episode 1 of Season 10 is called "Talking to Machines", which features stories about AI/Human interaction, and how it can be difficult to discern whether or not one is conversing with a human or a computer.
Talking to Machines

For some time I have been hosting content on multiple servers, and I am currently undergoing an effort to get my portfolio, blog posts, and tutorials under one roof. I have been meaning to do this for ages, but I was never able to settle on a framework. Finally I said "Self, you are a developer. You can do this."

So that's what this is. The reality is that this will probably become a monument to blog posts unfulfilled. I'm calling it the Blink Engine, as in, 'don't blink or you will miss it'.