When I bought my Shure E2c earphones two years ago, I was blown away by the sound quality. I never spend more than $50 for earphones before and after buying the E2c model I would never consider downgrading to anything less. Shure really knows how to create addictive high quality products. The quality of the sound produced by my old E2c earphones was so good that I had to get rid of some albums that I ripped into mp3s long time ago when hard drive space was measured in megabytes rather than in gigabytes.
After two years of slave-like everyday service my Shure E2c earphones started to show signs of wear and it became apparent that they were going to retire soon.
Afraid of being without a good pair of earphones during my upcoming transatlantic flight, I got a new pair of Shure SE210. The design has change slightly compared to the older model, but it still preserves the main features that I loved so much.
I've been listening to some music via these earphones for only an hour or so, but I can already tell that SE210 brings "great sound" to a brand new level. I don't consider myself to be an audiophile, but even my untrained ear can hear the big difference between the two. The new pair fits better as well as feels more comfortable in my ears.
J, lost his mind a couple of weeks ago and bought a pair of the high-end SE530. I don't even want to know what those sound like. I know that if I tried them, I would be tempted to pay an insane amount of money for them, so I better say away :)
Friday, November 23, 2007
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
When I tried to run rails console or tests I saw an error like this:
The problem turned out to be in the commented-out rails example in
This fixes the problem:
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:
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.
- JDK6 is missing - WTF Apple!?!?!?
- Only read-only support for ZFS, unless you count the developer preview version at ADC
Where is Xray? - The neat DTrace GUI that used to be promoted on Apple.com website a few weeks agoUpdate: The app is now called Instruments and is part of developer tools. Thanks Ron and Barry for pointing this out to me- JDK6 is missing!!!!! Are you kidding me? Even James Gosling who liked to work on Macs, left Mac for Solaris
- 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"
- 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
- 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!
- 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
- JDK6 is still missing! - Seriously how much longer do we have to wait?!?!?
- 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.
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:
The problem, I encountered already twice, is that if the
To install Mercurial support in NetBeans, do the following:
- Get Mercurial and install it. On Mac you can install it via MacPorts
- Get NetBeans 6 and install it
- Install the Mercurial plugin via
Tools->Plugins->Available Plugins->Mercurial
- Restart the IDE
- If
Versioning->Mercurials
in the menu bar is disabled, go toTools->Options->Miscelanious->Mercurial
(on MacNetBeans->Preferences->Miscelanious->Mercurial
) and verify thatMercurial executable path
is set up correctly - in my case, since I installed Mercurial via MacPorts, the path should be/opt/local/bin
- 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.
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. :)
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.
A big thank you to everyone who planted the seed!
Number of users 1144 Number of spaces 94 Number of pages 1006 Number of page revisions 6362These 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:
Check out the
The
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
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
In my case, my sherlock.src looks like this:
It's not perfect because it is deliberately missing the
The
Once the file is created, upload it to your site, e.g.
And now you can create the link on a page that contains the JavaScript code mentioned above:
For more information on this topic check out this blog, but watch out for an XSS hole - the
The
You can replace
For example, the url for a descriptor for our About space would look like this:
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
This OSD is based on a wicked Lucene search query that looks like this:
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.
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 &
, 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. aswikis.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 thehead
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 theUrl
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.
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, Iplan 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
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.
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.
Name | Content | Click to Install1 | Download OSD2 |
---|---|---|---|
SunWikis | wikis.sun.com all spaces | Install | Download |
Confluence | confluence.atlassian.com the DOC space | Install | Download |
Confluence+Extras | confluence.atlassian.com the DOC, DISC, and CONFEXT spaces | N/A3 | Download |
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
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 doc3 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:
Which in casually spoken Slovak means:
The same thing in Czech would be:
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. :)
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:
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:
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
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
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:
- let a user create special account used only for remote access
- add this account to a special group (would be automated)
- 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)
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
Saturday, September 22, 2007
API Design - A Lesson Learned
In one of my older posts, I mentioned that I watched an excellent video of Joshua Bloch's presentation on API design.
Joshua mentioned that these days, developers are API designers and often don't even realize that. It's very easy to create a bad API when you don't realize that you're actually creating an API. And that's exactly what happened to me this week.
One of the new features for SunWikis, we released with v1.0.6, was a macro for embedding YouTube and Google videos. A simple features implemented via Confluence's user macros - it was so simple that I actually managed to make it more complicated than it needed to be. All of that just because I wasn't aware of all the options that Confluence had to offer.
My original macro sytax for this feature was:
Only later this week I realized that I could have made the syntax simpler by creating a user macro without a body. The syntax of the video macro without body looks like this:
This makes the macro code shorter, and as my friend J commented, it helps to make the macro syntax look less like an ugly version of XML.
Compare the old and the new code used to embed our promo video:
I was lucky enough that I realized this soon enough to be able to fix it before it started to be used at wikis.sun.com. So yesterday I changed the macro code, updated the documentation and fixed all the few pages that already were using the old clunky syntax.
This made me realize that Joshua missed one point in his presentation:
Be more than familiar with the language, protocol or libraries you use to create the API.
In the Java language this means use all the nice features that can make the lives of your users easier (e.g. annotations, generics, ..). In Ruby there are plenty of great idioms one can follow, and the same applies to Confluence's user macros - learn how they work, what they can do, and how you can leverage that.
Lesson learned! Next time I'll think twice and read more docs before I design any API.
Joshua mentioned that these days, developers are API designers and often don't even realize that. It's very easy to create a bad API when you don't realize that you're actually creating an API. And that's exactly what happened to me this week.
One of the new features for SunWikis, we released with v1.0.6, was a macro for embedding YouTube and Google videos. A simple features implemented via Confluence's user macros - it was so simple that I actually managed to make it more complicated than it needed to be. All of that just because I wasn't aware of all the options that Confluence had to offer.
My original macro sytax for this feature was:
{video:youtube}<insert the youtube id here>{video}
Only later this week I realized that I could have made the syntax simpler by creating a user macro without a body. The syntax of the video macro without body looks like this:
{video:youtube|<insert the youtube id here>}
This makes the macro code shorter, and as my friend J commented, it helps to make the macro syntax look less like an ugly version of XML.
Compare the old and the new code used to embed our promo video:
{video:youtube}tpR_6y-OoRc{video} {video:youtube|tpR_6y-OoRc}The second one is obviously shorter and a bit simpler.
I was lucky enough that I realized this soon enough to be able to fix it before it started to be used at wikis.sun.com. So yesterday I changed the macro code, updated the documentation and fixed all the few pages that already were using the old clunky syntax.
This made me realize that Joshua missed one point in his presentation:
Be more than familiar with the language, protocol or libraries you use to create the API.
In the Java language this means use all the nice features that can make the lives of your users easier (e.g. annotations, generics, ..). In Ruby there are plenty of great idioms one can follow, and the same applies to Confluence's user macros - learn how they work, what they can do, and how you can leverage that.
Lesson learned! Next time I'll think twice and read more docs before I design any API.
Tuesday, September 18, 2007
Monday, September 17, 2007
SunWikis v1.0.6 Released - Embedded Videos & Google Analytics
Yet another update for our wikis.sun.com, bringing exciting new features, was rolled out today!
Just to mention a few:
Detailed release notes, with instructions on how to use the new features are available here
Ohh.. and did I mention that we have a new lol zuke for our maintenance page? :)
What's next? I want to finish up the Google Analytics support so that it is fully configurable from the Space Admin interface. And most likely we'll also open up the remote API so that SunWikis can be used in other than traditional ways. Stay tuned!
Just to mention a few:
- Support for Google Analytics - space admins can now track activity in their space on their own
- Support for space logos and user avatars
- New Plugin: Create Page Macro
- Support for embedding YouTube and Google videos
Detailed release notes, with instructions on how to use the new features are available here
Ohh.. and did I mention that we have a new lol zuke for our maintenance page? :)
What's next? I want to finish up the Google Analytics support so that it is fully configurable from the Space Admin interface. And most likely we'll also open up the remote API so that SunWikis can be used in other than traditional ways. Stay tuned!
Sunday, September 16, 2007
Solution for the Java Web Start Not Launching Problem
A couple months ago I noticed that I couldn't launch any Java Web Start application from my browser (by downloading and launching a
I struggled for a long time, but then I found a solution posted on a site.
All you need to do is to delete the cache:
I have a feeling that this problem is somehow related to the preview version of JDK6 that I installed on my Mac. Apple, where is that darn JDK6 final?!?!? Unfortunately, even when Apple JDK6 is out, it most likely won't be any good for my Mac OSX 10.4 Tiger.
*.jnlp
file). When I try to launch an app, the Java Web Start logo appeared and after 20-30 seconds it went away and that was it. How frustrating!I struggled for a long time, but then I found a solution posted on a site.
All you need to do is to delete the cache:
rm ~/Library/Caches/Java/deployment.propertiesToday the problem re-appeared, but armed with this knowledge, I fixed it in a second.
I have a feeling that this problem is somehow related to the preview version of JDK6 that I installed on my Mac. Apple, where is that darn JDK6 final?!?!? Unfortunately, even when Apple JDK6 is out, it most likely won't be any good for my Mac OSX 10.4 Tiger.
Friday, September 14, 2007
Is Blockbuster Playing Fair?
I just got an email from Blockbuster telling me that they are canceling my plan and I'll either get less for the same amount of money or I have to pay more to retain the current services.
Blockbuster launched their Total Access program approximately a year ago. With this program online subscribers could return DVDs to traditional brick-and-mortar stores, and exchange them for free in-store rentals.
Now Blockbuster is modifying this program to limit the number of DVDs one can rent. I understand that some can be abusing the system and renting many many many DVDs for little money. But for some reason, I have a feeling that all of this was just about hurting Netflix, their only real competitors, by taking advantage of their store network. And now when Netflix is bleeding, it's time to stop giving out DVDs for free and start cashing in. Taking advantage of assets to temporarily blind customers and not-so-temporarily hurt the competition, doesn't seem to be fair to me.
Now is the time for Netflix to fight back, down and dirty. Maybe by adding the one category into their catalog that Blockbuster won't touch with a ten-foot pole? Yes, I'm talking about adult movies. :))
Blockbuster launched their Total Access program approximately a year ago. With this program online subscribers could return DVDs to traditional brick-and-mortar stores, and exchange them for free in-store rentals.
Now Blockbuster is modifying this program to limit the number of DVDs one can rent. I understand that some can be abusing the system and renting many many many DVDs for little money. But for some reason, I have a feeling that all of this was just about hurting Netflix, their only real competitors, by taking advantage of their store network. And now when Netflix is bleeding, it's time to stop giving out DVDs for free and start cashing in. Taking advantage of assets to temporarily blind customers and not-so-temporarily hurt the competition, doesn't seem to be fair to me.
Now is the time for Netflix to fight back, down and dirty. Maybe by adding the one category into their catalog that Blockbuster won't touch with a ten-foot pole? Yes, I'm talking about adult movies. :))
Wednesday, September 12, 2007
API Design and JSR 310 Replacing Java Date and Calendar Classes
It seems that today I'm stumbling upon a lot of interesting stuff.
While coding stuff for tomorrow's wikis.sun.com release, I watched this pretty good talk in which Joshua Bloch, once again, excellently addresses the issues and pitfalls of API design:
During the talk, Joshua makes an interesting comment. A JSR was created earlier this year, that is supposed to *finally* replace the crippled Date and Calendar classes in JDK. JSR 310: Date and Time API is lead by folks responsible for Joda Time library, that's a great sign! The request well captures current problems and needs, and I can't wait to see it implemented as a part of JDK.
While coding stuff for tomorrow's wikis.sun.com release, I watched this pretty good talk in which Joshua Bloch, once again, excellently addresses the issues and pitfalls of API design:
During the talk, Joshua makes an interesting comment. A JSR was created earlier this year, that is supposed to *finally* replace the crippled Date and Calendar classes in JDK. JSR 310: Date and Time API is lead by folks responsible for Joda Time library, that's a great sign! The request well captures current problems and needs, and I can't wait to see it implemented as a part of JDK.
NetBeans IDE 6.0 Beta 1 is Out!
While searching for a nightly build of NetBeans I noticed that NB6 Beta 1 is out. Great!
I'm looking forward to using the new version. After spending the last couple of weeks (or months?) developing in NB6M10, I can't wait to see what this release brings.
The first thing that stuck me though is the lack of "drag&drop" installation on MacOS which was replaced with "pkg-style" installer. I liked the drag&drop installation better - it's more mac-ish. I hope the surprises that will follow will only be pleasant.
Thanks, NB guys!
Download link: http://bits.netbeans.org/download/6.0/milestones/latest/
I'm looking forward to using the new version. After spending the last couple of weeks (or months?) developing in NB6M10, I can't wait to see what this release brings.
The first thing that stuck me though is the lack of "drag&drop" installation on MacOS which was replaced with "pkg-style" installer. I liked the drag&drop installation better - it's more mac-ish. I hope the surprises that will follow will only be pleasant.
Thanks, NB guys!
Download link: http://bits.netbeans.org/download/6.0/milestones/latest/
Tuesday, September 04, 2007
TinyURLs are Evil!
Thanks to Linda and J, I got introduced to Twitter and after a couple months of hesitation I created my own account.
Shortly after I started tweeting, I noticed that Twitter uses the TinyURL.com service to cut down the length of their tweets (twitter messages) to minimum.
Seeing all these tinyurls all day long provoked me to post a list of problems that TinyURL and other similar centralized url hiding services bring:
Other than that, there is not much you can do about most of the problems mentioned above, except for the XSS & XSRF problem: If you get a TinyURL, you can preview it by modifying the url from
Developers that want to cut down on the amount of rendered text should consider rendering urls as en.wikipedia.org/... or just as [url] instead of using the evil TinyURL service. This approach however doesn't work for e.g. printed media, sms.
Don't get me wrong, I'm not saying that the TinyURL service was created with evil intentions, I just think that it was an attempt to solve a common problem, that took a wrong route. Interestingly the Wikipedia page dedicated to TinyURL contains more content about issues related to TinyURL than anything else, I guess it proves my points. :)
Just to confuse everyone even more, there is a few cases when using TinyURL-like services is recommended, I'll come back to these in one of my future posts.
Shortly after I started tweeting, I noticed that Twitter uses the TinyURL.com service to cut down the length of their tweets (twitter messages) to minimum.
Seeing all these tinyurls all day long provoked me to post a list of problems that TinyURL and other similar centralized url hiding services bring:
- TinyURL doesn't have any semantics:
Rails, wikis, REST and other new technologies are striving for human readable URL. When these urls are seen posted somewhere, one gets an idea of what to expect and can easily determine if he's interested in viewing the page behind the url based on the domain name, keywords in the url or file type (in case of downloadable files). Compare:
http://en.wikipedia.org/wiki/TinyURL
tohttp://tinyurl.com/dmsfm
. Both point to the same page, but while the original url sets the expectation (almost everyone knows what can be found on wikipedia, and the keywords "TinyURL" offers even more specifics), the TinyURL (short url) has no meaning for anyone until it is opened in the browser. - TinyURLs can be misused for XSS and XSRF attacks:
Would you click on a link in an email from a friend that looks like
http://mybank.com/sendmoney?amount=50000&to=badguy
and how abouthttp://tinyurl.com/2nwz9q
? This example is a bit exaggerated, but who knows, it might not be far from reality. :-/ The fact is that TinyURLs are being misused for obfuscating urls with exploits. - TinyURL and user privacy concerns: Since every TinyURL request is handled via TinyURL infrastructure, all the information about who, when, from which site, and from which computer clicked on a TinyURL link.
- TinyURL messes up search engine logic: Many, if not all, top search engines rely on analyzing which site links to which and use this information to determine which site is popular. What happens when many urls point to other sites via TinyURLs? You can guess which site (hint) gets all the extra points and is considered to be popular.
- TinyURL messes up web site statistics: If you track activity on your website via services like Google Analytics or Omniture SiteCatalyst, you often want to know where your traffic is coming from. Well, if someone points to your site via a TinyURL, all you'll see is that the traffic is coming from a TinyURL.com site. The reason for this is that when coming to a site via a TinyURL, the referer is always set to TinyURL.com
Other than that, there is not much you can do about most of the problems mentioned above, except for the XSS & XSRF problem: If you get a TinyURL, you can preview it by modifying the url from
http://tinyurl.com/dmsfm
to http://preview.tinyurl.com/dmsfm
. This will show you the destination URL before you are redirected there. If you want this to happen automatically every time you click on a TinyURL, you can save this preference as cookie that will trigger the preview behavior automatically.Developers that want to cut down on the amount of rendered text should consider rendering urls as en.wikipedia.org/... or just as [url] instead of using the evil TinyURL service. This approach however doesn't work for e.g. printed media, sms.
Don't get me wrong, I'm not saying that the TinyURL service was created with evil intentions, I just think that it was an attempt to solve a common problem, that took a wrong route. Interestingly the Wikipedia page dedicated to TinyURL contains more content about issues related to TinyURL than anything else, I guess it proves my points. :)
Just to confuse everyone even more, there is a few cases when using TinyURL-like services is recommended, I'll come back to these in one of my future posts.
Friday, August 31, 2007
The Wikification of Sun Video
Danny Holland created a really awesome video about how publishing at Sun changed from a highly specialized profession accessible to only a few, to a super easy community-oriented model supported by wikis.sun.com
When you are ready, go ahead and create your wiki space or help out in existing wiki spaces. Anyone can now create missing documentation, FAQs, examples, best practices or anything else useful for Sun communities.
Thanks Danny!
When you are ready, go ahead and create your wiki space or help out in existing wiki spaces. Anyone can now create missing documentation, FAQs, examples, best practices or anything else useful for Sun communities.
Thanks Danny!
Thursday, August 23, 2007
SunWikis v1.0.5 released - We've got (a) space for everyone!
Today we released another upgrade to our wikis.sun.com, version 1.0.5.
Besides a few bug fixes and cosmetic changes in the UI, Sun employees are now allowed to create wiki spaces without having to submit requests.
So Sun employees, if you have a great idea that you want to share with a Sun community but were not able to find the right publishing platform, think no more! Creating a wiki space is super easy, just follow these instructions. Keep in mind that wiki is about collaboration. So before creating a space, look if a space for your desired topic already exists. If you find one, help it's creators instead of fragmenting information across multiple spaces.
Non-Sun folks, you can collaborate via comments or request write permission from space administrators.
Besides a few bug fixes and cosmetic changes in the UI, Sun employees are now allowed to create wiki spaces without having to submit requests.
So Sun employees, if you have a great idea that you want to share with a Sun community but were not able to find the right publishing platform, think no more! Creating a wiki space is super easy, just follow these instructions. Keep in mind that wiki is about collaboration. So before creating a space, look if a space for your desired topic already exists. If you find one, help it's creators instead of fragmenting information across multiple spaces.
Non-Sun folks, you can collaborate via comments or request write permission from space administrators.
Monday, August 20, 2007
Wikis and SCM Tools Can Contain Many Hidden "Treasures"
One thing that all the wikis and SCM (Source Code Management) tools have in common is that they keep change revisions (at least they should!). This feature makes it possible to go back in time and see events that happened in the repository even 4 years ago.
While working on some features for wikis.sun.com I stumbled upon an interesting discovery in the Atlassian's Seraph Subversion repository.
Well :), I know that a job in software development can be frustrating at times, and sometimes it is hard to overcome that sudden urge to express exactly what one feels. :-D
This is a good showcase of why the controlled ability to delete revisions in an SCM as well as in wikis is a really important feature.
Imagine that your wiki gets vandalized by a malicious user (or you accidentally publish confidential or private information). You can superficially fix the issue by reverting the page(s) to the last good state, but the vandalized revision will stay with you forever (visible for users willing to dig in the page history as well as to web crawlers and search bots, blindly crawling all links that they find). At least that's how it is in Confluence, which we use for wikis.sun.com. Someone foresaw this issue 3 years ago and created a JIRA issue requesting this feature (CONF-1573). Unfortunately Atlassian never got around to delivering it.
Maybe after today's lesson when forums.atlassian.com got vandalized by users who found a way to hijack forum visitors and send them to their web site, Atlassian will start to appreciate the ability to fully recover from these kinds of incidents. Atlassian?
For those of you who get into trouble with the inability to delete revisions, there is a workaround that is not pretty and requires some sacrifices:
There are a few things to watch out for and understand:
While working on some features for wikis.sun.com I stumbled upon an interesting discovery in the Atlassian's Seraph Subversion repository.
Well :), I know that a job in software development can be frustrating at times, and sometimes it is hard to overcome that sudden urge to express exactly what one feels. :-D
This is a good showcase of why the controlled ability to delete revisions in an SCM as well as in wikis is a really important feature.
Imagine that your wiki gets vandalized by a malicious user (or you accidentally publish confidential or private information). You can superficially fix the issue by reverting the page(s) to the last good state, but the vandalized revision will stay with you forever (visible for users willing to dig in the page history as well as to web crawlers and search bots, blindly crawling all links that they find). At least that's how it is in Confluence, which we use for wikis.sun.com. Someone foresaw this issue 3 years ago and created a JIRA issue requesting this feature (CONF-1573). Unfortunately Atlassian never got around to delivering it.
Maybe after today's lesson when forums.atlassian.com got vandalized by users who found a way to hijack forum visitors and send them to their web site, Atlassian will start to appreciate the ability to fully recover from these kinds of incidents. Atlassian?
For those of you who get into trouble with the inability to delete revisions, there is a workaround that is not pretty and requires some sacrifices:
- Get the wiki markup code of the latest good revision (go to the edit view and copy the contents of the text area)
- Delete the page
- Create new page with exactly the same name as the page you just deleted
- Paste the contents of the clip board into the editor and save the page
There are a few things to watch out for and understand:
- By doing this procedure you'll lose the page history, page level permissions, and most likely also watches that you and other users set for this page
- Make sure you don't accidentally lose content of the clip board between the copy and paste :)
- The name of the page should be exactly the same as the name of the old page, otherwise URL links within the wiki or from external sources will be broken
Friday, August 10, 2007
SunWikis 1.0.4 released - Is the Outage Really Necessary?
We just went through the first upgrade of wikis.sun.com since the launch a week ago.
The main highlight of the 1.0.4 release was the upgrade to Confluence 2.5.6 which contains many critical security fixes. Other than that, we fixed some UI issues that we found in the previous SunWikis release.
You might wonder why did we go offline for a little less then 30 minutes during the upgrade. The answer is that Confluence doesn't support "live" upgrades. As mentioned in the Confluence Cluster Upgrade HowTo, we had to take the site down in order to upgrade safely.
I don't like the idea of having an outage every time we upgrade Confluence. I'll see if we can get Atlassian to help us minimize the down time somehow.
It is usually safe to let nodes with different versions of software touch the same database, supposing that no changes to the data or the db schema happened during the upgrade. This should apply to Confluence as well and it could be the first step in minimizing the down time.
If Atlassian started differentiating between the upgrades that modify the underlaying database and those that don't, and this information would be available in the Confluence release notes, we could minimize the down time from 30minutes every 2-3 weeks down to 30 minutes every 2-3 months.
2-3 months is the usual release cycle for major Confluence versions. Changes to the db schema in such releases are expected, as opposed to minor releases which IMO should change the db only when it is necessary for fixing a high priority bug.
Atlassian has been pretty responsive to our requests so far*, so I hope that we can come up with some solution to this problem as well.
* though I haven't heard from them anything related to the request for Confluence roadmap yet
The main highlight of the 1.0.4 release was the upgrade to Confluence 2.5.6 which contains many critical security fixes. Other than that, we fixed some UI issues that we found in the previous SunWikis release.
You might wonder why did we go offline for a little less then 30 minutes during the upgrade. The answer is that Confluence doesn't support "live" upgrades. As mentioned in the Confluence Cluster Upgrade HowTo, we had to take the site down in order to upgrade safely.
I don't like the idea of having an outage every time we upgrade Confluence. I'll see if we can get Atlassian to help us minimize the down time somehow.
It is usually safe to let nodes with different versions of software touch the same database, supposing that no changes to the data or the db schema happened during the upgrade. This should apply to Confluence as well and it could be the first step in minimizing the down time.
If Atlassian started differentiating between the upgrades that modify the underlaying database and those that don't, and this information would be available in the Confluence release notes, we could minimize the down time from 30minutes every 2-3 weeks down to 30 minutes every 2-3 months.
2-3 months is the usual release cycle for major Confluence versions. Changes to the db schema in such releases are expected, as opposed to minor releases which IMO should change the db only when it is necessary for fixing a high priority bug.
Atlassian has been pretty responsive to our requests so far*, so I hope that we can come up with some solution to this problem as well.
* though I haven't heard from them anything related to the request for Confluence roadmap yet
Wednesday, August 08, 2007
Is Atlassian (and the Code Base of Confluence) Really That Bad? I don't think so.
Rama in his recent blog entry defended Atlassian against the rough critique posted on the BileBlog. As an engineer working on wikis.sun.com, here is what I have to say about my experience with Atlassian and Confluence.
Yes, I did spend quite some time playing with things under the hood of Confluence, but I got access to the source code only recently so my opinion might be premature in certain points. This is what I think about the code, based on the portions of codes that I explored so far:
Overall the Java code is easy to read. I can't judge the architecture because I haven't been digging in the code for too long yet, but the bits and pieces that I needed to look at or modify were well formated, easy to read and absorb.
Having said that, I don't understand why I couldn't find one single JavaDoc comment in the source base. Is Atlassian allergic to JavaDocs? It would make my life much easier if things were properly documented in the code. In general the code documentation is lacking or nonexistent. When I needed to write a custom authenticator, it took me much longer to do it than expected, just because the documentation was missing, wasn't detailed enough, or was outdated.
One thing that surprised me a lot was the database schema. I usually try to make the db schema in my applications as tight as possible and I'm not happy unless all the table/column/constraint names follow certain (unified) naming conventions.
The first time I looked into the db after I got my Confluence up and running was "OMG! These people can't even decide on table name conventions". After digging deeper I found other flaws. Just to mention a few:
The other thing that I appreciate a lot is Atlassian's agile release cycle. We are getting new production builds every 2-3 weeks and these builds usually contain fixes for issues that we recently reported. One thing I miss here though, is some kind of roadmap. I don't need a very detailed roadmap, all I'd like to see is a list of all planned releases for the next 6 months, with approximate dates and key features. This would allow me to plan our releases better.
When it comes to support, in general I had a feeling that it wasn't as responsive as I'd like it to be, but we recently heard that Atlassian's about to expand its support team so I have faith that this will improve shortly. Having said that, I recently tried the live chat support option and it worked great, I got my question answered quickly and that helped me resolve some issues I had.
Atlassian got recently wet from the rain of security issues that we, as well as another customer, reported in the last few days and weeks. It didn't take relatively too long and all the issues were fixed in the recently released version 2.5.6.
I had a conversation with Chris Owen from Atlassian, who assured me that Atlassian is taking proactive measures to weed out all the easy to catch security issues from Confluence. In addition to that Atlassian is planning to make some changes to the process of how security issues are being handled. If he keeps his word and these things become reality then I'll be a happy camper :).
Confluence Code Quality
Yes, I did spend quite some time playing with things under the hood of Confluence, but I got access to the source code only recently so my opinion might be premature in certain points. This is what I think about the code, based on the portions of codes that I explored so far:
Overall the Java code is easy to read. I can't judge the architecture because I haven't been digging in the code for too long yet, but the bits and pieces that I needed to look at or modify were well formated, easy to read and absorb.
Having said that, I don't understand why I couldn't find one single JavaDoc comment in the source base. Is Atlassian allergic to JavaDocs? It would make my life much easier if things were properly documented in the code. In general the code documentation is lacking or nonexistent. When I needed to write a custom authenticator, it took me much longer to do it than expected, just because the documentation was missing, wasn't detailed enough, or was outdated.
One thing that surprised me a lot was the database schema. I usually try to make the db schema in my applications as tight as possible and I'm not happy unless all the table/column/constraint names follow certain (unified) naming conventions.
The first time I looked into the db after I got my Confluence up and running was "OMG! These people can't even decide on table name conventions". After digging deeper I found other flaws. Just to mention a few:
- when using MySQL, Confluence doesn't create InnoDB tables by default. It happily creates MyISAM tables, unless you configure your db to use InnoDB by default.
- FKs are not used as often as one would expect
- the "users.username" and not "users.id" is used all over the place as a reference to user accounts, which effectively makes username changes next to impossible (Atlassian knows about this problem and promised us to fix it by v2.7)
- lastly - is the db schema documented somewhere at all? I found a messy doc describing JIRA's db schema, but I couldn't find anything similar or better for Confluence.
Atlassian as a Company and its Processes
The things I like about Atlassian is that they are trying to be transparent towards its customers. JIRA where anyone can search existing bugs and submit new reports for all of their products is extremely helpful for everyone in the community. There aren't many commercial projects that practice such an openness. Did I mentioned all the tech and biz blogs that Atlassians have?The other thing that I appreciate a lot is Atlassian's agile release cycle. We are getting new production builds every 2-3 weeks and these builds usually contain fixes for issues that we recently reported. One thing I miss here though, is some kind of roadmap. I don't need a very detailed roadmap, all I'd like to see is a list of all planned releases for the next 6 months, with approximate dates and key features. This would allow me to plan our releases better.
When it comes to support, in general I had a feeling that it wasn't as responsive as I'd like it to be, but we recently heard that Atlassian's about to expand its support team so I have faith that this will improve shortly. Having said that, I recently tried the live chat support option and it worked great, I got my question answered quickly and that helped me resolve some issues I had.
Atlassian got recently wet from the rain of security issues that we, as well as another customer, reported in the last few days and weeks. It didn't take relatively too long and all the issues were fixed in the recently released version 2.5.6.
I had a conversation with Chris Owen from Atlassian, who assured me that Atlassian is taking proactive measures to weed out all the easy to catch security issues from Confluence. In addition to that Atlassian is planning to make some changes to the process of how security issues are being handled. If he keeps his word and these things become reality then I'll be a happy camper :).
Conclusion
I think that the BileBlog's claims are far fetched and exaggerated (in a nasty way, so typical for him). Atlassian is not perfect, but they are better than the average in many aspects. As long as they listen to their customers and do their best to change things that are being constructively criticized (I read that that's what they like), they'll have my praise.Monday, August 06, 2007
The Foreigner's Guide to Living in Slovakia - the Website Launch
As if the frenzy related to the wikis.sun.com launch was not enough, my wife and I launched our own project last week as well. A website called "The Foreigner's Guide to Living in Slovakia".
Three years ago my wife Margarete (girlfriend at that time), got an idea to write a book. A book about something that we share passion for. A book about the country that I come from and in which we met and lived for a few years. This country is called Slovakia, and is located in the heart of Europe - Central Europe.
When Margarete moved to Slovakia to live and work there for a year, she found that there weren't many resources in English that could help her to get around. Over the years (yes, she stayed longer than the originally planned one year) she learned and experienced a lot and captured a lot of the hard to find information and insider tips in her book The Foreigner's Guide to Living in Slovakia.
After a lot of hard work, the book recently went to print and now is available for anyone, especially those who are considering moving to Slovakia for a year or two, or just about anyone interested in learning more about what Slovakia is like, what kind of people live there, their history, customs and traditions, as well as tips on how to settle or just get by, should you visit or pass through the country.
To support the book and provide additional information that didn't make it into the already relatively thick (200 pages) book, Margarete and I put together a website with the same name which can be found at www.fgslovakia.com.
The www.fgslovakia.com website contains additional resources as well as a blog focused on anything Slovak, from how to cook some Slovak meals, to how to learn a little bit of Slovak language and use it in common situations.
Margarete seeded the site with some really good content and that's just the beginning. As time goes by, more and more blog entries about Slovak stuff will be added.
If you are interested in Slovakia and Slovak culture, this is definitely a site you want to keep an eye on.
wikis.sun.com Is Live - the Engineering Perspective
Hooray! We made it! It's finally out there!
What a week! After weeks of preparation (4 months to be exact) we finally launched wikis.sun.com last Friday, just after going through the screen name drama (that I have to blog about later) and launching a site for my wife's project, The Foreigner's Guide to Living in Slovakia.
Linda and Rama already blogged a bit about the launch here and here, so now it's my turn to blog about Sun Wikis from an engineering perspective.
wikis.sun.com is powered by Confluence, a wiki platform created by Atlassian. Why Confluence and not something else? I hear that question a lot. Well, the decision was made even before I joined the project, but I'm not afraid to say that it was a good decision.
Confluence is a scalable (content-wise via wiki spaces, and performance-wise via clustering) and extensible, feature-rich application, with a strong community. And let's not forget that it's a Java app ;-). Having said that, we certainly do miss some features and we also are bothered with some bugs. But these are things that can be fixed, and we are working hard on our own, as well as in cooperation with Atlassian, to get things fixed and to deliver the missing features.
In the last couple of weeks, our focus was on establishing the right infrastructure for the application, and making sure that the platform is relatively secure and stable. There is still some work to be done in these areas, but I believe that we will soon start to look more and more into delivering the missing features.
So what have we done to Confluence so far:
For those of you that want to know all the tiny implementation details, we run Confluence on Sun Java System Webserver 7.0u1 with a MySQL backend. In the dev environment I was able to run Confluence on the latest Glassfish v2 without any problems as well.
Atlassian has a very agile release cycle with minor releases shipping every 2-3 weeks and major releases shipping every 2-3 months. This means that things are getting fixed quickly, which is very good, but it also means that we need to reapply our customizations to the main source code very often. When I realized that we need to make modifications to the core code, and that we also want to stay in sync with Atlassian's release cycle, I started to look for a solution that would make this as easy as possible. I looked at Subversion's vendor branches, but the solution felt clunky. By chance I heard or read somewhere that the SCM system Mercurial (used on OpenSolaris and OpenJDK projects)is very good at managing patches. I dived into reading about Mercurial and it was one of those love-at-first-sight encounters. Mercurial Queues totally blew me away and are saving me huge amounts of time when working on wikis.sun.com.
So what does the final result look like? Here is the compulsory screen shot:
What's next? We certainly don't feel like we are done; quite the opposite is true. Launching wikis.sun.com is just the beginning of our wiki journey, so you can expect things to get even better, and we expect from you to create some great content for all of us to benefit from.
This is the first community-oriented project that I've ever worked on, and I'm doing my best to work with the community on achieving our common goals. Therefore, I'll try to blog often about Sun Wikis, about our progress, new features, and current problems on this blog (entries will be labeled with the SunWikis label). Stay tuned and go participate! :)
What a week! After weeks of preparation (4 months to be exact) we finally launched wikis.sun.com last Friday, just after going through the screen name drama (that I have to blog about later) and launching a site for my wife's project, The Foreigner's Guide to Living in Slovakia.
Linda and Rama already blogged a bit about the launch here and here, so now it's my turn to blog about Sun Wikis from an engineering perspective.
wikis.sun.com is powered by Confluence, a wiki platform created by Atlassian. Why Confluence and not something else? I hear that question a lot. Well, the decision was made even before I joined the project, but I'm not afraid to say that it was a good decision.
Confluence is a scalable (content-wise via wiki spaces, and performance-wise via clustering) and extensible, feature-rich application, with a strong community. And let's not forget that it's a Java app ;-). Having said that, we certainly do miss some features and we also are bothered with some bugs. But these are things that can be fixed, and we are working hard on our own, as well as in cooperation with Atlassian, to get things fixed and to deliver the missing features.
In the last couple of weeks, our focus was on establishing the right infrastructure for the application, and making sure that the platform is relatively secure and stable. There is still some work to be done in these areas, but I believe that we will soon start to look more and more into delivering the missing features.
So what have we done to Confluence so far:
- Sun.com theme - this is by far the most visible change. Confluence uses Velocity templates for views, and supports creating themes packaged as plugins. So thanks to Greg from our UX team and his CSS skills, the theme was created in almost no time.
- Custom authenticator - I remember days when I needed many different accounts to get into many applications on the .sun.com domain. Fortunately this has changed and these days you can use a unified "Sun Online Account" to get into most of our apps. So a custom authenticator that taught Confluence how to talk to our custom Single SignOn infrastructure was one of the first things I had to develop on this project. It wasn't as easy as I thought it would be. Judging by the poor documentation, it seems that this isn't something that many Confluence customers do. But after a lot of experimentation and hitting a few dead ends, a functional authenticator was created.
- Customization of a few views - "Wikis Home" and "Report an Issue" links, and some other parts of the view needed to be added, removed, or customized.
- Content seeding - we launched the site internally quite some time ago and we called this period the "Wiki Pilot". We got in touch with some great folks who saw this soon-to-be-public wiki as a good opportunity to get their job done. Brian Keith is working on a great Sun Cluster Wiki and Paul Kasper and the BigAdmin team are also getting ready to show off at wikis.sun.com.
- Patching security holes - there were certain issues that we didn't want to have unresolved for our launch, so some last minute patching was necessary.
- Many other small fixes or customizations.
For those of you that want to know all the tiny implementation details, we run Confluence on Sun Java System Webserver 7.0u1 with a MySQL backend. In the dev environment I was able to run Confluence on the latest Glassfish v2 without any problems as well.
Atlassian has a very agile release cycle with minor releases shipping every 2-3 weeks and major releases shipping every 2-3 months. This means that things are getting fixed quickly, which is very good, but it also means that we need to reapply our customizations to the main source code very often. When I realized that we need to make modifications to the core code, and that we also want to stay in sync with Atlassian's release cycle, I started to look for a solution that would make this as easy as possible. I looked at Subversion's vendor branches, but the solution felt clunky. By chance I heard or read somewhere that the SCM system Mercurial (used on OpenSolaris and OpenJDK projects)is very good at managing patches. I dived into reading about Mercurial and it was one of those love-at-first-sight encounters. Mercurial Queues totally blew me away and are saving me huge amounts of time when working on wikis.sun.com.
So what does the final result look like? Here is the compulsory screen shot:
What's next? We certainly don't feel like we are done; quite the opposite is true. Launching wikis.sun.com is just the beginning of our wiki journey, so you can expect things to get even better, and we expect from you to create some great content for all of us to benefit from.
This is the first community-oriented project that I've ever worked on, and I'm doing my best to work with the community on achieving our common goals. Therefore, I'll try to blog often about Sun Wikis, about our progress, new features, and current problems on this blog (entries will be labeled with the SunWikis label). Stay tuned and go participate! :)
Labels:
DotSunEngineering,
Projects,
Software Engineering,
Sun,
SunWikis
Tuesday, July 17, 2007
Mail.app Unread Message Mystery Resolved
Last night I finally resolved an issue that was bothering me ever since I got my MacBook Pro and by posting this entry I hope to help others with the same issue.
I use Mail.app for reading my emails via pop3s and imaps and I noticed that some messages were randomly getting flagged as unread. Sometimes the message would stay read forever, other times I had to mark it 10 times as read and a couple of hours or days later it would become unread again.
This was really frustrating and even though I tried googling around, I couldn't find the cause or resolution for this problem. When asking others, nobody knew or suffered from the same issue and that gave me hope that there must be a fix or a way to avoid it.
Last night enough was enough and I googled again. I don't know if I used the right combination of keywords, or if Google's index got better, but I found a forum thread discussing the very same issue I was having!
Apparently GPGMail (an extension that integrates GPG with Mail.app) is responsible for this. Sure enough, the author even acknowledges the issue on his site.
The workaround didn't work for me, uninstalling the extension did!
I'm not thrilled by not having GPG support in my mail client, but for now I'd rather be without GPG than having to bear with ~500 unread emails in my mailbox.
Since in my case the issue is repeatable (even after reinstalling MacOSX), I can provide any necessary information to the author if he's interested in fixing it.
In my opinion the issue has something to do with imap or imaps mailboxes and I wouldn't be surprised if many people at Sun would be suffering from the same issue, since imaps is the default mail retrieval protocol at Sun.
I use Mail.app for reading my emails via pop3s and imaps and I noticed that some messages were randomly getting flagged as unread. Sometimes the message would stay read forever, other times I had to mark it 10 times as read and a couple of hours or days later it would become unread again.
This was really frustrating and even though I tried googling around, I couldn't find the cause or resolution for this problem. When asking others, nobody knew or suffered from the same issue and that gave me hope that there must be a fix or a way to avoid it.
Last night enough was enough and I googled again. I don't know if I used the right combination of keywords, or if Google's index got better, but I found a forum thread discussing the very same issue I was having!
Apparently GPGMail (an extension that integrates GPG with Mail.app) is responsible for this. Sure enough, the author even acknowledges the issue on his site.
Q: Since I installed GPGMail, some read messages have their 'read' status come back to 'unread'. What's happening? A: It's is a bug in GPGMail that I've been unable to fix yet. The only workaround that works for most people (but not all) is to disable automatic decryption/verification of emails.
The workaround didn't work for me, uninstalling the extension did!
I'm not thrilled by not having GPG support in my mail client, but for now I'd rather be without GPG than having to bear with ~500 unread emails in my mailbox.
Since in my case the issue is repeatable (even after reinstalling MacOSX), I can provide any necessary information to the author if he's interested in fixing it.
In my opinion the issue has something to do with imap or imaps mailboxes and I wouldn't be surprised if many people at Sun would be suffering from the same issue, since imaps is the default mail retrieval protocol at Sun.
Monday, July 02, 2007
NetBeans 6 Milestone 10 is out
My random check of the NetBeans site shows that NetBeans 6 M10 is out.
Release Notes New and Noteworthy in Milestone 10 Download
I'm looking forward to tasting the new bits. What a great way to start a new week. ;-)
Release Notes New and Noteworthy in Milestone 10 Download
I'm looking forward to tasting the new bits. What a great way to start a new week. ;-)
Saturday, June 30, 2007
TomTom One Caught Speeding!
While writing my post about TomTom One, which I bought recently, I realized that the device is speeding! TomTom One has a feature that enables users to preview the route in a demo mode. TomTom previews the route and all the turns as if you were driving the car, while you sit in your chair. The interesting thing is that my TomTom was "driving" 75mph on the 101 freeway which has speed limited posted at 65mph - standard in the Silicon Valley!!!
TomTom One "driving" 75mph in 65mph zone
A simple explanation is that TomTom bases all its calculations (as well as preview) on the real life speeds rather than "posted" speed limits. I must admit there isn't too many people out there driving 65mph or less on Freeway 101. ;-)
A simple explanation is that TomTom bases all its calculations (as well as preview) on the real life speeds rather than "posted" speed limits. I must admit there isn't too many people out there driving 65mph or less on Freeway 101. ;-)
How TomTom Saved My Day
As probably any other technology junkie out there, I had been looking at the evolution of car navigation systems and thinking about how cool it would be to have a device that could really make it easy to travel in a unknown area without having to worry about studying maps ahead of time or having another person filling out the role of a navigator.
A friend of mine bought a TomTom One recently and was telling me how great this device was. Not that he's untrustworthy person, but for some reason I accepted the information but didn't decide to take any further action.
On our last trip to Yosemite, I didn't pay attention to the direction I was driving for a moment and forgot to take a turn that I should have. This little mistake cost us 1 hour delay, wasted gas and created some frustration. At that point I revisited the information from my trustworthy friend and started looking for a GPS car navigation system that was affordable, yet feature rich and reliable.
Consumer Reports made it clear that TomTom One is the way to go. Other reviews as well as information from my trustworthy friend confirmed this.
Last week, my TomTom unit arrived, after I ordered it on the Internet. It looks good, is compact, and is very easy to use. In the following days I started to get to know it during my daily commute.
It wasn't until last Thursday, that I had to put my TomTom into a real-world test. The main project that I work on right now at Sun is customization and deployment of Confluence for soon to be launched wikis.sun.com. Atlassian, the company behind Conluence, organized Atlassian User Group meeting in Stanford, that I was joining.
Even though I have been living in the San Francisco Bay Area for 2 years now, I don't know Stanford very well. The meeting was taking place in the Stanford campus, which is beautiful, but can be pretty challenging to navigate through thanks to many little streets with many intersections through out the campus. Combine all of that with my "talent" for doing things last minute and you get a person rushing to get somewhere where he's never been before. Sounds like a good challenge for my brand-spanking-new TomTom, right? ;-)
Well it really was. I left from Menlo Park campus much later than I originally planned to, so I quickly jumped into my car, input the destination address and headed out into the unknown.
TomTom picked a route that most likely I would have picked as well if I studied the maps or used Google Maps*. The fact that I didn't need to watch out for turns and making sure that I was on the right street made the whole "rush" much easier.
One thing that I observed during the first ride with TomTom was that the 3D maps that TomTom uses by default are really good. At first it seemed unnatural for me to use 3D maps instead of birds eye's view 2D maps. But after driving with the 2D maps on I quickly switched to the 3D view. It really is much easier to keep track of where you are and where you need to go on the 3D map!
There was one point during my travel to the meeting, when I truly appreciated having my TomTom. When I was already in the Stanford University campus, navigating through a maze of little streets, my TomTom said "Turn right", I tried, really tried - but the sign "Road construction. Road Closed" didn't let me go through. I had to take the only possible turn that there was and ignore the instructions. If I had just a small scrap of paper with driving instructions on it, I would have been lost. With TomTom there is no need for panic, I just took the only turn that I could, TomTom realized that something went wrong and recalculated the route taking into consideration my current position, successfully navigating me around the road construction.
I got to my destination on time and it wouldn't have been like that if it weren't for my TomTom One.
No product is perfect (at least not in my eyes ;-) ), so here is a few things that I'd like to see improved:
- Reorganized menu - some items that are often needed are buried deep in the menu structure (e.g. clear route), others are not found where one would look for them (e.g. edit favorites)
- Map Share technology recently announced with the TomTom Go 720 model, should become standard feature for all TomTom GPS products - to make this feature really useful they need to gain critical mass and to do that they should offer it in all products
- Redo the TomTom Home application - currently I found almost no value in this app - it's just shopping desktop application that happens to be able to backup your TomTom. Did I mention that it crashed on me at least 5 times on my Mac during the few minutes that I used it so far?!? All in all the app is next to useless. Features like creating an itinerary, reviewing past trips, showing some statistics are lacking.
- There are absolutely no statistics offered for the current trip, or just after reaching the destination. Americans love statistics, so it's interesting that such a feature is missing in a product that is successful on the American market ;-)
- Rama brought up a good point while we were talking about the device - there is no way to tell your current elevation. Isn't that like the most basic feature of a GPS device?
- The device seems to be a closed platform - software-wise as well as hardware-wise. I wish it was possible to write plugins that would make it possible to add some of the features that I miss. I haven't found any "developer" section on the tomtom.com website. If it was possible to connect the device with something else than bluetooth cellphones, it would be interesting to see what could one do with a combination of a TomTom and a SunSPOT - temperature, atmospheric pressure, humidity and acceleration readings, anyone? How about switching TomTom to the night mode when it gets dark outside? How many other possibilities would opening the platform enable?
- Last but foremost - I'd appreciate having a button which when pushed would make a car in front of me disappear. There should be a limit on how many "clicks" one can make per day or week though, to avoid a large scale abuse of this feature, which might have undesirable side effects :-D
See also: TomTom One Caught Speeding!
* btw have you heard of the new real-time route adjustment feature? It would be really great if it was this easy to adjust the route in TomTom.
Thursday, June 21, 2007
I Survived Upgrade to MacOS X 10.4.10
Last night I installed the freshly released update for Tiger (update 10.4.10).
The installation went fine, but took unusually long time, which made me a little worried for a moment (a spinning wheel is not the best indicator of progress).
After the problems I (and many others) had with 10.4.9, I recommend doing at least these steps in order to install a MacOSX Update:
- close all the apps
- backup important stuff
- launch Disk Utility and verify the disk *and* disk permissions
- start the installation
- don't touch your machine until the update is done
- start praying
Tuesday, June 19, 2007
No Mustang for You Tiger! - JDK6 Only in Leopard
There are times when I hate to be right and today is definitely one of those days.
Just a month ago I wrote an entry "Where is Apple JDK6", in which I proposed an explanation for the sudden stop of releases of Apple JDK6 developer previews.
Today I read some news coming from WWDC, that proves my theory.
Well, thank you Apple! As if the delay of Leopard due to some phone was not enough. :-/
One would hope that after Java went open source, it would be easier for Apple to integrate it into MacOS without any big delays. But apparently that's not the case.
Apple probably needs JDK6 as a feature of Leopard so that they can claim that Leopard has 300 new features. Without JDK6 the number would be 299 which doesn't look good in marketing presentations.
Just a month ago I wrote an entry "Where is Apple JDK6", in which I proposed an explanation for the sudden stop of releases of Apple JDK6 developer previews.
Today I read some news coming from WWDC, that proves my theory.
the fact that Java 6 will take advantage of new features only available in Leopard and the fact that the latest Java 6 preview requires the absolute latest Leopard preview confirms the suspicions many have had: First, Java 6 will not be released for OS X until Leopard ships. Second, Apple is going to continue its trend of forcing you to upgrade to the latest version of OS X if you want to use the latest version of Java.
Well, thank you Apple! As if the delay of Leopard due to some phone was not enough. :-/
One would hope that after Java went open source, it would be easier for Apple to integrate it into MacOS without any big delays. But apparently that's not the case.
Apple probably needs JDK6 as a feature of Leopard so that they can claim that Leopard has 300 new features. Without JDK6 the number would be 299 which doesn't look good in marketing presentations.
Sunday, June 10, 2007
OpenOffice.org Aqua Development Snapshot - First Impressions and Comparison with NeoOffice
I came across the news that the first OOo Aqua build was released. This is still an early alpha and as my brief testing proved it's not suitable for any kind of production use.
First impressions are good though. OOo Aqua looks a lot like NeoOffice. There is still of lot of areas where OOo Aqua is lacking behind, but the improvement from the X11 based OOo are definitely noticeable.
OOo Aqua
NeoOffice
The application is much faster than the X11 version and feels more like a Mac application than X11 application. If any of you tried running OOo via X11 on a Mac you know what a pain it is :-/.
My shallow experiments showed that OOo Aqua uses only half of the memory compared to NeoOffice. If the stable release will keep this feature it will be a huge improvement and a slap in the face to NeoOffice.
Don't forget the NeoOffice numbers don't include memory used by X11
Some users claim that the alpha version of OOo Aqua is faster in certain areas than the current NeoOffice (see this in-depth review). I didn't notice a big difference between the two, except for performance in window resizing where NeoOffice is faster (but still terribly slow compared to any other Aqua application).
Overall I'm impressed about the results of only a few weeks of active development since the project announcement in the May. OOo Aqua developers keep up the good job!!!
(If you ever wondered why OOo Aqua and NeoOffice are two very similar projects that run in parallel, then here is a couple of answers that shed some light on this situation)
First impressions are good though. OOo Aqua looks a lot like NeoOffice. There is still of lot of areas where OOo Aqua is lacking behind, but the improvement from the X11 based OOo are definitely noticeable.
The application is much faster than the X11 version and feels more like a Mac application than X11 application. If any of you tried running OOo via X11 on a Mac you know what a pain it is :-/.
My shallow experiments showed that OOo Aqua uses only half of the memory compared to NeoOffice. If the stable release will keep this feature it will be a huge improvement and a slap in the face to NeoOffice.
Some users claim that the alpha version of OOo Aqua is faster in certain areas than the current NeoOffice (see this in-depth review). I didn't notice a big difference between the two, except for performance in window resizing where NeoOffice is faster (but still terribly slow compared to any other Aqua application).
Overall I'm impressed about the results of only a few weeks of active development since the project announcement in the May. OOo Aqua developers keep up the good job!!!
(If you ever wondered why OOo Aqua and NeoOffice are two very similar projects that run in parallel, then here is a couple of answers that shed some light on this situation)
Subscribe to:
Posts (Atom)