While I haven't written about it here yet, much of my past year has been spent learning and writing Elixir.

As I have started to delve beyond surface-level language features I have found topics that are not discussed to my satisfaction (or at least in words that I think make sense) so I am determined to document my adventures here.

One such feature I recently started using that fit this bill is the macro. A macro in Elixir is a feature that essentially enables a sort of metaprogramming. For example, say you have several modules that all do the same things essentially, but in a different context - like notifications.

You might have MyApp.SMS, MyApp.Email and so on, where each module has common functions that they need. One option would be to write each module with all the functions it needs. Another would be to extract it to another module. But what if you could utilize the design approach of separating things into modules, without extracting and also without repeating yourself? Enter macros!

Here are some example code snippets without macros:

defmodule MyApp.SMS do

    def send(target, body) do
        # Your logic
    end
    
    def create_body(body) do
        # Shared function
    end
end 

defmodule MyApp.Email do
    def send(target, body) do
      # Your logic  
    end
    
    def create_body(body) do
        # Shared function 
    end
end

In this example imagine that create_body/1 does something that both modules will need. Perhaps it will take a body string and replace certain characters, sanitize it, or something along those lines. You could write it each time like I did above, or maybe even move it to a common module, but with macros you could bake in this behavior using using.

defmodule MyApp.NotificationFramework do
    def __using__(_opts) do
        defmacro do
            def create_body(body) do
                # Shared function
            end
        end
    end
end

With this macro created, we can now use it in one of the modules above:

defmdoule MyApp.Email do
    use MyApp.NotificationFramework
    
    def send(target, body) do
        # Your logic
    end 
end

use differs from import or require in that it essentially allows the module you are useing to arbitrarily insert things into the context that used it. In this case, that means that it is inserting the macroed create_body/1 function. At run time, the module as written above is essentially the same as the one with the use clause.

Here is what the module really looks like after the use:

defmodule MyApp.Email do
    def send(target, body) do
      # Your logic  
    end
    
    def create_body(body) do
        # Shared function 
    end
end

This can essentially create modules that are similar with the exception of maybe one or two functions that must be implemented differently, but should be self contained for design reasons (like ease of reading, or something similar).

Note there are some caveats around when the things in the macro are inserted into the context where use is called - in general the macro is compiled late so it will not overwrite things defined in the module directly. There are also some considerations around declaring variables - I recommend referencing the official documentation if this is an area you want to know more about.

There are other uses for macros that I have not yet explored, but I will certainly write more about them as I learn more.

Over the past 6 or so months I have been working on a new project. It started as a way to dive into Elixir and the Phoenix framework but ended up being (in my opinion) a fully fledged product.

The idea was to provide a hosted documentation service that was simple, affordable and easy to use. During my work on Statusy, I spent a great deal of time trying to find a decent product that 1) didn't cost a ton of money (a lot of options were easily $50+ a month for essentially a static site), 2) didn't require a ton of setup and 3) was mostly hands off. I couldn't find such a product, so I began working on Docuie.

Docuie allows you to create documentation projects as well as pages and headings to create a hierarchy for your users. It has a WYSIWYG editor, supporting both point-and-click style writing and full HTML editing if you wish to take that route. Docuie supports free docuie.com domains in addition to custom domains on the higher packages. Pricing is based around the features and number of seats you need, the cheapest plan starts at just $10 per month and gives you a fully featured product.

In addition, one thing we did with Statusy that I really enjoyed was offering free service to open source projects, so I will be continuing this with Docuie. If you run an open source project (or a charity of some sort) please reach out to me if you are interested in getting set up on Docuie.

You can view an example of the product through Docuie's own documentation site here: https://docs.docuie.com

Thanks for reading, I hope you will give it a shot if you are in the market for a documentation service.

That said, integrating with Paypal is almost always a great business move as it will aid in capturing as many customers as possible for your web service or platform.

This post will walk you through a basic integration for Paypal with recurring billing. Paypal's latest REST API will be used in combination with Paypal-Checkout.

Terms

Before diving in, it is worth explaining a few terms that Paypal uses often when it comes to recurring billing:

1. Agreement - An agreement is essentially a subscription, that is, a recurring payment that happens based on a predetermined schedule.

2. Billing Plan - A billing plan provides the basic information to create an agreement. Things like cost, term and taxes are defined on a billing plan.

Integrating Checkout.js

To begin, Paypal-Checkout (checkout.js) will need to be included on the web page(s) where you would like to offer support for Paypal subscriptions.

This can be done by adding the following script to the scripts area of your web page:

<script src="https://www.paypalobjects.com/api/checkout.js" data-version-4></script>

Next, you will want add a <div> where the Paypal button should be shown:

<div class="paypal-button"></div>

Lastly, some Javascript code will be required to instantiate the button and remaining functions. You can add the following directly to a web page, or you can add the Javascript to a separate js file and include that in your web page.

paypal.Button.render({

    env: 'sandbox', // Or 'production',
    commit: true, // Show a 'Pay Now' button
    client: {
        'sandbox': 'YOUR CLIENT ID HERE', // switch to 'production' if in prod
    }

    payment: function(data, actions) {
        /* 
         * Set up the payment here 
         */
         
         // The goal here is to return a promise or callback that
         returns a payment ID
    },

    onAuthorize: function(data, actions) {
        /* 
         * Execute the payment here 
         */
         
         // Once the user has authorized the subscription, you will
         need to execute the agreement here.
    },
}, '#paypal-button');

If you reload your page you should now see a button similar to what is shown below:

Creating Plans

Next you will need to create a plan to offer to your customers. Currently Paypal does not offer a web interace to do this, so plans must be configured via the REST API. That said, the best source for examples here would be the Paypal API documentation directly, found here.

Creating an Agreement

With plans created you can now begin the process of creating your first agreement. Paypal-Checkout does not offer direct support for billing agreements so you will need to manually handle this information server side.

First, write the server endpoint - in this example Python, the Flask framework and the Paypal Python SDK will be used (pip install paypalrestsdk - docs here) will be utilized:

# import standard flask modules
from urllib.prase import urlparse, parse_qs

