Forem: Joseph Jude

What’s your take on the coming decade?

Joseph Jude — Wed, 06 Jan 2021 04:21:43 +0000

The last two decades have been about convenience. Developers converted every activity into algorithms and then into apps, improving our lives in tangible ways.

Now that convenience is covered, most would upgrade to the next level in the hierarchy of wants. I suspect that level is “experience.”

Joseph Pine and James Gilmore wrote of the emerging experience economy in a HBR article. They published a book later on the same topic.

Joseph & James predicted that “the next competitive battleground lies in staging experiences” We witness the competition playing out in some areas already.

I wrote my take on this here: https://jjude.in/expdevto

What is your take?

I coded for a year. Here are ten lessons

Joseph Jude — Fri, 16 Aug 2019 12:29:56 +0000

Read the full article at my site

I coded daily for a year. I skipped when we went on holidays and Sundays. Even when I skipped, I got back to the streak as quickly as possible.

Here are ten lessons I learned in this year of coding.

I am privileged
Make it a morning routine
Build something you need
Default choices make you productive
Keep a swipe file (backlog)
Separate thinking and doing
Dope vs. Discipline
Everything takes more time than planned
Can't do without the internet
Obsess over fundamentals; not techniques and tools

Mastering sales as a CTO

Joseph Jude — Sat, 07 Apr 2018 02:02:07 +0000

Read the full article at my site

Two years back, I became a CTO of an offshore IT services company. Part of the job is to get on sales calls to build trust in the minds of prospects to do business with us.

When I started attending sales calls, I thought I could just say we are a well established IT services company and prospects will just sign-up for our services. How naive!

Now I prepare relentlessly. Preparation builds confidence and confidence wins trust. I prepare by asking questions. Here are some questions that help me prepare for sales calls.

What are we selling?
How are we different?
What are the objections?
Have we practiced together?
Who is the prospect?
Do we have examples?
What can go wrong?

Once I'm prepared, I am ready for the calls. I take a note and a pen with me for calls. As the call proceeds, I take notes. I listen for signals. I scribble anything that will help me during the course of the call.

After every call, I write notes about the call. I note down what went well as well as what went wrong.

The more we prepare, play, and retrospect together, we get better together.

When we strive together, we thrive together. And then we become lucky. Because one-half of life is luck; the other half is preparation.

I have seen the future of jobs and it is Hollywood model

Joseph Jude — Thu, 25 Jan 2018 12:07:27 +0000

This is summary of the post I posted at my blog.

A.R. Rahman and Danny Boyle came together first for the popular movie Slumdog Millionaire. The movie won eight Academy Awards and seven BAFTA awards. Since then they have worked together many times.

As players in Hollywood, Rahman and Danny Boyle don't work for each other. In fact, they don't work for anyone. "They are jobless," says Antonio Paraiso in his Porto Business School lecture discussing the Hollywood model of working. As he explains in his lecture, they have a career, not jobs. They don't work for a company, they work on interesting projects.

In the traditional IT business, companies hire employees for long-term. They may undergo training or work on client projects or stay on "bench" or retrained or asked to leave. It is common to see employees working in the same company for decades. As long as they work in a company, employees work only on projects within the company that employs them.

Hollywood flips this model.

No studio employs director or musician or editor on a long-term basis. As Antonio says, those in Hollywood don't have jobs; they work on projects. Studios identify a project and bring together a suitable team for that project. The team works together as long as needed to complete the project—whether it is six months or three years. Members may come and go as needed. Some members may work exclusively on a project; some may work on many projects simultaneously. They work together to create value for themselves and others. Some get paid; some take a share in profit. When that project is completed, they move on. They may or may not work together again.

Governments embrace Hollywood Model for their premier projects

The government of India (GoI) adopted this model for UIDAI project, the largest biometric ID system. Once GoI identified the project, it appointed Nandan Nilekani to head project implementation.

GoI also brought-in Amit Ranjan, co-founder of Slideshare on the same model.

Taavi Kotka was the managing director of the largest software development company in the Baltic region. The government of Estonia appointed him as CIO to architect the popular e-residency program of Estonia.

Time for companies to embrace this model is now

Technology is penetrating into every domain. Newer technologies like blockchain and newer regulations like GDPR are emerging at a pace never seen before. Such changes disrupt but open enormous opportunities. It is not possible for any company to develop necessary talents in-house to exploit these opportunities. Only way companies can thrive is to embrace this Hollywood style of project-based value creation.

What it means for developers

Until now, if you graduated from an engineering college you could get into a software company. Once you got into a company, if you worked hard you had a good chance of growing up in that company.

