OpenSolaris 2008.11 on Virtual Box

I've just installed OpenSolaris (AKA "Slowlaris") on my new MacBook, using VirtualBox (screw you, VmWare!).

Overall, everything fubar, exactly as expected: now it finally boots from GRUB and does not hangs as before, trying to use AMD on Core Duo; network is OK and won't suck anymore, as it did in "Nevada" build; video barely works in a simple mode and VBox Additions won't help you out of the box.

To fix video working full-screen and seamless mode, it is needed to be manually fixed, by simply removing away all of those display resolution modes from /etc/X11/xorg.conf file and also setting up virtual machine with 64Mb of video memory.

Second step is audio that won't work anyway anywhere, unless you manually debug it again (as described above). First, throw away slim_install package, a waste of space dependency that keeps root of all evil: SUNWaudiohd package. After those two gone, get OSS driver for Slowlaris and install it (pkgadd -d package-file.pkg):

Open Sound System installation complete
You can use osstest command to test audio playback in your system.
It may be necessary to reboot the system before all devices get properly detected by the system.
Installation of OSS was successful.

Damn great! Unix follows now the most popular trends, exactly like in good-old WinNT times: install a driver, reboot the system...

P.S. Sound still sucks on Solaris big time and also randomly crashes (/usr/sbin/soundoff and /usr/sbin/soundon cures current random crash). Well, never mind, I don't need sound during packaging software and, besides, I use iTunes on my Mac anyway... :-)

Swing and Hibernate (feedback)

I've found an example how to use Hibernate in Swing.

Not to mention weird existence of HQL entity in general, you have to use it for the very trivial SQL request. Why?.. Oh, that's a "short-cut" to automatically generate very inefficient and wrong SQL query, I see.

You also need a pile of XML to configure your ORM. Then you need another pile of XML to map your database stuff to the objects through these entities. Ah, right, you also need those excellent entities themselves just to hard-design your application, thus making it rock-stubborn against any minimum changes, removing any possible flexibility without whole recoding and recompilation. After all at the end, you also need to hard-code your QUERIES_BASED_ON_VARIOUS_CRITERIA (look at the code in the example to understand what I am talking about).

*Sigh*... It is just all pathetic... Disappoints even more, than that anyone could expect. Hey, folks, wake up! ORM supposed to make life easier, not harder!.. Therefore, if ORM concept does not makes your life any easier but generates a mess of general hodgepodge, maybe quite correct logical conclusion would be to do not use it at all?

Legacy databases solves legacy problems. We need new databases and new approach to the data management. Thus having it simple and understandable: keep sets away from objects.

Moral: Keep it simple, stupid.

Java + Groovy

If you do not need a blazing rocket-science performance, but just need to toss up some prototype or even production software in Java platform, but you really-really-really do not waste time on Java language verbosity, you may consider using Groovy as a dynamic language extension to the Java platform.

Let's do something silly, but to see how the things are interacting between each other. For example, let's read our "/etc/passwd" into a list and display a first element of it from a plain Java, omitting an empty lines and/or commented ones. :-) Here how it is done in NetBeans IDE:

1. Make sure Groovy support is in your NetBeans 6+. Usually it is there out of the box, but maybe some plugins must be installed. Check it by Plugin Manager, navigating to "Menu→Tools→Plugins" and see maybe you need some tweaks in Preferences for Groovy specifically.
   
2. Create new Java Application project. Let's call it "JavaAndGroovy".
3. In your package, called now "javaandgroovy" create a Groovy Class. Since it is an example, let's call it "Grovample".
   

Great. Now is a time to read the file with one codeline, as a text and return a list of the lines. Here you go:

package javaandgroovy

class Grovample {
    def readfile(filename) {
      List data = []
      for (line in new File(filename).readLines()) {
          line = line.trim()
          if (line && !line.startsWith("#")) {
              data.add(line)
          }
      }

      return data
  }
}

Now, to use this class in the plain Java, just... use this class! Like this:

package javaandgroovy;
import java.util.List;

public class Main {
    public static void main(String[] args) {
      List passwd= (List) new Grovample().readfile("/etc/passwd");
      System.out.println("Lines: " + passwd.size());
        if (passwd.size() > 0) {
          System.out.println("First line: \n" + passwd.get(0));
      } else {
          System.err.println("Well, you're on Windows. :-P");
      }
  }
}

As a result, I am getting the following output:

Lines: 40
First line:
nobody:*:-2:-2:Unprivileged User:/var/empty:/usr/bin/false

Now, let's look how the distribution looks like. Press "Clean and Build" button or simply navigate to your project directory in the terminal and run "ant" command. In a "dist" subdirectory, here is the following tree:

.
./JavaAndGroovy.jar
./lib
./lib/groovy-all.jar
./README.TXT

