2020-09-12

So, I'm trying something new. Each week I'll try to write down three things that I enjoyed that week. Here’s the first edition for Week 37 (Sep 6-12, 2020).

The Morning Brew

I signed up for an email newsletter last week as an experiment. It’s called - The Morning Brew. They send you an email every morning covering the news on a variety of interesting topics. What I like about it is that there's no political news, no negative news. It’s very informative, and very engaging. It’s got a fun personality to it. It's really well done.

I don’t usually look forward to newsletters, or even make it a habit of reading them, but I have actually been looking forward to “The Morning Brew" every morning. I scroll through the entire email while sipping on the morning coffee - perhaps exactly how they intended it? Highly recommend signing up, and giving it a try.

Protein Shake

Tried a new protein shake recipe last week - The Creamcicle, and it came out really well. I typically do a mix of almond milk, bananas, and strawberries, along with the protein powder, but decided to switch strawberries with fresh orange juice, and it came out so delicious. I think I may have cracked an all time favorite recipe for me.

• 1 scoop Vanilla Protein Powder
• 1/2 cup unsweetened almond milk
• 1/2 cup water
• 3 ounces frozen orange juice concentrate
• 1/2 frozen banana
• 1 tsp honey
• 3-5 ice cubes

Paul Graham's Essay - How to make wealth

This is a long essay, covering a bunch of related topics, but one thing that caught my attention was the argument that “Money is not the same as Wealth". You can have wealth without having money. It’s an important distinction that we often forget. Money is a “medium of exchange”, something we use as a mechanism to trade what we have with what we need. Wealth, on the other hand is the fundamental thing.

Wealth is stuff we want: food, clothes, houses, cars, gadgets, travel to interesting places, and so on. You can have wealth without having money. If you had a magic machine that could on command make you a car or cook you dinner or do your laundry, or do anything else you wanted, you wouldn’t need money. Whereas if you were in the middle of Antarctica, where there is nothing to buy, it wouldn’t matter how much money you had.

Wealth is creating or making something that can then be either sold or even donated (think vaccines, like the penicillin). The point here is that wealth is about creating value in the world by making something that didn’t exist.

The second point I really liked is the argument -

The people most likely to grasp that wealth can be created are the ones who are good at making things, the craftsmen.

He then goes on to suggest that programmers are the ultimate craftsmen, because like craftsmen (who btw are now dwindling by the day) are the rare breed that can create something out of nothing, and create value for the company, or the community. That was pretty fascinating to me, and served as a reminder to me that as programmers, we have that power and privilege, which we must use with great responsibility, to create wealth.

2020-05-22

It took me some time. Fine, it took me a few years, but I finally got around to creating my first iOS app, using SwiftUI.

Created a simple single screen app that displays a random quote on the click of a button. A different quote each time you click that button. That’s it.

I’ve been reading James Clear’s fantastic book Atomic Habits last couple weeks, and loving it. I figured I would add some gems from the book, so each time you hit that button, you get a fresh dose of Atomic Habits.

Steps

If you’ve never created an iOS app, I leave you with the basic steps, and the code that you can copy/paste. Thanks to SwiftUI, simply pasting this code will generate the view and the functionality for you.

1. Open Xcode, and create a new project . File -> New -> Project
2. Choose Single View App -> Next
3. Give it a Name, for example - MyQuotesApp
4. Leave the Language set to the default of Swift
5. Leave the User Interface set to the default of SwiftUI
6. Uncheck the boxes for Core Data, Unit Tests, and UI Tests
7. Select the file ContentView.swift in the project navigator on the left.
8. Paste the code below inside this file.
9. cmd+s to save the file
10. cmd+r to run the code
11. That should open the simulator and display the app

Source Code

// Inside  ContentView.swift

import SwiftUI

struct ContentView: View {
    //define the variable quoteText as @State, so we can track any changes to it, and update our display accordingly
    @State var quoteText = "Quote goes here"

    var body: some View {
        VStack {
            Text(quoteText) //Text object to hold the quote
                .font(.largeTitle)
                .multilineTextAlignment(.center)
                .padding(.vertical, 100.0)

            Button(action: {
                //generate random number
                let index = Int.random(in: 0..<quotes.count)

                //pull a quote from the array using a random index number
                let quote = "\(quotes[index])"

                //update the state for the varaible quoteText
                self.quoteText = quote

                print(quote) //prints to the console
            }) {
                Text("Give me a quote")
            }
        }
    }
}
struct ContentView_Previews: PreviewProvider {
    static var previews: some View {
        ContentView()
    }
}

let quotes = [
"You do not rise to the level of your goals. You fall to the level of your systems.",
"You should be far more concerned with your current trajectory than with your current results.",
"Goals are good for setting a direction, but systems are best for making progress.",
"Problem #1: Winners and losers have the same goals.",
"Habits are the compound interest of self-improvement",
"If you want better results, then forget about setting goals. Focus on your system instead.",
"Professionals stick to the schedule; amateurs let life get in the way.",
"When you can’t win by being better, you can win by being different.",
"Every action you take is a vote for the type of person you wish to become.",
"Success is the product of daily habits—not once-in-a-lifetime transformations."
]

Next, I want to get that data dynamically by calling an API. That's for another post.

2020-05-14