@billing.route('/billing/paypal/agreement/token', methods=['POST'])
def get_agreement_token():
    plan_id = json.get('plan_id') // Get the plan ID from the request
    
    agreement = paypalrestsdk.BillingAgreement({})
    
    if agreement.create():
        parsed_url = urlparse(agreement.links[0]['href'])
        return jsonify({ 'token': parse_qs(parsed_url.query)['token'][0]})
    
    return jsonify({ 'error': 'failed'})

The goal with this endpoint is to take the plan ID selected by your customer and use it to retrieve a payment token. The token is retrieved on this line: parsed_url = urlparse(agreement.links[0]['href']) and then returned as a JSON object here: return jsonify({ 'token': parse_qs(parsed_url.query)['token'][0]}).

Back on the Javascript side, you can write an AJAX call to this endpoint like so:

paypal.Button.render({

    env: 'sandbox', // Or 'production',
    commit: true, // Show a 'Pay Now' button
    client: {
        'sandbox': 'YOUR CLIENT ID HERE', // switch to 'production' if in prod
    }

    payment: function(data, actions) {
        var plan_id = '1'; // change this to be the actual paypal plan ID
        
        $.ajax({
          url: '/billing/paypal/agreement/token',
          type: 'POST',
          data: JSON.stringify({ plan_id: plan_id }),
          contentType: 'application/json',
          dataType: 'json',
          success: function(data, status, xhr) {
            agreement_id = data.agreement_id;
            resolve(data.token); // resolve the promise so onAuthorize is called
          },
          error: function(xhr, status, error) {
            console.log('checkout error', error);
            reject(error)
          },
});        
    },

    onAuthorize: function(data, actions) {
        /* 
         * Execute the payment here 
         */
         
         // Once the user has authorized the subscription, you will
         need to execute the agreement here.
    },
}, '#paypal-button');

Once the payment token is returned in resolve the user is prompted to accept the agreement you have created. Once this has been done, the onAuthorize handler is called and you will need to execute the agreement for it to complete.

Executing the Agreement

To execute the agreement a separate server side endpoint will need to be created. Here is an example:

@billing.route('/billing/paypal/agreement/execute', methods=['POST'])
def execute_agreement():
    payment_token = json.get('payment_token')
    
    if paypalrestsdk.BillingAgreement.execute(payment_token):
        return jsonify({ 'status': 'success' }) // we're good to go!
        
    return jsonify({ 'error': 'failed' }) // something broke!

This endpoint does not need to return anything in particular, so long as the response code is 200. The payment_token is obtained in the JSON body POSTed to this endpoint, it is then supplied to the Paypal Python SDK and the execute function is called with that parameter. If all is well, the status: success line is returned, else an error is returned.

To integrate this on the Javascript side, another AJAX call will need to be made:

    env: 'sandbox', // Or 'production',
    commit: true, // Show a 'Pay Now' button
    client: {
        'sandbox': 'YOUR CLIENT ID HERE', // switch to 'production' if in prod
    }

    payment: function(data, actions) {
        var plan_id = '1'; // change this to be the actual paypal plan ID
        
        $.ajax({
          url: '/billing/paypal/agreement/token',
          type: 'POST',
          data: JSON.stringify({ plan_id: plan_id }),
          contentType: 'application/json',
          dataType: 'json',
          success: function(data, status, xhr) {
            agreement_id = data.agreement_id;
            resolve(data.token); // resolve the promise so onAuthorize is called
          },
          error: function(xhr, status, error) {
            console.log('checkout error', error);
            reject(error)
          },
});        
    },

    onAuthorize: function(data, actions) {
         $.ajax({
          url: '/billing/paypal/agreement/execute',
          type: 'POST',
          data: JSON.stringify(
            {
              payment_token: payment_token,
            }
          ),
          contentType: 'application/json',
          dataType: 'json',
          success: function(data) {
            // success!
          },
          error: function(xhr, status, error) {
            // failure! 
          },
    },
}, '#paypal-button');

If all is well, the success handler will be called and you can then direct the user to the appropriate page, do further requests or obtain additional information if necessary.

Conclusion

At this point you should have a very basic Paypal integration with support for recurring payments. Please note, the endpoints shown in Python are written under the assumption you have a working Flask application, to do that you will need to import additional modules not explicitly shown above. However, regardless of backend, the flow would be the same:

1. User clicks Paypal button
2. Fire request to server to get a payment token
3. User accepts agreement
4. Fire another request to server to execute it with the agreement token
5. success or error is called, redirect appropriately

I hope this has been a helpful look at creating a basic Paypal subscription integration. Please do not hesitate to let me know if you have any questions, thanks!

Introduction

One of my all time favorite topics is the brain, but more specifically, how the brain's operation results in the human condition. Recently I have been reading about the dichotomy between the conscious and unconscious mind.

The most interesting of which, I think, is a study conducted at the University of Tennesee that investigates the timing of the decision making process while observing brain activity in an fMRI machine (an imaging device that allows researchers to view brain activity in real time) [1].

Research

During the study, researchers placed subjects in an fMRI machine and prompted them to decide to press a button in their left or right hand. Simulatenously, the subject is shown a clock with a rapidly moving second hand. Subjects are asked to identify which number the hand is closest to when they make the decision to press one button or the other. Comparing the data, researchers identified a roughly 200-300ms delay between when the subject reported making the decision and when they actually pressed the button. More interestingly, though, is that the fMRI scanner showed activity in the area of the motor cortex (the part of the brain that drives our movements) 300-500ms before the subjects reported making their decision.

This effect was so prevalent, researchers found they could readily and consistently predict how the subject would react before the subject reported making a decision.

In a separate but related study at Harvard University, Alvaro Pascual-Leone went on to modify the experiment to utilize TMS (transcranial magnetic stimulation, a way to manually stimulate the brain). In the follow up experiment, subjects were asked to think about moving one hand or the other during a specific auditory cue. Following a random pause, a second distinct auditory cue signaled that they should actually move the hand they decided to move. During some tests, researchers determined the hand that the subject intended to move using real time brain imaging and, prior to the second auditory cue, delivered a shock to the subject's motor cortex that would result in the opposite hand moving. When this happened, the subjects were questioned about the change in behavior with researchers noting that the subject's brain activity suggested that they would move their other hand. Consistently the subjects seemingly made up an explanation, stating they changed their minds, or something similar. But, given the brain imaging, it is possible to discerne with reasonable accuracy that this was not the case, and rather, the conscious brain simply tried to rationalize why the decision it made (to move the left hand, for example) did not happen. Moreso, subjects reported feeling completely normal, as if making a decision to move one hand and having the other move instead was normal.

