Since I moved to OSX, one ugly and unstable tool that I had to live with, was the Cisco VPN client. Being completely unhappy with this Cisco  little app, I was always looking for an alternative and few days ago I found it: SHIMO.

Shimo has many reasons to be the best choice for OSX, and I'll just quote few:

• ... full Cisco compatibility
• ... saves passwords in your keychain
• ... automatic (re-)connect on wakeup, network-changes, etc
• ... global shortcuts for fast connect/disconnect
• ... stable and well integrated with the OSX. Better than the Cisco VPN client
• ... statistics screen
  

And the feature I also love: it can be easily integrate with growl for notifications.

If you already have a CiscoVPN connection defined, SHIMO will import your previous settings and use them right away.

I love it!


Goodbye Cisco :)

A lot of times I had to do acrobatics to be able to display the contents of a UNIX folder as a tree.  Well, no more!

Looking for using the ls command in various combinations I found this command gem:

ls -R | grep ":$" | sed -e 's/:$//' -e 's/[^-][^\/]*\//--/g' -e 's/^/   /' -e 's/-/|/'

So for a folder where the standard: ls webapps/hello/ will display this:

WEB-INF   actions   content   pages     public    templates

The new command trick:  ls -R webapps/hello/ | grep ":$" | sed -e 's/:$//' -e 's/[^-][^\/]*\//--/g' -e 's/^/   /' -e 's/-/|/', will display:

   |---/WEB-INF
   |-----classes
   |---/actions
   |---/content
   |---/pages
   |---/public
   |-----styles
   |---/templates

Neat, eh?

There is also a nice script wrapper for the above command, follow this link for more.

 

In my recent blog entry I was contemplating adding Wiki support to JPublish. It is available now :)

I decided to add Textile support through JTextile. This is possible now very easy due to the improved support of the new JPublish Component API which I plan to improve even more. RADEOX implementation will follow.

I can say that I am already addicted to this new feature, especially that you can create your pages with smart editors, such as: TextMate, who already understands the Textile syntax and the bundle supplied with TextMate is very valuable.

Let's see how easy is to use the Textile support in JPublish.

1. download and build our latest JPublish version from our new SVN repository.
2. if you want to go straight to the demo app, check the folder components/jptextile from your JPublish folder and build the jptextile web application (ant dist), deploy the distribution into your preferred Servlet container and start playing with Textile, skip the rest.
3. in your jpublish.xml configuration file from an existing application, add the following:

    <component-manager>
        <components>
            <component id="jpTextile" classname="ca.flop.jpublish.wiki.JPTextileComponent">
                <repository name="fs_repository"/>
            </component>
        </components>
    </component-manager>

4. use Textile syntax in any page you need, through this simple component support:  $components.jpTextile.renderText("h1. Hi!"), if you want to transform a string containing Textile sytax, or include and transform an external file containing a larger text: $components.jpTextile.renderPath("text.textile") , where the "text.textile" is a text file from your JPublish repository you mentioned in the jpublish.xml file; fs_repository, respectively.

I hope you'll find this support handy, and if yes, please send us your feedback to our user-group list.

Cheers,
-florin

After a couple of intense days of code cleaning, tweaking, testing and some more development (long week-end here in Canada), I committed the newest version of our AJAX-DWR and the TagCloud support for JPublish. You can grab the source from our new repository.

I am also thinking to implement some Wiki support for our ViewRenderer, so you could for example use Wiki syntax through RADEOX for pages where you don't really need the template logic of Velocity or FreeMarker. My favorite Wiki syntax is Textile and Markdown, but I am only familiar with the RADEOX implementation for now. Anyway, one of these will be supported by JPublish, and should be relatively easy to implement, so stay tuned; JPublish just started to be more interesting :)

Have a nice long week-end,
-florin

PS
Hmm, I just found a Markdown implementation in Java, MarkdownJ ... niceeeeee :)

Some time ago, when I was selecting a cache for JPublish, I was looking at two of the best cache solutions of that time: Ehcache and Whirlycache.

Both of them are good cache implementations, actually I have to look again at the recent version of Whirlycache, but Ehcache is the best option for what we need inside JPublish. While WhirlyCache is a memory only cache, Ehcache shines with many options and a nice palette of settings.

I am happy to see that once again Ehcache proved to be the best option for us, read more...

With JPublish is very easy to choose between different cache implementations. In jpublish.xml, the main configuration file for a JPublish application, the cache is defined as follows:

 <cache-manager>
  <jpublish.cache.provider>
    <implementation name="default" class="org.jpublish.util.JPublishCacheImpl"/>
  </jpublish.cache.provider>
 </cache-manager>


The above setting is using EHCache (our default cache implementation), but if you want to switch to WhirlyCache then you can change the implementation to:
  <implementation name="default" class="org.jpublish.util.JPublishWhirlyCacheImpl"/>

Feel free to experiment and let us know your opinion.

Cheers,

This is just a small update to let you know that a bunch of us will revive JPublish and put this trusty framework back where it belongs: in the hand of those who want to have the job done :)

Right now we're in the midst of cleaning the docs, organizing the new space, cleaning the examples and the new code, and obviously: bringing new values to JPublish and teaching this framework new tricks :)

You are all invited to join us and send your feedback.

The code can be found here:
http://code.google.com/p/jpublish/

The code, based on JPublish 2.x series, is stable and functional.

Best regards,

I spent a few good hours in the last days migrating my old blog to Pebble 2.0.1. As described in my previous post, I encountered a couple of issues but with Simon's help I was able to fix them all; none of them related to the code itself. Thanks again Simon!

The paint was still wet on my new and shiny Pebble :) when Simon launched the newest version of Pebble: 2.1-RC1.

I decided to migrate again and bite the bullet, and guess what? Two hours after and I am up and running with no problems, wow!

What else can I say?

Found my Pebble :)

All mysteries solved and all my entries are all back again, no glitches and no mysterious invisible articles.

As instructed by Simon, simply removing the DATA_DIRECTORY/blogs/default/pebble.version  file re-triggered the auto-upgrade utils and restored my entire article set.

Welcome back Pebble :)

Guess what? ... is time to upgrade and bite the bullet, let's see :)

---

PAST TENSE:

I still don't get it :(

I was spoiled with a very robust application in the past, Peeble 1.9 being solid as a rock ... Pebble 2 is also supposed to be great and better, but during the recent migration from my old and trusty Pebble 1.9, something mysterious happened.

All my articles from 2006 are not showing up (the files are there you can still see them in the search results), the main links for the RSS and ATOM feeds are broken, God knows what else?!

Thanks to the support I received from Simon, the ATOM and the RSS feeds are restored now, yay :) He correctly pointed me to a Pebble on Jetty mail list post which shows you how to fix this type of error if encountered. The full link is here, thank you Simon!

All the files I can't see (throwing 404) are in place, the file permissions are sound .. I don't know what else I should check..

I'll continue to browse the Pebble mailing list but so far I am out of luck :( ... Debugging?? I guess :'(

Please let me know if you are aware of anything that may cause something similar.