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.
Revised editions of two significant programming books are due this May.
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:
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.
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.
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.
“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.
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.
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:
~/Projectsdirectory. In the Finder I typically move the tar file to
~/Projectsand then double-click the tar. The Mac OS X 10.5 Archive Utility will handle the file.
git-1.6.1.tar.bz2will be unpacked into a directory named
tar xjf git-1.6.1.tar.bz2
/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
sudo mkdir /usr/local/git-1.6.1
sudo mkdir /usr/local/git-1.6.1/man
sudo ln -s /usr/local/git-1.6.1 /usr/local/git
/usr/local/gitshould always link to the release you currently want to use.
/usr/local/git/binto your PATH.
/usr/local/git/manto your MANPATH.
sudo make install
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
Resources for Git on Mac OS X:
I don’t build from scratch on Windows. I’m currently trying out the msysgit package from Google Code.
1The bzip2 compression is more efficient than the older gzip compression.
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.
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.’1
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.