These findings seem to suggest that this is a completely normal state for the brain. That is, that the conscious mind is not the portion of the brain that actually results in decision making.

fMRI scans during these experiments showed the activation of various regions of the brain, showing that the motor cortex was stimulated 300-500ms before the subject reported making a decision, suggesting the decision was made elsewhere in the brain and that the conscious mind, seemingly, was one of the last to know.

Foreward

From here, I wanted to take some time to expand upon the findings above, but before that I would like to note I am aware the objective of the studies above was to determine brain functionality and not to attempt to support or reject the concept of free will. However, I do believe that these findings can be used for further extrapolation in the discussion of free will.

Concept

What would it mean if the findings of these studies actually meant that free will was an illusion at best? We tend to operate under the assumption that our conscious minds are making the decisions we eventually act out, but it seems that the conscious mind is just along for the ride while doing its best to make sense of our actions.

If this is true, it would imply that what we typically consider to be free will simply does not exist. How then do we ultimately formulate our relatively complex actions then? I would like to assert that the brain operates deterministically. That is, given a specific brain state and a set of stimuli, the brain will always product the same output, similar to a computer program.

Discussion

With a deterministic brain we can be expected to react the same way every time a set of criteria are met. If I were to poke your arm right now, the reaction you would have is the same reaction you would have if we replicated the poke with the exact same brain and the exact same stimuli. That said, it is worth noting that it would be neigh impossible for the physical state of the brain to be the same since brain plasticity (the tendency for the brain to physically change based on actions and memory) has been well documented [2]. But, if you took your brain as it is right now, placed it in a vat and gave it all the stimuli you are currently experiencing, along with my poke, you would likely react the same way you did originally.

To further expand upon this idea - with a brain operating in a deterministic way, every action we take is literally the only action we will ever take because, given a certain state and a certain set of stimuli we will always act the same way.

If this is the case, then regardless of how much you want to think you wouldn't do X or Y, it is ultimately the state of your brain that decides what you will actually do.

Conclusion

If we were to agree that the idea the brain operates in a deterministic way is correct, what would that mean for the idea of free will? Researchers have demonstrated it is not the conscious mind that is first made of aware of decisions, rather, it is looped in on a need to know basis and allowed to make its own narrative. Think about this the next time you take a seemingly random action - why did you do that? Take some time to ponder the reason your conscious mind provides you - does it actually make sense?

Furthermore, consider what this means in terms of law and order. When we punish a criminal for committing a crime, are we punishing the conscious mind or the unconscious mind that likely decided to take the criminal action in the first place? Is this ethical if the brain is truly deterministic, if so, the criminal was incapable of acting in any other way.

What else would be impacted if we were to determine with certainly that our brains operate in a deterministic way?

[1] https://www.nature.com/news/2008/080411/full/news.2008.751.html

[2] https://www.psychologytoday.com/blog/the-athletes-way/201702/how-do-neuroplasticity-and-neurogenesis-rewire-your-brain

I think we all realize that death is the unfortunate end we are all moving towards. It is an inevitability, a when and how, not an if. In my experience, most deal with death by way of religion. Many major religions have a concept of a heaven or heaven equivalent, with this, it is easy to find comfort knowing your loved one is in a better place. I have no gripes with this, in fact I have found myself finding comfort through similar ideas since learning of my grandmother’s passing. However, I ultimately identify as an agnostic or atheist depending on the exact context. That said, I have been spending time trying to reconcile my beliefs with my need for comfort in such a difficult time.

In doing this, I read similar anecdotes by other atheists and one in particular caught my eye and truly resonated with me.

While I highly recommend giving the original article a read, the author is posed with a question by friend whose father had passed recently. The friend asks how the author deals with death given he is an atheist. The author discusses this in the form of a letter, during it he highlights this passage by Aaron Freeman:

You want a physicist to speak at your funeral. You want the physicist to talk to your grieving family about the conservation of energy, so they will understand that your energy has not died. You want the physicist to remind your sobbing mother about the first law of thermodynamics; that no energy gets created in the universe, and none is destroyed. You want your mother to know that all your energy, every vibration, every Btu of heat, every wave of every particle that was her beloved child remains with her in this world. You want the physicist to tell your weeping father that amid energies of the cosmos, you gave as good as you got.

And at one point you'd hope that the physicist would step down from the pulpit and walk to your brokenhearted spouse there in the pew and tell him that all the photons that ever bounced off your face, all the particles whose paths were interrupted by your smile, by the touch of your hair, hundreds of trillions of particles, have raced off like children, their ways forever changed by you. And as your widow rocks in the arms of a loving family, may the physicist let her know that all the photons that bounced from you were gathered in the particle detectors that are her eyes, that those photons created within her constellations of electromagnetically charged neurons whose energy will go on forever.

And the physicist will remind the congregation of how much of all our energy is given off as heat. There may be a few fanning themselves with their programs as he says it. And he will tell them that the warmth that flowed through you in life is still here, still part of all that we are, even as we who mourn continue the heat of our own lives.

And you'll want the physicist to explain to those who loved you that they need not have faith; indeed, they should not have faith. Let them know that they can measure, that scientists have measured precisely the conservation of energy and found it accurate, verifiable and consistent across space and time. You can hope your family will examine the evidence and satisfy themselves that the science is sound and that they'll be comforted to know your energy's still around. According to the law of the conservation of energy, not a bit of you is gone; you're just less orderly. Amen.

Having never read (or heard) this quote, I was very moved by it. I found it particularly interesting that the ideas conveyed in the passage so easily mirror those that the religious among us rely on during difficult times. When it is broken down, what we truly want to know is that our loved ones mattered, that their existence changed something in the world irrevocably, and through that change they live on.

While I am ultimately not sure if there is a heaven or hell, I do know that my grandmother lived a long, passionate and fulfilling life. She had two children, my mother and my uncle, both went on to have children of their own. My grandmother’s actions have profoundly changed the world, as a nurse she cared for the sick, as a mother she brought new life into this world, and as a grandmother she helped raise the future generations of our family. Her energy and passion live on in her children, her grand-children, and eventually my children, their children and so on.

