constructive nonconformist

Party Like It's 1993

Revised editions of two significant programming books are due this May.

• The C++ Programming Language, 4th Edition (updated for C++11)


• Advanced Programming in the UNIX Environment, 3rd Edition

Takes me back to 1993 — in a good way.

Mac OS X Preview Hang on Mac OS X Lion and Mountain Lion Solved by Disabling AutoTermination

Mac OS X Lion introduced iOS style automatic termination for applications. If an application is running for a long period but is inactive, the operating system will automatically terminate, close and quit, the application. With auto resume it can be invisible to the user that the application was ever terminated.

I prefer the built-in Preview app to Adobe Reader and I have the OS configured to open PDFs in Preview.

After upgrading to Lion, Preview would sometimes hang with a spinning cursor. This would happen when I already had a document open in Preview and I clicked a PDF link in Safari.

If Preview is quit it seems to AutoResume without any issue. So the next suspect to investigate was AutoTerminate.

Here’s how to disable auto terminate for Preview:

1. Open Terminal


2. Run the following command:
   defaults write com.Apple.Preview NSDisableAutomaticTermination -bool yes

I commonly have Preview open and running usually with software development related material. With AutoTerminate disabled I no longer get the spinning cursor hang.

Update on the BlackBerry and CalDav MobileMe calendars issues

Solved this problem for my wife: BlackBerry Desktop Software for Mac OS X does not support CalDav MobileMe calendars. She no longer uses a BlackBerry.

Me? I’m planning on resolving this issue for myself by dumping my BlackBerry in the late June/early July time frame.

BlackBerry Support has only been able to tell me that they don’t know when or if CalDav MobileMe calendars will be supported, but keep checking for updates. Great.

I’ll give the Support people the benefit of the doubt on this issue and assume they truly know nothing. But my guess, and this is truly complete speculation, is that BlackBerry will never support CalDav MobileMe calendars. RIM is busy circling the wagons in the corporate enterprise market which is Windows-centric. An issue for individual consumers on a non-Windows OS just isn’t going to get funded.

BlackBerry Desktop Software for Mac OS X does not support CalDav MobileMe calendars

Apple had CalDav based calendars for MobileMe and iCal in public beta in July and out of beta in October. The CalDav calendars are wonderful because my wife and I can have a shared calendar.

As of December: Known synchronization issues between BlackBerry Desktop Software and the new MobileMe calendar from Apple

“This is a previously reported issue that is being investigated by our development team. No resolution time frame is currently available.”

The work-around is to create a local calendar that the BlackBerry Desktop Software can sync with. If an event is created on the BlackBerry, after syncing to iCal the calendar for the event can be changed to shift the event from the local calendar to a CalDav calendar.

rentzsch.tumblr.com: [C4 release];

I believed the best way to move software forward was to inform Apple programmers about better ways to build software — to infect the best top-downer minds with fertile discontent.

My hope was that developers would care primarily about user experience yet also be passionate about utilizing lingual and tooling advances. C4 was my attempt to push on the Apple community from the bottom-up.

With that background in place, I hope you can understand how Section 3.3.1 has broken my spirit.

— Jonathan ‘Wolf’ Rentzsch
rentzsch.tumblr.com: [C4 release];

I don’t know Jonathan Rentzsch. I never attended C4. I don’t have any stake in the iPhone application development space. I understand it is easy to armchair quarterback. I understand he may not be being figurative when he says his spirit is broken.

But will all respect, ending C4 over Section 3.3.1 seems odd.

It would seem that the mission of C4, as he describes it in his post, is needed more than ever.

links for 2010-02-16

• Xcode 101: Installing the 3.2 SDK alongside the 3.1.1 SDK

  (tags: apple macosx xcode)

Installing Git

This is a ‘note to self’ about Git and how to build and install on Mac OS X and how to install on Windows.

Building and Installing Git on Mac OS X (specifically 10.5 Leopard)

I haven’t been won over by Fink or MacPorts. There is the git-osx-installer project on Google Code which provides a DMG. But I’m comfortable with Makefiles and I have the Developer tools installed, so I build and install from the source.

Here are the steps I follow:

1. Get the ‘latest stable GIT release’ from http://git-scm.com/. As of this post the latest stable Git release was v1.6.1. Get the tar.bz2¹ file, for example: git-1.6.1.tar.bz2.
2. Unpack the tar file. I have a ~/Projects directory. In the Finder I typically move the tar file to ~/Projects and then double-click the tar. The Mac OS X 10.5 Archive Utility will handle the file. git-1.6.1.tar.bz2 will be unpacked into a directory named git-1.6.1.
   
   From the command line the tar command would be something like:
   tar xjf git-1.6.1.tar.bz2
