In Instantly grab a high-res icon for any iOS app, the awesome Brett Terpstra (@ttscoff) offered a script and an app to get the icon from iTunes for any iOS app.

I wanted the same for Mac apps. Turns out, it’s a one word change to Brett’s scripts. Just follow his instructions using the below files, but replace the script name with macicon.rb and the application name with MacIcon.

• Download and save the script as macicon.rb.
• Download the MacIcon Application.

Usual disclaimer: It works for me, should work for you, and no bunnies were harmed.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

Today, April 30, 2013 is the 20th anniversary of CERN making the WWW free, see Twenty Years of a free, open web. I thought I’d share a story about how it was like before then.

The year was 1988 or 1989, and my Computer Science Professor wanted to send his first email. But first we had to connect our University to the fledgling Internet. Since I ran the UNIX lab, I was tasked to set this up.

I should point out that I was at the University of Cape Town in South Africa at the time, about as far from the physical internet as was possible back then.

This was before ISP’s. We ran our own wires, hubs and routers. And the Computer Science department had it’s own LAN. We also had a bank of modems available for graduate students to dial in from other parts of the campus. We were not even wired to the next building. That was our entire network.

Since we were not interconnected, we had no access to the fledgling DNS network that was growing in the United States. And web servers and web browsers had yet to leave the lab and be opened up. And SMTP, which the planetary email network still depends on, would only work in a fully-connected environment.

The first step was then to find a way to connect to this Internet thingie from the far end of the world.

One of my Professor’s colleagues had written in a letter that his University, The University of Cambridge in the UK, had already been connected, and offered to enable us to route through them. All we needed to do was find a way to connect to them first.

We could have just used one of our modems to call out to Cambridge via the phone network. But international phone calls to host slow modem connections were prohibitively expensive, and the international lines out of Africa were notoriously noisy and unreliable. We needed another way.

Then we found out that the Rhodes University in Grahamstown in the Eastern Cape had been given a huge grant to pay for their connection to Cambridge. So my Professor got on the phone to his counterpart there and they agreed that UCT could route through Rhodes and piggyback on their UK connection.

So I set up a modem, scripts and routes to use UUCP (UNIX to UNIX copy) to connect our primary UNIX computer to the Rhodes one. It would dial up Rhodes every hour and use UUCP to transfer any files and messages between the two computers. I tested it by sending messages and files to my counterpart there. It was then up to the Rhodes computer to process any email messages for us.

And it worked. My Professor sat at my desk, typed in his email and hit send. Then we both stared at the screen. Because nothing happened. I checked the UUCP folders, and the message was there in the queue. Sometime in the next hour, our modem awoke, called Rhodes and UUCP sent the message out. Rhodes forwarded it on sometime later to Cambridge and I have no idea how it went from there onwards.

The next morning we came in to see if there was a reply. But there was none. The UUCP queues and folders were empty. Maybe the message did not get through.

But the day after there was a message. It had come back through this ad-hoc network of computers, dial up connections, hand-coded scripts and home grown routing tables from the other end of the world.

Donald Knuth himself had replied to my Professor’s first emailed question.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

Or how many people get so stuck in the processes of how to do the job, they simply forget to actually do the job. Many a product has failed to materialize because the process to make that product has gotten mired, stuck, distracted or waylaid. It becomes about the people and the politics and the process and no longer about the product.

I use this Hiltmonism to help me to focus on the goal, the reason we are creating the product, and the need to be ruthless in getting it done. We are doing what we do to make a product, to ship it, to delight our customers, and to make money. Not because we love following a process for the purpose of process following.

There are so many examples of when the process takes over, and the product never gets done:

• Too many head chefs: Projects that are run by committee or need to have “buy-in” from a multitude of people and departments get waylaid by the process to achieve consensus. The number of opinions and egos grows exponentially as the number of owners grow.
• Too many deliverables: Projects get slowed down in project management reports, process documentation, regular presentations and meetings instead freeing the Project Manager to lead the team and get things done.
• Bureaucracy: The growth of a bureaucracy as an organization matures is natural, but it leads to discussions on seniority and turf wars instead of laser focus on product.
• Used to Do X: The continued slavish performance of manual processes that distract and take up time just because “we always did X this way”. Look for processes that may not even be necessary any more as the business changed or another process covers it.
• Waiting For: Incessant “waiting for” others before one can do their task, and accepting this as an excuse for non-performance and an acceptable business practice. This leads to human deadlock, and the inability to move forward on a product.
• Minutiae: Getting lost in the minutia of a product, or “seeing a leaf and missing the trees and the forest”. This often manifests in management trying to solve all the problems instead of leaving that up to individual designers or engineers.
• Doing all the steps: Following strict adherence to a development methodology and process without actually creating the product, because the methodology takes over people’s time. Methodologies are good, but are not the all.
• Blame: Processes also assign blame, invariably to those who cannot choose the assignment, and folks don’t like to be blamed. So they do all sorts of crazy things to ensure they cannot be blamed or held accountable, spending time and effort covering their asses instead of making the product. And so the product does not get made.
• Fear: And good old fear of the unknown, so the product never even gets started. You can tell if this is happening when the team tries to solve all the problems that may never occur, just to be 100% sure that the product will work before even launching the project.

How to keep the impact of the process down and maintain focus on the product?

• Start with a light process. Do only the minimal amount of process to track the product development project and report on it, and focus more on the work of creation and building.
• Cross bridges if and when you get to them. Good product planning is worthwhile, too much over-planning means that you never stop planning and get started doing.
• Spike the known issues early and deal with the unknowns when they come up. If there are a few issues that are unresolved at the start, spike them, solve just them. Once they are sufficiently solved to move on, do so, and the rest of the product should be easier.
• Maintain clear and proper team communication, keeping folks in the loop and not hiding anything. Keep meetings short, make information available to all but do not overload or bore them with details.
• Delegate decision making responsibility. People who feel they have the responsibility to decide and to do something usually get down and do it. And if they depend on some one else’s work, give them the authority and responsibility to chase their dependencies up as well. That gets rid of the ‘waiting for’ mentality.
• Step back every once in a while and remember what you are trying to make and why. Look to see if the product is on track from a high level, then get back to the details.
• Fix instead of Blame. If an issue arises, and it will, all those who need to should get involved and resolve it. If an individual screws up, help them rectify and move on.
• Iterate a product, don’t try build it all at once. Aim for a minimum viable product, then take the time to flesh it out.
• Get parts of the product in front of users as it grows. Nothing motivates a team more than joyful acceptance of work done and excited anticipation of deliverables to come.

Many a product has failed to materialize because the process took over. Look for the signs, and remember, the process is not the product. The process is not what you do nor why you do it, the product is.

See also the other Hiltmonisms in the ongoing series.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

I have no idea why I am sharing this, but this is my current workspace:

On and around it you will find (left-to-right-ish):

• My original iPad 1 running Panic’s Status Board on a Twelve South Compass Stand for iPad.
• A Koncept Equo Gen 3 desk lamp, stylish and bright.
• An AT&T MicroCell so I can get Mobile Phone service at home in Manhattan!
• My iPad 3 WiFi 64GB, gray Apple smart cover.
• My primary computer, a 15-inch Mid-2009 MacBook Pro with dual 3.06Ghz CPUs, 8GB RAM, a 240GB OWC Mercury Electra 3G SSD in an OWC Data Doubler and the original 500GB HDD.
• My rent bill.
• A classic Apple Cinema Display 23” connected to the laptop via an old Apple DVI to ADC Display Adapter and a Mini DisplayPort to DVI adapter, and it still works great.
• Altec Lansing speakers, about as old as the hills but still sound adequate for my needs.
• A Wacom Bamboo Pen tablet for artwork.
• Apple Bluetooth Keyboard and Magic Trackpad.
• An ancient Dell 2408WFP 24” monitor (that does not render properly with OS X), attached to my 2008 Mac Pro server (8 core, 32GB RAM, 4.5TB disk – hidden below the desk) and my original iSight above it.
• On top of the Mac Pro tower is my trusty HP 12C financial calculator, an Airport Extreme and several old WD 500GB My Passport drives – link to newer model – that I use for backups.
• My favorite Zebra Sarasa 0.7 Gel Retractable pen.
• A Zebra Z-Grip 0.5 mechanical pencil.
• The desk is a Galant with T-Leg from Ikea, 10 years old and starting to peel and warp.