I am comforted by the fact that, while yes, my grandmother is no longer with us, that her life had meaning. This meaning is not something that will ever die, it lives on in all of us, and in a way, my grandmother lives on too.

Recently, I have spent a great deal of time pondering the nature of what we call gut feelings. Personally, many of my decisions have been primarily guided by what I would describe as a gut feeling - but what is a gut feeling really?

I recently spoke to a woman who posed an interesting idea, that our gut feelings are a mechanism by which the universe communicates with us - an invisible hand attempting to shape our fate and our destiny. There was more that went along with the idea, but the rest was cloaked in fictional ideas based around bona fide creatures that lived within us. I don’t necessarily believe in those ideas, but I do think that the core concept is still valid.

In thinking about this some more I have been reminded of the concept of our “lizard brain” as some affectionately refer to it. Commonly, “lizard brain” refers to our more primal brain, the brain stem and associated areas. This area of the brain is commonly associated with reflexive actions that require little to no processing in the higher orders of the brain. For instance, the heart beat and respiration is largely controlled in this portion of the brain.

Evolutionarily speaking, the brain developed upwards, if you will, from the brain stem, eventually culminating in the frontal cortex that is responsible for much of the logic and reasoning us humans enjoy today.

I find it most curious that there are portions of our brain, that are very much brain in the literal sense, that we are unable to consciously tap in to. For instance, we cannot reason our heart beat down to some desired level, likewise, we cannot override the idea that we are hungry, or thirsty. This has lead me down the path of reasoning that perhaps our gut feelings have something to do with these active, but not consciously accessible portions of the brain.

The lesser brain, as I will refer to it from here on out, was what our earlier ancestors used to accomplish basic tasks. The lesser brain told them when they were hungry, it helped them move around and generally, live the life we see in most other reasonably evolved animals on earth. But there had to have been some sort of complex analysis done in this portion of the brain for our ancestors and animals to accomplish what are inherently complex tasks – intercepting prey, analyzing images provided by the eyes to locate predators, and so on. These tasks likely happen autonomously given that these creatures are not conscious in the human sense. This is all well and good in creatures that only have primitive brains, but for humans there is so much more going on, especially with the frontal cortex and the higher orders of the brain.

So then, I’ve reasoned that as humans, our lesser brains still process information much like what I have described above for animals and our ancestors. While this is no revelation in and of its self (it has been scientifically proven that this is the case), I have also posited that the lesser areas of the brain help us in processing complex situations more than we may realize.

Perhaps, what we describe as a gut feeling, is the lesser brain attempting to help us with our analysis of problems that are typically beyond its wheel house. While the frontal cortex and other higher brain orders act as a sort of central processing unit, picking apart details, perhaps the lesser brain acts as a sort of crude auditor, looking over the previously analyzed facts and drawing a more basic conclusion.

Given the separation, it would make sense that the lesser brain would communicates this information in an inherently vague and sometimes confusing way, in the form of a gut feeling.

What I find most intriguing about this idea, is that often, my gut feelings are counterintuitive. I spend a great deal of time analyzing a situation when anything more than a cursory decision is to be made, arguably, too much time. What I find curious, though, is that the conclusion I come to through my analysis is often logically sound and, objectively, a sound decision while my gut feeling is often completely the opposite.

Does this mean our lesser brains are better at processing this information? No, probably not, but then again I am not a brain scientist either. My interpretation of all of this has resulted in the idea that we should carefully consider our decisions, but not too carefully. Perhaps the over analysis that I, and probably some of you, are guilty of is clouding our judgement. Perhaps the logically sound choice isn’t the best choice? As a big fan of logic (I am a programmer after all) it pains me to suggest this, if we can’t trust logic what can we trust? But all in all, I take comfort in the idea that there is likely no “right” choice. With that in mind, we shouldn’t be afraid of taking a chance – if there is no “right” choice, logically, there can be no “wrong” choice either.

It is that time of year again, time to reflect on what has happened over the past year, where I succeeded and where I failed, and more importantly set goals for the coming year.

I, like many of you, had a pretty rough year so I am quite pleased to bid adieu to 2016.

I like to start these posts by covering what I actually did this year before delving into the specifics of last year's goals and how I did there, so here it goes!

• Started a new business - Last year I started Bitkumo with my friends Lev and Mike. Things didn't work out super well there, but before Bitkumo ended Lev and I started a new business, Statusy. Statusy makes affordable status pages. I've put tons of time into this business and it has grown over the year into a profitable business.

• Lost a job - I really enjoyed my time at Virtkick, but unfortunately budgetary constraints resulted in me being laid off around the beginning of the summer. While this sucked at the time, I look at it as a blessing in disguise, giving me a chance to relax and work on personal projects for the first time since I was high school.

• Got a new job - One door closes, another opens. Not long after I departed from Virtkick I started working for Plaid Technologies, a position I have really come to love over the past few months. I feel like this position was made for me and it is allowing me to grow substantially as a developer.

• Moved - Another year, another move. After I finished my time at Virtkick my then girlfriend and I decided it would be wise to move closer to family, so we packed up our apartment and moved north to Minnesota. When we arrived it wasn't much different than San Antonio, honestly the heat was kind of worse (with humidity stacked in), but I quickly forgot about that as we moved into the winter and sub-zero temperatures. I never understand what -19 meant in terms of temperature, but I do now: pain.

• Traveled - I had the pleasure of taking a road trip from San Antonio to the Minneapolis area at the beginning of the year so my then girlfriend could attend a friend's wedding. I love road tripping and it is always a joy to see family so that was a good time. I also spent a few weeks in San Francisco, I hadn't been there previously but it was an enjoyable time, thanks Plaid!

• Ended a relationship - Easily the roughest part of the year was the end of my near nine year relationship with my girlfriend, April. Break ups always suck, but this was especially rough given the time and experiences we had together. Fortunately, many friends and family were there to help me make it through to the other side with relatively minor wounds, thanks guys!

With that out of the way, it is time to look at what I wanted to accomplish this year. In my post from 2015 I listed the following goals for 2016:

• Grow Bitkumo - This sort of happened. Bitkumo stagnated about four months after the beginning of the year, my good friend and then business partner Lev decided we shouldn't proceed. After some himming and hawing we eventually decided to sell the business to Virtkick, who continues to operate Bitkumo to this day. But hey, a successful exit is still success!

