This post isn’t about carpentry, it’s about Apple.

A bad carpenter blames his tools.

A good carpenter blames his tools, but for different reasons.

A bad carpenter will blame his tools uncritically when he can’t achieve the end effect that he desires, because he lacks the skill, the know-how and the wherewithal to produce the desired outcome. His frustration with the tool is borne of inexperience.

A good carpenter blames his tools with a sensibility and criticism not available to an unskilled initiate because he sees the inefficiencies in them, because he can produce the outcome he desires but may have to jump through hoops to get there, he blames the saw for ruining a perfectly good cut because it snagged in the last two inches and he most likely knows why it snagged and how to stop it happening again. His blame is a criticism of the essential qualities of the tool, not the tool itself.

I have frequent conversations with people about carpentry and they often want to know which brand of carpentry tools I prefer, or what particular tools I used to create something. These are people who are not carpenters themselves. They worry about the non-essential details, “Was that a Craftsman hammer you used or a Wilton brand?”

Tear down all barriers to carpentry tools. Give a large collection of extremely high quality carpentry tools to a number of people, running the gamut from utterly inexperienced to highly experienced. There’s no barrier to entry, only the desire to create something.

What do you get?

A whole lot of wood shavings and one or two masterpiece pieces of furniture. Maybe even a few craftsman houses. But only from those experienced enough to create them.

Now put up an artificial barrier, the tools are hard to use, their expensive, and only available to people who are willing to put in years of time and dedication in learning them before they are permitted to make anything.

What do you get?

A very small amount of people willing to commit to creating anything.

Ignoring the economics of production, labour demand and all of the other things, what you have now is a scarcity economy where only the most dedicated will create anything, willing to jump through artificial hoops to produce anything. Only the most well heeled can afford to pay the prices for carpentry.

When I am at parties and gatherings not frequented by game developers, the people I meet and converse with often ask what language I write my games in, as though the choice of C++, or assembler, or Python or even Visual BASIC, i.e. the tools I use, has any bearing on the quality of the work I am capable of producing. I’ve put in the time, I’ve learned my craft, give me the means to production, and whatever the tools at hand, I will produce something.

These people asking the question, whilst interested in what I do, don’t really understand the question they are asking. They are so out of touch with software development and video game production I might as well lie to them because they wouldn’t know any different.

I don’t worry about the brand of pots and pans that a chef friend of mine uses in his restaurant kitchen because whilst I dabble in the culinary arts, what he does and at the level he does it, I cannot even grasp. His years of training and work experience have taught him, in a way akin to osmosis, about how chemistry works and combines in the human mouth and nose to produce an entire experience. The same goes for me when I write code. I know how all of the parts fit together in the big picture, the individual statements in a function or the functions in a module are immaterial to the process of writing software, most of the time.

When Steve Jobs states that applications or games written in anything but Objective-C or C++ produces crap, it only shows just how out of touch he actually is with the whole world of software development.

It makes me cringe to hear it, that someone purportedly so tech savvy could be so ignorant. Put him in the same category of people at the party wondering if I use C++ to write my games. The answer is “No, I use whatever gets the job done. The tool is irrelevant.”

If the questioner, and Steve Jobs, knew anything about game development and modern software development, he’d know that very little of the actual game is written in C++ or Obective-C these days, just as very little of an operating system is written in assembly language anymore. The engine of the software, yes, C++ or some other arcane language. The rest is script, such as Lua, or a variation JavaScript or some other higher level scripting language, coupled with XML and other ancillary data created by people who wouldn’t know how to write a C++ functor if their lives depended on it.

The problem doesn’t stem from the tool. The problem begins with the easy access by inexperienced carpenters banging ugly holes in the wall with a sledgehammer or making off-square cuts because they haven’t yet learnt their trade. They’re jumping in feet first, creating bad applications and games in whatever tools at hand, not because the tools that they use are bad, but because the barriers to entry of acquiring those tools are low and the barrier to putting it out there in front of the public even lower.

When the tools are easy to use, people will create, even if they create utter rubbish. When the tools are hard, sometimes artificially so and sometimes because the maker of the tool was not particularly clever and sometimes because the maker of the tool was too damn clever, the craftsman will often spend years honing his skills before he produces anything worthwhile and worthy of charging for or that people are willing to pay for.

We’re not seeing bad work from bad tools, we’re seeing bad work from bad workmanship. Putting in an artificial barrier such as only creating in C++ or Obective-C isn’t going to stop this because artificial barriers never succeed.

Disclaimer: I do not condone stealing software (creators have got to eat), I figured that in this case, it was fair use and I was grateful to a friend for pointing me in the right direction.