File "groovy-all.jar" has a weight of 2.7Mb. Not so small for very tiny apps, but not so big for bigger ones. You might consider put this lib in your GlassFish somewhere, in order to do not deploy it every time with your WAR/EAR. :-)

Keep in mind: Groovy is significantly slower than plain Java. Really slow. Check out it how much slower. Still, it does not means that we can not use Groovy for many-many tasks around and simplify our Java code.

Happy Grooving! :-)

Beast 666

Beast 666, originally uploaded by I.S.B.M..

In this Sunday, on a street I saw very weird car, made out of various different parts. That's was a real beast! :-)

Why Ajax is evil

"Ajax or not Ajax?"

Making my yet another Swing app on Java, I've been thinking on an answer to a question:

Honestly, what the hell Ajax thing is so special, so many people
are rushing in to use it just right everywhere?

So much time went away since ESR wrote his excellent "HTML Hell" page. I am just wondering who is reading this?..

I found this Ajax thing is not just mostly bad idea, but actually it is that evil. To the company of public resources it is not yet that much harmful, but for the enterprise it is. Because it simply has no future, whilst your enterprise is already poisoned by this stuff, probably. Hence you have to support it or spend some more money to rewrite your project. Here a list of main issues (too lazy to write much):

• There is no real integration with a desktop, but through a web browser. Hence, your application acquires all the limitations.
• While Ajax website is more fun to use, yet you're nearly have to pray for your browser worked properly with a particular website.
• Issues with off-line and on-line modes. To write entire application in a JavaScript that sits in a memory of the browser is not really a thing you want to go.
  
• Your browser is not working as designed: history issues, refresh will destroy everything etc. Of course, there are (expensive) workarounds to avoid state loss on refresh, but history won't work anyway.
• Google won't index your website much, once your HTML has nearly one tag, like: <script>EntireWebsite.build()</script>
• There are no real widgets, except standard HTML ones. There is an emulation of such.
• It suppose to deliver only an user interface. However, in practice it often takes place much wider scope, thus interfere with other paradigms.
• Quirky, full of hacks and tricks JavaScript code and CSS stylesheets. Once browser's vendor changes something that breaks your page, you have to fix it.
• It is very expensive ("time" equals "money", you know) because of its heterogeneity. Typical Ajax application is a hodgepodge of various stuff: XML, CSS, HTML, JavaScript and a thing on a server-side (call it yourself: Java, Python, PHP, Ruby... whatever).
  

But the main issue with Ajax is:

There are NO standards!

Very "good" at enterprises, right? You might say: there IS a standard specs: ECMA Script, CSS, XHTML etc. Yes. You're completely right till the point of... different browsers differently spits on those specs. Look at the reality: today we have 21th century, while the best open source browser (Firefox) can not hit even 80% of Acid 3 test! What browser is the most popular at a regular Windows box and how much percents this thing can hit of Acid 3 test?..

When you select a technology for your online perfume shop, then maybe you have to think how often your site random people are going to use. At that time Ajax DHTML stuff with plain alternative would be OK. However, if it is an enterprise under controlled network, I doubt any browser is the best Virtual Machine for scripting.

The future is quite different. If you increment that O'Reilly's buzzword one more time up to "Web 3.0", you will find that there is just no Ajax. There is JavaFX. There is Java Swing and a Java Web Start. There is Adobe Air and all the rest of Adobe multimedia streaming magic. There is even Microsoft Silverlight that works pretty well. But there are no Ajax...

If tomorrow there is no Ajax, maybe you should not bother much with it, but go to the next level? Thus, before you rush to follow everybody's hype and bubble just "to be as everybody else", better really think about it twice. Or more.

"I hate what you just saying, it's all lame!"

OK, dear social networker, to raise a finger on a problem is not a big deal, I agree with that. Thus some solution should be proposed. I could drop you a few lines why I would choose Java Swing + web services versus Ajax stuff at enterprise. As well as why I would choose JavaFX, if I need funky RIA for fun. Keep in mind for yet your perfume shop can be just as damn great without any Ajax thing, you know... — simply look at Amazon.com and take it as an example for yourself. :-)

Here you go:

1. You anyway want to go SOA, no matter what type of UI you have in a front.
2. Java Swing has a rock solid internal standards and runs identically on various platforms.
3. Swing is homogeneous. Your employees can be specific to Java only and do not need to know a mixture of various stuff and be proficient in each.
4. You can make whatever hell widgets you want with any possible shapes and behaviour, because the whole thing is just a plain canvas, that simply listens to input events, after all.
   