• Get my code into production - Check! Much of my code eventually went into production at Virtkick. I also have a fair number of things in production with my current employer.

• Learn RoR - A swing and a miss. I learned what I needed to know during my time at Virtkick, but after moving to a company that didn't utilize Rails I kind of lost interest. I have more than made up for this in my improved JS skills though.

• Continue growing as a developer - Definitely. I've learned a ton more about Javascript, wrote a React/Redux app and continued expanding my Python knowledge. I have also improved my code reading skills drastically. I never imagined this would be as hard as it is, but it is definitely a skill to be developed.

• Continue growing as a person - Sure. With the end of the relationship I mentioned above I took a lot of time to do some soul searching and learn a bit more about myself. Through this I've become a better Joe, I think.

Overall I am happy with my progress for the year, especially given the difficulties it has introduced. Now, on to 2017!

• Continue growing Statusy - I love working on Statusy, I have found a great partner in Wojtek, a former colleague from Virtkick. Together we have made innumerable improvements to the Statusy platform including several major redesigns, improved UI/UX and more features than I can count on my fingers and toes. I want to continue growing this business, it is fun, and I feel it fills a hole in the market.

• Continue learning about myself - It sounds kind of like BS, but hey it is what it is. Doing my own thing has allowed me to learn more about who I am, what I am, and what I want. I want to continue this adventure in 2017.

• Resume pilot training - A few years back I started developing a love of aviation. This manifested its self in the pursuit of my private pilots certificate. Unfortunately, things didn't work out financially so I ultimately stopped this pursuit, but now that I am where I am, it seems like a great time to pick this up again.

• Have fun - Another thing I have learned throughout the year is that working all the time is simply no fun. I've had several very productive years, but working all the time has started to have an impact on myself today, my previous relationship and relationships with friends and family. I don't intend to become a bum, but I do want to take it easy this year and enjoy myself a bit more.

With that, good bye 2016, hello 2017. I hope you all have a great 2017!

Another year is coming to an end, thankfully. Like most others, I have had a rather dreadful year, bidding 2016 farewell will be quite satisfying. The end of the year always makes me reflect on how things went over the course of the year. This year I have been thinking quite a bit about pivotal moments.

Looking back, there are a number of moments in my life that drastically altered where I am today. At the time, these decisions did not feel like they would be pivotal. In some cases, the outcome was disappointing, in others, indifference, and in some I fought tooth and nail to prevent that outcome.

But, despite my efforts, things ended up happening this way, this specific way and I am where I am because of each and every one of those minute decisions.

This got me thinking, what was the first pivotal decision that I made? Was it deciding not to play soccer in middle school? Picking to sit next to X or Y at lunch? At some point in my past there was a moment that created this particular path through life. I don't know what this moment was, but I wish I did.

After thinking about this extensively lately I've decided that I need to start living in the now more often, rather than the future. The decisions we make today can be the pivotal decisions we look back on in a few year's time. Taking time to live in the moment and ultimately make yourself susceptible to these pivotal moments can shape your future in a big way.

Think before you act, but not too much. Happy New Years everybody!

I mentioned in my other post about some events that fundamentally changed my view on the world. Here, I wanted to dive into one event in particular, the break in I experienced in early August this year.

Not long after I moved from Texas to Minnesota to be with my girlfriend's family I headed out to San Francisco for a couple weeks to do onboarding for a new position I had just secured. The onboarding went great, I loved (and still do) my new company and the expereince overall was exemplary. It was the last weekend I would be in San Francisco, I remember snapping awake around 8 AM. I rolled over and grabbed my phone, as I usually do in the morning, to see what had happened while I slept. I saw one message from my girlfriend "Dude, look at the camera".

I had purchased a "smart" security camera and set it up in the apartment before I left. The camera had an app that notified you of movement, or in this case, an "Unknown Face". I looked at the other notifications on my phone and my heart dropped, I saw several "Unknown Face" notifications in a row.

I quickly opened the app and started watching the videos. The first shows a man kicking down our door, walking in and looking around. The others showed two other men carrying things out of our apartment. One video showed our TV sitting in the hallway before one of the burglars swept it up into what I assume was a waiting vehicle. I looked at the live view on the camera to see the now shattered door to our apartment hanging about half open with nobody to be seen.

The feeling was devestating - sitting a thousand some odd miles away, in an Airbnb watching your apartment being robbed.

My girlfriend, who was still in Minnesota at the time, but away with family handled the event like a true champ. She managed to call the police (for the record, if you need to call the police in another area, just dial 911 and they can connect you to the police department where the crime is happening) and not long after I watched the videos I saw more "Unknown Face" notifications as the police had arrived.

After I arrived home, my girlfriend and I combed through the apartment to see what had been taken. We found our TV missing, a box of credit cards and other personal documents missing, all of my girlfriend's jewelery, an iPad and some other miscellaneous things were all nowhere to be found. This sucked, especially my girlfriend's jewelry (which included a number of sentimental pieces), but the coming days would make it clear this was not the primary loss.

We stayed with my girlfriend's family for about a week after I returned from San Francisco while we made improvements to the security of the apartment. When we were satisfied, we hesitantly moved our things back into the apartment and spent our first night there. Neither of us slept, every little creak and whisp of wind made us roll over and check our security camera for invaders. This continued, unfortunately, for months.

When I thought of what a burglary was in the past, I always thought about losing things. Things like laptops, jewelry, TV's and such, just like the things we lost. But what I never thought about is the emotional and psychological impact something like this has on you. An event like this kind of introduces fear as a regular emotion in your life. Will they come back? If they do will they hurt us? Should we move?

I am fortunate in that I have never really felt true fear, but having it forcefully added as a regular feeling in your life is very traumatic.

Despite how bad this experience was, it does have a silver lining. It has made me realize that physical security is a very real thing, and it goes beyond a lock on the door. True security should exist in layers. Introduce redundancies to ensure an invader is caught before they have the opportunity to enter your home, and if they do enter, make sure you can watch their every move.

Beyond the security implications, I also wanted to mention that should something like this happen to you, go find yourself a therapist to talk about it. My girlfriend and I did not do this, but looking back on it and our experience since I really wish we had. This is very much a traumatic experience, it isn't something you should just sweep under the carpet and move on with. Deal with it while it is fresh and you will probably suffer much less in the months after.