Been meaning to write this post for my future self, who’s invariably going to forget the steps to set up Django on a new machine. So, here are the steps to set up Django on a Mac.

Django what? Django is a fully featured Python web framework that can be used to build complex web applications.

Installing Python 3

The first thing obviously is to make sure you have Python installed. Python 3 is the latest, so we will go with that by using Homebrew (if you don't have that installed, follow the instructions here)

$ brew install python3

Note that since macOS ships with Python 2 already installed, after you install Python 3, you will now have both versions available.

To run Python 2, use the python command in the Terminal. For Python 3, use python3 instead.

We can test the installation by typing in the Terminal:

python3 —version
Python 3.7.7

I ran into an issue where I simply could not get python3 to run. Executing both python and python3 would just run Python 2.7. Turned out, it was a symlink error, and running the following command, AND removing any redundant python PATH from the ~/.bash_profile fixed it.

brew link —overwrite python3

See [python 1="Mac" 2="Python3" 3="Not" 4="Working," 5="any" 6="idea?" 7="-" 8="Stack" 9="Overflow" language="-"]/python, and “python” points to Python 2.7 under macOS Homebrew - Super User

Setting up Python Virtual Environment

Now that we have Python 3 installed, we are ready to setup Virtualenv.

Installing Virtualenv

We will use pip, a command line tool that lets you manage and install Python packages, to install virtualenv.

Note that when you used Homebrew to install Python 3, it also installed pip for you under the name pip3. So pip3 is already available for you.

In the Terminal, execute the command below:

$ sudo pip3 install virtualenv

Create a new virtual environment

Create a new virtual environment with the following command:

$ virtualenv <environment_name> -p python3

Our virtual environment is created. Now before we start using it, we need to activate:

Activating a virtual environment

$ source venv/bin/activate

You will know it worked if you see (venv) in front of the command line, like this:

Installing Django

We are now ready to install Django.

$ pip install Django==3.0.5

Verifying Django Install

To verify that Django can be seen by Python, type python from your shell. Then at the Python prompt, try to import Django:

$ python
>>> import django
>>> print(django.get_version())
3.0.5

Starting a New Project

To start a new Django project, run the command below:

$ django-admin startproject mysite

The command-line utility django-admin is automatically installed with Django.

This will create a mysite directory in your current directory.

Running the web server

Django comes with a simple web server installed. It’s very convenient during the development, so we don’t have to install anything else to run the project locally. We can test it by executing the command:

$ python manage.py runserver

You may receive some migration errors. For now, you can ignore the migration errors.

Serve the website

Now open the following URL in a Web browser: http://127.0.0.1:8000 and you should see the following page:

Congratulations on your first Django-powered page!

Hit Control + C to stop the development server.

Sources

1. A Complete Beginner’s Guide to Django - Part 1
2. Get Started With Django Part 1: Build a Portfolio App – Real Python
3. Writing your first Django app, part 1 | Django documentation | Django

2020-05-11

As a developer, I spend a large amount of my time writing code everyday. The rest, of course is spent debugging that code and “Googling” the internet for answers. But, I digress. All to say, that I am always looking for ways to speed up the development workflows when it comes to “getting started” with something, and then making it easy to “run”, and “deploy” the code.

One area I spend a significant amount of time every week is creating new Alexa Skills from scratch from a learning and education point of view. This is where I’ve found the ASK CLI to be super helpful in speeding up the workflow to create and update Alexa Skills, using the Alexa Skill Kit CLI tool.

What is Alexa Skills Kit CLI?

The Alexa Skills Kit Command Line Interface(ASK CLI) provides a quick way to perform a lot of Alexa skills tasks from the command line interface, like creating new skills, and deploying the code to Alexa Hosted or AWS. You can even simulate your skill from the command line.

Using Templates with ASK CLI to jump start development of a new Alexa Skill

One feature that I like the most about ASK CLI is that it allows you to create a new skill by using your own custom skill templates. So, if you’re like me, you can create a starter template for all your Alexa Skill projects. For example, if there are certain helper functions you use in every skill, it would make sense to include those in the template, so they’re available in the new skill right off the bat.

Creating a new skill using a custom template

To create a new skill using a custom template, you provide the Git URL of the template with the flag --template-url:

The command to create a new skill using a custom template varies a bit based on the version of the ASK CLI. To check the version of ASK CLI, simply type ask -v or ask -V in the terminal.

If you’re using ASK CLI v2
If you’re using ASK CLI v2, you can create a new skill using a custom template using the command below -

$ ask new --template-url https://example.com/example/example-skill.git --template-branch master

Example:
Here’s a CLI v2 compatible I use to jump start my Python based Alexa Skills -
https://github.com/ajot/python-alexa-skill-starter-template-cli-v2.git. If you like, you can use this to create a new skill by using the command below.

$ ask new --template-url https://github.com/ajot/python-alexa-skill-starter-template-cli-v2.git --template-branch master

You may get a warning, like the one below. Type "y" to continue.

"[Warn]: CLI is about to download the skill template from unofficial template. Please make sure you understand the source code to best protect yourself from malicious usage."

This will create the skill locally on your machine. You’re now ready to deploy the skill. See “Deploy” section below.

If you’re using ASK CLI v1
If you’re using ASK CLI v1, you can create a new skill using a custom template using the command below -

$ ask new --template-url https://example.com/example/example-skill.git

Example:
Here’s a CLI v1 compatible template I use to jump start my Python based Alexa Skills -
https://github.com/ajot/python-skill-basic-template.git. If you like, you can use this to create a new skill by using the command below, and optionally, providing a skill name.

$ ask new --template-url https://github.com/ajot/python-skill-basic-template.git -n <optional-name-for-your-skill> -n <optional-skill-name>

You may get a warning, like the one below. Type "yes"

“Downloading skill template from unofficial resource. Please make sure you understand what each script is doing to best protect yourself from malicious usage".

This will create the skill locally on your machine.

Deploying the code to Alexa Developer Console, and AWS Lambda

At this point, we need to locally install any other modules your skill may need. In the case of the Python template I mentioned above, it needs ask-sdk-core package to be installed.

As is generally a good practice, we first need to create/activate a virtual environment. There are several options available for managing virtual environments for Python. I personally use virtualenv, but you can tailor the steps below to match your virtual environment of choice (like Conda).

Create a new virtual environment
Create a new virtual environment with the following command:

$ virtualenv skill_env -p python3

Our virtual environment is created. Now before we start using it, we need to activate:

Activating a virtual environment

$ source skill_env/bin/activate

You will know it worked if you see (skill_env) in front of the command line, like this:
[Image: Screen Shot 2020-05-07 at 8.01.34 PM.png]Install any modules your skill may need
This specific template, for example needs the ask-sdk-core module. So let’s install that inside the virtual environment we created using the Python's pip command -

$ pip install ask-sdk-core

We are now ready to deploy our skill to the developer console, and AWS lambda -

$ ask deploy

Verify and test the skill deployment

1. Verify the skill deployment on the Alexa Developer Console

2. Verify the code deployment on AWS Lambda Console

3. Test the skill in the Alexa Developer Console

You can now test your skill using the "Test" tab inside the Alexa Developer Console at https://developer.amazon.com/alexa/console/ask/test

More Resources for ASK CLI:

ASK CLI Command Reference
Alexa Skills Kit Command Line Interface (ASK CLI) Overview
Quick Start: Alexa Skills Kit Command Line Interface (ASK CLI)

2020-04-17

As a developer, every day we interact with remote APIs and web servers. Almost all services we consume on the internet today are available in the form of an API: weather forecasts, geolocation services, Twitter feeds, and so on.

It’s only fair to imagine, that you may run into situations in which you would want an Alexa Skill to get meaningful data from one of these remote sources by making HTTP requests to their APIs. HTTP requests allow you to fetch data from a remote source. It could be an API, a website, or something else.

In this post, we will take a quick look how you can get external data from an external API from an Alexa Skill using Python 3.

While there are many libraries to make an HTTP request in Python, including http.client (formerly named httplib ), urllib , httplib2 , treq , etc., the Requests library is among the most popular Python libraries for making HTTP requests. The subtitle of “HTTP for Humans” perfectly captures the philosophy behind it. It abstracts the complexities of making requests behind a simple interface, and makes HTTP requests easy and simple.

If you’re using Alexa Hosted as the backend for your skills, there’s an added advantage of the Requests library being built-in, so you don’t need to install or upload it manually. If you’re using AWS Lambda or any other service as the backend, you may need to install the requests module locally, and then upload it to the service.

So, with that out of the way, let’s jump into how you can use the Requests library to make an HTTP request to an API. For the purposes of this tutorial, we will be using the Chuck Norris API. You can obviously replace that with other APIs of your choice.

Using Requests library to make an API call from an Alexa Skill

Step 1: Import the requests package by adding an import statement to the top of lambda_function.py:

import requests

Step 2: Create a helper function to make the call to the API using the endpoint

def getResponseFromAPI():
    url = 'https://api.chucknorris.io/jokes/random'
    response = requests.get(url)
    print(response.status_code) 

    json_data = response.json()
    joke = json_data['value']
    return joke

Here’s a sample of what the data that would get returned by the Chuck Norris API, and would be stored in the variable

Step 3: Call the helper function from inside the LaunchRequestHandler (or any other intent handler that may be appropriate).

class LaunchRequestHandler(AbstractRequestHandler):
    """Handler for Skill Launch."""

    def can_handle(self, handler_input):
        # type: (HandlerInput) -> bool

        return ask_utils.is_request_type("LaunchRequest")(handler_input) or ask_utils.is_intent_name("AMAZON.YesIntent")(handler_input)

    def handle(self, handler_input):
        # type: (HandlerInput) -> Response
        logging.info("LaunchRequest was trigerred")

        joke = getResponseFromAPI()
        return (
            handler_input.response_builder
            .speak(f"{joke}. Would you like to hear another Chuck Norris joke?")
            .ask("Would you like to hear another joke?")
            .response
        )

Hopefully that makes it easy to make API requests from your Alexa Skills. If you're looking to learn more about building Alexa Skills, I’ll leave you with some resources if you’re looking to learn more about Alexa Skills, and the Python requests library in general.

1. Create an Alexa Skill in Five Minutes - Python & Node - Step-by-step training course from the Amazon team to build your first Alexa Skill
2. Alexa Skills Kit SDK for Python
3. Alexa Skills Kit SDK for Node.js

2019-11-06

If you’re into building skills, you’re probably familiar with Alexa Skills Kit’s Command Line Interface, which lets you create and manage your skill using the CLI, like updating the interaction model, and the backend code. You can of course manage these directly through the Alexa Developer Console, and AWS respectively, but CLI is a much faster workflow.

There are two ways to create a new Alexa skill using the ASK-CLI. You can use AWS Lambda as your backend, or if you are new and would like to keep things simple initially, you can use Alexa Hosted.

With an Alexa-hosted skill, your code is available inside a code editor in the Alexa developer console itself, so you can edit and deploy changes to your code quickly, without needing to set up an AWS account.

Let’s look at how you can use the ASK-CLI to create a new skill using each of these two backend options.

Option 1: Using AWS Lambda as the backend

Prerequisites

1. An Amazon developer account. Sign up is free.
2. Set up an AWS IAM user
3. Install and initialize ASK CLI

You can find more information about the prerequisites on the Amazon Developer Documentation here.

Step 1: Create a new skill using the ASK-CLI with AWS Lambda as backend

1. Assuming you already have the ask-cli setup (see prerequisites) , open up the terminal, and type the following -

$ ask new 

This will provide the following prompts -

2. Select the runtime - Node.js V8 or Python3
3. Choose hello world as the template to get started with
4. Type in your skill name - ice-cream-soda (or a name you prefer)
   

This will create the skill locally on your machine.

Step 2: Deploying the skill (Interaction Model and AWS Lambda)

Type the following into the command line -

$ cd ice-cream-soda
$ ask deploy

This may take a few minutes, and if everything goes well, you will get a confirmation that Your skill is now deployed and enabled in the development stage. Try simulate your Alexa skill skill using "ask dialog" command. You can verify by logging into the Alexa developer console at developer.amazon.com/alexa/console/ask. Your backend code has been deployed as an AWS Lambda function using the AWS IAM user you set up in #2 of the prerequisites, which you can verify by logging into your AWS Console at console.aws.amazon.com/lambda.

Step 3: Pushing the skill code to GitHub for collaboration

1. Create a new repo on GitHub.com, say ice-cream-soda. If curl is your thing, you can also type this on the command line -

$ curl -u 'YOUR_GITHUB_USER_NAME' https://api.github.com/user/repos -d '{"name":"YOUR_NEW_REPO_NAME"}'

When you use ask new to create a new skill using one of the templates (say hello world), the git remote for the skill directory that's created for you points to https://github.com/alexa/skill-sample-nodejs-hello-world.git. If you’d like to push your skill code on GitHub, you need to remove the .git directory, which removes the remote. Let’s do that now.

2. Remove the .git directory (hidden by default) to reset the remote origin, which is by default set to https://github.com/alexa/skill-sample-nodejs-hello-world.git(https://github.com/alexa/skill-sample-nodejs-hello-world.git).
   

$ rm -r .git

You may get a warning asking if you’d like to override removal of .pack and .idx files. Typeyes to confirm.

You can now deploy your skill code to a GitHub repo with no problems, without breaking the ask deploy process to deploy the skill to AWS Lambda/Developer Console.

3. Initialize Git

$ git init

4. Add a remoteto point to the new GitHub repo
   

$ git remote add origin git@github.com:YOUR_GITHUB_USERNAME/YOUR_GITHUB_REPO_NAME.git

// example: 
// git remote add origin git@github.com:ajot/ice-cream-soda.git

5. Push to GitHub
   

$ git add . 
$ git commit -m "first commit"
$ git push -u origin master

Option 2: Using Alexa Hosted as the backend

You can also use the Alexa Skills Kit CLI to create a skill using Alexa Hosted as the backend, instead of AWS Lambda using the create-hosted-skill(https://developer.amazon.com/docs/smapi/ask-cli-command-reference.html#create-hosted-skill-command) command. Support is available for Node.js only for Alexa Hosted through the CLI.

Step 1: Create a new skill using the ASK-CLI with AWS Lambda as backend

1. Open up the terminal, and type the following -

$ ask create-hosted-skill

2. Type in your skill name: kiwi-cream-soda
3. Select the runtime - Node.js V8 or Python3
4. Alexa hosted skill is created. Do you want to clone the skill project to current working directory? (Y/n)
5. Type yes
   

Your skill has now been automatically deployed on the Alexa Developer Console using Alexa Hosted. For future deployments, just use ask deploy from within the skill directory.

Step 2: Pushing the repo to GitHub

When you use ask create-hosted-skill to create a new skill, the git remote is set to an AWS Code Commit service https://git-codecommit.us-east-1.amazonaws.com. We need to add another remote, so we can push to both GitHub without breaking the AWS Code Commit service. We will do this in step by adding a new remote (Step 2 below), and then updating the Push URLs for the remotes (Step 3 below)

1. Create a new repo on GitHub.com, say kiwi-cream-soda. If curl is your thing, you can also type on the command line -

$ curl -u 'YOUR_GITHUB_USER_NAME' https://api.github.com/user/repos -d '{"name":"YOUR_NEW_REPO_NAME"}'

2. Type the following into the terminal -
   

$ cd kiwi-cream-soda
$ nano .git/config

Make a note of the Push URL. We will need this in the next step. This will be something like -https://git-codecommit.us-east-1.amazonaws.com/.....

CTRL + X to exit the nano editor.

3. Add a new remote
   

$ git remote add github git@github.com:YOUR_GITHUB_USERNAME/YOUR_GITHUB_REPO_NAME.git

// example:
// git remote add github git@github.com:ajot/kiwi-cream-soda.git

3. Configure the Push URLs - for GitHub, and the original push URL for deploying the skill code to Alexa Hosted.
   

Set remote URL for GitHub

$ git remote set-url --add --push origin git@github.com:YOUR_GITHUB_USERNAME/YOUR_GITHUB_REPO_NAME

//example: 
// git remote set-url --add --push origin git@github.com:ajot/kiwi-cream-soda.git

Set remote URL for AWS Commit Service to enable the ask deploy workflow.

$ git remote set-url --add --push origin YOUR_PUSH_URL_FROM_GIT_CONFIG_FILE_FROM_STEP_2

//example:
// git remote set-url --add --push origin https://git-codecommit.us-east-1.amazonaws.com/v1/repos/xxxxx-xxxxx-xxxxx

4. Verify the Push URL’s have been updated for the remote origin

[remote "origin"]
        url = https://git-codecommit.us-east-1.amazonaws.com/v1/repos/xxxxx-xxxxx-xxxxx
        fetch = +refs/heads/*:refs/remotes/origin/*
        pushurl = git@github.com:<YOUR_USER_NAME>/kiwi-cream-soda.git
        pushurl = https://git-codecommit.us-east-1.amazonaws.com/v1/repos/xxxxx-xxxxx-xxxxx

CTRL + X to exit the nano editor.

6. Deploy to Alexa Hosted, and push to GitHub
   

$ git add .
$ git commit -m "first commit"
$ ask deploy

This will deploy the skill to Alexa Hosted, and also push to GitHub.

Updating the ASK-CLI

$ npm install -g ask-cli
$ ask -v 

2014-02-12

Been using Fantastical on Mac for a while now for creating calendar appointments. While I've been using it to good effect to create calendar appointments, I wanted to see if I could use it as effectively for creating reminders as well. The idea is to get in and out of the verbose Fantastical UI as quickly as possible. Using the mouse to switch between the calendar/reminder mode was a downer for me in that respect.

Turns out Fantastical has a solution to this already. Just add /r to switch to reminder or /w for work, /h for home calendar etc. Pretty nifty. Way faster than the mouse.

2013-12-22

It's been almost 4 years now, since I quit my job at ESG. I remember I had written the email draft I was to send my manager a good 3 weeks before I gave in my notice - Jan 4 2010.

If I think about it, what I am and able to do today, I owe it wholly to that decision I made back in 2009. It was a scary decision. I had set myself on a journey to build something. We (Kunal and I) built Rootein. It didn't work out the way we would have wanted it to, but it was an amazing experience. All we really wanted to do was build and launch something. Perhaps that's where we went wrong. We had no idea what we wanted the future to be with Rootein. We were just too excited to launch it and let people play around with it.

If I hadn't left ESG back then, I would've never visited New York as often as I did. I wouldnt have fallen in love with the city. I would've never made the decision to move here. I would've never been to Startup Weekend in DC in 2010. I would've never met John Britton. I wouldn't have been at Mashery. I would've never had the privelege to rub shoulders with my mentors Delyn, Neil back in 2011. I would've never had the professional grooming had I not been a Developer Evangelist. I wouldn't have met so many amazing people I;ve had the privilege to meet. I wouldn've have been the same person.

I really owe it to that guy back in 2009. Thank you Amit, Circa 2009.

2012-07-09

This post was originally written by me back in 2010 and posted on Rootein's blog. Sadly, the blog had to be brought down, thanks to some ambitious Russian hackers and poor house keeping on my part!

I had then recently quit my job to create Rootein along with @duak. I remember I was scared, unsure of the future. I hated what I was doing then and quitting the job just felt right at the time. Looking back, was it the right decision? Absolutely. In fact, I regard that as the single best decision I've ever made.

We were just about getting ready to warm up for the practice game over the weekend when I had an interesting conversation with one of the team mates I actually didn't know quite well.

"So what do you do?" he asked. "Well, we work for ourselves, we run a software company", I replied. "Oh really! that's awesome! I work for xyz company, but you know I always wanted to get into animation design and work for myself. It was my dream. I got stuck in the wrong industry"

"You ain't dead yet, are you?" I thought, trying hard not say that aloud. He continued, "You know, I've been wanting to do this for 10 years now, but once you have a family, it's very tough to do anything else"

I couldn't resist anymore, so I said "That's great. If you really want to do that, may be you should take up some animation classes, or do some self learning at your own pace. That would be a good start." Pat came the reply "Nahh it's very difficult, with family, full time job, no time. I would love to, but I can't."

Reluctantly, I suggested - "Then may be you should consider training full time for a few weeks/months and perhaps dive in full-time?" He looked at me like I had just asked him to cut off his right hand - "Are you crazy? Where will the paycheck come from?"

Realizing this conversation was heading towards an argument with someone I didn't know very well at the first place, I chose to just smile and leave it at that. But it made me think. What is it with people refusing to take some risks to follow their dreams. Are their dreams not worth it? If not, why do we sulk about them later? Don't we owe it to ourselves to at least give our dreams a fair shot?

Now, I understand, diving in full time isn't always an option for everybody, but that shouldn't deter us from at least starting to move in the right direction. Take baby steps I say if you can't afford drastic measures, but for God's sake don't kill your dreams.

We all had some crazy ideas and dreams when we were kids. When people asked - "What do you want to do when you grow up?" you didn't say "I want to play safe and be an executive for a fortune 100 company" or "I want to work for the government for the job security"? You wanted to do something that excited you, that you were passionate about - "Armed forces, scientist, sports, music, dance, miss world" etc. You didn't even think if that would get you enough money. You just wanted to do it.

So why is it that as we grow up we lose all the passion, the energy, the will, and the strength to keep our dreams alive. Why does money dictate our passion or in most cases, kill it? Why do we let "safety of a paycheck" screw our dreams? Why do we stop thinking about what we love?

We are so seduced by the thought of a guaranteed paycheck every month that we completely ignore the fact that it's actually never too late to pursue our dreams. The reason, as I can understand is probably "fear of failure". We fear we might fail and that fear leads us to cook up stories about why we can't have what we want. Alibis like "I don't have time. I have family. I'll do it when I have more money etc." Stories that convince us that it's ok not to follow up on our dreams, that it's ok not to do what we love, that it's ok to just keep doing the everyday drill.

Like Tony Robbins put it - "The only thing that's keeping you from getting what you want is the story you keep telling yourself about why you can't have it."

What are we waiting for? A perfect day when all stars would line up in just the right direction and you would be guaranteed success? It never works that way. That moment of glory never arrives. All circumstances will almost never be in your favor. There will always be something that would be challenging. You just have to bite the bullet and take the plunge. When we set out to create Rootein, we didn't wait for everything to be just perfect, much as we would have liked. We just dived in. We started developing rootein while we were working full-time. We loved what we were doing and we did it while keeping our day time jobs. It wasn't easy, but it was fun because we were chasing our dream of working for ourselves, building software that we were passionate about.

May be it's just us. May be we are weird. May be we are foolish, but we would rather be foolish and strive to live our dream than come up with some alibis. True success is not money driven, it's driven by love and passion. You've got to love what you are doing and you've got to be passionate about it.

Failing is not scary. What's scary is that you are 60 and reflecting back on your life "May be I should've given my dreams a chance, may be I would've succeeded, may be I would've lived my dream" But now it's too late. You might have missed the boat.

Don't be scared to follow your dreams. That's the worst thing you can do to yourself.

Rocky sing!

"So many times, it happens too fast
You change your passion for glory
Don't lose your grip on the dreams of the past
You must fight just to keep them alive"

Update: As it turned out, quitting my job was one of the biggest turning points in my life. It's rightly said that we learn more from our failures than our successes, and boy, was driving Rootein a humbling yet insightful experience.

So, am I following my dream? I have since moved on to be a Developer Evangelist at Mashery. I absolutely love what I do. I love the people I work with. I don't hate Mondays. I don't wait for Fridays to happen. I meet and work with some incredibly bright and passionate people everyday. If that's not a dream, I don't know what is.

2012-06-07

Last week, I was given an opportunity to give a talk at NYC Developer Evangelists Meetup and I chose to talk about what it is like being a Developer Evangelist, basing it off the lessons I’ve managed to learn in the last 9 months being a Developer Evangelist at Mashery . The talk was fairly well received and I thought I’d go ahead and document it, so it can be available to more evangelists and hopefully kick off some discussion/feedback around it. Intend to keep this an updating piece with tips/suggestions from fellow Developer Evangelists. [Slide deck here ]

Lot of these tips & lessons learned hover around interacting with people. I thought they were relevant, given the amount of interaction we as Developer Evangelists do everyday dealing with developers.

Goal of a Developer Evangelist

A Developer Evangelist is relatively such a new role that the goals/role differ widely between companies. Following are some goals however that I feel are/should be universal across all evangelists.

1. Excite developers - Our top goal as a Developer Evangelist is simple - get people excited. We are not here to teach people to code. Our role is to simply excite the heck out of them. Excite them enough, so they go play with the APIs/frameworks and then ask us questions. Incite their creative cells. Perhaps even sit and brainstorm with them about their ideas. This is probably the reason why hackers make the best Developer Evangelists - cause they tinker with stuff all the time and can pass on that infectious energy along. Show them the lego pieces you’ve built yourself using the API/Framework you’re evangelizing. Nothing beats that.
2. Make life easier for developers - One of the other goals of a Developer Evangelist, I feel, is to make things easier for developers. That includes making sure the documentation is succinct, to the point and up to date. Developers have very little patience when it comes to reading documentation. They want spend more time building stuff, not reading stuff. Read less. Do more should be the mantra. Tools like I/O Docs , for instance help a lot in that regard.
3. Creating a community - should be one of the top goals of a Developer Evangelist. Always be building a community that evangelizes on your behalf. Let’s admit it. We’d love to be everywhere, but we can’t. In fact being everywhere should not be a goal in the first place. Your community should be doing that for you out of love. There’s nothing better than that. If your product is awesome, this job is a little easier already.
4. Earnestly reflect the true face of the company - Being Developer Evangelist is a really fun gig. The fact of life is that you gotta love what you do to be able to do well. That holds especially true for a Developer Evangelist. I am convinced, you cannot be a successful evangelist if you do not truly believe in the product you’re evangelizing. All awesome evangelists do. That’s why we travel on weekends and enjoy it. That’s why we don’t wait for Fridays to happen. That’s why we don’t cringe about Mondays. That’s how we enjoy every minute of what we do. But, with great power comes great responsibility. We are the face of the company and we owe it to our peers to reflect them in good stead.
   • Know your company - People expect us to know everything about our company and the industries we are in. It’s our responsibility to know as much as we can about the company and the API we represent. Right from things like when was the company incepted to the background of your CEO to limitations of your product.
   • Admit mistakes when you are wrong - Admit where your API falls short. Have total honesty and visible integrity. Particularly the ability to admit when the competition is better, or when your technology has flaws.
   • Don’t argue for the heck of it. Don’t be insulting. This might sound like a pretty obvious thing, but I saw this evangelist couple weeks ago argue to death with some developers over their API implementation. At some point you gotta stop and think - what am I doing here? Developer feedback, both positive and negative, is a gift. Accept it graciously.
   • Be good. Be genuine - Don’t be a douche bag. Be genuinely helpful and good to people - even your competitors. There’s no reason to be rude or obnoxious to anyone, just because they happen to be your competitors.
   • Encourage them. Motivate them. Drop the ego. Drop the power words. Get to the level of the developer you’re speaking with and motivate them.
   • Talk less. Listen more. - Do not interrupt people. Ask questions without interrupting and don‚Äôt just pretend that you are listening whilst you are daydreaming. Again, be genuine and true.

Achieving the goals

1. Being there for the developers when they need you
   • Be Pro-active on Twitter - Engage in conversations and answer developer queries.
   • Set Google alerts - So you know what/when people are talking about your product and then act on them as needed.
   • Answer questions on Quora/Stack Overflow etc
2. Participating in Events - Goes without saying that participating and/ore representing at events is one of the top ways to spread the love among developers. It gives you a chance to connect with the developers at ground zero. Excite them and gather feedback. Think Hackathons, Barcamps, conferences etc. If you’re not doing at least a couple every month, you’re probably doing it wrong. This is where the real fun and evangelism takes place.
3. Creating Useful Content - Write blog posts recapping the events you represent at on a regular basis and other related content around your product. Think event recap blog posts, code samples, wrapper libraries, talks/presentations etc.
4. Make on boarding easier - Falls under the goal of making life easier for developers. On boarding is a critical part in the cycle of getting developers’ attention and making sure they have a pleasant overall experience. Also includes providing awesome documentation. Again, use Read Less. Do More as a guideline.

Some Lessons Learned

1. Engage with people - That’s why we are there. Don’t be self-involved. Interest people by talking about the subject they are interested in and not so much about what you would prefer. Remember, it’s not about you. It’s about them - the developers.
2. Take notes at Hackathons - you’ll need it when you do a recap blog post. Trust me!
3. Connecting with people - Don’t follow everyone you meet at events on Twitter. I used to do that and it quickly hijacked my timeline. Use LinkedIn or Twitter lists instead for that. Who you follow on Twitter is sacred. Keep it clean to get maximum value out of it.
4. Stick around. Have fun. I’ve seen many evangelists present their APIs and then leave. That’s so stupid and mind boggling. The real evangelism happens after that demo you just gave. You need to stick around for the entire hackathon for instance. Be available when developers begin dabbling and have questions for you.
5. Take pictures at events - Pictures make great blog posts!
6. *Get there early. Meet new people.**

Fuck, please don’t do these

1. Don’t humble brag. They don’t care - People don’t give a shit about how well your company is doing. Don’t show them slides after slides of what your product is capable of doing. Show them. Tell a story. Show code.
2. Don’t be a Brand promoter or a brand manager or a social media consultant. So don’t pretend to be one. Just be yourself. Be personable. Be responsive. Try not to get all “official” lingo get in your way. Interact and answer questions as you’d if you were talking to a really close friend. “Dude” is better than “Sir”.
3. Don’t be a salesman - We all hate being sold. You cannot influence people by telling them what you want. Show them how your product can help them solve their pain and you’ll never have to sell. What’s more - they’ll even do the evangelism for you.
4. Don’t fuck up people’s names - Remember the names of the people you meet. A person’s name is the most important sound to them in the world. Get it wrong and you’re not going to be liked very much.

Devangelist Power Tips

FACT: Developer Evangelists have a high burn rate. Most of us travel on weekends to hackathons and conferences. While we don’t consider that work, we do need time to recuperate and recharge our batteries.

1. Take time off: Take regular time outs. This means you stay completely away from email/phone. Easier said than done I know. My boss once told me to “treat my PTO with as much diligence, conviction and execution as I treated my work. All highly functional people need downtime to be highly effective at work. Otherwise you burn out and are no good to anyone.” I have since been trying to make that my mantra. Not perfect yet. Getting there.
2. Get enough sleep: Given the travel and sometimes weird schedules we keep, it’s important to get enough sleep. I’ve lately started using SleepCycle app on the iPhone. It’s based on the fact that we go through sleep cycles every 30-40 mins from deep to shallow sleep. It aims to wake you up when you are on your shallowest sleeps, so you wake up more fresh. Bonus Tip: Keep the alarm away from you, so you’re forced to get up to even snooze it. Better still, keep it in your bathroom! More chances of you splashing water on your face, since you’re already there!
3. Keep Checklists: Every multi-step recurring task should have a checklist. Travel kit, writing blog posts being some examples.
4. Be lazy: As a Developer Evangelist, our goal should be to be as lazy as possible. Lazy is good. Laziness encourages us to find easier ways to do things. Laziness leads to creativity and innovation. Note that being lazy is not the same as being lousy.
   • Despise typing repetitive stuff: Create Keyboard shortcuts for repetitive tasks. I use TextExpander for example to automate all my repetitive keystrokes.
   • 1 Password - If you’re not using 1Password, you’re doing it wrong. It balances laziness with security perfectly. It allows you to autofill your username/passwords with just a keystroke. Oh, did I mention - you still get to use unique and secure passwords.
   • Alfred - is my new found love. While I’ve been using Alfred for a while now as a replacement to Spotlight, I was recently introduced to the power of it’s extensions. You can write your own scripts or download one to automate pretty much every task that you find yourself doing often. Must have.

Getting more done

A direct derivative of being lazy is getting more done with as little effort and as much focus as possible. Always be looking for ways to get more done with as little effort as possible. Here are some tips around that -

1. Decide your Most Important Tasks everyday: We’ve got a million things to do every day, but chances are there are 1 or 2 that are top priority. Knowing your MITs helps keep you focussed. Write it down and place it somewhere you will see it. These MITs are then the first thing you’d do. No matter what. So, at the end of the day, you’ll have the satisfaction of completing at the very least the things that mattered the most, rather than being busy all day and yet not having a satisfying day.
2. Focus on one task at a time: Use the Pomodoro Technique for instance to get the most out of your time. It’s amazing how the things that I thought would take me at least 2 hours have been done in 1 Pomodoro (25 minutes). Here’s how it works:
   1. Choose a task to be accomplished
   2. Set the Pomodoro to 25 minutes (the Pomodoro is the timer)
   3. Work on the task until the Pomodoro rings, then put a check on your sheet of paper
   4. Take a short break (5 minutes is OK)
   5. Every 4 Pomodoros take a longer break
3. Stay focussed: Close all distractions and focus on the task at hand. Close your Email/Twitter client/IM App. I use Concentrate app on the Mac to accomplish this. It allows you to quit any distracting or unnecessary apps/websites and stop them from launching while a “concentration” is in progress, thereby covering those weak moments when you feel the urge to check Twitter/Facebook or launch an IM conversation.
4. Turn off email notifications: Do not live inside your email. Don’t spend your day just responding to emails. Turn off email and check them every 30 mins or so. Respond to the urgent ones and get back concentrating again.
5. Powering Email: I use Mail.app + MailAct-On + MailTags to keep myself organized and top of email.
   1. MailTags allows you to add tags keywords, project, priority, notes to your messages, so they are easily searchable.
   2. MailAct-On - allows you to move or copy messages to any folders with just a keystroke. Also integrates seamlessly into Mail’s rule editor. Very useful.
6. Get a task list manager: Don’t keep the todos in your head. Worse still, don’t keep them in your email. Get them all in a task list manager of your choice. I have a slight bias towards Things.app . I value good UI. It’s important for me to continue using a product. I have to like the UI. Omnifocus is another great task list manager that follow the GTD principles to the core.
7. Defer reading: Use services like Instapaper / Pocket to defer reading. Concentrate on the tasks at hand. Read these deferred articles on the subway, in the flight, waiting in lines etc.

Devangelist Travel kit

Every Developer Evangelist worth his salt carries a hardcore Devangelist travel kit at an arms reach. I am always prepared for the worst tech fail that can happen while I am on travel.

1. Battery pack - Mofi or similar
2. MiFi Hotspot device
3. Stickers & similar pocket schwag
4. Chargers & display adapters
5. Kindle
6. Take that banner
7. Business Cards
8. Protein bars

Helpful material (books, blogs etc)

Here are some books I’ve found helpful -

1. Developer Evangelist Handbook by Mozilla Developer Evangelist, Chris Heilmann, . Probably the only book I’ve seen on Developer Evangelism. It’s a really good read.
2. How to win friends and influence people by Dale Carnegie back in 1930’s. If there was one book I had to recommend, given the amount of interaction we do with people, this would be it. Must read. Brilliant piece of work.
3. Getting Things Done by David Allen
4. 18 Minutes: Find Your Focus by Peter Bregman
5. ReWork by Jason Fried & David Heinemeier Hansson
6. Getting Real - 37signals

Questions

Like many evangelists that I bump into on a regular basis, I absolutely love what I do. This piece obviously is not the be-all, end-all of developer evangelism, but hopefully it’ll kick-off some conversation around the subject and get us all talking about what it takes to be a rockstar Developer Evangelist. So, please keep the comments/feedback coming and feel free to reach me on Twitter at @amit. Also, if you’re an evangelist based out of NYC, please consider joining the NYC Developer Evangelists Meetup . It’s pretty awesome!