This is where I work and spend my days. What does yours look like and what do you use – please link in the comments?

Warning: Some links on this page are affiliate links; I get a few pennies if you buy any of these products.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

We all spend a lot of time talking on the phone, and have been doing so for many years. It’s far beyond the right time to learn basic voice call etiquette, but here are some of the best practices I have come across.

See other articles in Etiquette, including Email Etiquette and US Dining Etiquette Failures.

We’re not perfect, yet:

You can only learn from making perfectly good mistakes.

We all know of people’s reluctance to try things out in new software products because they are afraid of making mistakes and looking foolish. They are striving for perfect execution, yet unknowingly fail to learn the product or gain the benefits of its power.

Yet the failure to try new things is the biggest mistake of all. If you do not take a chance and try, you cannot learn anything.

Mistakes themselves are not bad. Making mistakes is not bad either. Mistakes are not failures. Instead, making mistakes is evidence of trying things out. And trying things out is evidence of learning. And learning is never foolish.

So go ahead, try things out as I do. And make a lot of perfectly good mistakes as I do. We will both learn new things, new paths, new ways, new techniques and also new things not to do. Make a perfectly good mistake, learn something, shrug and move on.

Think of it this way: One needs to make a lot of perfectly good mistakes in order to learn new things, grow and develop.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

punc·tu·al /ˈpəNGkCHo͞oəl/

Adjective
1. Happening or doing something at the agreed or proper time; on time.
2. Denoting or relating to an action that takes place at a particular point in time.

Synonyms
precise – exact – accurate – prompt

One of my many peeves is with people who are not punctual. If we schedule a call or a meeting at a given time, I will be there, on time, prepared and ready to go. It’s only right that others do the same.

10:00 AM means “At exactly ten o’clock in the morning”, not 10:15 AM or 10:30 AM or later.

It really is easy to be punctual. We are surrounded by timepieces, on our computers, phones and even on our wrists. Our lives are all scheduled in calendars which automatically bleep reminders to all our devices in advance of an event. And we all know what’s in our daily plans because we continually check them, so it’s not hard to ensure we can be on time to each event.

Tardiness is disrespectfulness. A tardy person implies that they believe their time is more valuable than others, or in other words, they disrespect others. I take it personally when someone is 15 minutes late and offers no excuse. And I take it even more personally if the excuse is lame, or they could have called to let me know they were running late beforehand.

In fact, these days there is no excuse after the fact for being tardy. If your previous event is running late, or your transport is gridlocked, send a text or an email before the fact. Let others know that you are trying to be there on time and the circumstances in advance for being late. If the other person can accommodate, all is well. If they cannot, reschedule there and then. At least you respect them enough to alert them and give them a choice.

Now I understand that there are cultures where punctuality is not the norm. And douchebags who like to keep others waiting as part of their power games. I do not live in that culture, and I am not a power player nor politician. I have, in fact, gotten up and walked away on several occasions where I knew the person was alone in their room, but was making me wait on purpose.

And I accept that there are certain areas where service providers, like Doctors and Dentists, cannot schedule as tightly as they would like because they cannot know in advance just how long each consult will take and so make people wait. In that scenario, there’s still no excuse for the patient to be tardy, it holds up all later patients.

Whether or not you can plan the length of each consult, trust George Washington:

Undertake not what you cannot Perform but be Careful to keep your Promise.

A person who is punctual:

• Has integrity, they make and keep their promises.
• Is dependable, you know they will be there on time.
• Has discipline, they planned to be prompt and are most likely also better prepared.
• Has respect for others, as they are available as agreed when others are available too.
• Is not a thief. If “Time is Money” then tardy folks waste punctual people’s time, burn their money and are therefore thieves (according to Washington).
• Respects the relationship, a punctual person values the time they spend in the relationship.

So next time we schedule something, know that I will be there on-time out of respect for you and your time. I expect you to do the same. And if you are going to be late, text me, let me know in advance so I can manage my time better. Surely that’s a small thing to ask and an even smaller thing to grant.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

Lets take a look at the Widget market. It’s maturing but still expanding, with sales growing to about 2 million a quarter.

An experienced investor, looking at fundamentals, history and buyer preferences, will expect Peach to sell 1 million Widgets and Pear to sell about 250 thousand, with the remaining Widgets being sold by others.

But lets assume the presence of an Analyst that wants to drive Peach’s stock down, and wants to promote Pear. They want to do this because that Analyst’s firm makes more money when Pear shares, securities and derivatives trade.

The Analyst cannot say Peach will sell 2 million widgets this quarter, that’s the whole market and will seem like an unreasonably large and implausible number to their clients. They also cannot say the correct number they expect based on fundamentals, because if Peach achieves that number (very likely it will) then the Peach stock price will go up, not what their employer wants. So the Analyst picks a number that sounds reasonable, but is made up, that will achieve their goal.

Lets say the Analyst picks 1.25 million sales. On the surface it seems a reasonable, if high, expectation. A long pass if you will.

On the other hand, the Analyst calls 150 thousand sales for Pear, also not unreasonable, a 2 yard rush, especially if Peach is growing quickly.

Then Peach announces its earnings. Revenue is up, profits are up, cash is up, debt is nonexistent and market share is up on great sales of 1.1 million Widgets. It is, in fact, Peach’s best quarter ever. Fundamentally, Peach just proved itself to be a more valuable company and it’s share price should rise.

The press and the Analyst report the Peach earnings as a miss, because Peach reported fewer Widgets sold than the Analyst made-up number claimed was expected, and the Peach stock price tanks. The Analyst’s company wins.

Later that week, Pear announces its earnings. Revenue is down, profits are negative, margins are down, market share is down, and debt is up on sales of 200 thousand Widgets. All in all, a shitty quarter by all measures for Pear. Fundamentally, this company looks worse, the prognosis is that it’s getting worse and it’s share price should drop.

The press and the Analyst report that Pear beat expectations and the Pear share price rises instead. It seems that Pear did better than the intentionally low-ball figure chosen. The Analyst’s company wins again.

It makes no sense. Fundamentally, economically, and return-wise, Peach is a good, sustainable business and Pear is a money-burning disaster heading over a cliff. Yet Pear shares go up and Peach shares go down.

Now replace Peach with Apple and Pear with, well, anyone else in the same space (or use Amazon if you wish).

It makes no sense. It’s wrong. Yet this is how it really works on Wall Street these days. And it’s perfectly legal.

I am expecting this scenario to play out tonight at the Apple earnings call, and at the next, and the next. Just like the last one and the one before. And there is nothing we can do about it.

Follow the author as @hiltmon on Twitter and @hiltmon on App.Net. Mute #xpost on one.

I think Apple’s recent move to annual releases for major products like iOS, OS X, iPhone and iPad is a huge mistake. It opens up too many cans of worms and is hurting the company’s public image and stock price.

I have been using Brett Terpstra’s (@ttscoff) Slogger for the last six months, and I think it’s time to review it. Slogger is a script and a set of plugins that log your online activity each day into Day One, the best journaling application for OS X, or in Markdown files if you prefer. It’s a core part of my Backing up your Online Life process.

TL;DR: It’s totally worth taking the time to set it up and get it going. The data captured is so useful and often hard to gain access to, especially as we operate across many services, and as these services come and go.