Skip to main content


Showing posts from 2011

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 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 a…

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,…

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 i…

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 compani…

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, usi…

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 …

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 test…

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.
@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:

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 …

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 …