The Markdown Payoff
A long, long time ago in a galaxy far, far away, I switched to Markdown format for documents, notes and other scratchings. (And wrote about it - see the posts in the Markdown category).
Was switching to Markdown a good call? Did it pay off? And if so, how?
I actually wrote this post not knowing how it would turn out. I wanted to know for myself if it paid off, or if I just followed a fad. A fun exercise.
Keep long running UNIX commands alive
Here’s the situation: you have a UNIX script that takes a long time to run, but gets killed when your computer goes to sleep and the SSH terminal or VPN disconnects. Ouch.
I know of three ways to kick long running scripts off and not worry about sleeping computers or disconnections: nohup, disown or tmux.
Simple: nohup
From the man page:
nohup -- invoke a utility immune to hangups
Which really does not tell the story. When the parent terminal session terminates, it sends a hangup (SIGHUP) to all child processes, causing them to terminate as well. nohup tells a process to ignore that hangup.
Social Network Precedents for Connecting and Friending
Rebooting OmniFocus
I’ve been using OmniFocus forever to record and track my personal and professional actionable to-dos and ideas. But over the past year, I have been using it less and less, getting less and less tracked and done, and it’s all my fault.
You see, I started to experiment with what could be done with OmniFocus and messed up the whole concept of actually getting things done.
My primary experiment was to create scripts to automatically load actions in from my project files and to merge the company-wide Asana. The big idea was that I could save time and effort by automating task entry and assignment, and let the meat-bag (that’s me) process and review these tasks. If I could spend less time creating tasks and more time performing tasks, I would be more productive.
It's that process that is the magic
CRINGLY: What’s important to you in the development of a product?
JOBS: One of the things that really hurt Apple was after I left, John Sculley got a very serious disease.
It’s the disease – I’ve seen other people get it too – it’s the disease of thinking that a really great idea is 90% of the work.
And if you just tell all these other people, you know, “Here’s this great idea,” then of course they can go off and make it happen.
How I use OS X Tools to build a Linux-only Product
OS X really is a developer’s dream platform, a solid UNIX core on which almost everything compiles with a brilliant graphical environment hosting the most amazing developer tools.
It’s the “almost” in the above sentence that has recently tripped me up.
I have a new vendor library that does not compile or run on OS X (yet!). As this is a big project which I will be working on for months, I want to set up my development environment so that I am comfortable and productive.
Open Source Compiles in an Xcode 5.1 World
So today I needed to work on an older, open-source based C++ application on my Mac and there was no way to compile it under Xcode 5 even though the development tools were installed and working perfectly.
The issue, it seems, is that Xcode 5.1 has finally removed and deprecated a lot of old C++ stuff that is still required by older, popular libraries such as boost and quickfix. It emulates g++ 4.2.1 OK, but is no longer 100% compatible with it. I am quite sure that Apple and the Open Source community will eventually get these to work with the new compiler.
Develop Locally, Stage Nearby, Production Anywhere
One of the things that surprised me as I moved back into the land of corporate software is the number of developers I talk to that commute and work in offices and yet develop on remote computers. I thought, as you probably do, that by now all software development would be local, as in on the developer’s own computer.
Instead, it is not uncommon for corporate developers to rely on remote shells or desktop virtualization to access remote development computers and use them to code. It’s slow, unproductive, frustrating and so pre-1990’s.
From Tool Maker to Tool User
Abstract: Programming is still seen as a single-language, single-platform tool-maker role. That has not been true for a long time. Over the years, the platforms, tools and libraries available have multiplied. We’re tool users now, where a programmer can pick up a new platform with ease, and use the tools available to create complex, reliable products a lot quicker. That which was impossible then is commonplace now.
The role of the programmer has changed over the years, from being a certified single language, single platform tool-maker into a master of application styles, technologies, use cases and platform tool-users. And when you think about it, the tremendous change in the tools we can use and master has steered us here. But we, the industry and the job market still view programmers as singular tool makers (just look at most programming job ads).
Easy SSH to local linux VM
TL;DR: Run avahi on the VM, ssh to the VM name dot local.
Many of the Simple C++ Projects I work on, whether I use Xcode or not, land up needing to be recompiled on a Linux Virtual Machine prior to being deployed to the production Linux server. I do this because I want to be sure the I know what needs to be set up in the Linux environment, that the compile succeeds without errors in a production-like environment and the code works properly before deploying.