Monday, October 29, 2007

Inflector/environment.rb Bug in Rails

Today I needed to get Rails to grok an uncountable noun "media". Easy you think, right? Just add an inflection rule.

So I went to config/environment.rb, uncommented the Inflection example and modified it with my "media" noun, just like this:
Rails::Initializer.run do |config|
  ...
  ...
  ...
  
  Inflector.inflections do |inflect|
    inflect.uncountable %w( media )
  end

  # See Rails::Configuration for more options
end

# Add new mime types for use in respond_to blocks:
# Mime::Type.register "text/richtext", :rtf
# Mime::Type.register "application/x-mobile", :mobile

When I tried to run rails console or tests I saw an error like this:
me@Xbook:testapp$ ./script/console 
Loading development environment.
./script/../config/../config/environment.rb:55:NameError: uninitialized constant Inflector
/opt/local/lib/ruby/gems/1.8/gems/actionpack-1.13.5/lib/action_controller/assertions/selector_assertions.rb:525:NoMethodError: undefined method `camelize' for "top":String
/Users/me3x/Development/DSE/mediacast2/apps/testapp/app/controllers/application.rb:4:NameError: uninitialized constant ActionController::Base

The problem turned out to be in the commented-out rails example in environment.rb. The Inflector.inflections block must not be nested within the Initializer.run block.

This fixes the problem:
Rails::Initializer.run do |config|
  ...
  ...
  ...

  # See Rails::Configuration for more options
end

Inflector.inflections do |inflect|
  inflect.uncountable %w( media )
end

# Add new mime types for use in respond_to blocks:
# Mime::Type.register "text/richtext", :rtf
# Mime::Type.register "application/x-mobile", :mobile

10 Things I Hate About MacOS X Leopard

Almost everyone is hyped about the new release of MacOS. All those great new features. Auweeeeee! I'm a an Apple fan, for now - I'm starting to struggle to justify it. Leopard does have a lot of nice features, but it is missing a lot as well. Considering the delay of the OS, I'm disappointed mainly about these ten things:

  1. JDK6 is missing - WTF Apple!?!?!?
  2. Only read-only support for ZFS, unless you count the developer preview version at ADC
  3. Where is Xray? - The neat DTrace GUI that used to be promoted on Apple.com website a few weeks ago Update: The app is now called Instruments and is part of developer tools. Thanks Ron and Barry for pointing this out to me
  4. JDK6 is missing!!!!! Are you kidding me? Even James Gosling who liked to work on Macs, left Mac for Solaris
  5. MacPorts break here and there - This might not sound like Apple's fault, but considering that Fink and MacPorts are the two main ways to get unix apps installed on Mac, Apple should have cared more about making sure that "things will just work"
  6. Case sensitive FS is still only a second class citizen - I'm sick of all the dupes that iTunes and iPhoto creates, I'll be migrating to case insensitive FS soon
  7. Mac Mini and possibly some other Macs, currently come with "upgrade only" Leopard DVDs - this means that if my Mac goes fubared, I'll have to install Tiger and only then I can install Leopard. Lame!
  8. Why are Spaces one of the major features of Leopard? If I were Steve Jobs, I'd have added it long time ago, or if I added it only now, I'd be quiet and try not to attract too much attention to my past failures
  9. JDK6 is still missing! - Seriously how much longer do we have to wait?!?!?
  10. Why did Apple bothered to include built-in Ruby on Rails? Or should I say broken Ruby on Rails!?!? There was nothing wrong with installing Rails via MacPorts, but the one from Apple is already outdated and when I tried to upgrade it, it broke


MacOS X Leopard is "the most impressive Mac OS X version yet"? It's pretty good but hardly the most impressive without the latest Java.

Wednesday, October 24, 2007

SunWikis Used for San Diego Fire Emergency Coordination

I guess today is one of those days when I can really feel that what we do at wikis.sun.com is of great value - potentially life saving value.

As almost everyone in the world knows there are big fires in San Diego right now - even my family from Slovakia contacted me yesterday to check that my wife's family in San Diego is ok.

Today I noticed that SunWikis are being used for an emergency coordinations at Sun's San Diego campus: http://wikis.sun.com/display/Fires.

I'm glad that we could help the guys in SD and I hope that everyone is fine over there.

Wednesday, October 17, 2007

How to Install Mercurial Support in NetBeans

Getting NetBeans to grok Mercurial is pretty simple when you know all the gotchas. I already got stuck on the installation twice so I decided to turn this into a blog entry, so that I know what to do when I see the problem again. :)

To install Mercurial support in NetBeans, do the following:
  1. Get Mercurial and install it. On Mac you can install it via MacPorts
  2. Get NetBeans 6 and install it
  3. Install the Mercurial plugin via Tools->Plugins->Available Plugins->Mercurial
  4. Restart the IDE
  5. If Versioning->Mercurials in the menu bar is disabled, go to Tools->Options->Miscelanious->Mercurial (on Mac NetBeans->Preferences->Miscelanious->Mercurial) and verify that Mercurial executable path is set up correctly - in my case, since I installed Mercurial via MacPorts, the path should be /opt/local/bin
  6. Restart the IDE

The problem, I encountered already twice, is that if the Mercurial executable path is not set up properly, the Versioning->Mercurials menu item is disabled and NetBeans doesn't give you any hint as to what went wrong. For some reason the path on my Mac is by default pointing to my python directory, which is not correct. Once the path is corrected and the IDE is restarted, everything works as expected.

Apple to Bundle a Wiki Server with MacOS X Leopard Server

Now that Apple finally released information about MacOS X Leopard, I learned that a wiki server will be part of Leopard Server OS.
Mac OS X [Leopard] Server makes it easy for groups to collaborate and communicate through their own wiki-powered intranet website complete with group calendar, blog, and mailing list. Users can create and edit wiki pages, tag and cross-reference material, upload files and images, add comments, and search content with point-and-click ease. (Source)
Pretty interesting, right? I wonder how the wiki server is implemented. I'd expect to see a lot of eye candy, seamless integration with other Apple offerings, but I'm not holding my breath for too many features.

The website doesn't offer many details, but it seems that the wiki server is intended mainly for team collaboration and not for external facing sites like wikis.sun.com. I hope that I'll get more information soon. MacOS Server is not that easy to see around here. No wonder, after all, we have our cool Solaris everywhere. :)

Thursday, October 11, 2007

SunWikis Update: 1000+ Wiki Pages in 10 Weeks!

Today it happened! We made it! Let's go and celebrate! The wikis.sun.com community created altogether more than 1000 unique wiki pages in just 10 weeks since our launch.

Number of users             1144
Number of spaces              94
Number of pages             1006
Number of page revisions    6362
These are just number, but numbers that mean great adoption of this fairly young project.

A big thank you to everyone who planted the seed!

Monday, October 08, 2007

Adding the OpenSearch Descriptors to Confluence or Other WebSites

Earlier today I blogged about the browser search plugins for SunWikis and Confluence.

This is how it all works:

1. Create the descriptor file

Create an OpenSearch descriptor (OSD) file:
<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
   <ShortName>SunWikis</ShortName>
   <Description>SunWikis (wikis.sun.com) Search</Description>
   <InputEncoding>UTF-8</InputEncoding>
   <OutputEncoding>UTF-8</OutputEncoding>
   <Image width="16" height="16" type="image/x-icon">http://wikis.sun.com/favicon.ico</Image>
   <Url type="text/html" method="GET"
template="http://wikis.sun.com/dosearchsite.action?searchQuery.queryString={searchTerms}&searchQuery.spaceKey=conf_global&searchQuery.lastModified="/>
</OpenSearchDescription>
Download

Check out the template attribute - the {searchTerms} will get replaced with the keyword typed into browser's search box. Keep in mind that if your template url contains an "&" character, it needs to be escaped as &amp;, otherwise your XML will not be well formated.

2. Host the descriptor file

Once you have the file ready, host it on your server e.g. as wikis.sun.com/search/wikis-osd.xml

3. Expose the descriptor file

Now you need to let browsers know about the descriptor. You can do this by placing a snippet like this somewhere between the head HTML tags.
<link rel="search" type="application/opensearchdescription+xml"
   title="SunWikis" href="$req.contextPath/search/osd.xml">
In the case of using Confluence, you can do this by editing your template.

The $req.contextPath part is Confluence specific. Replace it with a piece of code that retrieves the context path or replace it with static context path e.g. /myapplication.

4. Bonus: Click-to-install link

Firefox and IE support the installation of search engines via JavaScript, which can be handy if you want to provide an "install" link.

As usual, both browsers use a different approach, and to be fair IE is ahead of Firefox in this one. :-/

Here is a JavaScript I put together based on some resources
function addEngine(srcUrl, osdUrl, faviconUrl, fullName, category)
{
 if ((typeof window.sidebar == "object") && (typeof window.sidebar.addSearchEngine == "function")) /* Firefox */
 {
     window.sidebar.addSearchEngine(
         srcUrl,                                                /* engine URL */
         faviconUrl,                                            /* icon URL */
         fullName,                                              /* engine name */
         category);                                             /* category name */
 } else { /* IE */
    if (window.external.AddSearchProvider) {
       window.external.AddSearchProvider(osdUrl);
    }
 }
}
Download

For some weird reason (legacy?), Firefox uses Apple's Sherlock format for JavaScript installation instead of OpenSearch descriptors. For this reason you need to create a Shrelock descriptor based on your OpenSearch descriptor. Keep in mind that the Shrelock descriptor filename must end with a .src extension.

In my case, my sherlock.src looks like this:
<search
version="1.0"
name="SunWikis"
description="SunWikis (wikis.sun.com) Search"
action="http://wikis.sun.com/dosearchsite.action"
searchForm="http://wikis.sun.com/dosearchsite.action"
queryCharset="UTF-8"
method="GET">

<input name="searchQuery.queryString" user>
<input name="searchQuery.spaceKey" value="conf_global">
<input name="searchQuery.lastModified" value="&">

</search>


It's not perfect because it is deliberately missing the browser element, but it will do. :)

The user attribute is an equivalent of the {searchTerms} variable in OpenSearch specification.

Once the file is created, upload it to your site, e.g. wikis.sun.com/search/sherlock.src.

And now you can create the link on a page that contains the JavaScript code mentioned above:
<a onclick="addEngine('/search/sherlock.src', 
    '/search/osd.xml', '/favicon.ico', 'SunWikis Search', 'Wiki')" 
    href="#">Install
</a>


For more information on this topic check out this blog, but watch out for an XSS hole - the searchTerms variable in the JavaScript snippet in the section "Step 3: The Search" must be url-encoded before it is used later in the script.

Some extra Confluece-specific stuff

You can create OSD files that search in all the spaces of your Confluence instance or in one space only. You can specify this via the Url attribute in the OSD file.
<Url type="text/html" method="GET"
template="http://wikis.sun.com/dosearchsite.action?searchQuery.queryString={searchTerms}&searchQuery.spaceKey=conf_global&searchQuery.lastModified="/>


The searchQuery.spaceKey=conf_global part means - search in all Confluence spaces (with the exception of personal spaces IIRC).

You can replace conf_global with a space key and you get a descriptor for space specific search.

For example, the url for a descriptor for our About space would look like this:
<Url type="text/html" method="GET"
template="http://wikis.sun.com/dosearchsite.action?searchQuery.queryString={searchTerms}&searchQuery.spaceKey=About&searchQuery.lastModified="/>


If you want to get really fancy you can use the power of the Lucene search engine (used in Confluence) to craft all kinds of interesting descriptors. For example this one that searches all the Confluence related spaces (the DOC, DISC, and CONFEXT) at confluence.atlassian.com by specifying the spaces in the earchQuery.queryString parameter instead of the searchQuery.spaceKey, which accepts only one space key.
<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
   <ShortName>Confluence Extras</ShortName>
   <Description>Documentation for the latest version of Confluence and Confluence Community + Confluence Extension Docs</Description>
   <InputEncoding>UTF-8</InputEncoding>
   <OutputEncoding>UTF-8</OutputEncoding>
   <Image width="16" height="16" type="image/x-icon">http://confluence.atlassian.com/favicon.ico</Image>
   <Url type="text/html" method="GET"
           template="http://confluence.atlassian.com/dosearchsite.action?searchQuery.queryString=spacekey%3A%28DOC+OR+DISC+OR+CONFEXT%29+AND+%28{searchTerms}%29&searchQuery.lastModified="/>
</OpenSearchDescription>
Download

This OSD is based on a wicked Lucene search query that looks like this:
spacekey:(DOC OR DISC OR CONFEXT) AND({searchTerms})
You can find out more about Lucene goodies here.

The last word of advice - instead of creating n+1 descriptors, one for each space + one for the search in all the spaces, use a JSP page to dynamically render the OSD file - that's how I implemented it for SunWikis.

Saturday, October 06, 2007

Browser Search Plugins for SunWikis and Confluence

One of the small but useful features of the next release of SunWikis, due some time next week, will be support for Open Search descriptors.

Open Search descriptors (OSD) help browsers (and other clients) to discover ways to search content of a website. If you go to a site that supports OSD and you are using an Open Search enabled browser, the browser will notify you about the possibility of adding the current site's search among the browser's search plugins (Firefox does this by glowing the down arrow in the search box).



Once the search plugin is installed, you can search SunWikis directly from your browser's search box.



While I was at it, I created this descriptor for Confluence documentation located in the DOC wiki space at confluence.atlassian.com and a second descriptor that searches the DOC, DISC (Confluence Community), and CONFEXT (Confluence Extensions) wiki spaces at the same time.

So now I can search SunWikis and Confluence docs with ease:



If you are interested in installing these plugins as well (even before we make them available at wikis.sun.com), click on the links below:

Warning: As for SunWikis, you can install the search plugin now, but once the next SunWikis release is out, you should probably reinstall it just in case we tweak and enhance it.


NameContentClick to Install1Download OSD2
SunWikiswikis.sun.com
all spaces
InstallDownload
Confluenceconfluence.atlassian.com
the DOC space
InstallDownload
Confluence+Extrasconfluence.atlassian.com
the DOC, DISC, and CONFEXT spaces
N/A3Download


Who knows, maybe Atlassian will use my code and officially support these search descriptors on their site - they have my full support.

As for technical details, I plan to write wrote another entry just about how I created and added these descriptors to Confluence.


1 Might or might not work for your browser. Click and sit tight :)
2 The OSD file can be used for an alternative installation method - If you have Firefox and Mac you can place the file into /Users/[yourname]/Library/Application\ Support/Firefox/Profiles/[the profile name]/searchplugins/ and restart Firefox, for other platforms, check out this doc
3 Due to limitations of the Sherlock format, it is not possible to craft a "click-to-install" file for the 3rd plugin, however you can still install it using the alternative2 installation method.

AT&T's Language Mix-up in the "Philawarepragueacago" TV Ad

Last night I saw a new TV commercial for AT&T called “Philawarepragueacago”. In this ad a, guy studying and living in Prague says "How are you, brother?" supposedly in Czech. The problem is that he doesn't say it in Czech at all. He says it in Slovak! :)

After I heard it the first time I wasn't sure if I heard it correctly or not, but after a quick Google search I found the commercialy green blog dissecting and analyzing the commercial.

Commercially green was not able to transcribe the supposedly Czech line, so here it is:
Jak sa máš, brácho?

Which in casually spoken Slovak means:
How are you, brother?

The same thing in Czech would be:
Jak se máš, brácho?

It might be a small difference for Americans but I caught the difference right away.

Maybe if the director of the commercial read the book, The Foreigner's Guide to Living In Slovakia, he'd know that there is a difference between the Czech and Slovak languages.

The only explanation that AT&T can get away with is that there are a lot of Slovaks studying at Prague's universities, so it's possible that the "brother" has Slovak room-mates from which he picked up some Slovak. :)

Thursday, October 04, 2007

What Would You Do with SunWikis Remote API?

As I mentioned previously, one of the features for wikis.sun.com that I'm working on is opening up the remote API. Before we do so, we need to customize the current behavior in order to make it a bit more secure. Before the feature is in production, I'd like to know how you would like to use it, so that we can factor that in, while customizing it.

The main problem with the remote API right now is that it is either on or off. There is nothing in between. Because the remote API is very powerful (you can do everything that you could do via the browser and more), we'd like to limit who can use it in order to avoid having to clean up the mess created by reckless or malicious clients. Right now we are thinking about limiting the client IP addresses that can connect to the remote API, and/or limit the access to the service based on user's group memberships or user account permissions.

I'd like to get a better understanding of if and how would you use the remote API for wikis.sun.com, so that we can provide you with the best solution that fits needs of the majority.

Some use cases that come to mind are:
  • use an existing command line client to access SunWikis
  • a (command line) tool that takes your data in some (XML) format, transforms it to our wiki markup and uploads it to your space
  • an application that creates an XYZ report from your database, build server, or other data source and publishes it in a wiki space every night at 3am
  • wikification of an existing application a la JDocs
Feel free to come up with another (crazy) idea and let me know about it (leave a comment on my blog or send an email to our mailing list (internal only)).

For those who want the technical details:

Each approach of limiting the access that I mentioned above has it's pros and cons. IP address restrictions are suitable for the integration of SunWikis with another web application or web service. On the other hand, it won't work well if the remote API is being accessed from your notebook or desktop that doesn't have a stable IP address.

The restrictions based on group memberships (e.g. only Sun employees can access the API) are very well suited for personal use (e.g. the uploading multiple wiki pages or the renaming of wiki pages in batches), but won't work for web application integration, because employees would have to include their passwords in these applications, which is not a smart thing.

Another problem with both of the previous approaches is that a bug in a client could affect content in all the wiki spaces, because Sun employees have write access to all spaces by default.

A compromise might be to:
  1. let a user create special account used only for remote access
  2. add this account to a special group (would be automated)
  3. grant write access to this account on a per-space basis (requires space admin intervention - the same as how permissions are being granted to external users)
This way a space admin (a Sun employee), has to endorse such an account (by granting it the write permission). In addition to that, this account will have access only to this space or maybe a few other spaces (if it is granted access to more spaces), which limits the potential damage.

Maybe there is another way to let trust-worthy folks use the remote API - if you know about something, let me now. ;-)

If you can't wait to start using or even writing clients for SunWikis, Atlassian has some good Confluence documentation that might be interesting for you if you have big remote API plans. Most importantly check out the Remote API Specification. Other interesting stuff: Remote API Examples, Confluence SOAP Client in Java