Not any more.

Dorie Clark is an author of two books on this subject — "Reinventing You" and "Stand Out". She identified three foundational techniques to stand out in a noisy world. She writes in her HBR article:

These are social proof, which gives people a reason to listen to you; content creation, which allows them to evaluate the quality of your ideas; and your network, which allows your ideas to spread.

Your network plays an important role if you want to work in Hollywood model. Who-knows-whom is an important aspect in this model. Still you need to create a portfolio and put it out in public. This in-turn will enlarge your network, as new people will come in contact with your work.

Under the guise of scientific management, holistic expertise degraded into narrow specialization. As the world becomes collaborative, we all should develop inter-disciplinary skills. Specifically, we should become "T" shaped experts — with deep expertise in few areas and basic understanding of other associated areas.

As Robert Heinlein said:

"A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."

Peter Merel reframed it for developers like this:

A programmer should be able to fix a bug, market an application, maintain a legacy, lead a team, design an architecture, hack a kernel, schedule a project, craft a class, route a network, give a reference, take orders, give orders, use configuration management, prototype, apply patterns, innovate, write documentation, support users, create a cool web-site, email efficiently, resign smoothly. Specialization is for recruiters.

Gospel for some, tragedy for others

Hollywood model won't be a good news for all. History will repeat. Those who can adapt will succeed. Others might pop up in a song.

The winner takes it all
The loser has to fall
It's simple and it's plain
Why should I complain

Read the full post at my blog

What is a multi-tenant system?

Joseph Jude — Fri, 17 Nov 2017 13:18:22 +0000

This post was first posted on my blog

It is no coincidence that designers of software systems are called architects. Software architects have borrowed quite a lot of concepts from civil engineering. Multi-tenancy is one such concept borrowed from civil engineering. Much like in civil engineering, software multi-tenancy optimizes resource utilization, but offers flexibility of customization.

Let us understand the concept from civil engineering first.

I was born in an independent house. Small house, yet independent. We styled it whatever way we wanted it. We partitioned the house into two and had a cow shed on one side and a living space on the other. We didn't have to seek permission from our neighbors to do that. We had the freedom to do whatever we wanted within our plot of land. That freedom had a cost. If we had any issue with any utilities (say water) we had to handle it ourselves.

When I went to college, I lived in a hostel. Each of us had an independent room. We could bring our own furniture. Some of us brought bare minimum to get through four years, while few rich kids brought luxurious furniture. The college took care of the maintenance and repairs. While we were allowed to bring our own furniture, we couldn't modify the rooms, not even the color of the walls. The rooms did not represent us.

After few years in job, I bought a flat. Each of the 200 owners have the same layout but each of us have filled our homes with our own style of furniture. Some of them have customized even further. They have a sound-proof room for audio recording! Like in our hostels, the maintenance and repair is by a common agency.

Now let us understand the concept from software engineering perspective.

Let us talk with examples from software industry.

Say that I want to host my own email and document server. After much search I choose owncloud¹. I install it on my own server. I create one account for myself and I use it. This is a single-user, single-tenant system. I'm the user as well as the tenant. I can make whatever modification I want on the system.

Want to host it on a separate domain? Check.
What to change the colors in the system? Check.
What to pick and choose modules? Check.

As I get used to this system, I want to share the calendar with my wife and family. I create individual accounts for each of them. Now the system becomes multi-user, but it is still single-tenant. Each user can customize few features, like calendar name, but they can't pick and choose a functionality. If my sister wants to sync this calendar with her gmail calendar, she can't. Why? Because if I enable it, it will be enabled for all and I don't want to confuse my father with a new option. There is no option to enable it only for one user or set of users.

Now my colleagues Martin and Bob are impressed with how I manage my family schedule and they want to do the same. I could install owncloud in their own server. They will get the freedom to customize the way they want. But they don't want the headache of managing their servers and monitoring them. So they ask me to manage for them. They also tell me, they don't want to share their data with anyone else. They ask me if I could set up independent data storage for them. It doesn't stop. Martin wants only calendar facility and want to access the system via schedules.martinfamily.com. Bob on the other hand, wants to access the system from familyroom.bob.com. As indicated by the url, he wants to store family documents in addition to using calendar. He wants AWS S3 to be his data store. I can setup all of these because Owncloud supports multi-tenancy. They are pleased with the setup and invite all their family members to use the system. They decide to pay me for my service. I charge them according to the usage instead of a flat rate. (I wish I could end the story like the fairy tales: I lived happily ever after in Hawaii :-) ). This setup is now a multi-user, multi-tenant system.