Every now and again you encounter a series of events that fundamentally changes the way you view the world. For me, the past few months have held a number of events that have definitely change my view substantially.

Looking back, I've realized that I placed a great deal of importance in objects. I spent time looking at cool new gadgets, tech and other gizmos that I longed for, so much so that I would buy them against my better financial judgement. I'm not sure if this is strictly a Joe thing, or a symptom of being very wrapped up in technology as a whole, but I have realized that this is not the way I should be.

As I mentioned above, a number of events have happened in my life in the past few months that have given me pause, so much so that I have taken time to evaluate my perception, my actions and myself at a fundamental level. What I previously thought were sources of happiness (gadgets, tech, and so on) I have realized were just a sort of bandaid to keep me going. The joy of getting that new NAS, or the new iPhone is fleeting. It feels incredible at first, but you quickly forget how it made you feel and look for the new gadget or gizmo to purchase.

I've realized, what is not fleeting though is the feeling you have when you are around those who love and care for you. I have never, not even once, found myself longing for a lost object (hold maybe one of signficiant sentimental value), but now, as this rough year comes to a close, I do find myself longing for those who are no longer around.

So, I suppose the point of this little entry is to pay attention to those who matter to you most, especially as we enter the holidays. It has been said a thousand times, I am sure, but sometimes you do not realize what you have until it is gone, this has held especially true for me this year. So take time, evaluate yourself and think of who matters to you and give them a hug and a kiss, while they are still there.

I have learned so much about the startup life over the past couple years. I worked with a larger startup, a smaller one, and several that I can call my own. I learned how funding works, how marketing works, how sales happen (how sales don't happen), how to avoid technical mistakes and how to make great products.

Despite all of this, I believe the most important thing I have learned over this time has to do with co-founders.

Co-Founders are those people who share your vision - they work for little or no pay, they do the grunt work early on, they transform the vision into a real product. They do this in hopes of creating something great. Co-Founders are immensely important in shaping the future of your company. Given this, you should take time in considering who should become a co-founder.

What to consider

To become better at this process I have compiled this short list of things to consider. This list is by no means exhaustive, but I think it covers most of your bases.

1. How do you work with this person?

Find out how your potential co-founder works. Things I have found of particular important include:

• How many hours will this person put in to the business?
• How fast do they work?
• How detail oriented are they?

Bringing somebody on board who works slower than you, less time than you, and sloppier than you will make you (and probably the rest of the team) pretty unhappy. Make sure you see eye to eye with your potential co-founder, make sure you are both ready to put in similar amounts of effort and you have similar ideas about the quality of your work.

2. What do they bring to the table?

Ideally, you should bring on co-founders that fill some gap in skills at your company. Given this, make sure the potential co-founder has skills that are valuable to you and your team. Already have five backend devs? It probably isn't wise to bring on a co-founder who loves writing backend code.

However, bringing on a co-founder with overlapping skills isn't necessarily a bad thing if the person brings other things to the table, but just be mindful about how other co-founders or team members may feel if you bring somebody else into the fray that may do the same thing they are doing.

3. Do you like this person?

Arguably one of the most important traits you should be looking for is relatability. This is somebody you are going to be dealing with every day for the next few years so you should pick somebody you generally like.

Do not invite somebody to join your team as a co-founder if you can't stand them - regardless of how skillful they may be.

4. Are there any warning signs?

Generally, people who are up for coveted co-founder positions are people you know somehow. They are friends or co-workers, so you probably know a fair amount about them. You should use any and all of this information to your advantage:

• Have they done something like this before? How did it end?
• How do they interact with others? Are they well liked?
• What is their previous work like? Are they known for quality?

If the answers to these questions are not positive you may want to reconsider bringing this person on as a co-founder. I have found that behaviors from the past rarely disappear completely - if the person has done something undesirable in the past, it is likely that behavior will continue in the future. Make sure you are okay with this.

The team is more important than the idea

If you are like me, you have probably read tons of stories about startups, how they failed, how they succeeded and what could be done better. One common theme I have found is that the team is more important than the idea and execution is key. That being said, you should set yourself up for success by picking the best possible co-founders early. It is easier to be critical now than it is to deal with a bad match later on.

Have any other tips about selecting good co-founders? Please let me know, I'd love to hear your suggestions.

Upon realizing there was a major gap in the hosted status page market, Lev Lazinksiy, Ricardo Feliciano and I started working on a product to fill that gap, Statusy.

We started working on Statusy in mid-January earlier this year, and I am very pleased to announce that Statusy is open to the world in an early release state.

Our mission with Statusy was twofold:

1. Make an excellent hosted status page that truly met all the needs of our potential customers
2. Make it affordable enough for even early stage startups to afford

I am please to say we have succeeded on both fronts.

Statusy offers almost all of the features of other providers including:

• Customization - Logos, CSS, domains
• Social integration - Twitter for now, but more to come
• Redundancy - All of our infrastructure is fully redundant, your status page will be there when you need it most
• Teams - No need to share one login, we offer team accounts so any member of your team can update your status page
• Extensible - We have launched with a robust RESTful API so you don't even need to log in to report things

We have managed to offer all of this for just $10.00 per month, this is nearly 66% off the price of other providers.

That being said - it would be excellent if you were to give Statusy a try.

We consider Statusy to be in an early release state so we are primarily looking for feedback. If you give Statusy a try and have any feedback please feel free to add it via the in-app feedback button in the bottom-right corner, or via email to hello@statusy.co.

Thanks for reading!

I always seem to find myself reflecting upon the year during the holidays - where I was this time last year and where I am now. This year has been pretty good to me overall. I've gone on several adventures, moved to Texas, gotten a new job, started my own company and so much more. I'm super excited that I've kept to this blog going for a whole year - I've always enjoyed writing but I seem to lack the dedication to keep a single project moving. Fortunately, that is not the case for this blog, this is especially fortunate because last year I wrote a post very similar to this one. This allows me the opportunity to compare what I've done this year with what I wanted to do last year. So here it goes!

According to last year's post, I wanted to do these things in 2015:

• Obtain RHCSA - This did not end up happening, primarily because my situation changed pretty drastically over the course of 2015 - because of this, the RHCSA was not as valuable as it was to me last year.

• Complete Master's program - This did not happen either. No good reason, just laziness.

• Learn more virtualization - This definitely happened.

• Learn Ruby - I would say this one is 50/50 - I definitely know more Ruby than last year, but I am certainly not proficient yet.

• Work on personal projects - This absolutely happened.

• Move - I'm writing this from San Antonio, TX where it is 80 degrees in December. Check!

So all in I was able to accomplish a total of 3 (and a half) goals from last year, 60% met, not too bad!

Now, on to what I've actually done this year:

• Created SpacePanel - SpacePanel is easily the best thing I've ever personally made. I don't mean best as in it was awesome for other people, but best as in I learned so much writing it. I learned about libvirt, KVM, maintaining an actual project with people who care about the project and even a bit about crowdfunding. The knowledge is definitely the best thing to come from the project, but very close runner up was a new position at a Techstars company called Virtkick.

• Became a developer at Virtkick - Looking back it is amazing that Virtkick and I ever connected. Virtkick learned of me because I made a snide remark on one of their blog posts (saying how SpacePanel rocked and people should use it instead of Virtkick). This got the attention of the founders of Virtkick who apparently admired my dedication to SpacePanel. Shortly after making that comment, Nowaker and Rush reached out to me, told me they liked SpacePanel and wanted me to come work for them in San Antonio. So that is exactly what I did.

• Left my position at DigitalOcean - After getting a job offer from Virtkick I toiled for days trying to decide what to do. On one hand, I had a great job at an amazing company, but on the other hand: adventure, experience and the chance to do something I love (writing code). I eventually decided to resign from my position at DigitalOcean and move to San Antonio to work with Virtkick.

• Moved to San Antonio - About a month after I left DigitalOcean and started working at Virtkick remotely April and I packed up all of our stuff in a big Penske truck and began the three day drive to the great state of Texas.

• Wrote some cool software - Working at Virtkick has been amazing - I wrote code, all day every day. Previously this was something I only did for fun, but the idea of doing it all the time and getting paid for it was incredible. I learned so much throughout the year and I made a super cool new backend system for the company. Said super cool new backend system is now being tested at Bitkumo.

• Traveled a bit - The Grand Canyon has always been on my bucket list. Right before we moved we were planning on flying out to Arizona to check out the Grand Canyon. Unfortunately, the move was pretty expensive so we had to cancel this trip. Fortunately, not long after getting to San Antonio we were able to visit the Grand Canyon with several friends. Getting there was an adventure - wanting to do the trip as cost effective as possible we did the 16+ hour one-way trip in a single day, spent two days checking our Arizona, and then did another super-not-fun 16+ hour day in the car. But all in, it was super worth it. You can know something is big, you can see pictures of it and see that it is big, but I find it almost impossible to comprehend how big something like the Grand Canyon is until you are standing there before it. It is, in a word, incredible.

• Started a business - Along with two of my great friends and colleagues Lev and Mike I started a new cloud hosting called Bitkumo. Bitkumo of course uses Virtkick (specifically the backend system that I wrote myself - how cool is that?). The company is still young (about a week old at the time of writing) but things are moving fast and it is awesome.

So I think the tl;dr is that it has been an awesome year. Now that the year is nearing its end, its time to look to the future. That being said, my goals for 2016 are:

• Grow Bitkumo into a strong, thriving business - I love business, I love strategy and I feel 100% in my element working with Bitkumo. I'm dedicated to making Bitkumo an awesome platform and a great company in 2016.

• Get my code into production - I've spent most of 2015 working on the aforementioned backend at Virtkick. In 2016 I want to see this code go to production. This would be the first time something I've written is actually used for anything remotely resembling production - that idea is both frightening and very exciting.

• Learn Ruby/Rails - This didn't completely happen in 2015 so I'm adding it to my goals for 2016. Ruby as a language, and Rails as a framework have a huge following. I firmly believe becoming proficient in RoR will be a good thing for my career overall, so I'm going to make it happen.

• Continue growing as a developer - The most rewarding thing for me as a developer is seeing my code in use, but a super-close second is seeing my code improve. I love looking at code I wrote a year ago, saying "Wow this is terrible!" and realizing how far I've come. This needs to continue.

• Continue growing as a person - This means traveling, spending time with my friends and family, learning, and overall learning to live a better healthier life.

I'm looking forward to another great and productive year in 2016. I hope 2015 has been great for you and I hope 2016 is even better!

Coming from Python, Node.js quickly blew my mind with the whole concept of asychronous stuff. I don't think I actually understood managing things asynchronously for a few months after I started writing Javascript (lets be honest, I probably still don't completely understand it). While the wound is still fresh, I figured I would take some time to write a basic guide for navigating callbacks and promises in Node.js.

