In order to learn, there are three kinds of questions to ask: What?, How?, and Why?

Of these, Why? is the best question to ask, and What? is the worst; How? is in the middle but right near the bottom near What?.

The reason Why? is the best question for learning is that it conditions you to go to first principles and learn how to learn.

What? is the absolute worst type of question to ask, because usually the answer to What? is a reference lookup away. A better question to ask is: Where? can I find my own answer to my What? question?

Likewise, How? is rarely a good question to ask. Knowing how to do something is different from being able to do it. The answers to How? questions are best answered by not asking it directly, but rather by finding an expert who already possesses the knowledge of How?, and simply watch that master at work. To achieve this level of mastery takes years upon years of honing one’s craft, and the answer to How? is rarely succinctly communicable, therefore frustrating both the mentor and the apprentice. Instead, just Watch and learn.

Hopefully, at whatever institution you are in, you are surrounded by individuals who have mastered the How? and you can find opportunities to learn from them. If not, there are plentiful and abundant (not to mention, free) resources online to learn How?, such as YouTube. So, really, How? is a pretty bad question to ask since it is actually a series of What? questions in disguise. Instead of asking How?, just observe those who already know how and do, and as you observe, find opportunities to ask them, Why?. And, if they are not available, a still better question is, Where? can I find the resources to learn How?

All too frequent an occurrence in the development lifecycle is doing some work, closing up your laptop/suspending the machine, and coming back to your work hours or days later.

As you try to start up the local webserver or API server, you get cryptic error messages like the following:

• Address already in use
• Another process is already listening on port
• Port xyzw is currently used by another application
• OSError: [Errno 98] Address already in use
• self.socket.bind(self.server_address) blah blah blah blah

And after checking all of your open terminal windows, that you have not in fact any running or killable-processes…

At this point, the n00b naive way to fix this problem is to simply restart your entire machine. To be fair, this technique works almost all of the time, but kills productivity, and forces you to save work-in-progress that’s not at a good stopping point, or worse, accidentally restart without saving your progress.

But, there is a better way.

Let me introduce you to a command:

netstat -tulpn

This command will print out the bound network ports on your machine, and which processes and process ids are running them. To free up the port to be used by your development server once again, simply kill PID, where PID is the process ID.

Now, how to remember this command? I haven’t figured that out yet, nor have I thought of an alias I want to save it to, that is just as memorable. The arguments almost spell out “tulip”–like the flower, except missing the i, and you just add an n to it. Maybe a mnemonic like, “If you fix your network address port in use issue, you will smell the essence of n tulips”?

Whatever you do, netstat -tulpn is now a friend and welcome companion in my software toolbox.

Edit: This article also got published on the GoodAudience Blog.

I’ve been using println debugging since forever. It’s the best! It’s minimal, is the least surprising form of debugging, and allows you to set-it-and-forget it. I’ve also used interactive debuggers before, but when println debugging techniques are used effectively, I’d argue that step-through interactive debuggers are not necessary at all, and actually slow you down.

For years now, I’ve been using an evolved form of println debugging, which I affectionately call “Slack debugging,” and I’ve written various manifestations of utility/helper functions called slack_debug over the years.

This has been a close-kept secret for myself and select other teammates and colleagues who were curious to know what exact wizardry I was doing.

And now, for the first time, I’ve decided to clean up the solution, open-source it, and share it with the world.

Behold, the Power of “Slack Debugging”

In [1]: from htk import slack_debug

In [2]: from htk import slack_debug_json

In [3]: slack_debug('This is seriously awesome!')
Out[3]: <Response [200]>

In [4]: slack_debug('Yeah, no kidding.')
Out[4]: <Response [200]>

In [5]: slack_debug_json({'A':1,'B':2,'C':3,'X':['foo','bar','baz'],'Z':{'nested_key':'nested_val
   ...: ue'}}),
Out[5]: (None,)

And without further ado, Slack debugging is available here: https://github.com/hacktoolkit/python-htk and https://github.com/hacktoolkit/pyhtk-lite. (And for Ruby: https://github.com/hacktoolkit/htk-rb).

Love it? Hate it? Please share your thoughts and comments, or even better yet, submit pull requests to make it better!

Netskope is a corporate security tool installed on corporate-owned devices that will introduce and override the default SSL certificate authorities by injecting its own local server.

For developers, this often poses an inconvenience especially if they need to develop applications that make API calls and HTTP requests to other web services, if the developers are hitting a web service that has not previously been white-listed by the IT department. The IT department may not be in close communication with the engineering teams, and require additional information from the developers in order to configure a new whitelist rule, impacting the ability of engineers to meet deadlines.

tl;dr; How to kill temporarily disable Netskope

sudo launchctl unload /Library/LaunchDaemons/com.netskope.stagentsvc.plist

TIL: Discovered a super game changing technique. From command line, you can copy contents of any file to Mac OS clipboard by running this command:

1. cat yourfilename.txt | pbcopy
2. Open your other application, press Command+V to paste as normal
3. Profit. Immensely.