As you can understand, not all web applications have to be multi-user system and not all multi-user web-applications have to be multi-tenant system. All solutions are contextual. An architect has to select the right approach for a given set of requirement.

Architecting a multi-tenant system is more complicated than architecting a multi-user system. There are two models of architecting a multi-tenant system: instance replication and data-segregation.

In instance replication model, the system spins a new instance for every tenant. This is easier to start, but hard to scale. It becomes a nightmare when 100s of tenants signup.

In data-segregation model, the application is shared between tenants but data of each tenant is stored in separate data stores. Separate data stores could be separate databases or separate schema within the same database.

To support such data-segregation, there has to be an additional management layer in the system architecture to provision a separate data-store every time a tenant signs up. Multi-tenancy includes customized UI for each tenant, selective subscription of services, and metered billing. This management layer is responsible for all of these functions.

By now it should be obvious that multi-tenant systems are not appropriate for every web-application. A multi-user architecture is sufficient enough for a B2C (business-to-customer) web-application. A multi-tenant architecture should be considered for a B2B (business-to-business) application.

Even though a multi-tenant architecture is a complex one, data privacy regulations like GDPR will force most B2B SAAS applications to become a multi-tenant system. If you are building a new B2B SAAS application, you better start with a multi-tenancy architecture.

I have no connection with owncloud. This is only an example. ↩

Descriptive analytics in Javascript

Joseph Jude — Sun, 17 Sep 2017 15:59:04 +0000

This was published in my blog

Descriptive analytics is usually the first step in data analytics exercise. As the name suggests, it describes a dataset. It answers the question, "what happened".

Any data set can be described with:

summary factors like mean and mode;
spread factors like standard deviation;
shape or pattern factors like standard distribution.

Let us talk with an example. Let us say that following are the unit sales figures for two sales managers for the last 6 weeks:

43,41,42,46,41,41
32,34,68,62,28,30

What do these numbers tell? In total, they both sold 254 items, which means they both are equally competitive. Their average is 42.3, which again says they both are equal in caliber.

The standard deviation paints a different picture. The standard deviation measures concentration of data around the mean. The standard deviation for the first manager is 1.8, while the second one is 16.2. What does this mean? The first manager is consistent week after week in meeting his target, but the second manager is not. If all else remain the same, then this data indicates that the first sales manager is more dependable than the second one.

Now let us look at calculating these descriptive analytics for any dataset, using Javascript. The web is replete with Python tutorials, not much of Javascript. If developers are already using Node.js to develop web-application or they use Javascript for designing front-end development, they shouldn't have to use another language only for computing statistics.

We will use two packages for this purpose. The first one, csvtojson, is to read csv records and convert them into json values. The second one, simple-statistics, is to compute statistics. Refer the documentation for all the features of this package. In this post, we are using only the essential functions.

Simple Statistics takes an array of values and computes statistics. Computing sum, mean, and standard deviation for the above two sales values goes like this.

$ node
> const stats = require('simple-statistics');
> const first=[43,41,42,46,41,41];
> const second=[32,34,68,62,28,30];
> stats.sum(first)
254
> stats.sum(second)
254
> stats.mean(first)
42.333333333333336
> stats.mean(second)
42.333333333333336
> stats.standardDeviation(first)
1.7950549357115015
> stats.standardDeviation(second)
16.224124698183942

Too often when we learn a subject, we get neatly arranged examples. It is like going to the zoo. But the real-world is complex.

Recently, I analyzed sales figures for a large e-commerce company. There were about 150000 records. I couldn't glance through the numbers to make sense. I loaded all the data and analyzed through simple statistics package. It showed me how different real-world sales figures compared to the neatly arranged values we get while learning.

Here is the code I wrote to load the data and describe the data:

const csv = require('csvtojson');
const stats = require('simple-statistics');

let salesData = [];
let totalRows = 0;

const data = csv()
  .fromFile('sales.csv')
  .on('json', (jsonObj, rowIndex) => {
    totalRows = rowIndex;
    salesData.push(parseFloat(jsonObj['Sales'].replace(',', '')));
  })
  .on('done', () => {
    descriptiveStats();
    process.exit(1);
  });

function descriptiveStats() {
  console.log('descriptiveStats of ' + totalRows + ' rows');
  console.log('Min: ', stats.min(salesData));
  console.log('Max: ', stats.max(salesData));
  console.log('Mean : ', stats.mean(salesData));
  console.log('Median: ', stats.median(salesData));
  console.log('Mode: ', stats.mode(salesData));
  console.log('standardDeviation: ', stats.standardDeviation(salesData));
}

The results are:

Min:  -33116.58
Max:  70049.89
Mean:  316.117162163024
Median:  159.53
Mode:  0.01
standardDeviation:  777.6360644532846

The sales engine is completely messy for them. Each of the descriptive statistics element says only one thing: there is no consistency in their sales.

A good book to understand descriptive statistics and in general numbers, is from "The Economist", aptly titled Numbers Guide. If you want to understand standard deviation, read Understanding Standard Deviation.

I will continue to write about machine learning and data analytics using Javascript. If that interests you, please subscribe from my blog.

Guidelines for picking tech-stack for startups

Joseph Jude — Mon, 31 Jul 2017 02:16:22 +0000

One of the best anecdote on consulting comes from Professor Clayton Christensen. Andy Grove, Intel chief, asked the professor what his theory of disruption means for Intel. Instead of giving a direct answer, the professor taught Andy Grove, "how to think" about the problem. I have followed this method for decision making. Instead of seeking answers, I seek "how to think" about a particular problem. Such method has helped me make decision in varying situations. In the similar vein, let me give three guidelines to design tech-stacks for startups.

Pick the right tool for the job

When a fly invaded his meeting, President Obama rolled up a magazine and whacked the fly. He didn't ask for a gun or call up his army generals, or punch-in nuclear codes. He picked a near-by magazine, rolled it, and whacked it himself.

I'm often asked if .Net is better or Python is better or node.js is better for building a startup product. If there is a technology co-founder, my advise is always to start with the stack that they know. Later as the product grows, add what is needed, or move to a more suitable stack. Marco Arment coded backend for his popular overcast podcast player in PHP because that is what he knew. Later when it grew he switched to Golang. Likewise, Twitter was originally written in Ruby and then switched to Scala.

As it should be clear now, the right stack changes as the startup goes through its growth stages.

Build for iteration and feedback

Startup is all about validating ideas quickly. So choose a tech-stack that gives you this advantage. Validating ideas quickly is not only about tech-stack. It is also about company's devops process. It is also about having probes in the application to give you operational insights. This combination of tech-stack, devops, and application analytics help validating ideas quickly.

Most technology teams in startups don't invest in devops and application analytics. Lack of devops and analytics limits their agility and speed, more than the tech-stack.

Decide well or fast

Every business executive has to take ton of decisions. Lack of data complicates the decision making. I use a rule-of-thumb to help me decide. I ask myself, is this something money can solve at a later time? There are few problems that money can't solve.

Company culture is one problem that more money can't solve. In fact, money amplifies what is already there. So if a company starts with a sexist, dishonest, authoritarian culture, more money later won't turn the culture around later. Uber is an example.

However, lot of problems can be solved by bringing more money. Logo, website design, and tech-stack are some of the problems that money can solve. As I said earlier, Twitter switched from Ruby to Scala. Dropbox is experimenting with Golang. Facebook invested in writing its own compiler for PHP.

If more money can solve a problem, choose to iterate fast. You shouldn't wait on more data. Decide by your gut feel and most probably it will work out ok. If not, bring in more money to solve that problem.

If more money won't solve a problem, think deep. If needed, get outside help. Talk to people who have already solved the problem. These decisions will have lasting impact on the company. Getting them wrong will be a disaster for the founders and the company.

You can read the full article on my blog

Getting started with React.js and Typescript

Joseph Jude — Thu, 22 Jun 2017 16:31:21 +0000

I posted this originally in my blog

React.js is a Javascript UI library by Facebook. In this guide, we will wire it up with Typescript to display a "Hello World" on the browser page.

Want to learn basics of Typescript? Read my guide

I'm assuming you have already installed node.js. In this post, I use yarn package manager from Facebook. But everything will work with npm, the default package manager for node.js.

It is a commonly accepted practice to have all the Typescript sources under a directory named src and compile final output in a directory named build. So let us create those directories.

Go to terminal and issue mkdir src build.

Let us initiate a new node.js project. yarn init -y comamnd will create a new node.js project with default values. We need to add few modules for our program. Let us add them. Issuse the following commands one by one.

yarn add react react-dom
yarn add -D typescript webpack ts-loader @types/react @types/react-dom

The -D in the second command indicates that the modules should be installed as development dependencies, which means they won't be installed in production.

Let us understand the modules we have installed:

react and react-dom are the core react modules. Without them, our program won't work;
typescript is the superset of Javascript;
webpack is a module bundler, which means it efficiently combines multiple Javascript files to create single Javascript file. This improves performance of the application.
Webpack knows to combine Javascript files. But we are using Typescript. That's why we need ts-loader.
@types/react and @types/react-dom contain type definitions for the react and react-dom modules.