3. I want to install Git to /usr/local. I also want to be able to easily mange new Git installs and Git has lots of parts so I create a subdirectory for Git in /usr/local.
   1. Create a directory in /usr/local for the Git release, for example:
      sudo mkdir /usr/local/git-1.6.1
   2. Create a subdirectory for the Git release man pages, for example:
      sudo mkdir /usr/local/git-1.6.1/man
   3. If this is the first install of Git on the machine, create a symbolic link to the release directory:
      sudo ln -s /usr/local/git-1.6.1 /usr/local/git
      
      Going forward, /usr/local/git should always link to the release you currently want to use.
   4. Add /usr/local/git/bin to your PATH.
   5. Add /usr/local/git/man to your MANPATH.
   
   
4. Change directory into the unpacked source code, for example:
   cd ~/Project/git-1.6.1
5. Configure the build. Set the prefix to the directory the release should be installed into. For example:
   make configure
./configure --prefix=/usr/local/git-1.6.1
6. Build Git.
   make
7. Install Git.
   sudo make install
8. Don’t bother building the man pages. Get the matching man pages tar from http://kernel.org/pub/software/scm/git/.
   

   For example: git-manpages-1.6.1.tar.bz2.
   

   From the command line, unpack the tar into the install location, for example:
   sudo tar xjf git-manpages-1.6.1.tar.bz2 -C /usr/local/git-1.6.1/man

9. If needed, update the /usr/local/git symbolic link.

Resources for Git on Mac OS X:

Hivelogic - Installing Git on Snow Leopard
Compiling and installing git on Mac OS X - Guides - GitHub
Compiling Git for Mac OS X Leopard (10.5)
A Funkaoshi Production :: Building Git on Mac OS X

Windows

I don’t build from scratch on Windows. I’m currently trying out the msysgit package from Google Code.

¹The bzip2 compression is more efficient than the older gzip compression.

"Photoshop will now exit"

I realized tonight that Photoshop 7.0.1 doesn’t run under Mac OS X 10.5 Leopard.

Officially Adobe doesn’t support Photoshop 7.0 anymore and there will be no updates for Leopard compatibility. The consensus on various forums is that there is no work-around.

Link: Photoshop 7.0 - FixYa

I upgraded to Leopard a while ago and I’m running an old version of Photoshop, so clearly I’m not a heavy user. But I was a bit dismayed — for a moment. And then I thought “Why do I need Photoshop?”

My use of Photoshop was largely oriented toward preparing images for the web. There was a time when Photoshop was the leader among a very small number of applications that could do that job well. That’s no longer the case.

I will not be going back to Tiger for the sake of any one application. I will not be buying an upgrade from Adobe. I will be freeing up some space on my hard drive. Photoshop has left the building.

Mac OS X: Setting Environment Variables for User Processes

Link: Technical Q&A QA1067: Setting environment variables for user processes.

Coda Sites

Of Coda some have said essentially “Cool app. Too bad I can’t use it.” The reasons are varied but can mostly be generalized to ‘Coda doesn’t fit the work I do and/or doesn’t fit the way that I do my work.’¹

Panic shouldn’t try to change Coda to please everyone. Doing so would ruin the product. It’s fine and good for the product vision to remain idiosyncratic and for some people to ‘not get it.’

I have no inside knowledge of Panic’s vision for Coda and I have no expectation of having any influence but that’s not going to stop me from sharing a few ideas about Coda.

I have issues with the way Coda manages sites.

Clearly Panic created Coda in part to scratch their own itch. Apparently their custom is to directly edit their live sites. A Coda ‘site’ is modeled on the idea of a production web server and a local copy of the files. With the v1.0.1 update, support was added for a local development web server.

I need a different ‘site’ model. When I build a website it’s generally for a client. In addition to development and production, I need a third server: a ‘user acceptance testing’ web server. Sometimes I need a fourth server for prototyping. (Of course I don’t need separate physical servers. Prototyping, development, and testing could be different directories and/or ports on one server.)

For Coda the live site is primary and there is one set of content for the site. For me the set of content is primary and there can be multiple deployments of the content.

According to Cabel’s blog in Coda’s first week of release subversion integration was a top request. If version control is used effectively the ‘authority’ for a web site’s content should be the version control repository, not the live site. Deployments to the live site should be based on a branch or a label in the version control system. Direct updates to the live site should, under normal circumstances, be avoided.

Site information appears to be stored as opaque data in the Coda preferences file. This means that site information is tied to Coda for a specific user account on a specific machine. Working on different machines or working with others as a team requires redundant copies of the site information.

A project file would allow for sharing and versioning site information. But I’m guessing Panic purposefully avoided the concept of a project file. Although others have referred to Coda as an IDE, Panic has not. Panic may envision Coda as something much less ‘industrial’.

It will be interesting to see how Coda evolves. (Here’s an idea: Add an embedded web server.) I wish Panic success with Coda but I have to say as of v1.01: Cool app. But I can’t use it.

¹ Some posts about Coda:
Link: Clickable Bliss — Coda Thoughts.
Link: Panic’s Coda is Not My Style | NSLog();.
Link: Michael Tsai - Blog - Coda 1.0.