Last week I was able to download a torrent of thousands of iPhone and iPad games. Many more than I needed for my sample. After removing duplicates, i.e. the iPad release and the iPhone release of the same game, and also removing all games prior to August 2008. After a few hours of tinkering with Perl I had a script that could scan each of the apps and look for sequences of bytes that would identify what software was used to produce the game.

Technology Used	Number of Games	Percentage of Games
Pure C++ or Objective-C	789	26.3%
Unity	255	8.5%
Flash, Titanium, etc	570	19.0%
C++/Objective-C with Lua/Python/Javascript/other scripting langauge	726	24.2%
Non-C++/Objective-C framework, i.e. I don’t know what it is, but it’s not C++	660	22.0%
Total Games Sampled	3000

Many of the games that are not pure C++ or Objective-C have been huge hits, selling many tens of thousands of copies. These aren’t exceptions to the rule, they are the norm. Games that I consider to be total dross that couldn’t have taken more than a few weeks are coded up in Objective-C or C++ and nothing else. Games that are top ten hits created in Flash or in Lua on top of a usually quite small C++ game engine.

Need For Speed Shift? Pure C++? Nope.

Mirror’s Edge? Pure C++? Nope.

Baseball Superstars 2010? Pure C++? Not even close.

Civ Revolutions? Pure C++? Don’t make me laugh.

Monkey Island 2? Pure C++? In your dreams.

I have sat on the fence about writing this post for a long time, ever since the 3.3.1 debacle.

Frankly, this entire Apple broohaha is just sabre rattling on their part. If Apple really wanted to fix it, they would create a more stringent submission process that actually tested for things like quality and playability, much like SONY or Microsoft or Nintendo do on their platforms.

But of course, they don’t, and they won’t, because having a quarter of a million applications in your online store gives you a certain buzz when comparing the size of your wang against everybody else’s.

Share this post with others

Posted in Articles, Games Industry, Software Development | No Comments »

I have been trying, unsuccessfully, for two days to download the latest iPhone SDK and XCode IDE from the Apple Developer Center with absolutely no luck.

I’ve recently moved in to a new house and the DSL connection we have, slow at the best of times, flakes out several dozen times per day. Connectivity problems aside, there had to be a way of reliably downloading large files from Apple’s Developer Center without using Firefox or Internet Explorer because neither of them would resume a failed download. Unfortunately, after having also messed about with a few different download managers, none them would continue a broken download either.

What to try next?

How about good old fashioned WGET?

WGET, originally for UNIX, and available as part of the GNUWin32 project for Windows, is an absolutely fantastic command line tool. WGET lets you retrieve web pages and files from both web servers and ftp servers anywhere on the internet. It’s robust, flexible, versatile, reliable and is a really handy tool to have in your tool box.

Back to the problem of reliably downloading XCode and the iPhone SDK, a two gigabyte disc image which means plenty of chances for crapping out before the download completes.

Apple’s Developer Center requires that you login, which means session state, and that is going to be in the form of a cookie. That’s easy then, we just need to get access to that cookie. One twist though, and I found this out after a little messing about is that when you download the iPhone SDK, or in fact any kind of secured download, it gives you another cookie that is valid for that download.

The job is to get those cookies out of Firefox, or whatever other web browser you use, and into a format suitable for WGET.

I will detail how to export your cookies in a while, but the first thing you have to do is get the cookies from Apple.

Load up Firefox or Internet Explorer , login to the Apple Developer Center website at http://developer.apple.com, then navigate to the file you want to download, in this case, XCode 3.2.3 with the iPhone 4 SDK.

 

The URL for that particular file is https://developer.apple.com/mac/scripts/downloader.php?path=/iphone/iphone_sdk_4__final/xcode_3.2.3_and_iphone_sdk_4__final.dmg.

Make sure you click to download the file via your web browser. That step is very important. After a few seconds of file transfer you can terminate the download.

The reason for this is that you need the download authorization cookie as well as the website user login cookie that are supplied. If you do not do this download and terminate step, you won’t get the proper cookies.

Instructions to Export Cookies from Firefox

The version of Firefox that I am running stores the cookies in a SQLite database, not exactly human readable.

Firefox add-ons to the rescue!

I am currently running Firefox 3.6.4 so I used the Cookie Exporter 1.5 add-on to export my cookies in to a cookies.txt file that WGET can make use of.

Assuming you have Firefox open and are logged in to the Apple Developer Center.

Step #1

Install Cookie Exporter 1.5 or similar add-on if you do not already have a cookie exporter add-on available.

Step #2