By now, your package.json should look like this:

{
  "name": "01-react-tsc",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "author": "Joseph Jude",
  "scripts": {},
  "devDependencies": {
    "@types/react": "^15.0.30",
    "@types/react-dom": "^15.5.0",
    "ts-loader": "^2.1.0",
    "typescript": "^2.3.4",
    "webpack": "^3.0.0"
  },
  "dependencies": {
    "react": "^15.6.1",
    "react-dom": "^15.6.1"
  }
}

We want to invoke webpack without prefixing with its path (./node_modules/webpack). Let us install it globally so that we can invoking it directly. Issue yarn global add webpack.

We need a config file to use webpack. Let us add the config file, named webpack.config.js. The config file is self-documented with comments.

var path = require("path");

var config = {
  /*
   * index.tsx represents the entry point to your web application. Webpack will
   * recursively go through every "require" statement in index.tsx and
   * efficiently build out the application's dependency tree.
   */
  entry: ["./src/index.tsx"],

  /*
   * The combination of path and filename tells Webpack what name to give to
   * the final bundled JavaScript file and where to store this file.
   */
  output: {
    path: path.resolve(__dirname, "build"),
    filename: "bundle.js"
  },

  /*
   * resolve lets Webpack now in advance what file extensions you plan on
   * "require"ing into the web application, and allows you to drop them
   * in your code.
   */
  resolve: {
    extensions: [".ts", ".tsx", ".js", ".json"]
  },

  module: {
    /*
     * Each loader needs an associated Regex test that goes through each
     * of the files you've included (or in this case, all files but the
     * ones in the excluded directories) and finds all files that pass
     * the test. Then it will apply the loader to that file.
     */
    loaders: [
      {
        test: /\.tsx?$/,
        loader: "ts-loader",
        exclude: /node_modules/
      }
    ]
  },
  // When importing a module whose path matches one of the following, just
  // assume a corresponding global variable exists and use that instead.
  // This is important because it allows us to avoid bundling all of our
  // dependencies, which allows browsers to cache those libraries between builds.
  externals: {
    "react": "React",
    "react-dom": "ReactDOM"
  },
};

module.exports = config;

We need to add tsconfig.json file for Typescript. Copy paste the following code. If you have chosen to use different directory names, change these directory names in the outDir and include section.

{
  "compilerOptions": {
    "outDir": "./build/",
    "sourceMap": true,
    "noImplicitAny": true,
    "module": "commonjs",
    "target": "es5",
    "jsx": "react"
  },
  "include": [
    "./src/**/*"
  ]
}

Only one more step before we get into programming react.js library. We need to add a build step in the script section of package.json.

"scripts": {
  "build": "webpack"
},

Now we can run yarn run build and it will invoke webpack, which in turn will compile Tyepscript files and combine them into a single file.

Now that we have all the setup done, let us move on to create our application files.

Create an index.html in root directory with the following content. Here we are using the cdn version of react files. The bundle.js will be created by the webpack in the subsequent steps. Not the empty div tag with main as the id. This will be used by the react library to display the message -- for now, it is going to be Hello World.

<!DOCTYPE html>
<html>

<head>
  <meta charset="utf-8">
  <title>Getting started with ReactJS and Typescript</title>
</head>

<body>
  <div id="main"></div>

  <!-- we pick from cdn so can be cached by browsers -->
  <script src="https://unpkg.com/react@15/dist/react.min.js"></script>
  <script src="https://unpkg.com/react-dom@15/dist/react-dom.min.js"></script>

  <!-- compiled file for this project -->
  <script src="build/bundle.js"></script>
</body>

</html>

Let us create our logic file. Create index.tsx file in src directory.

import * as React from "react";
import * as ReactDOM from "react-dom";

ReactDOM.render(
    <h1>Hello World</h1>,
    document.getElementById("main")
);

Here we are importing the main modules of react. ReactDom.render has two parameters -- what to display and where to display. We are going to display Hello World as a title within h1 tags. We are going to display it in the empty div that we created.

By now your directory structure should like like this:

.
â”œâ”€â”€ build
â”œâ”€â”€ index.html
â”œâ”€â”€ package.json
â”œâ”€â”€ src
â”‚Â Â  â””â”€â”€ index.tsx
â”œâ”€â”€ tsconfig.json
â”œâ”€â”€ webpack.config.js
â””â”€â”€ yarn.lock

Time to execute. Issue yarn run build at the terminal. Now webpack will compile the application file and create bundle.js. If you open index.html in the browser, you will see Hello World as a header.

