Google and Darth Vader

I stumbled on so many articles lately, both on the web and in print, about the emergence of Google as the second-most hated/feared company after Microsoft. OK, enough said. Let me now draw parallelisms of Google and Darth Vader. This can be simple urban legend of some sort.

Darth Vader : was born and then-known as Anakin Skywalker. He was born out of virgin birth (no father). He was created straight by the force. We was the chosen-one, destined to bring balance to the Force by destroying the Sith. However, he fell in to the dark side and became a Sith Lord himself.

Google : was incorporated in 1998 and had seen a phenomenal growth through the pasts years. Google was having an anti-corporate, developer's-dream image that it is a company that geeks love see as the most capable of being a Microsoft-killer (apparently climaxing at the much speculated GoogleOS). Story to be continued...

Made-up Story : with Google's war-making chest, it is capable of producing quality products that can be better than the much bigger Microsoft. But now, being as aggressive as Microsoft (the Sith) in its startup years, Google is being hated, if not feared, in Silicon Valley. Google's aim to outwit its competitors earned it the right for a second look from the tech community as well as corporations from the Silicon Valley. As Microsoft has said, Google is the most Microsoft-like company that they ever competed with. But, have you ever heard of "if you can't beat them, join them". Oh, it gives me the creeps that the more Google becomes aggresive, the more it'll be enticing from Microsot's eyes. It can either be defeated OR absorbed (merger). Without Google, there'll be no company large enough to battle with the giant (no, F/OSS community cannot do it without being backed-up or "forked" by a large company, ie. IBM). With Google merged/acquired by Microsoft, your desktop-bound and mobile life will end up micro-googling everything.

Beware, the heralded Google could be straying into the Dark Side.

richard@work

Open Source TODO too

I stumbled on this blog. It makes me realize how working on a non-open source company collides with an equal passion: development and contribution to open source. As I see it, I might only have a chance if I quit. But not for the moment, my job is my bread and butter. So, open source can wait. For the mean time, I'll tune in to our application (Java).

richard@work

Pinoy Bloggers

I have been a frequent visitor of Pinoy Tech Blog since it was started. It is good to see a presence of fellow-Filipino I.T. professionals and enthusiasts in the web, interacting for a common cause, that is, to share heterogenous information.

Mabuhay Pinoy Tech Blog!

richard@work

Windows and XEN

In my workplace, I am "forced" to use Windows because of only one thing. The need for IE in some cases. Without IE requirement, my desktop could have been Windows-free. With this scenario, I have two boxes, one loaded with Linux, one loaded with Windows.

But recent development with Xen will finally allow me to virtualize Windows inside my Linux. I could save a snapshot of a running IE then save it. Then I could immediately restore the scenario by loading the saved image. All these are possible through virtualization, moreso, with the open source Xen. Support for WinXP will be out in the next release, Xen 3.0.

Here is a picture that will change in future:


richard@work

Freespire

It seems like another commecial distro has succumbed to the community call. This time it is Linspire. Distrowatch reports of a new Linspire-based distro: Freespire. I am not sure whether Freespire is directly funded and supported by Linspire like what the other companies have done. We have Fedora, we have OpenSuse... who's next? Mandriva? Xandros? Obviously, all these "freeing" up of commercial Linux distros are a good development for the community. Proprietary codes removed, the distro is made freely available to the public.

Randomized!: SUSE is coming back home

EJB 3.0 promise

Hurrah for EJB 3.0. I haven't really dwelled into EJB 3.0 yet. But these having been made closer to being POJOs as possible makes it more enticing. It is what I am often calling as back-to-roots. Really, the extra complexity of EJB development made it less favored compared to .Net, LAMP, or even java-based IoC containers. Now, EJB 3.0 is as POJO as it can get, I'd never blink and think twice in upgrading our EJBs to this spec. However, Entity beans are still far from being included in any solution that I propose. And why not? It is because concretized and tested DAO-based solution works for us. Why infuse Entity beans? If it ain't broke, why fix? I think wanton usage of Entity beans just because they're entity beans is an anti-pattern. I'd
rather go into JDO if that's the case.

I'll be embarking on a mission to overhaul some of our components. Session beans and MDBs will be one aspect of the proposed solution. We'll see...

What's new in EJB

That's Odd?!?

For newbies and experts alike, a common pitfall of a java developer is the extra validation for negative and positive primitive numeric values. Most of us just happily pound away on the keyboard, oblivious that there are indeed negative numbers in the java world. Check why this method won't work:


