Dirty Little Secret About QWERTY Layout and How I Switched to Colemak to Reduce Trauma and Gain Productivity

Typing is everywhere right now. We type for work in emails and on IM clients, we type for personal relationships on Facebook (when was the last time you spoke with a friend on a phone?), and we type to have fun in Whatsapp or iMessages. Then of course, we code in editors and IDEs, and type commands in shells.

Imagine that you woke up tomorrow and weren’t able to use your keyboard. Maybe you would have broken both of your wrists skiing… Terrible, right? Even if you don’t write books or blog posts like I do, typing on a keyboard is how most of us live. And touch screen typing and voice dictation take only small roles. Let me tell you why you might be in danger of losing your ability to type and maybe even close to losing your job, career and relationships.

Continue reading “Dirty Little Secret About QWERTY Layout and How I Switched to Colemak to Reduce Trauma and Gain Productivity”

React for Fun and Profit

React is a fun little library for User Interfaces. You can use it for web, or mobile development. It’s fun because it’s very developer-friendly. You write your code in the same place without having to switch between HTML and JavaScript files.

I’ve heard many times people complaining about React’s favorite syntax JSX. I found it great, after I spent a few hours learning and coding with it. Contrary to what people unfamiliar with React think, JSX is not HTML in JavaScript. JSX is just an XML-like syntax which produces JavaScript. There’s not HTML involved at this step. When you develop with React, you write JavaScript objects. Later React automagically transforms those object into rendered HTML.

Also, React is very fast due to its virtual DOM and smart diffing algorithm. And React’s component approach to architecture allows for great development scalability. Just ask Facebook, Twitter, Slack and other companies with large web apps.

Furthermore, you can use React with React Native to create native iOS and Android apps. These apps can share the same code. It’s not the same as the so called hybrid or HTML5 apps. The latter are websites trapped into a headless browser in a mobile app. The former is a real native app which uses JavaScript interface for it’s UIs and logic.

Hey, you can even use live reloading when developing apps with React Native. Pure joy! The feature native mobile developers can only dream of! “React is fun, but show me the money”— you can yell. Fair enough.

Continue reading “React for Fun and Profit”

My Predictions for 2015