You can download the entire code from the repository. Then run yarn install (or npm install) to install all the dependencies. Then execute with yarn run build (or npm run build).

Four Cs of dev.to (What I like and what I suggest)

Joseph Jude — Thu, 25 May 2017 07:30:27 +0000

I have come to enjoy dev.to. As I mentioned in a Hackernews comment, dev.to has become one of the site, I visit daily.

While taking my morning walk, I thought about what I get out of Dev.to and what I would like to see in dev.to. Keep in mind that I don’t know the future roadmap of Dev.to and I’m not in any position to influence the future direction. This is an opinion of a happy and a regular reader.

Content: Dev.to is full of user generated content. Almost all of the content is useful in your day to day work, meaning they are all "how-to" articles. My Pocket reading list is full of articles from dev.to.

Community: Because of high quality content, dev.to has built a valuable developer community around it. There are architects, product managers, and beginners. There are developers who use all programming languages. This diversity brings with it, its own depth. I love to interact with the community and learn from them. So far, I've not read a "RTFM" type of a condescending comment, which is prevalent in developer community.

Content and community around it are the two factors I have enjoyed with dev.to. I hope they keep these tight as they scale. It is a challenge, but I hope Ben and team are able to meet the challenge.

As I said in a previous para, I was thinking about how else the portal can be useful (not necessarily monetized, but useful). These are the two aspects that came to my mind.

Collaboration: As the community grows, why should it limit itself to passive consumption and few answers to question? Why can't the community collaborate for each other's benefit?

"Hey, I'm stuck in debugging this java code. Can anyone help?"
"I'm self-publishing a book on d3.js. Would anyone review if the content is technically correct?"
"Can we have a digital hackathon?"

And so on.

The collaborative work itself can happen outside dev.to. But it can enable searching for people. Taking the second question in the above list, dev.to can enable searching for people who have worked in d3.js and shown willingness to collaborate.

Commerce: Most developers are altruists (at-least the ones who come to dev.to. Today there is no money to be made there; why would they come there, otherwise?), but we have bills to pay. When we collaborate, we like to get paid. Again, the deals can happen outside of the portal; but the portal can have all the essential elements to support commerce.

Coming to think of it, there could be a marketplace within dev.to. Every market place wants a community built around it, because people buy from people they know and trust, aka community. If so, why can't dev.to go from community and to commerce? It can also partner with other marketplaces like Ionic marketplace and Evanto market.

Today dev.to is simple and there is certain attractiveness in simplicity. I hope these changes won't break that simplicity.

Originally posted in my blog.

What we can learn from Jack Ma and Derek Sivers about building our career

Joseph Jude — Tue, 09 May 2017 16:25:17 +0000

Now-a-days I'm either the oldest or one of the older member in any meetup. So juniors walk up to me all the time and ask for career advice. In this video, I answer one such question.

Watch the video or read the transcript below

There was one question that occupied my mind in the early part of my career. That question was: Should I specialize in a single technology or learn as many business functions as I could learn? After all, my friends were choosing to build their career on SAP or Oracle Forms, or Java.

I’m going to be honest with you. I didn’t find the answer easily. I found it through lot of experimentation.

In the last few years, I’ve listened to popular entrepreneurs answering this question. I was pleasantly surprised that their advice confirms what I found through trail and error.

First is Jack Ma, the owner of Alibaba. He says in this video in the early part of your career, learn as many things as you possibly can. Then as you age, focus on your strengths and build on them.

Let me read out to you what another successful entrepreneur has to say on this. He is Derek Sivers. I came to know about Derek through his TED talks. He is the founder of CD Baby. He sold it for 22 million dollars and donated all the money to charity.

In his podcast interview with Tim Ferriss, he talked about how he started his career. He didn’t have any lofty goals back then. He just wanted to be a professional musician and he started as one playing in a pig show. He said this about starting a career:

When you’re earlier in your career I think the best strategy is you just say yes to everything, every piddly little gig, you just never know what are the lottery tickets.

What I have found working, and what these two entrepreneurs say is this: Learn as much as possible in the early part of your career. If you get a chance to work in marketing department, do it. If your company asks you to develop a server application, develop it. If you come across an opportunity to sell, sell. Do this for about 10 years. By doing this, you would learn quite a lot about most of the business functions. You will also know what you like the most and what comes easily to you.

Once you find what you like and what you comes naturally to you, dive deep into it. Become master of those skills. That way you will have a rich life. When I say rich, I don’t necessarily mean money, but satisfying life.

For me, I found out that I love technology and teaching. That is exactly what I am doing through this blog and my new vlog.

Good luck finding what you like and what comes naturally to you.