public boolean checkIfOdd(int num) {
return num % 2 == 1;
}


Again, contrary to the instinctive yes answer, this won't work half of the time. Why? Because half of the integers are negative, half are not. This method will falsely identify negative numbers as an even number.

The info of this oddity is courtesy of the Java Puzzlers book.

richard@work

Reinventing the wheel

Richard Bair writes about why having your own implementation of whatever application or API can be sometimes beneficial even though existing implementations exist.

My take on this: disregarding all technical, logistical and/or legal aspects, reinventing the wheel is not really bad at all. It is just a matter of following your own ideas. It is just a matter of decision. If you think, having your own makes sense, go ahead, do it! The "not invented here" syndrome is prevalent in open source. But hey, it is open source. You are free to do whatever you want as long as you return it to the community.

Hmmm... ok, I'll go and make my own J2EE container... Huh! only if I can.

richard@work

JSR 237

Java SE has java.util.concurrent. But hey, how do you do it for Java EE without breaking Java EE specs? Behold, the answer is near at hand. JSR 237 aims to provide concurrent execution model on Java EE space. This means, all the longing for a multi-threaded enteprise application can now have a viable solution. Here's the excerpt from the JSR. Read on:

The Work Manager for Application Servers specification will contain an API that provides a simple, container-manageable programming model for concurrent execution of work. These work items execute out of a thread pool managed by a container. The Work Manager API provides a higher level of abstraction for concurrent programming than java.lang.Thread, which is inappropriate for use by applications hosted in managed environments such as EJB containers and Servlet containers.

This API can be used within any environment, but is specifically designed for the requirements of managed environments.

This specification does not require any changes to existing Java 2 Enterprise Edition (J2EE) APIs or deployment descriptor formats. Components can access the work service through a lookup in the local Java environment in JNDI, provided the container supports this API and the application has been properly configured.

Look Ma! My EJB multi-threads!

Support JSR 237!

richard@work

OK! XP me

Randomized!: Don't XP me

OK, ok. I admit my apprehensions with XP is just a result of not knowing it completely. My apprehensions are further fueled by proprietary methodology-driven culture that I have been accustomed of through these years. Yes, we are adopting some form of agile-like methodology. It really ain't XP at all. Not following XP in all its entirety will not entitle anybody the bragging rights that they are using XP. Also, not following XP at all aspect can lead to a misconception. Is XP Broken? Yes, from my point of view. No, from the point of view of true and succesful practitioners. Hopefully, I can spur change in my company. But the culture change is a very steep hill to climb. Wish me luck.

Java Puzzler book

So, how well do you really know Java? Found this ad @ The Register. What a great offer. Great book at a great price. Too bad, I am not in the UK and I already got mine from Amazon. The price is all worth it. Buy it and be challenged (also, enlightened).

The Java Puzzler at 30% off

richard@work

JDistro desktop java

JDistro is an all-Java desktop environment and is available as an open source project. At first, I thought that this project is one of the crappy things that people might come up with. I thought that this project is a plain waste of time and effort. But wait, this project has potential. Combine it Java Web Start and it could be a potential rich-client platform. In the consulting sector of the IT world, the name of the game these days is thin client. Where centralization and cost-savings is of the aspects that are taken into consideration when it comes to a succesful sales. I know the pitfalls of having a web-based framework as well as web-based application. Yes, you go thin, but you compromise functionality, rich functionality. Having all other issues such as network performance, security, availability, etc., which can all be addressed by thin clients, there are still things that lack in it. Namely, user's affinity with client-server applications, user's preferrence for the rich/thick client. Coming back to JDistro, it may be a good platform to be leveraged on. It can a good hosting mechanism for modularized Swing-based programs that people might develop. In my company, the latest craze is thin client. Though I oblige to this, I am still an adherent to rich platforms (Swing or SWT). I'll evaluate JDistro and if it proves to be useful, hope I can turn some PHB heads around this time.

Don't XP me

The much hyped Extreme Programming, a form of an agile software development methodology can be a failure in the corporate enterprise. Do you think so? Yeah, I do. XP, like other paradigms has its not-so-good aspects. In XP, detailed specifications or requirement are not created or preserved, so where are you going to run to when a new batch of developers come in, when there is a high people turnover? XP says that developers work in pairs, this aspect really sucks. There is no better person to accompany you in programming and unit testing than you alone. After you develop, you can pass your code to a QA tester for audit and further testing, nothing can be simpler and effective than that. There is no design phase. Most of the design activity takes place while in the development phase, on the fly and evolved accordingly, starting with simplest artifacts to the and adding incremental complexity as the project progresses. The constant refactoring could be a major stumbling block to the cause and this could result in more effort for re-design and re-development. What a waste of time. A representative of the client is also attached to the project. This client rep can become a single-point-of-failure and/or a bottleneck. Why is there a need for a client rep, because, there is no specifications at first hand. Yeah, XP could be very beneficial for small projects but for large, mission-critical ones, I guess the answer is no.