Here are my ten predictions for 2015. Most of them probably will be incorrect. Yes. I’m seldom right, but I’m never without an opinion.

  • Web development, online payments, Node.js and JavaScript will continue to grow with more and better frameworks, hosting and solutions that don’t even require coding.
  • Udemy, SkillShare and similar marketplaces for online courses will increase the number of offerings. The quality bar will raise. The marketplaces might become saturated.
  • Coding academies will expand into online format to cut costs and consolidate as the geo-markets will get saturated. At the same time traditional education (colleges, universities) will continue to get people into debt and produce inadequate results.
  • The number of freelancers (coding, design, copywriting, VAs) will increase while their prices will remain competitively low.
  • Apps and small SaaS businesses will become even easier to build spiking new offerings for consumers and business.
  • Majority of unsuccessful and unpopular podcasts (~95%) will die.
  • More people will start leaving their normal jobs for entrepreneurial endeavors or start side projects. Other will look for alternative paths for their creativity (books, blogging, freelance).
  • Robots will become smarter and continue to displace blue-color jobs (driverless cars, Amazon.com delivery drones, Roomba). Hence, re-training for new jobs is vital (see #2 and #3).
  • The zen-like lifestyle stress-free trend will continue to grow supported by more studies and better diets like Paleo/Bulletproof/SCD/Slowcarbs. More farm-to-table choices and more organic and grass-fed options will be available.
  • Technical and business books will become cheaper, often times free to serve as lead generation for later upsell into other products like online trainings, seminars… and entertainment books are already at the $0.99 mark.
  • Internet television (YouTube) and shows from tech companies (Netflix, Amazon.com) is going replace traditional TV in more home. It will be even cheaper to start your own TV channel online that ever before.

What are your thoughts about my predictions? What are you predictions for 2015?

Guest Blogging

Guest blogging is writing a post on someone else’s blog. It’s a good way to get new readers and engage in a new community. For new bloggers, it’s a good way to get attention to your own blog.

Michael Hyatt, whose book Platform I’m reading now, emphases this point. Other prominent bloggers, such as Chris Brogan and Guy Kawasaki, state it as well. Moreover, for readers it provide a new perspective and variety.

I decided to offer other people to write on Webapplog.com. Send me your ideas to my email hi (at) azat (dot) co.


Free & Easy Hosting

If you need a simple website for your project, then use GitHub pages. It’s free and better than cheap $4.99/mo hosting, which can be easily hacked, is slow and requires you to use cPanel.

Here’s what you’ll need to get your website up and running:

  1. Create account on GitHub (do it once).
  2. Create a new repository.
  3. Send your developer a link to that repository, and a Twitter Bootstrap theme of your choice (Google it if you don’t know where to get a beatiful theme).
  4. Point your CNAME records in Godaddy, or whatever you’re using, to GitHub IPs ( and
  5. Merge pull request from you developer on GitHub.com.
  6. Boom! You’ve got your website.

I use this technique for my 10+ websites, some of them quite fancy:

There’s no need for WordPress or PHP. GitHub Pages is free and it is faster than BlueHost.

The site must be static only without any PHP, Node.js or any other server-side logic. You can use foxyform or EmailMeForm for contact forms, and Gumroad for sales. For blogs, you can use Wintersmith or Jekyll.

Guide to Hiring Your First Developer for Non-Techies

One of The Foundation members asked in forum, “How do I find a good developer?”. I was glad to help, but then I thought that others might benefit from this advice so I answered it via a post.

The best thing is to work on something small first. This way you’ll test the waters before putting a major project under risk. This might include a test or a real, but small task, (preferably outside of the main project) like writing a bookmarklet or a scrapper.

Continue reading “Guide to Hiring Your First Developer for Non-Techies”

Job Security is Dead But There Is a Way

There is no such thing as a job security. You can trust my word on this, because I worked for one of the most stable employers in the world, the U.S. federal government, during 2007–2008, and had seen a lot of bright software engineers, analysts, technical writers, quality assurance engineers, and project managers let go due to the market downturn and budget cuts. Startups and private corporations are even more brutal. They won’t even give you a two-week notice! I know of a company that fired its lead software engineer with just ONE hour of notice… poor fellow didn’t expect it at all when he was coming to work in the morning just to go back home for the rest of the day right away!

Continue reading “Job Security is Dead But There Is a Way”

Punishment for Becoming Better

If you do something for a living every day (i.e., you have a job) you have two choices:

  • Learn and become better: this is the default path for most people (it’s hard to do something over and over without getting better at it).
  • Stagnate and regress: this is actually harder than progress, and may require some subconscious proactive self-sabotage.

So everything is better if we automatically make progress, right? Not quite, because when we make progress, other people (including bosses) start to notice, and they then give/bring/order more of the same work—not a new type of work. Usually it’s the same stuff you’ve been doing already (and for the same money), because management doesn’t want to lose a good producer. I call this punishment for becoming better.

Continue reading “Punishment for Becoming Better”

CoffeeScript: The Good Parts

It’s not a secret that the topic of CoffeeScript is controversial to say the least. Many reputable JavaScript and Node.js developers just hate CoffeeScript, but there are lessons we can all learn from its good parts! However, many developers just won’t go back to plain JavaScript after building something relatively serious with CoffeeScript.

Continue reading “CoffeeScript: The Good Parts”

Introduction to OAuth with Node.js and Online Subscription—RELEASED!

The much-needed Introduction to OAuth with Node.js mini-book is released!

Introduction to OAuth with Node.js
Introduction to OAuth with Node.js: Twitter API OAuth 1.0, OAuth 2.0, OAuth Echo, Everyauth and OAuth 2.0 Server Examples

Get your PDF, EPUB, MOBI copy here –> gum.co/hRyc
or sign up for Node.js and JavaScript Mastery Online here.

The online bundle has five (5!) books. Here’s the list of available books. It’s a $50+ value for only $4.87/mo.

Node.js and JavaScript Mastery Online: Colored code examples—paste into your projects!
Node.js and JavaScript Mastery Online: Colored code examples—paste into your projects!

If you read all the books in less than a month—great! Just cancel the subscription. But most readers prefer to keep it just so they have a handy reference when they need it.

The Introduction to OAuth book includes:

  • OAuth 1.0
  • OAuth Echo
  • OAuth 2.0
  • OAuth 1.0 Sign in with Everyauth
  • OAuth 2.0 Server

A typical modern web applications has to communicate with other services. Even if it’s your own service or application. This is usually done via an open standard for authorization or OAuth. Therefore, the ability to use OAuth in your work is paramount!

There are standards, specifications and fancy diagrams, and it’s useful to read them as the first step. However, developers often need hands-on experience to acquire the full understanding and confidence.

Introduction to OAuth in Node.js is a concise practical book that will help you to get started with OAuth 1.0, 2.0, Echo and implement a Sign in with Node.js using Twitter API (and hopefully any other) authentication.

We’ll go through the three main authentication methods utilizing minimalistic oauth module to explain basics, then use extensive everyauth with an Express.js app.

Get your PDF, EPUB, MOBI copy here –> gum.co/hRyc
or sign up for Node.js and JavaScript Mastery Online here.

Seven Things You Should Stop Doing with Node.js

Inspired by 5 Things You Should Stop Doing With jQuery by Burke Holland, I decided to open a discussion and highlight seven things you should immediately stop doing with Node.js:

  1. Stop using callbacks
  2. Stop using * for versions
  3. Stop using console.log for debugging
  4. Stop using GET and POST for everything
  5. Stop using semicolons
  6. Stop using comma-first style
  7. Stop limiting your connections with default maxSockets value

Continue reading “Seven Things You Should Stop Doing with Node.js”

CoffeeScript Quirks

CoffeeScript is a solution without the problem.

— Unknown ironic source.

CoffeeScript is awesome, until it’s totally confusing, and it’s illogical, which can lead to unexpected and subtle bugs. If you’re one of the CoffeeScript haters please skip this post; for others, I’ll share a few notes on the CS quirks that I’ve observed.

For example, let’s say we have a counter and need to assign a value of index subtracted by one to it:

numberOfRadios = index -1

But the line above is not the same as:

numberOfRadios = index - 1

Did you notice that there’s a space after the minus sign in the second example? It took me awhile to track down this type of bug. The reason for this behavior is that the first line will be converted by the compiler to the function invocation and that is probably not what you wanted.

Try the minus one snippet on CoffeeScript.org. It outputs the following JavaScript code:

var numberOfRadios;

numberOfRadios = index(-1);

numberOfRadios = index - 1;

Another pitfall, that leads to writing despondently inconsistent code (by us developers), is caused by the fact that parentheses are optional for function calls.

This example involves if conditions in which we want to compare the value of the expression model.get() or the operand typeof to some strings:

a() if @model.get 'groupType' is 'radioGroupTabs'
a() if typeof @model.get 'condition' is 'function'

CoffeeScript is treating the entire thing as an argument and the results are pathetic. Duh. ;-( Here is the native JavaScript code:

if (this.model.get('groupType' === 'radioGroupTabs')) {

if (typeof this.model.get('condition' === 'function')) {

Placing parens over the function still does us no good. Look at this CoffeeScript code:

a() if @model.get ('groupType') is 'radioGroupTabs'

And its JavaScript output:

if (this.model.get('groupType' === 'radioGroupTabs')) {

The workaround involves using () around function calls, or flipping the order in the if statement so that the function invocation is the last bit of code in the if statement:

a() if (typeof @model.get 'condition') is 'function'
a() if 'function' is typeof @model.get 'condition'
a() if (@model.get 'groupType') is 'radioGroupTabs'
a() if 'radioGroupTabs' is  @model.get ('groupType')

The code above compiles to what we wanted originally:

if ((typeof this.model.get('condition')) === 'function') {

if ('function' === typeof this.model.get('condition')) {

if ((this.model.get('groupType')) === 'radioGroupTabs') {

if ('radioGroupTabs' === this.model.get('groupType')) {

Is it all good now? Not really, because I personally think this approach leads to inconsistencies: parts of CoffeeScript code that must have parentheses, while in other places they are optional.

Try these if conditon snippets yourself on CoffeeScript.org.

The next note explains the most common beginner’s mistake in CoffeeScript; that is to use an a instead of an a() for function calls. However, super inside of a class, must be called without parentheses in order to pass the arguments to it.

Moving on to the single hash (#) comments which are just skipped over by CoffeeScript. Again, this can lead to unexpected consequences.

For example, a straightforward if statement has a few lines of code:

unless A 
  blah blah

But if we comment out all of the lines inside of if, the whole thing will fail miserably at the compilation step (at least thank you for that, CoffeeScript!):

unless A 
  # b()
  # blah blah

Just by adding an empty else we can mitigate the failure:

unless A 
  # b()
  # blah blah

c() # the code continues here

Try this snippet yourself on CoffeeScript.org

Last but not least, there is another CoffeeScript pitfall related to jQuery events that don’t propagate when the event handler returns false. Of course, CoffeeScript philosophy makes every function an expression (the last statement is evaluated if there is no return statement present).

b = ()->
  false # usually this result is less obvious and buried deep down in code
$a = $ 'input'
$a.click ()->
  console.log 'this happens all right'

$a.parent().click ()->
  console.log('this never happened')

Of course, in real life the b() function is not so obvious and it’s buried somewhere deep within Backbone and Angular model methods. And the event isn’t propagating up the DOM tree (return false). Therefore, we’ve lost the second event handler without even realizing t. Buyers beware of this elusiveness! :-)

Try the event propagation bug yourself on CoffeeScript.org

This is the end of my list. If you know of any additional CoffeeScript idiosyncrasies, please send them my way. :-)

Further CoffeeScript reading:

Getting Published as a Programmer: The Practical Node.js Story

This is the story about how I got my first publishing deal, what this book is about, and what problems I encountered along the way.

TL;DR: This is the story about how I got my first publishing deal, what this book is about, and what problems I encountered along the way.

I spent last weekend sitting in an awesome new coffee shop in Oakland, typing up the last two chapters of my Practical Node.js manuscript. The book is scheduled for release by the UK-based technical publisher Apress in the late spring.

I started writing the manuscript in October 2013. I devoted my weekends and holidays to it (as so many entrepreneurs and writers do). The fact that I smartly had a few example apps and some drafts written — some of them for my blog, others for proposals to Pragmatic (declined!) — helped to speed things up. (Needless to say, in publishing rejection is a common thing and often an opportunity to get better.) However, the writing itself wasn’t the hardest part. Here’s the short story why.

Continue reading “Getting Published as a Programmer: The Practical Node.js Story”

How to Stay Healthy and Sane Working 12-hour Days As a Programmer

The DocuSign Momentum conference is just a few days away, and my team and I has been pulling long shift in order to deliver something absolutely amazing and to make sure that it’s in a great shape. So I wanted to share what exactly helps me stay healthy, sane, productive and happy working as a programmer 10–12 hours per day sustainably:

  • Get at least seven to eight hours of sleep
  • Skip breakfast: clears mind, reduces calories intake, and saves time
  • Check work email only a few time per day and check personal email/Facebook/LinkedIn/etc only once (in the evening) preferably inboxing zero both categories
  • Meditate and workout (12 minutes is enough)
  • Cancel all activities and avoid any additional obligations and projects
  • Wear uniform-like clothing
  • Drink lots of good coffee (e.g., bulletproof coffee)
  • Avoid fruits, sugars, sodas (even diet ones), grains, legumes and potatoes, i.e., paleo lifestyle/diet
  • Change workstations: resistance ball chair, stand-up desk, sofa, etc.
  • Consume vitamins: C, Omega–3, Multivitamins and D3
  • Take walks and stay positive!

PS: The Healthy Programmer book has been on my to-do list for a long time. Please let me know whether you read/liked it.

Succeeding with Agile, Brief Overview I

Couple months ago, I was promoted to a ScrumMaster role at DocuSign. In light of it, I decided to brush up on my agile development skills and theory by reading. My choice fell on the highly acclaimed Succeeding with Agile: Software Development Using Scrum by the guru of Agile Development and Scrum — Mike Cohn.

Succeeding with Agile
Succeeding with Agile

Here is a short overview of the first half of the book, or gist as programmers call it:

  • A ScrumMaster has more responsibility and authority over processes, but a limited authority over people; the role is akin to a fitness trainer (a yoga teacher analogy fits me better): enforcing the agile process.
  • Every sprint team needs to deliver shippable (and tested) code: features, bugs, etc.; if the task is too large — split it.
  • Developers should work with product managers/owners directly on requirements.
  • Different developers should work on all parts of the application / code base.
  • Agile is not for the developers who likes to work in privacy putting their headphone and not talking to people (Bummer). :-)
  • Team functions better with a mix of generalists and specialists; avoid all-specialists teams at all cost.
  • When possible use feature teams rather than component teams.
  • Keep teams small. Four to nine people is an optimal size due to the social loafing (having more people reduces average productivity) — this was one of the reason our DocuSign team was split into three smaller teams!
  • A non-coding architect and project manager are obsolete roles on a Scum team.
  • Don’t let team members multitask. Each additional task reduces productivity; however, after three and more tasks the reduction becomes smaller and smaller. Direct quote: “Individuals assigned to work on multiple projects inevitably get less done

To be continued…

What I really liked about the book so far is that it’s not just boring theory. Each point is supported by data, references to sources and personal three-decade-long (anecdotal) experience of the author (Mike Cohn). If you liked the bullet point above, get Kindle Succeeding with Agile on Amazon.

Programmers Are Assholes?

Right now, I’m lucky to work in a great team where everybody is a wonderful human being. However, during the years in software engineering, I’ve encountered a disproportionate number of assholes comparing to other fields or professions. Does coding affect someone’s personality negatively or it’s the other way around? Do computers attract certain asocial elements, so they can put on the headphones and not talk to people? Why there are more assholes in software engineering than in real estate or food&beverage?
Continue reading “Programmers Are Assholes?”