My Open Source Debugging talk that I gave at JavaZone, Oslo, Norway last September is online and can be watched in Flash format or downloaded as an M4V file. If you were not able to catch this talk at either this venue, or any of the many NoFluffJustStuff.com stops that I gave this talk at last year, give it a try and let me know what you think of it.
When restoring from a backup, depending on the Mac-specific intelligence of your backup solution, or when copying files written by a 10.4 Mac, your Spotlight (Finder) Comments stored in the .DS_Store files might not survive the round trip. You’ll first notice this by the fact that your comments field or column is completely empty for files you know you previously tagged or made comments on.
Tiger and previous editions of Mac OSX store Spotlight comments in the .DS_Store file exclusively. Leopard and Snow Leopard on the other hand, claim to maintain backwards compatibility by storing the Spotlight Comments in both the .DS_Store and the new Extended File Attributes. I question this thinking though, because Mac OSX developer Steve Gehrman of the awesome PathFinder team says that Finder, while it writes both formats, still only reads back the .DS_Store ones. It seems to me that Apple would have changed Finder to read from the newer Extended Attributes as soon as they started writing to those in duplicate.
“On Mac OS X 10.4 Tiger, for example, .DS_Store files also contain the Spotlight comments of all the folder’s files, whereas Mac OS X 10.5 “Leopard” stores this information in Extended file attributes.”
Giving a tip of the hat to the similar-but-not-quite-what-I-wanted script that helped me get enough of the syntax working (using type alias instead of type file was tricky) get my own authored, I give you:
A MacOSXHints article, and the corresponding code
To solve this extended attributes vs. .DS_Store discrepancy, we only need to read (from the extended attributes) and reapply (thereby recreating the .DS_Store) the same comment. The solution is this AppleScript. Just highlight the files needing the treatment in Finder, then execute this script from the AppleScript Editor.
The result is that Finder (which reads only the .DS_Store files) and PathFinder (which only reads the extended attributes) can both now see the Spotlight Comments.
If you would like your Mac to automatically clean up the .DS_Store files it writes out to flash sticks and network drives, check out BlueHarvest, an interesting little utility app that fills this need.
Fonts, fonts, fonts. What’s this obsession? For those of us that share a passion for making presentation materials as comprehensible as possible for our students, sandwiched right between a great story and great delivery is a great font.
Once you’ve installed Microsoft Office, iWork, or Open Office, you’ll find that you’ve been granted a few (or possibly many) extra fonts installed into your operating system. This is a temptation you should approach carefully, just as you would the edge of a cliff. It is truly a time and design precipice you can fall off of into the abyss.
As you gradually approach this list of fonts, if you obsess over design like I do, you’ll let out an “Ooooooo” as if mesmerized by the quantity of selections you could make. A tool would be perfect here. Let me grant your wish with FontDoc for the Mac and WinFontsView for Windows.
Now, you have a tool to whittle that list of massive fonts down to size. Let me give you two facets that will chisel it down even further.
First, use a maximum of two Font Faces per presentation. I’ll allow for three if you make judicious use of a handwriting font.
One font should be interesting and story-relevant. It should mesh well with your photography and choice of color in the slides. I’d suggest you primarily use it for titles, strong statements and short phrases. It adds spice to your presentation. Feel the freedom to have fun with your title fonts. I’ve recently styled a presentation on Hadoop with an African theme. I used the Tribeca font in the title and custom rhinoceroses for the bullet points (yes, I used some bullets).
The second (primary) font should be highly legible. I can’t stress that enough. For the portions of your slide deck that people will need to read (and quickly, so they can return mental focus to you), readability is the critical point. I always suggest sticking with a very legible Sans Serif font, as does Garr Reynolds of Presentation Zen Design.
I don’t always obey this rule of Sans Serif in the body, sometimes to my own peril. Fortunately, local audiences in Denver are kind, and remind me that I need to change it back.
Hello Verdana. Really, I didn’t mean to cheat on you! It was just that Aquiline showed up looking so stylish and I just couldn’t help it.
The short list of Sans Serif fonts that I printed and put across the room is:
I’d suggest you do the same. Also put them up on a projector if you have access to one. Do white font on black. Do black font on white. Notice the affect each font’s nuances have on legibility. Throw up some ranking numbers next to each. That’s precisely what I did. And I asked a few folks to give me their rankings too.
The variant that I (and my scientifically font-polled friends) love the most, is Helvetica Neue. The beautiful part is that it comes preinstalled on many systems these days, but can also be purchased online if you are on a OS or office suite that doesn’t include it.
In the life of a font, you know you’ve arrived when a movie is made about you. Yes, a biographical movie about Helvetica, the font named after Switzerland’s classical name.
Lest you think this is a factor of Steve Jobs and his Apple design shop, I’ll let you in on the secret that this predates the personal computer by several decades. Max Miedinger was the designer behind this font all the way back in 1958!
Give any of these Sans Serif fonts a try (but lean towards Helvetica!) in your next presentation and be sure to gather design feedback from your audience. I think you’ll be pleasantly surprised!
Shameless plug: Keep an eye out in 2010 for the Presentation Patterns book from Neal Ford, Matthew McCullough and Nate Schutta for a complete recipe book with easily digestible presentation improvement hors d’oeuvres like this one.
I’m very excited to announce I’ve been selected to present at the Great Indian Developers Summit in Bangalore, India in April. I just found out that my NFJS colleagues, Scott Davis and Venkat Subramaniam will be joining me there as well. It will be great to have familiar faces at this venue and to present to such a distinguished audience.
I’m excited to announce that my latest RefCard for DZone has been released. In a Q&A session with Lyndsey Clevesy, I discuss the card’s focus on helping developers get started with the Google App Engine for Java.
The RefCard is intended to be a jumping off point and provides information about and links to the frameworks that now support GAE as well as external resources to help you dive deep if this new arena of cloud computing. Grab a copy and send me feedback.
A little late night hacking and I was able to get encrypted passwords to work in the Maven SCM plugin with Maven 2.2 based on the prodding of Kurt Tometich, an NFJS attendee, and his JIRA bug# SCM-495. Previously, this encryption feature only worked for Wagon providers (the connectors for uploading artifacts), not for SCM providers, contrary to some blog comments.
It was quite the effort. After a few minutes, I found the code in DefaultMaven.java that performed the decryption. Now, I thought, “just implement a similar call in AbstractScmMojo.java right?” I harbor a bit of angst for the fact that the JIRA isn’t Fisheye-connected to the source code repository, so finding the files changed for a given defect is much harder than it should be.
The Maven Mojo Developer Cookbook did offer a bit of insight (though syntactically off a bit on the container.getLookupRealm()) on how to get a handle to the container and look up the security provider, DefaultSecDispatcher.java.
SecDispatcher sd = null;
try {
sd = (SecDispatcher)container.lookup( SecDispatcher.ROLE, "maven" );
}
There was even the fabled “java.lang.ClassCastException: org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher cannot be cast to org.sonatype.plexus.components.sec.dispatcher.DefaultSecDispatcher” at one point. Oh nuts. Not the classloader scoping issue, please…
The trick on the classloader is that the DefaultSecDispatcher class is available via a dependency to plexus-sec-dispatcher, but also included (repackaged) in the Maven core distribution maven-2.2.0-uber.jar. So the SCM provider project’s dependency on plexus-sec-dispatcher has to be scoped as <provided> for compilation of the maven-scm-plugin.
Lots of learning about the Maven code base occurred. The only interesting finding was how, instead of putting the decryption on the accessor (getter) of password from the settings data structure, it is put in each place it is attempted to be used (e.g. the Wagon “dispatcher”, and now the SCM “dispatcher”). I’ll bring up a refactoring of that with the Maven IRC folks…
The BTrace plugin for VisualVM, a tool that I love to showcase at No Fluff Just Stuff and user group events, has been updated to version 0.2.2. This solves an issue that prevented it from working on a Mac. Be sure to uninstall any prior version from your VisualVM prior to installing 0.2.2 to get the full benefit of the fix.
I’ve been battling getting jmap working properly on a new Mac. I followed the invaluable instructions my NFJS colleague, Ken Sipe, provided for the Rhino engine inclusion. However, I was still encountering an odd issue where I couldn’t get jmap to attach to a Java process.
First, I would start a simple helloworld Java application.
java com.ambientideas.HelloWorldJava Hello Java World!
Then I would get the PID:
jps 11554 HelloWorldJava 11573 Jps
Then I tried to jmap it, but got the following error
jmap -heap 11554 Attaching to process ID 11791, please wait... attach: task_for_pid(11791) failed (5) Error attaching to process: Error attaching to process, or no such process
So I thought, “These memory tools often require root access, so I’ll sudo it.” When I did, I got the following equally cryptic error:
sudo jmap -heap 11791 Attaching to process ID 11791, please wait... Exception in thread main java.lang.RuntimeException: gHotSpotVMTypes was not initialized properly in the remote process; can not continue at sun.jvm.hotspot.HotSpotTypeDataBase.readVMTypes(HotSpotTypeDataBase.java:111) at sun.jvm.hotspot.HotSpotTypeDataBase.&amp;amp;amp;amp;amp;lt;init&amp;amp;amp;amp;amp;gt;(HotSpotTypeDataBase.java:68) at sun.jvm.hotspot.MacOSXTypeDataBase.&amp;amp;amp;amp;amp;lt;init&amp;amp;amp;amp;amp;gt;(MacOSXTypeDataBase.java:35) at sun.jvm.hotspot.bugspot.BugSpotAgent.setupVM(BugSpotAgent.java:560) at sun.jvm.hotspot.bugspot.BugSpotAgent.go(BugSpotAgent.java:481) at sun.jvm.hotspot.bugspot.BugSpotAgent.attach(BugSpotAgent.java:319) at sun.jvm.hotspot.tools.Tool.start(Tool.java:146) at sun.jvm.hotspot.tools.JMap.main(JMap.java:128)
I though, “Hmmmm, this looks a lot like a java version mismatch. Let’s check which java version I’m running.” I had javac compiled the HelloWorld against Java 6, so was expecting a matching java. I made a quick stop into the Java Preferences pane. Yup. Java 6 set as the first-priority choice.
Let’s check the command line too…
java -version java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03-211) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02-83, mixed mode)
Excellent. Just what I expected. Java 6. But a little doubt crept into my mind. What if the sudo’ed invocation were finding a different Java. That didn’t sound plausible, but yet was still worth checking out.
sudo java -version java version 1.5.0_19 Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02-304) Java HotSpot(TM) Client VM (build 1.5.0_19-137, mixed mode, sharing)
Aha! There’s the culprit. So somehow, sudo’ed commands are running Java 5, even though I’ve set a preference for 6 in my profile. I searched the web high and low for a way to specify the Java version for “sudo” specifically, but could find no trace. I even tried the -E flag to maintain the caller’s environment variables, as is possible on Linux distributions. Not implemented on Mac.
I did a quick check of my path and a “which java”. Both ultimately routed to Java 6. I also had JAVA_HOME and JAVA_VERSION set just fine.
set | grep JAVA JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home JAVA_VERSION=1.6 echo $PATH /Applications/Dev/btrace/bin:/opt/local/bin:/opt/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin: /usr/X11/bin:./: /Users/mccm06/scripts:/Applications/Dev/apache-ant/bin: /Applications/Dev/apache-maven/bin
So I turned to harness the wisdom of one of the really smart guys (that uses a Mac) I’m privileged to hang out with in Denver, Fred Jean. Fred said, “Try adding the 1.6 java explicitly to the front of your path rather than letting Java Preferences pane be the sole controller.” I opened up ~/.bash_profile (alternatively you could edit ~/.bash_rc)and slammed in the following:
export PATH=/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Commands:$PATH
I opened a new terminal to pick up the shell changes. Then I started checking if this fixed the issue in reverse order, starting with the sudo:
sudo java -version java version 1.6.0_13 Java(TM) SE Runtime Environment (build 1.6.0_13-b03-211) Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02-83, mixed mode)
Looking good! Now let’s get back to our core goal, jmap.
sudo jmap -heap 5951
Attaching to process ID 5951, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 11.3-b02-83
using parallel threads in the new generation.
using thread-local object allocation.
Concurrent Mark-Sweep GC
Heap Configuration:
MinHeapFreeRatio = 40
MaxHeapFreeRatio = 70
MaxHeapSize = 88080384 (84.0MB)
NewSize = 21757952 (20.75MB)
MaxNewSize = 43581440 (41.5625MB)
OldSize = 64159744 (61.1875MB)
NewRatio = 7
SurvivorRatio = 6
PermSize = 21757952 (20.75MB)
MaxPermSize = 88080384 (84.0MB)
Heap Usage:
New Generation (Eden + 1 Survivor Space):
capacity = 19070976 (18.1875MB)
used = 2351616 (2.24267578125MB)
free = 16719360 (15.94482421875MB)
12.330863402061855% used
Eden Space:
capacity = 16384000 (15.625MB)
used = 2351616 (2.24267578125MB)
free = 14032384 (13.38232421875MB)
14.353125% used
From Space:
capacity = 2686976 (2.5625MB)
used = 0 (0.0MB)
free = 2686976 (2.5625MB)
0.0% used
To Space:
capacity = 2686976 (2.5625MB)
used = 0 (0.0MB)
free = 2686976 (2.5625MB)
0.0% used
concurrent mark-sweep generation:
capacity = 64159744 (61.1875MB)
used = 0 (0.0MB)
free = 64159744 (61.1875MB)
0.0% used
Perm Generation:
capacity = 21757952 (20.75MB)
used = 4716880 (4.4983673095703125MB)
free = 17041072 (16.251632690429688MB)
21.678878600338855% used
Thanks to a combination of Ken Sipe, Fred Jean, a few good guesses and some investigative work, the problem is solved! I’m longwindedly calling this the “java version is different for sudo-initiated processes on Mac” so that the next person Googling for this using similar keywords will hopefully find this tutorial.
As a closing note, I often get asked how I set my environment variables for Java so that Spotlight-launched, Quicksilver-launched, Dock-launched, and Terminal-launched processes can all see the variables (yes, there’s some odd pitfalls about that on a Mac due to the process parents being different). The short answer is to create a text file called /private/etc/launchd.conf and put the following (applicable portions, based on your tool usage) contents in it:
setenv JAVA_VERSION 1.6 # A) Some process-launchers will cause their child to default to 1.5 if using /Library/Java/Home # even if Java Preferences pane says 1.6 at the top # setenv JAVA_HOME /Library/Java/Home # B) Alternate: Force Java 1.6 as Java Home setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home setenv GROOVY_HOME /Applications/Dev/groovy setenv GRAILS_HOME /Applications/Dev/grails setenv NEXUS_HOME /Applications/Dev/nexus/nexus-webapp setenv JRUBY_HOME /Applications/Dev/jruby # Set up Ant setenv ANT_HOME /Applications/Dev/apache-ant setenv ANT_OPTS -Xmx512M # Set up Maven setenv MAVEN_OPTS -Xmx1024M setenv M2_HOME /Applications/Dev/apache-maven
As we have learned the hard way, the only pitfall is that the java version specified in launchd.conf is not honored by sudo’ed java invocations.
Drop me an email if you’ve seen this issue and this tutorial helps you solve it.
In the spirit of automating anything I’ve done more than twice manually, here’s an incredibly simple yet useful little script to recursively search a tree of JARs for a class file. I most often use this against a local Maven repository.
#!/bin/sh
#Example Usages:
# findjars com/ambientideas/SuperWidget
# findjars AnotherWidget
CLASSNAMETOFIND=&quot;$1&quot;
echo &quot;Searching all JARs recursively...&quot;
for eachjar in `find . -iname &quot;*.jar&quot;`
do
#echo &quot;Searching in $eachjar ...&quot;
jar tvf $eachjar | grep $CLASSNAMETOFIND &gt; /dev/null
if [ $? == 0 ]
then
echo &quot;******* Located &quot;$CLASSNAMETOFIND&quot; in $eachjar *******&quot;
fi
done
I’m very pleased to announce that my DZone Maven RefCard was released this week ahead of schedule, and JavaLobby did a little introductory interview for the launch. A handful of folks contributed to the early alpha reviews and I want to acknowledge their inputs: Ken Sipe, Tim O’Brien, Chris Maki, Tim Berglund, and Jason van Zyl.
The timing was great, as I did a Mastering Maven talk at the San Diego Java Users Group (SDJUG) on Tuesday night. A handful of the attendees came with printed copies of the RefCard in hand!
I’m always looking for ways to contribute to the Maven community, and this was by far the most fun I’ve had building materials to promote this unique Convention over Configuration build tool.