Apple, job creation and the App economy

The Apple job creation page is pure PR: they claim to have "created" or "supported" over 500.000 jobs.

It sounds like the kind of thing a politician would say. Because they even add transportation, health care and "the app economy"!

It's kind of like you claiming to be a job creator because you buy local and burn electricity.

Anyhow, what's interesting is that the App economy is estimated at 210,000 US jobs and Apple has paid over $4 billion to App developers world-wide, ever!

Assuming those $4 billion were all to US app developers in a single year, that ends up to about $19.000 / job in total or about $1600 / month / US developer if that amount is split over 12 months.

What this shows is quite interesting: the App economy isn't self-sustaining.

If the 210,000 US jobs are real then App Store sellers are burning cash.

Considering the money sellers make must follow some sort of distribution then most of those "app economy" jobs aren't even making minimum wage in profit.

Now, one might say: "yes, but those App creators are making money some other way -- perhaps they are giving the apps for free". I disagree. There are few brands that afford to have developers doing apps just so they make money in another way.

If you think about it Apple wants their 30% on every sale you make through the app. That's why the Kindle app removed their Amazon store button.

So it must only be that most of these "jobs" will go away once they realize there is no profit to be made. Or that most of these jobs don't exist to begin with and are nothing more than hobbyists coding after their real job.

It might be just a coincidence, but my company just dropped out of the iOS Developer Program. We were too busy with out other Java-based projects and iOS demand seemed to have leveled anyhow so it made no sense to keep paying those $99/year.

It might just be the start of a trend.

Intellij needs to introduce the Lookup API

I'm looking today at the toolbar classes from IntelliJ IDEA and I'm surprised by the amount of instanceof I see.

For example, NavBarPresentation.getIcon looks like this:

public static Icon getIcon(final Object object, final boolean open) {
    if (!NavBarModel.isValid(object)) return null;
    if (object instanceof Project) return PROJECT_ICON;
    if (object instanceof Module) return ModuleType.get(((Module)object)).getNodeIcon(false);
    try {
      if (object instanceof PsiElement) {
        Icon icon = ApplicationManager.getApplication().runReadAction(new Computable() {
          public Icon compute() {
            return ((PsiElement)object).isValid() ? ((PsiElement)object)
              .getIcon(open ? Iconable.ICON_FLAG_OPEN : Iconable.ICON_FLAG_CLOSED) : null;
          }
        });
        
        if (icon != null && (icon.getIconHeight() > 16 || icon.getIconWidth() > 16)) {
          icon = IconUtil.cropIcon(icon, 16, 16);
        }
        return icon;
      }
    }
    catch (IndexNotReadyException e) {
      return null;
    }
    if (object instanceof JdkOrderEntry) return ((JdkOrderEntry)object).getJdk().getSdkType().getIcon();
    if (object instanceof LibraryOrderEntry) return IconLoader.getIcon("/nodes/ppLibClosed.png");
    if (object instanceof ModuleOrderEntry) return ModuleType.get(((ModuleOrderEntry)object).getModule()).getNodeIcon(false);
    return null;
  }

That's just horrendous!

What they need to do is introduce a mechanism similar to the Lookup API from NetBeans.

Then, if object is a Lookup.Provider, just call getLookup().lookup(Icon.class).

The above method becomes

public static Icon getIcon(final Object object, final boolean open) {
    if (!NavBarModel.isValid(object)) return null;
    if (!(object instanceof Lookup.Provider)) return null;
    Lookup lookup = ((Lookup.Provider)object).getLookup();
    return lookup.lookup(Icon.class);
  }

and each of the individual classes (Project, Module, PsiElement, JdkOrderEntry, LibraryOrderEntry, ModuleOrderEntry) will have to add into their lookup the given Icon.

As it is right now, the existing code has a lot of imports. What looks like a little Swing module (com.intellij.ide.navigationToolbar) imports hundreds of classes from all over the place and seems to be a pain to read and maintain.