Click Export Cookies from the Tools menu

Step #3

Browse to the location where you want to export your cookies and click Save. I put mine in C:\temp.

 

Instructions to Export Cookies from Internet Explorer

Assuming you have Internet Explorer open and are logged in to the Apple Developer Center.

Step #1

Click Import and Export…

Step #2

Click “Export to a file” and then click “Next”

Step #3

Click “Cookies” and then click “Next”

Step #4

Browse to the location where you want to export your cookies to and click next.

I saved my cookies.txt file in to C:\temp which is also where I will be downloading the iPhone SDK to.

If you are on Windows, and use Firefox, it may be easier, if you don’t want the hassle of installing an additional add-on to login in to the Apple Developer Center via Internet Explorer. Click the download link you want, and then export your cookies directly from Internet Explorer. It achieves the same result.

Once the cookies are exported in to a cookies.txt file, right click on the link and select “Copy Link Location.”

Right click “Copy Link Location” in Firefox to copy the URL location.

That puts the URL to the file on the clipboard and can be pasted into a command window at the appropriate time.

Okay, I’ve got the cookies, I’ve got the URL of the file. Time to open a command window and navigate to where the location where the cookies.txt file was saved.

Once that’s done, issue the following WGET command: WGET –server-response –continue –no-check-certificate –load-cookies=cookies.txt https://developer.apple.com/mac/scripts/downloader.php?path=/iphone/iphone_sdk_4__final/xcode_3.2.3_and_iphone_sdk_4__final.dmg

The full URL of the file to download is on the clipboard by now, if you have been following along, and so you can just paste it the URL in to the command prompt window.

Paste the download link in to the command prompt window.

The WGET Options Explained

Continue: Should you need to terminate the download for any reason, such as a reboot, or closing the command prompt, you can continue downloading where you left by using the –continue option.

No-Check-Certificate: Apple appears to use a self-signed certificate on their Developer website. This means that when WGET goes to check the certificate authority, it throws out an error because WGET cannot verify authenticity. The certificate in this case is not used to prove that Apple is Apple, but to enable a secure connection between your computer and the Apple Developer server. A self-signed certificate is nothing to concern yourself with in this case, your data transfer, including user-name and password are all encrypted between your computer and Apple’s servers.

Load-Cookies: The cookies we saved from our browser session need to be loaded up by WGET, this option allows that to happen. Some older WGET clients will require that the equals sign between –load-cookies and the filename be omitted, be aware of that.

Server-Response: The reason to use the “–server-response” option is to debug the transfer when something goes wrong. With this option you can figure out what the server is trying to tell you. Perhaps a 403 Forbidden error, in which case, make sure you logged in and clicked at least once on the download you want. Perhaps you are getting a 404 Page Not Found, in which case, check to make sure you entered the URL of the file correctly.

The last parameter that begins https://developer.apple.com is the actual URL of the file to download. Again, you can paste that in by copying the download link from your browser.

What You Should See If Everything Went Right

If everything is working correctly, you should see something like the following:

In that screenshot of the command prompt window, I issued the WGET command and relevant options, and WGET has begun the download of the latest version of XCode and the iPhone 4 SDK. I also threw in the option to limit the download rate to just five kilobytes a second so that it does not affect anybody else trying to use the internet connection.

What To Do When Things Go Wrong

When you first attempt the download, you may get a failure, just a few kilobytes of downloaded of binary data, and nothing more. If that’s the case, don’t worry, it’s one of two things. In my case it was an old version of WGET.

Firstly, simplest thing to check, you do not have the necessary cookies, in which case, start from the top. You can verify you have the correct cookies by looking in the cookies.txt file for the string ADCDownloadAuth. This is the cookie that Apple Developer Center sends you when you request a download from them.

You can easily search the cookies file by issuing the following command at the command prompt: find “ADCDownloadAuth” cookies.txt

Find the relevant cookie

Second thing to check: You might be like me and have a WGET client that just cannot handle a two gigabyte download. On my workstation I confusingly have two WGET clients, both by GNU. I have version 1.8.2 and version 1.11.4. I have to keep the older version around for a particular application that I am developing for a website that requires a specific version of the WGET client. Unfortunately in my case version 1.8.2 and version 1.11.4 were both on the path, but it found the older version first and decided to execute that.

You can find out which version of WGET you have installed, if any, by issuing the following command at the command prompt:

WGET –version

Make sure you are running an up to date version of WGET otherwise you may not be able to download properly.

These instructions work equally well if you are on a Mac or Linux, you just need to export the cookies from your browser by whatever means you use.