Posted originally in my blog.

Any leads to get started with remote jobs?

Joseph Jude — Sun, 19 Feb 2017 17:02:00 +0000

How to get started with remote jobs (full time or part time)? How did you get started with remote jobs?

How to dockerize a hapijs application

Joseph Jude — Thu, 26 Jan 2017 15:59:35 +0000

Docker has drastically enhanced how we develop and deploy web applications. With docker, we can isolate our development environment and resemble the production environment as close as possible. When our development environment resembles the production environment, we deploy with confidence.

We can even go a step further. With automated tests, and few other tools, we can automate the deployment. That brings ease and confidence — for us, for our teams, and for our clients. In software development, ease and confidence is value.

In this tutorial, I'm going to show you how to dockerize an existing hapijs application.

Hapijs is a nodejs framework from Walmart. They use it to power their e-commerce system. If you require an introduction to hapijs, you can read my introductory post about hapijs.

First, we are going to create a simple hapijs application. To do that let us create the package.json file.

{
  "name": "sample-hapijs-inside-docker",
  "version": "1.0.0",
  "description": "Hapijs app in docker container",
  "main": "index.js",
  "scripts": {
      "start": "node src/server.js",
      "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "Joseph Jude",
  "license": "ISC",
  "dependencies": {
    "hapi": "14.0.0"
  }
}

This is a common package.json file. I want you to notice just two lines here.

We are using a start script: node src/server.js. It will become clear as we go along. Just keep this in mind.

Also, notice that we are using hapijs version 14.

Now let us create the server.js file.

const Hapi = require('hapi');

const server = new Hapi.Server();
server.connection({ port: 8080 });

server.route({
    method: 'GET',
    path: '/',
    handler: function (request, reply) {
        reply('Hello, docker!');
    }
});

server.start((err) => {

    if (err)
        throw err;

    console.log('Server running at:', server.info.uri);
});

Nothing special here. We instantiate a Hapi server at port 8080 and print Hello docker when the server comes up.

We can pull an existing nodejs docker container and build our application on top of it. Or, we can build a container from scratch. We are going to build it from scratch.

We are going to use alpine as the base OS for our container. Why alpine? Alpine is both small and secure.

We are going to create a text file named Dockerfile in the same directory where we created the above two files. Dockerfile contains the instructions to build the container.

So our directory structure looks like this:

├── Dockerfile
├── package.json
└── server.js

Let us build the Dockerfile step by step. It looks like this to start with:

FROM alpine:3.4
RUN apk update && apk upgrade
RUN apk add nodejs
RUN rm -rf /var/cache/apk/*

What does these lines mean?

Line 1: We are basing our container from alpine

Line 2: Update the OS

Line 3: Add nodejs

Line 4: remove apk cache

If we build a container with these lines, we will get a nodejs container. We want a hapijs one. So let us go on.

Remember, we already created a package.json and server.js files. Let us copy them into the container. Append these lines to Dockerfile.

COPY . /src
RUN cd /src; npm install
EXPOSE 8080
CMD ["node", "/src/server.js"]

Let me explain these lines.

Line 1: We are instructing the docker engine to copy the entire directory to a folder src within the docker container.

Line 2: Install the required dependencies. This will install hapijs.

Line 3: Notice that in the server.js we are running the hapijs server at 8080. In this line we instruct docker to expose 8080 port to the outside world, so that we can access the server from our host machine.

Line 4: Lastly we instruct docker to run the server with the command node /src/server.js. Commands and parameters are given in the fashion as in this line.

Our complete Dockerfile looks like this:

FROM alpine:3.4
RUN apk update && apk upgrade
RUN apk add nodejs
RUN rm -rf /var/cache/apk/*

COPY . /src
RUN cd /src; npm install
EXPOSE 8080
CMD ["node", "/src/server.js"]

We can build the container. Open the terminal and issue this command:

docker build -t jjude/hapi .

Docker needs a dockerfile to build a container. We can either provide the full path or instruct to use the dockerfile in the current directory. We are instructing the build process to use the Dockerfile from the current directory.

It is also a good practice to tag the container with <user_name>/<application_name>.

When you issue this command, it will start pulling the necessary components (os, nodejs, hapijs) from the web and build a container. You will start seeing the output that goes like this:

Sending build context to Docker daemon 5.632 kB
Step 1/8 : FROM alpine:3.4
 ---> 0766572b4bac
Step 2/8 : RUN apk update && apk upgrade
 ---> Using cache
 ---> edfde7516f9b
Step 3/8 : RUN apk add nodejs
 ---> Running in 4d786fc5787b
(1/4) Installing libgcc (5.3.0-r0)
(2/4) Installing libstdc++ (5.3.0-r0)
(3/4) Installing libuv (1.9.1-r0)
(4/4) Installing nodejs (6.7.0-r0)
Executing busybox-1.24.2-r13.trigger
OK: 41 MiB in 15 packages
 ---> 25426b5e81e2
Removing intermediate container 4d786fc5787b
Step 4/8 : RUN rm -rf /var/cache/apk/*
 ---> Running in 2db1ab7c47b5
 ---> efbdf59a5e3a
Removing intermediate container 2db1ab7c47b5
Step 5/8 : COPY . /src
 ---> f67db160cffb
Removing intermediate container b452bcf97da6
Step 6/8 : RUN cd /src; npm install
 ---> Running in eebeb5c18070
sample-hapijs-inside-docker@1.0.0 /src
`-- hapi@14.0.0
  +-- accept@2.1.3
  | `-- boom@4.2.0
  +-- ammo@2.0.3
  | `-- boom@4.2.0
  +-- boom@3.2.2
  +-- call@3.0.4
  | `-- boom@4.2.0
  +-- catbox@7.1.3
  | +-- boom@4.2.0
  | `-- joi@10.2.0
  +-- catbox-memory@2.0.4
  +-- cryptiles@3.1.1
  | `-- boom@4.2.0
  +-- heavy@4.0.3
  | +-- boom@4.2.0
  | `-- joi@10.2.0
  +-- hoek@4.1.0
  +-- iron@4.0.4
  | `-- boom@4.2.0
  +-- items@2.1.1
  +-- joi@9.2.0
  | +-- isemail@2.2.1
  | `-- moment@2.17.1
  +-- kilt@2.0.2
  +-- mimos@3.0.3
  | `-- mime-db@1.26.0
  +-- peekaboo@2.0.2
  +-- shot@3.4.0
  | `-- joi@10.2.0
  +-- statehood@4.1.0
  +-- subtext@4.3.0
  | +-- boom@4.2.0
  | +-- content@3.0.3
  | | `-- boom@4.2.0
  | +-- pez@2.1.4
  | | +-- b64@3.0.2
  | | +-- boom@4.2.0
  | | `-- nigel@2.0.2
  | |   `-- vise@2.0.2
  | `-- wreck@10.0.0
  |   `-- boom@4.2.0
  `-- topo@2.0.2

npm WARN sample-hapijs-inside-docker@1.0.0 No repository field.
 ---> e04821112bdf
Removing intermediate container eebeb5c18070
Step 7/8 : EXPOSE 8080
 ---> Running in 6889ad302d2f
 ---> adfd88fe97ca
Removing intermediate container 6889ad302d2f
Step 8/8 : CMD node /src/server.js
 ---> Running in dcde9b8ab986
 ---> 07786de22668
Removing intermediate container dcde9b8ab986
Successfully built 07786de22668

It should end with Successfully built.

We have the container. You can check it by issuing docker images. It should show something like this:

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
jjude/hapi          latest              07786de22668        23 minutes ago      41.1 MB

As you can see, the basic container that can execute our server.js is of 41.1 MB.

Now we need to bring up this container (run it). Issue this command docker run -p 8080:8080 -d jjude/hapi.

What does this command do?

We are running our container jjude/hapi and binding the container port 8080 to the host port 8080.

What if you want to use a different port, say 9000? You can do that with -p 9000:8080. The format goes like this:

-p <host port>:<container port>

It will come back to the terminal command prompt. How to check if our little server is running?

Issue a curl command.

curl http://localhost:8080

This should output this:

Hello, docker!

That's it. We successfully dockerised our sample hello docker program.

What if you want to go into the container and play around? Docker provides an option to enter into a running container. To do that, we need to know the id of the running container. Issue docker ps. It will show an output like this:

CONTAINER ID        IMAGE               COMMAND                 CREATED             STATUS              PORTS                    NAMES
2fb1cb0abb92        jjude/hapi          "node /src/server.js"   23 minutes ago      Up 23 minutes       0.0.0.0:8080->8080/tcp   cocky_hawking

The first parameter is the container id. Copy it and issue the command:

docker exec -it 2fb1cb0abb92 /bin/sh

Use the correct container id from the previous output.

Now you are into the container. You can stop and restart the server. The source code lives in /src/ folder.

You can checkin these three files (package.json, server.js, Dockerfile) to a repository and ask a member of your team to checkout the repository and build the container. It will work exactly the same way. That's the magic of Docker!

Interested in learning hapijs with typescript? Subscribe to my newsletter

Originally posted at jjude.com