Truth be told, the code is from 2008 -- perhaps the newer stuff already has a similar mechanism.

PS: While I am a NetBeans guy, I'm not trying to start a flamewar. I actually want to see if I can reuse navigationToolbar but all these imports are making it really difficult.

Magic is just programming without knowledge

There is nothing more cringe-inducing than seeing somebody try to program something without actually knowing what's going on. With some exceptions, programming allows you to know precisely what's going on. Not knowing how something works should trigger some alarm bells.

Magic might be an ancient form of "programming" nature where most of knowledge has actually been lost. Without factual information, only rituals were kept and some basic notions.

I wouldn't be surprised if in 1000 years or so we have a high-priest class of programmers that need to take care of computerized systems so old they forgot the logic behind them. They will basically become magicians.

LTS means ancient?

I was surprised today to see that Ubuntu 10.04 LTS comes with Mercurial 1.4! The latest Mercurial release is 2.1

Mercurial 1.7 also introduced a repository change, the dotencode requirement. This means any repository created after November 2010 with 1.7 and dotencode will not be accessible by the Mercurial from the Ubuntu LTS. This error should be familiar:

abort: requirement 'dotencode' not supported!

One solution is to use the Mercurial PPA to get a newer release.

But, it doesn't make sense to use an LTS if you are going to use software from PPAs, no?

With sun-jdk being pruned from the repositories, I'm starting to get annoyed by Ubuntu. I'm starting more and more to manage dependencies by hand instead of relying on the system. Which, imho, means the system is broken.

I will release an OSX-focused IDE distribution

I plan on releasing a NetBeans-based IDE distribution. Just as there are a whole bunch of Linux distributions, I believe there should be more IDE distributions.

What I intend to focus on is OSX support since, although a lot of people use NetBeans on OSX, it always looked to me like it needs more polish.

Native OSX integration is one of the reasons I wrote the NBnotify.com plugin, which shows IDE notifications via Growl. And there are other areas where NetBeans needs to pay more attention to the way it does things in order to be in tune with OSX.

I have many features in mind, but I'll leave you with just two low-level ones:

• Drag and drop installer
  
  The IDE should be available as a simple dmg which users just open and then drag and drop the application wherever they feel like it. You shouldn't need administrator rights just to install the application.
  
• Using proper OSX folders
  
  The ~/.netbeans folder will go away entirely. There are some standard places to store caches, preferences and everything else on OSX, usually in the Library folder. The IDE should be a proper citizen and store data there so that users and helper tools know what it represents, which is important and which may be discarded if disk space is becoming an issue.
  

Of course, one of the high-level features would be Growl notifications for IDE events.

So much for the first post talking about my IDE distribution. As I get closer to a release I might mention some of the other features.

When is it going to be released? Well, sometime this year, but in order to be certain let's say you should expect it in your Christmas stockings.

Why am I announcing it so early? Because I want to get some initial feedback about what people feel it's missing in their NetBeans IDE, either overall or specifically on OSX.

Also, this is as a way to commit myself to a release. So, feel free to bother me as we approach the release date.

The startup company hierarchy of needs

I've been focusing on different themes than usual with regard to my company and I've come to realize it might just be a mental shift on the Maslow pyramid.

We are still a tiny company (just 4 people) and our business isn't large in terms of income, but I think it's probably enough for me to trigger a shift into my thoughts.

Maslow's hierarchy of needs describes the stages in human growth and it seems to apply just as well to a company:



Physiological needs

The lowest level in the Maslow pyramid are the physiological needs. These are the basic survival needs: air, water, food, shelter and sex.

There is nothing fancy here. A company at this stage is basically aiming for that ramen profitability. Everything else are mostly nice thoughts, because the immediate future is all about corporate survival.

When I first started my company, this was the most important thing. I didn't care about anything else, except knowing that I had customers and I was profitable. Of course, personally I've been lucky to have some nice and decent customers where I worked on some interesting stuff, but from a corporate standpoint it was all about being profitable and having projects to keep me, and later my team, busy and liquid.