The great thing about using WGET for a big download like this is that the utility will just keep plugging away in the background, until the operation has completed, no matter how many times you have to cancel and continue the download.

If you have both CURL and WGET installed, you can also do the login and download directly from the command line without having to use your browser at all. Just three CURL commands followed by WGET. I’ll leave that solution as an exercise for the reader.

Share this post with others

Posted in Articles, Software Development | No Comments »

At the recent BayCon Science Fiction & Fantasy convention held in San Mateo California I had the pleasure of being moderator on several panels, one of these, which took place on Sunday afternoon, was "The Top Ten Gadgets That Changed The World."

I captured notes on my laptop and recorded audio with my Olympus DS-40 voice recorder. I apologise but the batteries ran down on my DS-40 ran down about 10 minutes before the end of the panel so we are missing the final debate

The debate was lively and at times, loud with full audience participation.

The notes below are direct from the ones I took at the panel with no editing, so it includes spelling mistakes and poor grammar.

If you want to sweat about your typing and spelling, try writing live on to a video display projected in front of 200 people whilst holding down a conversation too.

Download the audio of the panel. (22.6MB)

Philip Gust – CEO of software co. Inventor/Gadgeteer
Lee Felsenstein – Designer of lost computers.
Jay Freeman – Scientist and player
Justin Lloyd (moderator) – video game developer.

The "aye, "no" and "on the fence" at the end of each entry were added in the last few minutes using a democratic process of getting the audience to shout out whether they thought the gadget was worthy of being in the top ten list. Unfortunately we ran out of time to actually sort the list into a top ten.

1. Transistor – aye (Jay Freeman)
2. Wright Flyer – aye (Jay Freeman)
3. Apple II – on the fence (Jay Freeman)
4. Portable Phone – yes (Jay Freeman)
5. AK47 – on the fence (Jay Freeman)
6. Credit Card – no (Jay Freeman)
7. Television – yes
8. Movies -on the fence
9. Model T – yes
10. Meteorological Satellites – yes
11. Liquid Fueled Rocket Motor – on the fence (Jay Freeman)
12. Flip-flop – on the fence (Lee Felsenstein)
13. Cell phone/Mobile Phone – yes (Justin Lloyd/Lee Felsenstein)
14. Bloody PC – on the fence (Lee Felsenstein)
15. Raster Scan CRT – huh? (Lee Felsenstein)
16. Electronic Hand Calculator yes (Philip Gust)
17. VCR/Tivo – yes (Philip Gust)
18. Answering Machine – on the fence (Philip Gust)
19. Car Radio – no (Philip Gust)
20. Univac 1 – no (Philip Gust)
21. GPS – yes (Philip Gust)
22. GPS – yes (Justin Lloyd)
23. iPod – no (Justin Lloyd)
24. Air Conditioner – yes (Justin Lloyd)
25. Candidate- "Aluminium based anti-perspirant", aerosal can – on the fence
26. Candidate – photocopier – yes
27. Candidate – Post-It notes on the fence
28. Candidate – RADAR – yes
29. Candidate – Search engine "Altavista" – no
30. Candidate – White out/Tippex/Liquid paper – no
31. Candidate – Super glue – no

Lee Felsenstein – What is a classic design?
Where is the gee whiz factor?

Definition of PC/Univac/Apple II

Candidate – Scanning Tunneling Microscope, precursor to molecular microscope – on the fence
Candidate – Apollo programme – no
Candidate – Atomic bomb – yes

Is a transistor a gadget? But the transistor radio?
Pentode tube – huh
Candidate – Heterodyne Receiver – on the fence

Model T – First breakout automobile product, like the iPod.
Car Radio – made family road trips practical and tolerable, radio was their entertainment, larger captive advertising audience.
Liquid Fueled Rocket Motor – It lead to the Apollo programme.
GPS – changing the future, guided bombs, UAV, cell phone location spam

Candidate – Microwave oven, LCD, LED – yes
Candidate – Nylons, synthetic fabrics, "ropes" – on the fence
Candidate – LASER – yes
Explanation – AK47 – enabling tech for revolution

Is 100 years enough?
Candidate – Portable PC – yes
Candidate – CNC – yes
Candidate – Carbonless copy paper – no
Candidate – Autonomous and industrial robots – yes

What will be the future gadgets?
Digital paper
Batteries that never discharge

Audio recording & notes will be available at http://www.otakunozoku.com/

Suggestions
What ten gadgets changed the fannish world?
What are the best ten gadgets of all time?

Download the audio of the panel. (22.6MB)

Share this post with others

Posted in Articles, Ideas, Personal News | 1 Comment »