5. You can use only Ruby or only Python as well (JRuby or Jython), if you really like to do so.
6. You can create Swing GUI literally in minutes in front of your customer's or manager's eyes, using NetBeans and Matisse editor.
7. You still have clear MVC and you distinguish what is business data, and what is just a way to deliver it to user.
8. You have clear desktop integration.
9. Your internal company network is highly controlled, so you do not need to worry something is randomly missing on random machines (otherwise fire your system administrators ASAP because they are just morons).
10. ...I can continue this list till you fall asleep. :-)

If I would have say what is the future of Ajax, then I would say:
Ajax is a very expensive way to pimp your business network resource and this way of data delivery will eventually die on web applications market.

Have a fun!

Me on Architects

“Trust me that looks good, I'm an architect!!!”

— Any pretentious architect, or any for that matter

I've been often asked very stupid strange question:

"Should architects write a code?"

Should father take care of his child as deeply as possible? Should surgeons operate? Should Rudolf Christian Karl Diesel be aware of principles of physics for analysis, design, manufacturing, and maintenance of his great engine?

Let me tell you something here. See, in IT world, actually, there is no such thing as "architect". There are software engineers. Some of them are so serious about software, that they're building their own hardware.

So what does they do? They do know what to expect from some certain hardware. They do also know how their and related software works and what to expect. They also do everything actually, hands on. Just close your eyes and imagine a senior architect of any (nuclear) submarine, just has no idea about very details in the machine room or navigation system and does not getting how it all works, what to expect from certain modules and what these little things does in different places inside the submarine. Remembering that everybody else will simply follow the instructions of such senior architect, how far this submarine will go, you think?..

However, all times in IT there are plenty of parasites like in my example above. Typically, they are heatseekers and speaks damn really a lot of buzzwords or (recently) simply abbreviations (often they turn to change a topic, if you ask about one some specific details). Since they say a bunch of cryptic words, everybody else thinks: "Oh, he is a God!". No, he is not. Not at all.

They mostly spending their time on (useless) meetings, making them as long as possible and as much as they can per a day: to blah-blah-blah is much easier than type-type-type-compile. Instead to code, they do prefer to draw boxes and join them with arrows in some drawing software or (better) on a board in front of those, who thinks he/she is a God. On top of this, they mostly have zero of real hands on experience. More advanced parasites can work only on prototypes and usually they deadly sticking exclusively to one single technology, making no steps forward to look around. One will bluntly repeat you: "Perl! Perl! Perl! Perl! Perl!", another: "Java! Java! Java! Java! Java!", yet another: ".Net! .Net! .Net! .Net! .Net!" and so on and so forth.

In real life, especially when company is big, they will avoid any real full-scale coding participation, but will switch to paperwork and e-mail broadcasting. More advanced will try to give a born to simply CGI scripts or similar prototyping.

Why it happens so? Obviously, because they are too dumb to learn something new, hence they do have ZERO CLUE what is going around and how industry is trying to break the walls. Thus they do not know current problems and are not passionate to SOLVE them once and forever, simply because they are not really a geeks. Therefore, as a consequence, only what they can do apart of saying abstract incomplete "just ideas", they WILL do dirty politics things, disturb real engineers with brain-less directives and environment changes, will go write [useless] documents with a stupid injunctions, make moronic rules, release crazy instructions, do not care about company, but simply suck money as much as possible, fill their LinkedIn.com profile with best recommendations from their friends they drinking with and then disappear, moving to another victim company.

But the company will continue to live with completely brainless bullshit solutions that are quite useless or in real full-scale enterprise. So if you are employer and someone call himself/herself "trained architect" and "prefer to design, rather to implement" — simply avoid such candidate as soon as you can, no matter what his BranBench results and a bunch of other certificates/diplomas says.

Shortly: either you provide or you are politician.

Have a good day!

X11 + Gnome with Bugs = Kick For Innovation (Part 2)

Running Linux Mint on xVM. Uhmm... Not that bad anymore as it was before!


Still window borders and bluish title bar on a standard JInternalFrame looks very bad (in my opinion), but this is not really what user will pay attention at. The only one thing left: remove Java logo icon on the left side of title bar.

Ah, and I've added fade-in and fade-out effects when my modded window appears and/or disappears. Not really important, but just feels more smooth.

Update: I had to go across the code a bit to make sure now it works as should be on Slowlaris (2008.11, running on the same xVM). Nimbus default theme from Gnome looks pretty clear and not that bad. Default Java 6, Update 10 is a pleasant thing. Yet I am not getting why there on JInternalFrame that small Java logo is rendered *twice* on a title bar: once crappy, with extra-garbage pixels (on left) and once pretty good, near the title actually. Well, probably must be a Sun advertisement of their flagship trend...

Here how it looks like (no change much from previous shot above):



P.S. Damn, anybody wants to make it works on Windows?... :-(