Safety needs

Wikipedia has a nice explanation:

These needs have to do with people's yearning for a predictable orderly world in which perceived unfairness and inconsistency are under control, the familiar frequent and the unfamiliar rare.

This is where I find myself to be since about last summer...

Ever since the financial crisis came in Romania too, the government has made a lot of unexpected and rash changes: laws changed over night, tax legislation changed, corporate expenses limited by law in weird ways.

Also, corruption was left basically unchecked, while the government still found enough time to waste money.

So, I've started yearning for some predictable legislation (fiscal, labour, etc) as well as a reduced threat of corruption.

I still haven't found a solution to this. Since changing Romania first is impractical, I've been reading a lot about incorporating into other countries.

This is a complicated equation involving corporate specific variables such as taxation, accounting expenses, rent as well as personal variables: I'd probably need to relocate or travel a whole lot more and that's hard.

Love and belonging

Love and belonging has two levels in a company: internal and external.

Internally I don't think we have a particularly strong belonging feeling since we were very focused on just getting the job done. We are distributed in 3 cities quite far away so there is no physical closeness which I think hinders us a bit.

This is something we should work at, but I guess it's not on the list yet. One of my future plans is maybe get an actual corporate office but that's a problem in itself and it would split us: 2 guys would work in an office and 2 guys 500km away.

Externally, the company sends upstream bugfixes for the open-source code we work on, we support the localization effort into Romanian of an open-source product and this year I want to get a junior researcher / student into a part-time position doing open research (it's basically a sponsorship disguised as a job since legally it's way simpler).

But, sadly, the company isn't involved at all in the local community.

Esteem

Esteem means wanting respect, status, fame and attention as well as self-respect, competence, mastery, self-confidence, independence and freedom.

So far the company is very low level and mostly "behind the scenes". We basically do contract work so the end users never know anything about our involvement.

It would be nice to be known by our users and even nicer to be independent and actually sell products to end users directly. But we are not there yet.

Self-actualization

"What a man can be, he must be." Realizing the full potential.

I'm not even sure what to speculate here. I believe we have something interesting and I'm rather proud of my team but I couldn't say exactly what the full potential is. Still searching this one.

Conclusions