Why

If you've come from something like Python or other popular languages threading has likely been something that was either done automatically by a module or something you've had complete control over. In Node threading doesn't really exist, you have one thread so good luck and have fun!

With >1 threads you can do several things (perhaps things that are even blocking) at the same time without impacting the application as a whole (that is, other requests can still be served). With a single thread, a blocking action will block the application as a whole - if you make a synchronous call other requests will need to wait for that task to finish. This is clearly undesirable for things like web applications. What good is an application that can only serve one request at a time? Node addresses this with callbacks, and more recently promises.

Callbacks

A callback is a function that is executed after a task is completed. It usually looks something like this:

asynchronousFunction(argument, function(response) {
	// When the function is finished doing whatever it is doing, this stuff is executed
    // The callback takes any return values as arguments, so if asynchronousFunction returned 1+1, response would be 2
    console.log("asynchronousFunction is done with the response", response);
});

You can also use a callback that is defined elsewhere like this:

asynchronousFunction(argument, callbackFunction);

function callbackFunction(response) {
	// This is executed when the function is done doing its stuff
    console.log("asynchronousFunction is done!");
}

In general, callbacks will first take an error argument and then other arguments that are returned by the function that is utilizing the callback. You can test to see if the error object exists after each call to see if the call was successful:

asynchronousFunction(argument, function(error, response) {
	if (error) { 
    	console.log("Something broke!");
        return; 
    }
    // If this is executed there was no error!
});

The problem with callbacks is they are a little messy. Consider a chain of asynchronous functions that need to run one after another:

aFunction(argument1, function(response) {
	// This runs after aFunction is done
	bFunction(argument2, function(response2) {
    	// This runs after bFunction is done
        cFunction(argument3, function(response3) {
        	// This runs after cFunction is done
        });
    });
});

Not too pretty right? It gets even uglier if you want to deal with errors properly at every step of the chain:

aFunction(argument1, function(error, response) {
	// This runs after aFunction is done
    if (error) { return error; }
	bFunction(argument2, function(error, response2) {
    	// This runs after bFunction is done
        if (error) { return error; }
        cFunction(argument3, function(error, response3) {
        	if (error) { return error; }
        	// This runs after cFunction is done
        });
    });
});

Fortunately promises help make this much neater, easier to read and easier to control.

Promises

A promise is essentially an abstraction of a callback that uses simple to understand syntax and structures. A promise is just that, a promise to give something in the future. For example, say asynchronousFunction from above makes a call to an API requesting all of the virtual machines on an account. That process isn't instant, so it returns a promise which is a placeholder for the list of all the virtual machines on an account. A promise can be either resolved or rejected. A resolved promise is one that fulfilled its promise so to speak and actually has the data you were promised. A rejected promise happens if an error is encountered.

So to rewrite the asynchronousFunction from above using promises you would do something like this:

asynchronousFunction(argument).then(function(response) {
	// Executed after function is done
});

The flow works just like it states, do this function, then do this. You can also pass around promises pretty easily:

function aFunction() {
	return asynchronousFunction(argument);
}

aFunction.then(function(response) {
	// Executed after asynchronousFunction is done
});

Error management is a breeze:

asynchronousFunction(argument).then(function(response) {
	// This is executed if the promise is resolved
}).catch(function(error) {
	// This is executed if the promise is rejected
});

Promises really shine when you have to link a bunch of stuff together. Recall how callbacks looked with multiple functions and then take a look at the syntax used by promises:

aFunction(argument).then(function(response) {
	// Executed after aFunction is done
	return bFunction(argument2);
}).then(function(response2) {
	// Executed after bFunction is done
	return cFunction(argument3);
}).then(function(response3) {
	// Executed after cFunction is done
    return "All done";
});

Much cleaner and easier to read in my opinion. Errors can also propagate up the promise chain fairly easily as long as all promises in the chain are returned properly. A single catch statement for the entire chain will catch any errors thrown while processing those promises:

aFunction(argument).then(function(response) {
	// Executed after aFunction is done
	return bFunction(argument2);
}).then(function(response2) {
	throw new Error("foobar"); 
	// Executed after bFunction is done
	return cFunction(argument3);
}).then(function(response3) {
	// Executed after cFunction is done
    return "All done";
}).catch(function(error) {
	// Caught error from bFunction and stops executing
});

Bluebird is (in my opinion) the best library to use for this sort of thing. You can do tons of really cool stuff with it, including converting things that require callbacks to promises using promisifyAll:

var libraryThatUsesCallbacks = require("callbackLibrary");
var Promise = require("bluebird");

Promise.promisifyAll(libraryThatUsesCallbacks);

// libraryThatUsesCallbacks can now be used like so

libraryThatUsesCallbacks.aFunctionAsync(argument).then(function(response) {
	// I'm a promise now! 
});

// Bluebird adds new functions that basically map to the old function name + async, so bFunction would become bFunctionAsync

This can generally be done for all functions that use the callback(error, arguments) pattern though Bluebird does support other arrangements as well. Bluebird supports a wide array of other things, I would recommend taking a look at the API documentation.

Conclusion

Given the single threaded nature of Node applications learning how to write asynchronous code, and more importantly, think asynchronously, is necessary to becoming a successful Node developer. This isn't an easy task, especially if you are not used to thinking about things in this way, it took me a long time to fully grasp the concepts and properly use asynchronous functions so don't worry if it takes a bit. Hopefully this post will help you learn the basics if you are looking to develop Node applications. Please feel free to leave any questions in the comments.

After adding a couple things to Node-Libvirt one of the maintainers pointed out my original article on Node-Libvirt referenced the old callback style of using the library so I wanted to take a moment to write up a new guide for using Node-Libvirt with promises rather than callbacks. Since my first post offers a fair amount of detail regarding Node-Libvirt in general, I'll limit this one to showing syntax only.

Hypervisor

First lets take a look at connecting to the hypervisor using promises. Of the changes, this is the most prominent (in my opinion anyway).

Connection

var libvirt = require('libvirt');
var hypervisorObject = libvirt.hypervisor;

var hypervisor = new hypervisorObject('qemu:///system');

hypervisor.connect(function() { 
    // The hypervisor object is now connected. From here you can do just about any call you want...
    // Like hypervisor.lookupDomainById(1);
});

You'll probably want to wrap the code you need to access the hypervisor with in the hypervisor.connect() function to ensure the connection has been made before you attempt to communicate with the hypervisor.

Everything Else

It isn't really worth noting each and every function I mentioned originally, but I will give you a couple examples for how things look using promises.

The basic idea is you add Async to the name of the function you want to call, and then use then instead of a callback. For example:

hypervisor.helloWorld(function(callback) {
	// Old style
});

hypervisor.helloWorldAsync(arguments).then(function(return_value) {
	// New style
});

For real example take a look at a call to getNodeInfo:

hypervisor.getNodeInfoAsync().then(function(nodeStats) {
	// nodeStats now has the return value from getNodeInfo
});

Domains

Domains use pretty much the same syntax shown above but I'll run through a few examples:

// Lets make a new domain
hypervisor.defineAsync(domainXML).then(function(domain) {
	// Use domain to access this domain now
    
    // Now lets restart that domain
    domain.startAsync().then(function() {
    	// Domain has been restarted
    });
});

// Lets lookup a domain with the id 1
hypervisor.lookupDomainByIdAsync(1).then(function(domain) {
	// Use the domain object to do other stuff
});

Would you like to know more?

From here, everything looks almost identical to the syntax you see above. Just append Async to the name of the function and use then instead of a callback and you will be good to go.

If there are any specific calls you are interested in seeing please don't hesitate to leave a comment. Most of these calls do have examples in the Node-Libvirt tests. If you are planning on using Node-Libvirt consider following me on Twitter as I intend to document the full Node-Libvirt API in the future.

Thanks for reading!