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.