Maslaw's pyramid seems to be a quite nice simplification. Of course, the layers intertwine and evolution isn't linear like that but it seems to apply quite nicely for a startup too (which isn't entirely surprising since a company is a social construct.)

It might be an interesting exercise to analyze your own startup through this hierarchy and see where do you stand as well as what you should be focusing on.

The IDE must move onto the server

Here is a video of my prototype online IDE (watch it in 720p if possible):



It's basically a subset of how I think a browser-based IDE should look like and where we should get, pretty soon.

I've just focused on some essential parts in my prototype:

• The IDE must be accessed via a standard browser and should be installable (ie. your own startup should be able put it on a dedicated server).
• Project/user timeline with commits, bug reports, code reviews, etc.
• Good editor: syntactic and semantic highlighting, project-based code completion, code folding.
• Running tests locally (a signed applet gets disk access if needed) or remote. I guess the local part is just for reassurance and, perhaps, offline fallback.
• Some form of chat for internal communications.
• Integrated metrics and reports from various sources (FindBugs, build server, project planning tools, etc).

The most important thing is the editor: I still don't see a good Javascript-based editor and certainly not one for Java, which is what I would need.

The next thing is the proper integration of the various external tools. You could hook the build server test results and findbugs warnings straight into editor hints or error stripe, for example.

I also think nobody is focusing on the kind of automated learning we could apply to projects once everything is in one place. Nothing says progress like a browser Clippy saying Hey, it looks like you're solving almost the same threading problem as John did on this other bug 3 months ago.

All in all, my work is just a prototype. But I do hope that in the near future I wouldn't need a workstation to do my job -- just a humble device with a decent network connection.

About the Hudson debacle

There are some big discussions about forking Hudson. Oracle's latest response seems to have triggered this reply from Hudson's main developer Kohsuke, now hired by CloudBees.

Personally, I don't see all that much negativity in the Oracle message. Actually, it seems very well balanced.

One thing I agree entirely: there is no such thing as a project "renaming". We are talking about a fork. Even if the Jenkins fork becomes the one with the biggest market share, it's still a fork.

This reminds me of the EGCS fork of the GCC which became so good it actually became the next 'official' GCC release. There is still a chance this might happen for Hudson/Jenkins so I don't see why Kohsuke seems so eager to burn all the bridges with Oracle.

I am also part of the "community", using Hudson since before it was so fashionable, and I don't see why should I be so enraged about all this? I guess I am too cynical not to notice that there are two companies involved: CloudBees and Oracle and only one of these two makes money almost exclusively from Hudson-based services. I think there's a natural conflict when for-profit companies make money from open-source software -- they'll always want to keep some proprietary "added value".

What I did understand is that Oracle has some fear of using non-Oracle infrastructure (github, etc) which seems to annoy some of the developers. But, other than that, I don't understand the need to fork the project.

Slow hardware means lost opportunities and developer frustration

At my first job, after a steady pace of desktop applications, I was asked to make a web application.

It was 2006 and JSP was the big game in town (ah, taglets), Struts had just become a toplevel Apache project, JSF was just starting and Spring Framework was the only same-looking thing, at some 1.x version.

Having worked with Java on the desktop, the options were Java on the server side too or learning something new (I ruled out PHP quite early).

Thus it came to choose between something that seemed very flashy, called OpenLaszlo or a servlet-based Java solution, with PostgreSQL as the database (I didn't like MySQL either).

OpenLaszlo was quite interesting because it compiled to Flash so you could create quite beautiful pages. It would have also mapped quite nicely with the application as we required some rather custom stuff. Also, the site was used by management so charts and other flashy, interactive content would have been welcome.

In the end I picked a Java servlet solution, using Spring framework and a whole lot of the solution was custom-made.

The reason ? The laptop I had back then could barely run OpenLaszlo locally!

It was some clunky Compaq with 1GB of RAM (I got 2GB at some point) so it could barely keep up with a normal XP/Eclipse/Browser/email configuration, let alone run my local database and local OpenLaszlo server.

Of course, that might also have been a blessing in disguise, because who knows how easy it would have been to actually implement everything with OpenLaszlo? But, the problem is, we'll never know.

Ever since, I consider that developers need to have access to good machines. Software development is a hard job as it is, you don't need to fight your machine too.

Sure, some low-level computer might be used for testing purposes, but expecting the programmer to use a slow machine just because that's what the users have (or because there is no budget) is the seed to a lot of lost opportunities and developer frustration.

The 'miserable programmer paradox' isn't about technology

I've read a blog today which states that there is a miserable programmer paradox:

A good programmer will spend most of his time doing work that he hates, using tools and technologies that he also hates.

And the conclusion seems to be that it's all about the technologies that the programmer is using:

The bad technologies take big chunks of time and concentration. The good technologies take little time and concentration. The programmer has a fixed amount of time and concentration that he can give every day. He must give a bigger piece of the pie to the bad technologies, simply because they require more. In other words, he ends up spending most of his days working with tools and technologies that he hates. Therefore, the good programmer is made miserable.

This conclusion seems flawed because it assumes the programmers have no desires and preferences.

The conclusion reminded me of this interview called Edsger Dijkstra -- Discipline in Thought.

In this video, at 11:48 we have a very interesting quote:

And the programmers weren't interested [in faultless programs] because they derived their intellectual excitement from the fact that they didn't quite know what they were doing. They felt that if you knew precisely what you were doing and didn't run risks, it was a boring job.

I think this is a much better explanation for the miserable "good" programmer paradox (as defined above).

The good programmer is miserable because he doesn't get to use the shiny tools and technologies and because he feels bored by the fact there is nothing new.

But he is also good because he knows exactly what he is supposed to do.

Technologies and tools might have a part, but I think the humans in the equation are much more important to look at when searching for answers.

iPhone app which automatically rejects hidden or blocked callers

June 2nd 2013 update: The Do Not Disturb feature from iOS 6 provides something similar. It doesn't allow users to filter per call type but it does allow a "quiet" schedule which is very useful.

noblocked is an iPhone 3.1.3 app which automatically rejects incoming calls from callers that are hidden (or shown as blocked by the iPhone).

All the other calls aren't affected.

This app is not a generic whitelist / blacklist caller app, although it could be easily extended to do that too.

I wrote the app for personal use but I'm releasing its source code so that other people may learn from it -- I know it took me a while to get used to notions like private frameworks, etc. since I've always used only the official, documented, APIs.

Obviously, I'm not going to submit this app to the AppStore.

A precompiled binary is available in the downloads section but I haven't actually tested it, it's just an unsigned build I've uploaded. Clarifications or some testing would be nice.

Go read org.openide.modules.PatchedPublic for some binary backwards compatibility magic

The @PatchedPublic annotation was a nice surprise. Let's see:


/**
 * Marks a method or constructor as being intended to be public.
 * Even though it is private in source code, when the class is loaded
 * through the NetBeans module system the access modifier will be set
 * to public instead. Useful for retaining binary compatibility while
 * forcing recompilations to upgrade and keeping Javadoc clean.
 */
@Retention(RetentionPolicy.CLASS)
@Target({ElementType.METHOD, ElementType.CONSTRUCTOR})
public @interface PatchedPublic {}


This is a really brilliant way to force your codebase migrate to the latest APIs while maintaining binary backwards compatibility.

The idea is that you have an old method that you want to deprecate and eventually remove:

@Deprecated
public void doSomething();

The nice thing about @Deprecated is that it's a flag that signals to the API users they really shouldn't use it, but it doesn't do much else: new code might still be written against the method and your existing codebase might still use it.

So you replace it with

@PatchedPublic

private void doSomething();

Since the method is now private, all your local code that uses the old public method will fail at compile-time and will be forced to migrate to the proper APIs. That takes care of one thing.

New API users will also be unable to use it since it's private: they'll never learn about it! The bad thing about @Deprecated is that while it gives a signal to previous users that they should migrate to something else (which is nice), it also gives a signal to new users that they might do their task using some other method -- which is really bad, as they might just disregard the deprecated warning and still use it.

So the only issue now is how do you keep running the previous binary code?

The reasoning here is that if you still have humans compiling code, they will kinda be forced to migrate to the new APIs due to the compile-time errors. So source-code compatibility might not be as important for this given method.

But a big problem is when you have binary code executing -- that code will fail at runtime!

The trick is to leverage the fact that NetBeans has its own module system that does class loading and patch that class at runtime. (This is probably something they couldn't have implemented if they depended on some external OSGi container).

Since @PatchedPublic has a CLASS retention policy, it will be part of the bytecode and thus accessible by the module system. Thus, using probably some bytecode engineering, the method will be patched at runtime to become public and the old binary code will execute just nicely.

I'm usually not a big fan of annotations (I find most of the new NetBeans annotations that replace the layer.xml as more confusing instead of simplifying) but this annotation was a nice find.

But how did I find this annotation?

Well, I'm one of those guys that still has source code compiling against methods that used to be public and I'm now trying to figure out how to update my code :-) A bitter-sweet finding.

Browser based IDE

I'm spending a lot of time using the web browser, either to read my emails, check my build status on Hudson or see the latest changes on BitBucket.

Most of the stuff I produce is destined to live on some server: emails, blog posts, wiki pages, issue tracker comments, source code changesets, build tags and even the builds themselves. This means that, most of the time, the local data is just a temporary cache until I do my task.

But modern day web applications should provide just this: a way to do you task using a local cache and then publish it to some remote server.

The IDE is a prime candidate for a serious web application: your projects are always in some version control system, developers really care about their IDE configuration and the server could really help with the workflow and build times.


Your projects are always in some version control system

The local cache is just a matter of convenience, what you really care about are your local source code changes which become your changeset.

Losing the local cache shouldn't be a problem other than the inconvenience of waiting for a re-download. Treating the local source code tree as something transient will encourage better practices like simpler workspace configurations.


Developers really care about their IDE configuration

Installing the IDE on a new machine means spending time re-adding your preferred tab-size, formatting options and so on. A web app will just store that in your user preferences.

The server is very good with caching and indexing


There's nothing more annoying than noticing how much time the IDE spends indexing or processing very popular libraries like Apache Commons.

Imagine how much CPU has been used world-wide indexing the same library over and over just so you could see some methods in a code completion popup!

All that wasted developer time might have been replaced by having the server index and cache a given library version and then just download (part of) that index when needed in the browser.

The server is very good with large builds


If the backend server if powerful, you could offload large builds to the server too. An artifact might take a lot of time to compile on your local machine, but it might run a whole lot faster on a powerful server or distributed on some build cluster.

If the time it takes to build on the server plus download the artifacts on your machine is much slower than just compiling locally, why not do it ?

Plus, you could even share the build artifacts with your team! Using some server-side approach, you could just ask the IDE post the build on the server and share the artifacts among the team (yes, I know about Maven repositories).

Web developers' dream

But I'm writing this from the perspective of somebody that does desktop applications (NetBeans Platform based, actually). What if you are writing a web app ?

Well, after you press "deploy" you just let the IDE upload your app to the test server and just open another browser tab.

Or, you press "deploy" which commits your changeset to the IDE backend server that saves it into your local history then uploads the new app to the test server. Pretty soon all the hard work happens behind the scenes and you are free to work on huge builds using really low powered netbooks.

And if you only upload / download changesets, you just might be able to work over dial-up!

Thin, Thick, Remote client ?


Of course, there are a few moments when developers are offline or when the bandwidth isn't abundant, so I don't view this browser based IDE as a remote client or a thin client that sends everything to the server.

I see it more of a thick client -- it's just as usable offline but much faster and convenient online when offloading work to the server too.

Some of the features listed above would only work if the server does your builds and has access to your source code. So they wouldn't work if you are just using the IDE to work on private projects, that remain on the local machine and never touch the IDE's backend servers.

To be continued...


This is just a first blurb about how I imagine a browser based IDE and I'm looking forward on seing it happen either as some Javascript thing or as some NetBeans fork running as a super-applet with local permissions.

Google might be serious about Chrome OS and their Cr48 laptop, but they don't mean business until I'm able to develop on one too.

This might also be the end of the IDE acronym because I'm not talking about an integrated development environment but a distributed development environment.

NBnotify: NetBeans Growl notifications, now with its own website

http://nbnotify.com/ is live with the latest version of the NetBeans plugin which displays Growl notifications for builds (as well as everything else the IDE might need to notify you about).

It took about a week to get this up and running, but mostly because we had a weekend in between.

Andrei was paid to take care of the WordPress magic, I just provided the budget (yeap, open-source still costs money besides time), text, screenshots and the video.

Speaking of the video, it's surprisingly hard to find a tool that records plain .avi on OSX. Hard because Google is oblivious to the changes in Snow Leopard where I could just use QuickTime to do File | New Screen Recording. Of course, I've only seen this now, and fiddled with Camtasia, Snapz Pro X (which worked) and Jing.

Have fun with the plugin and let me know about it!

Linguistic musings

There are two notions that to me seem have been injected out of the blue into the mainstream.

First: systems programming (language)


This came for me out of nowhere. The first Wikipedia articles are from 2004 (and late 2003) but I've never heard it until Google Go was described as something good for systems programming.

If you look at the Google Trend for "system programming language, systems programmer, google go language" you should see something like this:

So basically all variations start showing up the same time as Google Go is introduced and even those that show up are basically job adds that just happen to have 'systems' and 'programmer' in them.

It's safe to say that Google Go brought the word systems programming into the mainstream.

If you are looking at Wikipedia, even the description of the C programming language is filled now with "system software" and "system programming" but go as far as the 2004 version and "system programming" is gone.  In the late 2002 Wikipedia version it doesn't even mention 'system software'.

Second: curated computing, curated platform

I think Apple thought long on hard about how to put a positive spin on the whole closed ecosystem they are selling with iPhone and AppStore and figured out the curated word. It's actually quite brilliant -- the experience is locked down, but it's curated, so we have someone there (the curator) that cares deeply about your experience.

Enough with my linguistics musing for tonight. Let me know about other words and phrases I might have missed!

Building an iOS project with Hudson

I'm mostly writing this here for archival purposes. This is how I used to build iOS projects via Hudson (I don't have any iOS projects ongoing).

First, since Hudson runs on a Linux machine, I need to add a new node then start the agent on an OSX machine from an account where I have all the digital keys set up properly.

Next, supposing I have an iOS app called Example, I just tell Hudson to poll the SCM then execute the script:

TIME=`date "+%Y-%m-%d_%H-%M-%S"`;


rm -r build || true;


xcodebuild -target Example -configuration Distribution -sdk iphoneos3.1.2 clean build


  && 


  (mkdir build/Distribution-iphoneos/Payload; mv build/Distribution-iphoneos/Example.app build/Distribution-iphoneos/Payload)
  
  && 
  
  (cd build/Distribution-iphoneos && zip -9 "example-$TIME.ipa" -r Payload)

Afterwards Hudson just needs to "Archive the artifacts" from build/Distribution-iphoneos/*.ipa


Obviously you need to tweak the sdk version a bit as this script is for an older 3.1 app but this is the gist of it.

Now you just have Hudson doing builds as soon as a commit comes up and you can send updates to customers by just grabbing the .ipa file from the Hudson site (or even give customers direct access to Hudson and have them download a build as soon as available).

NetBeans Slowness detector with Growl

Got surprised today when I saw the slowness notification on Growl:

I rarely get this message but it's nice to see it published via Growl, using my OSX Notifications module which is a Growl bridge for NetBeans Platform notifications.

Clicking on the notification

gets you this:

I'm not entirely satisfied with the way this message is presented because I would need a "Close" button, not an "OK" button. Also -- clicking on that hyperlink seems to open a new window behind this dialog.

Anyhow, there isn't much I can control since we have a lot of native components due to the broken OpenIDE AWT NotificationDisplayer API which encourages custom JComponents.

This particular notification for example should use no custom component. It should just say: "Slowness detected: Not responsive for 5 s" and then clicking on the (Growl) notification should open the "Report Problem" dialog.

Java (NetBeans) antialias issues

I ran into some antialias issues with NetBeans on Windows.

Here is the list of pages opened in my browser in case you don't want to Google as much:

• http://netbeans.org/bugzilla/show_bug.cgi?id=137845
• http://www.javakb.com/Uwe/Forum.aspx/java-setup/11041/Java-6-Swing-bold-font-problem-on-Windows
• http://download.oracle.com/javase/6/docs/technotes/guides/2d/flags.html#aaFonts
• http://forums.java.net/node/683260
• http://download.oracle.com/javase/6/docs/api/java/awt/RenderingHints.html
• http://download.oracle.com/javase/6/docs/api/java/awt/doc-files/DesktopProperties.html
• http://hedayatvk.wordpress.com/2010/02/26/antialiasing-and-java/
• http://download.oracle.com/javase/1.5.0/docs/guide/2d/flags.html
• http://download.oracle.com/javase/1.4.2/docs/api/java/awt/Graphics2D.html#getRenderingHints()
• http://www.docjar.com/html/api/sun/awt/SunHints.java.html
• http://www.docjar.com/html/api/sun/java2d/SunGraphics2D.java.html
• http://www.javalobby.org/java/forums/t98492.html
• http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6263951

NetBeans Growl notifications

Demo time

This plugin provides Growl integration with NetBeans. If you are using NetBeans on OSX and you have Growl, download my plugin.

As a proof of concept builds are shown but all other notifications that usually would have appeared using the default implementation are now posted via Growl.

Complex UIs trigger just a simple notification and then display a dialog when clicked with the actual custom components (obviously one can't publish custom Swing components in a Growl popup).



Speaking of complex UIs, some custom components are just JLabels that simulate hyperlinks so I would say those might be migrated to a normal text and ActionListener.

Background

One thing that NetBeans needs is OS-aware notifications and my two focused OSes are Ubuntu and OSX.

On Linux we have the Desktop Notifications Specification, which is a very clean, D-BUS based specification for desktop-wide notifications.

Ubuntu extends and modified the specification a bit as well as define a quite nice design guideline document.

Growl defines the OSX notification standard which is generally similar to the Ubuntu version. Their documentation provides a nice overview of their API.

NetBeans on the other hand has its own notification API in the via the OpenIDE AWT NotificationDisplayer API.

The problem is that all these are disconnected, but rather similar given the nature of the problem they are trying to solve.

What I think NetBeans is missing on OSX is a proper Growl bridge. Also, the NetBeans API should be modified to discourage custom components as those aren't easy to bridge to something else.

Implementations

It's rather hard to find Java bindings for Growl as the official implementation is deprecated.

Next, I was able to find Grrrowl by Sonatype, which uses native code (via HawtJNI) and seems to be originally part of IntelliJ. There's also a fallback implementation to AppleScript which is nicely provided as pure Java scripting engine on an Apple JVM.

The problem with Grrrowl is that while it does display notifications quite nicely, it doesn't support any click handlers, so we won't be able to respond to user interaction.

The best implementation seems to be a very low-profile implementation by Michael Stringer, posted as stringbean on CocoaForge.

Michael Stringer's version uses actual JNI and provides a click handler. This is what my implementation uses.

Obviously, it only works on OSX, specifically, Intel-based OSX (because that's what I used to build the native code).

Let me know what do you think about it.

MySQL as the first NoSQL database

I was watching yesterday a presentation at GeekMeet Timisoara about how to scale your websites and all the MySQL-related advices were as expected, but upon thinking about it, entirely agains normal database mantras:

• You should de-normalize the database (copies are easier to access and cheap)
• You should disable transactions (ie. use a MySQL storage engine that isn't transactional).
• MySQL Master-Slave replication (which is asynchronous!)

This made me realize that MySQL is successful precisely because of all the things I discredited it for.

You see, in my book MySQL was never a real database because, initially, it wasn't transactional. For the project where I could choose the database, I picked PostgreSQL and I always used MySQL knowing in the back of my head that, in fact, it was a bit of a sham.

But this might just be MySQL's good fortune: by providing a simple storage engine with some SQL front-end, they proved that most people don't need ACID compliance.

Furthermore, as more and more people need to scale their applications horizontally (since it's cheaper and because... Google does it), they need even less of an actual database.

NoSQL was a movement that started after people got tired of the constraints of SQL databases and started thinking about what do they really need when storing data. It was liberating to see that one must not assume from the start that "external data==database" and actually put some though into the specific needs of their application.

And by being such a lightweight and unconstrained implementation, MySQL is right here, still serving the needs of people that want to scale out.

MySQL was basically the first NoSQL database. By relaxing what a database must provide, they proved in the long run that this is what people actually need. So besides the pure NoSQL tools like the various key-value stores they are building nowadays, MySQL could very well remain the most used place to store your data precisely because it allows you to pick which of the database-specific features you actually need.