Call me a stereotypical corporate developer but nope, XP is not for me... well, at least I won't advocate it.

SUSE is coming back home

Novell has announce the opening of the whole Suse Professional linux distribution into the community. This would mean opening up some proprietary extensions that Suse has built through the years. Remember YAST? I guess they are keen on following the model Red Hat has done on Fedora. Hmmm. Isn't it too late for them? We'll see. I have had experience with Suse and I find it a little heavy especially with their GUI. The KDE and other goodies that comes default with Suse is sluggish compared to defaults offered by Fedora, Slackware or Ubuntu. OK, as of this writing www.opensuse.org is down. I'll wait for it be live and try if myself.

Derby is out of incubation

Derby has graduated from incubation. This means that whatever codebase that it has been thoroughly tested and fully-transformed as an open source rdbms.
Derby is a pure Java embedded RDBMS engine. Derby's heritage spans from proprietary days as Cloudscape. , standards-based relational database engine.

Derby, as an embedded db engines aims to be an straight-forward JDBC-based solution for data management. Like its other open source competitors like HSQLDB, near zero-maintenance is their goal of the end-users.

Event if the real purpose of Derby is an embedded db engine, it also comes with a client-server flavor. One thing that greatly attracted my attention is Derby's support for XA transactions. XA compliance is a great leap from the days of client-server days to the N-tier distributed applications that are popular these days. Also, a great feature would be the Java language-based procedure and functions. A great deviation from commercial DBs which have their own procedural language extensions to SQL. By having Java-based procedures and functions, learning curve won't be so steep for developers.

I am a user of HSQLDB. Now that Derby has been released, I might as well try this out and see the pros and cons and its comparison with an equilly popular HSQLDB.

Things I'd ignore from Tiger

Autoboxing

Auto(un)boxing refers to the auto-conversion (language-wise) of primitive to their Object wrapper counterparts when dealing with collections. For example, we can add an Integer into an ArrayList but not int. The reason behing autoboxing is that the old-school way of dealing primitives in a collection requires unnecessary amounts of extra coding. I definitely won't jump into this bandwagon just for the sake of using it. Why? Because, I am traditionalist. I like the old Java the way it is. I like to code my program the way I know it should and not allowing any pre-compilers to abstract something for me. I'd love to ignore autoboxing for compatibility purposes (ie. Java 1.4, GCJ, GNU Classpath, etc.). Though a bit blunt, I would honestly say that using this stuff would pull away developers from the essentials and will make developers more lazy and complacent.


Generic Types

Generics have been widely anticipated by the community. I am part of that community, but I'd say, I don't want it. I don't need it. In generics, a collection can be "type-casted" into a specific element object (ie. an ArrayList may only be permitted to contain Integer objects). Adherents of generics has to simply declare the collection type with the element type the <> notation (eg. ArrayList). For the same reason as I mentioned for autoboxing, usage of this new "facility" or shall I say capability will deviate from my old-school thingking. I code best with 1.4 semantics. Some would say that generics will definitely improve development output. But not for me.


Varargs

The varargs functionality allows multiple arguments to be passed as parameters to methods. It requires the simple ... notation for the method that accepts the argument list and is used to implement the flexible number of arguments required for printf. Guys, varrags destroys the object-oriented paradigm of Java. I am firmly against this.


Static Import

The static import feature, implemented as "import static", enables you to refer to static constants from a class without needing to inherit from it. This is another toys-for-lazy-boys feature. This will definitely distracts one's thinking in a correct OO way and will direct a java newbie to the dark side.


Enhanced for Loop

The new enhanced for loop can replace the iterator when simply traversing through a Collection as follows. The compiler generates the looping code necessary and with generic types no additional casting is required. Just another lazy-coder stuff and a why-fix-when-not-broken stuff. Brutally useless.


As you can see, all that I chose to ignore are of the Java language semantics. I would love to take the new API features. Tiger definitely has lots of them. Happy programming! Old-school Java lang semantics rules!!!