The official example template of creating a blog with Bootstrap.
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).
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.
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.
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.
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.
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.
cmd
+s
to save the filecmd
+r
to run the 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.
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.
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
andpython3
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
Now that we have Python 3 installed, we are ready to setup 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 with the following command:
$ virtualenv <environment_name> -p python3
Our virtual environment is created. Now before we start using it, we need to activate:
$ source venv/bin/activate
You will know it worked if you see (venv) in front of the command line, like this:
We are now ready to install Django.
$ pip install Django==3.0.5
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
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.
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.
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
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.
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.
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.
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.
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
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
ASK CLI Command Reference
Alexa Skills Kit Command Line Interface (ASK CLI) Overview
Quick Start: Alexa Skills Kit Command Line Interface (ASK CLI)
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.
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.
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.
You can find more information about the prerequisites on the Amazon Developer Documentation here.
$ ask new
This will provide the following prompts -
Node.js V8
or Python3
hello world
as the template to get started with
ice-cream-soda
(or a name you prefer)This will create the skill locally on your machine.
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.
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.
.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.
$ git init
$ 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
$ git add .
$ git commit -m "first commit"
$ git push -u origin master
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.
$ ask create-hosted-skill
kiwi-cream-soda
Node.js V8
or Python3
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.
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)
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"}'
$ 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.
$ 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
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
[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.
$ git add .
$ git commit -m "first commit"
$ ask deploy
This will deploy the skill to Alexa Hosted, and also push to GitHub.
$ npm install -g ask-cli
$ ask -v
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.
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.
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.
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.
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.
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.
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 -
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.
Here are some books I’ve found helpful -
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!