Tuesday, May 26, 2009

Offline Browsing in Firefox with Scrapbook

Got a long plane flight or car trip? Have several articles you've been wanting to read, or maybe need some online documentation that's a subset of a big site? The Scrapbook plugin for Firefox lets you access the latter while on the former. It is nearly perfect for assembling an offline reading list or a library of things you want to keep indefinitely. It has many options for capturing various parts of a page (selection, frame, etc) which is handy if you just want to save the main content and not things like ads or navigation menus. I also like the markup features available from a toolbar that appears at the bottom of the window when viewing captured pages.

The online docs cover the full feature set, so I won't repeat those. I do have a few tips for specific use cases that I came across though:
  1. I wanted to capture an article that spanned multiple pages. In theory, ScrapBook has a filter capability that should be available in the In-depth Capture section of the Capture Detail dialog. I couldn't access that capability, so instead I would highlight the page links for the article (you know... the "1 2 3 Next" links that are usually at the top/bottom of a page) and then use the URL Detector in the Capture Multiple URLs option to capture all the links in the selection. I would then save those links to a new folder with the name of the article. It's not perfect since the pages are independent of each other (you can't navigate between them), but it's better than having to manually walk through all the pages and capture them.
  2. While reading captured pages when I didn't have network access, I would often come across links that I hadn't captured, but wanted to mark to grab later when I was back on the net. You can grab the link do this with the Bookmark with Scrapbook option and then Capture Again to pull the content when you are backonline. (Oops - correction the Bookmark with Scrapbook option is not available from the context menu when you right click on a link. I'll have to add that to the list of features suggestions I posted for the author.)
On a related note - while looking for something that provided the capabilities of Scrapbook, I found some other interesting plugins to view the page cache (CacheViewer) and index pages you have visited so you can easily find where you read a certain factoid that you stumbled across, but can't remember where (Breadcrumbs). I'll see how much I end up using those before reviewing them.

Sunday, May 3, 2009

Useful Links for Java Memory Issues

Every once in a while I have some problem with memory usage in Java (usually related to either Eclipse or JBoss running out) and I have to remember various settings or tools for dealing with the problem. Here are some pages that I return to on occasion:

Heap memory and MaxPermSize interaction
JVMStat tool
Open Source Profilers
Random Info
Interesting thread I came across when researching the Groovy eclipse-plugin memory leakl

If you want a good setting for JBoss (and you are limited to 32-bit Java), try:
-Xms128m -Xmx1536m -XX:MaxPermSize=128m

Eclipe Groovy Plugin - decent for scripts, PITA for classes

I have been using the Groovy plugin for Eclipse for about 18 months now. First let me say thanks to the team who has put it together. I can't really complain about any problems since it is a volunteer effort and I haven't volunteered. And over the time I have used the plugin it has gotten some pretty nice improvements, especially for code refactoring and auto-completion. It's debugging capability has always been good (with a few quirks). The fact that I can debug scripts as well as regular classes kept me from switching to NetBeans when the major upgrade of that product came out in November without that feature (hmmm... I see there are some upgrades for NB. Yet another thing to add to my to-do list to check out). Overall I find the plugin perfectly capable when writing scripts, especially in small projects. For writing classes however, especially in a large project or when mixed with Java classes, it's a PITA.

For those that cannot or do not want to move from Eclipse to IDEA or NetBeans, here are a few tips for getting by with the plugin for now:

1) The largest issue is a memory leak. I posted to the groovy user list about it over a year ago. (My explanation of the problem in that post was slightly incorrect. The problem will occur in any project with a lot of classes on the class path, not just one that includes another project.) I think the issue has gotten better in some circumstances, but it still makes it impossible for me to easily integrate groovy classes into my major projects.
Work Around: I have a small "GroovySandbox" project that has the class directory and key required libraries from my main project on its classpath. (Do not include the main project as a dependent project because you will have the exact same memory problem.) I write new scripts and classes in this project and then when they are ready, I copy them into the main project. The memory issue still has an affect, but I can work a full day on groovy files without having to restart eclipse rather than having to restart every 20-30 minutes.

2) Whenever I modify the class path of a project that includes groovy classes (thus triggering a clean build by Eclipse), the groovy class files are wiped with everything else and are not regenerated. I have to go in and touch each groovy class to get it to compile.
Work Around: I now have enough groovy classes that this isn't feasible, so I created an ant target that compiles only the groovy classes and I trigger it from within Eclipse when necessary. Eclipse detects the newly generated class files and the remaining java classes I have that are dependent on the groovy classes finish compiling. (Why do I have to mix groovy and java so much? See #1, above and #3, below. Unless I want to take advantage of groovy syntax features a lot, I stick with Java.)

3. When I open a groovy class in the editor, it often doesn't populate the Outline view. Makes it hard to navigate the file.
Work Around: Touch the file, or add-and-delete a space. This was a pain when using CVS for our SCM since the files were tagged as modified, but since switching to Subversion there hasn't been a problem. I guess Subversion uses something beyond file dates to track mods.

4. When debugging, if I try to step into a class (java or groovy) that is included from another project (which I do frequently since nearly all classes are in the main project due to #1, above), I get an error window saying that the class is part of the Groovy Libraries plugin path and that the path is not modifiable. The screen doesn't give you a button to modify the source lookup path for the directory/jar. (This one is relatively new. It started happening in some update around the beginning of the year.)
Work Around: Go into the project properties->Java Build Path->Libraries and manually set the "Source Attachment" property for the offending directory/jar. The next time you start the debugger, it will let you step in without a problem.