Apparently so, by Steven Ringo

Set the correct Startup Disk when migrating to a cloned drive on Mac OS X

2009-10-28T06:29:00Z

I just migrated my MacBook Pro to a Crucial 128GB SSD drive using SuperDuper!

Even with the new speedy gonzales in the system, boot times were a tad slow coming in at a whopping ~60s. It took 40s to just show the Apple logo.

I was expecting ~20s from the legendary Mac OS startup sound to seeing my desktop. After poking around a bit I remembered that there is a “Startup Disk” setting in “System Preferences”. Once there, click on the new hard drive icon, then “Restart…”. The machine will restart with the new default startup disk.

To explain: It was trying to boot from the old drive (which is now no longer connected). Even though it is a perfect “clone”, there must be some drive IDs etc that the OS is looking for in order to identify the correct disk.

I just timed the boot now that that’s fixed. From power on to login ~ 16s!

Tech23 - key takeaways

2009-10-27T11:41:00Z

I spent most of today at Tech23. I arrived with few expectations and left very pleasantly surprised.

The format was simple. A representative (usually the CEO/founder) of a startup presented to a panel of “industry leaders” and provided a four-minute elevator speech about their startup. The industry leaders then engaged with the panelists; often with pertinent and challenging questions. The list of startups and industry leaders that presented today can be found at the Tech23 website.

Interestingly the audience were not allowed to participate directly with responses/questions. Rather, the magic of twitter and continuous tweeting by a substantial portion of the 300-or-so audience, gave all following on twitter a pretty accurate understanding of the zeitgeist in the room at any one time. It also allowed the organisers to relay questions from twitter to those on the panels.

There are a few key points that I came away with, and will treasure the information gleaned from today’s seminar:

If you cannot present well, forget it. You have one chance to impress your audience and the first few seconds of a presentation are golden. Notably presenters from companies including Posse, CultureAmp, PersonalAudio, HeardSystems, We are Hunted had it spot on, and we were engaged. Others didn’t fare so well, but managed to get points across, although I certainly wasn’t left feeling inspired. Alas, some never even got as far as their key message and we were left wondering why they were even up there :-(
Depth over breadth. Conquer a small slice of the market first and then build outwards from there - even if you think your offering is relevant across a wide spectrum, find a niche, get to know it well, experiment in it, and once you are experienced there, then move further afield. In other words stick to one narrow vertical first, and then use the learnings from that vertical to leapfrog into other verticals.
While it may seem obvious, social networking underpinned most of the offerings. Except of course the “weapon of mass pregnancy detection” invented by the good folk at Heard Systems. I guess you could say that’s social networking of a more beefy nature.
I made many new contacts and started following quite a few more people on twitter that I would never have known before today.

Similar learnings have come up before for me - in the field of software development, and its valuable to realise the parallels:

The point on presentation resonates when it comes to building user interfaces. Again, you have only a few seconds to impress the first time user. And for the regular user, you want them to keep coming back because your software is a joy to use.
Depth over breadth is a key to software development. I strongly believe in developing software in “thin slices of full functionality” that deliver a chunk of useful functionality from start-to-finish but where the scope is only as broad as what is required to accomplish that task. In other words develop narrow “verticals” within your software product and then move on and develop additional functionality, once the lessons have been learned many of the unknowns have been worked through.
Software development is best achieved when it is social. When your users become part of your team and you interact with them, get feedback, find out where things need to be improved. Not to mention the social aspects of peer-reviews, pair programming (if that’s up your street), user groups, etc.

To sum up, it was an awesome day, well done to Rachel and her team from Slattery IT. It is refreshing to see how much innovation is happening in Australia in this space. Love to see more events like this.

To sum up, it was an awesome day, well done to Rachel and her team from . It is refreshing to see how much innovation is happening in Australia in this space.

Love to see more events like this.

Elastic IP on Amazon EC2 — Why using a CNAME is better than an A record

2009-10-07T01:00:00Z

I am busy experimenting with some servers on Amazon EC2. A necessary feature of EC2 is the Elastic IP - essentially you “rent” an IP address that is then associated with you, or your account and not a machine instance.

When you request an Elastic IP you get given both an IP address, and a name in the DNS that points to that IP, for example¹.

186.210.34.68 and ec2-186-210-34-68.compute-1.amazonaws.com

That’s all very well and good. However, I want www.myfictitiousdomain.com to point to that IP. I have two options for creating this in my DNS Zone file:

Create an A record pointing to 186.210.34.68, or
Create a CNAME record pointing to
ec2-186-210-34-68.compute-1.amazonaws.com

On immediate inspection, these seem to essentially give the same end result. And for most purposes this will work fine. However there’s another tidbit of valuable information which plays a big part in making this decision: Amazon EC2 instances are assigned by Amazon both an internal and external IP address. External IP addresses provide connectivity to the Internet, whereas internal IP addresses allow instances to communicate with one another. If you create an A record, the name www.myfictitiousdomain.com will always resolve to 186.210.34.68. If you create the CNAME record, and run a ping from outside the EC2 cloud, you get the external IP.However, pinging the same domain name from a machine inside the cloud (or, on the machine itself), returns the internal IP:

external-machine~ $ ping www.myfictitiousdomain.com
PING ec2-186-210-34-68.compute-1.amazonaws.com (186.210.34.68): 56 data bytes

internal-machine~ $ ping www.myfictitiousdomain.com
PING ec2-186-210-34-68.compute-1.amazonaws.com (10.0.0.10): 56 data bytes

Now that can be useful for many reasons, particularly if you are using the custom host name inside the cloud and don’t want it routed externally, or if the machine is not exposed to the outside world at all. For more details, read the article on Using Elastic IP to Identify Internal Instances on Amazon EC2 - it also seems to confirm my findings.

Real IPs and domain names have been changed to protect the innocent. IPs and domain names quoted are fictitious. Any resemblance to an IP or domain name, either living or dead is purely co-incidental↩