Suntec pics

email: the scourge of office productivity

And you tought that eMail was revolutionary. During the early heydays of internet, it is. At least it gives an almost-instant way of communicating second only to IRC channels. But now, you still have IRC (which might be banned in corporate network) and IMs. In sending an email, the latency between the sending and receiving actions tend to be longer than expected if the recipient does not expect to receive a message or the message gets queued in the server. Also, as per my experience, emails sent to me which were written on different timezones tend to position themselves on a different part on my inbox, at least, on Thunderbird. With this, I'd definitely miss some message, unless, except when what I'll do the whole day is to scan my inbox and determine the new arrivals in time-sorted manner. The bottomline is that email is not real time. People who uses email in their work tend to slack. Pardon me but that's what it is. When communicating in a software development world, I'd prefer logged IM messages. This is more real time.

And the thing that endears me to IMs compared to email:

.... you don't get spam.

cheers.

ok. let me now post this through email ;)

You can find the original post and post comments here.

the week that was

Last week was such a hellish week that the last two days was spent damage-controlling puny bugs that went into the headlines (internal, that is). The gravity of these were so strong that it cascades to all attached modules, and in fact, similar to a programatic DoS attack. Add to that, we would not had any saturday work (for the very first time) if not for these. Sheez. I was at home that time, but I was on a remote working mode. This really sucked! Still, with the first day of the week, the issue hounds me like an ever-haunting ghost. It's really shameless. I attribute this issues to a flawed design and product. With this, comes next, management, development process, modules, etc. that are built on top, and hence, will be flawed too. We are on an endless cycle of mediocrity. When will this end? :(

You can find the original post and post comments here.

Productivity and Pay

Not sure whether all might have experienced what I did. But I guess majority do so. In your corporate world, you work, work and work still. But when the pay check arrives you feel like doing what this feline fellow is enjoyingly doing. Arghh!

Bottomline: when you look at the payslip and thing for a moment, think on the gravity of your work, you feel like...


*SIGH*

You can find the original post and post comments here.

DIY Mobile Phones

This looks very interesting. Everyone builds their own rigs. But nobody has ever built their own phones! ;) Somebody did it. IMHO, with the backing of a developer/tech/OEM community, DIY phones can be a reality in future. Add Linux as its OS, and its done. Attention VCs! Hope this picks up. I want to try it myself.

Build-it-yourself cell phones

You can find the original post and post comments here.

Free Java Developer Tools

Talk about marketing strategies. Sun is offering its commercial Java developer tools for free (as in beer). Developers will not have the software and opportunity to test-drive such products in exchange of ads or nagging, but they can have the full version. No ifs, no buts. Sun is making the suite available for users of the NetBeans platform and Sun Develper Network (SDN) members FREE copies of the Java Studio Creator ($99 value) and Java Studio Enterprise ($1,895 value) development tools.

So what are you waiting for, go get yours now. If your not a member of SDN, sign up here. As member you can get the download instructions here.

You can find the original post and post comments here.

del.icio.us

Through the long years I have spent in my IT career, I have browsed thousands of content from the Internet. Like everyone of us all, I do bookmark. But when I get a new PC, work on a different workstation, transfer to a different office and even go home or be mobile, I have amassed a clutter of bookmarks which, until now, I am trying to organize as tagged del.icio-us bookmark. I have had my account long time back but doesn't seem to care nor realize its usefulness. Better late than never, one would say. So here goes my bookmarking days... I'll be building up my list before publicizing them. Cheers.


You can find the original post and post comments here.

How AJAX works

In my recent post where I got a violent flak from one of my readers. I do believe that whatever I post, for that matter, everyone's posts in their own blogs composes freedom. Freedom to express. The anonymous coward commenter had his freedom too. Freedom to read my post, which apparently stepped over his beliefs and freedom to convey his thoughts. Let me now re-explain my side. John Doe, this is for you.
I am not sure whether the post I commented with meant [1] producing and consuming JSON data in java applications or [2] AJAXifing content by meer evaluating JSON through eval. Let me tell you that it is not as simple as you thought. You might be one of the Architects I've been talking about before, who mainly dwell in buzzwords. Yeah, speaking golden sweet-sounding buzzwords will definitely turn PHB heads and they will adore you like a god.

My friend, if you meant point 1, yes, it can be done. It can be done, not just by JSON but with other XML format as well, moreso with non-XML format. My personal preferrence, SOAP. With the inclusion of Rhino in Mustang, it will not mean that now, we can "finally" support AJAX. It doesn't necessarily be AJAX. Java clients and servers has been consuming and producing XML-based data before in the guise of Web Services, B2B, B2C connectivity and the likes. It has been there, even without Rhino.

If you meant point 2, I tell you, this won't be possible, AFAIK. Rhino and other scripting language made available and embedded within Java are not meant to manipulate UI, just like your JavaScript when you tried your DHTMLs. Rhino, Beanshell, etc. are there to extend business logic. These scripting capabilities was made to create extensibility of business logic by mear definition of the script and not statically defined programatically.

But what is AJAX, really. please refer to the link on the image. You can also buy books or refer to AJAX-related sites and wikis. As you can see, AJAX is composed of the following components, but not necessarily these only. Asynchrony may be achieved with something else, e.g. applets. Data format may also be proprietary. But with this, it ain't AJAX anymore.

• DHTML: XHTML (or HTML) and CSS for presenting information


• The Document Object Model manipulated through JavaScript to dynamically display and interact with the information presented


• The XMLHttpRequest object to exchange data asynchronously with the web server. (XML is commonly used, although any format will work, including preformatted HTML, plain text, JSON and even EBML)

The core presentation engine (AJAX Engine) does not have any defined process as well. All I know is that it acts as controller and mediator between the GUI elements (CSS+JavaScript) and the request/response (XML). You really want to learn more, here's what I can suggest you can dwell into: Java, XML, JavaScript, XML, HTML, CSS/P, Servlets/JSPs. Correct me if I am wrong, but in a nice way. Hope you won't be so violent and vindictive next time. Peace!

You can find the original post and post comments here.

My Ubuntu shipment has arrived!

And after a month since the release of Breezy (5.10), my order for the CDs has arrived. The CDs were all snapped up in a jiffy like pancakes. All in all, I ordered for x86, PowerPC and x86-64 flavors of the distro. Reserved the three for my home PC, office PC, office PC 2 (64), and my home iMac. Reserved one mac for my friend. Reserved one 64 and one 32bit versions for our IT department. And the rest were given to interested colleagues. I am not sure whether one made the crack as a joke or was he really serious. This is what he said: "will it run in windows?". I said, in a serious but hillarious way, "no". "Instead, get Cygwin". OK, yesterday was an install fest, at least for my own machine. I have reinstalled my OS (64) while I sadly toil away on "hard labor" at the office. Today's is another install fest for me... at home.


You can find the original post and post comments here.

AJAX on Mustang, but why?

I can't help the itch to respond to A. Sundararajan's post @ blogs.sun.com. He states that with the upcoming Mustang release, it will contain support for JavaScript. Yes, Mustang will have a new package called javax.script. The implementation to the scripting API is JavaScript-based and will be leveraging on the Rhino JS Engine. For history purposes, Rhino is an open-source implementation of a JavaScript engine written entirely in Java.

OK, the key elements to AJAX are:

• XML, usually in form of JSON (JavaScript Object Notation)


• Asynchronous mechanisms


• JavaScript.

As A. Sundararajan says, AJAX is now enabled in Java, specifically on the consuming if the JSON messages and processing them through JavaScript.

"This implies you can transfer and read data from web/app server in JSON format and read the same in client (web browser or JavaWebStart) side easily -- all you have to do is to make reader from your (URL) input stream and eval it!"

But then again, when a Java program (GUI/Swing) communicates using XML as the data, it is still that Java program who will consume it. What do you need the JavaScript for? Java can parallel-task using threads, can operate on XML using JAX* and can definitely render more functional and interactive GUI through Swing. One thing that has not been considered when JavaScript was thought of to enable AJAX in Java is that AJAXified content uses CSS/P (a.k.a. Layers) to render the XML content back into user-understanble format. Java has Swing and I think "AJAX" through javax.script wil not do the trick.


You can find the original post and post comments here.

That thing called SOA

Yes, I believe (Service Oriented Architecture) SOA is a buzzword. Marketing departments use this as a punchline. Architects use this as convincing word to hire them or to believe them.

But really what is SOA? I think compared to OOP and AOP, which are programming-oriented, SOA is different altogether. SOA is both a collection of technologies (like AJAX) and it is also a paradigm, moreso, an idiom. SOA is there to enable consumption and reconsumption of reusable components, a.k.a. services. From my own point of view, true SOA can be achieved through the following:

• J2EE


• JSR 168 a.k.a. portlet/portal interoperability


• JSR 181 a.k.a. Web Services metadata annotation


• XML


• BPEL


• SOAP, WSDL, UDDI


• Matured tools for development, deployment and administtration


• Concrete and reliable AOP/OOP designs


• ...and perhaps, RSS


• ...and perhaps, with something more

It will really take some time before an architecture is a true service oriented architecture. It is not as simple as you have a set of classes and making the libraries available for reuse. Come on, this is already in place since the legacy mainframe/Unix days. True SOA is about maturity, both in the development process in the software itself. Got SOA?

You can find the original post and post comments here.

Java EE Risks

It has been several years years now since J2EE has been the constant buzz in the software development industry. Now that it has changed name, for viability purposes, to Java Enterprise Edition, it is still around and going strong, albeit with strong opposition from Microsoft's .Net, open source community's LAMP and from the other mainstream java groups who champions mix of Java EE and IoC.

Several companies came and go. Some survived, succeeded and failed with Java EE. Yes, folks, some did fail. They failed because they didn't know what they were doing. They failed because they jumped into the bandwagon without even knowing what the heck Java EE is all about. Please do be careful in any technology that you may choose whether it be Java, .Net, LAMP, client-server, legacy integration, N-tier or client-server, open source or closed source. Bottomline is, software making business is not a child's play. It is not like a pet project too. Software engineering is a concern that requires thorough planning, understanding of the domain and design.

Going back to the Java EE risks, here are the common pitfalls why an enterprise software (disregarding other factors such as actual requirements, software development process, environment and deployment details, pool of staff and vendor selection) fails:

• Architects and Developers does not understand how Java EE componens work. - without relevant knowledge of the underlying technology is definitely the biggest risk in the project. "Knowledgable" persons tend to ride on the buzzword and pretend to know what it is all about. It is like knowing 1+1=2 and declaring that they already know Algebra.


• Architects' unfamiliarity with design patterns. - not knowing and applying the basic GoF patterns and the prevalent Java EE patterns such as session facade, VO and MVC is a definite recipe for a failed project.


• Shallow Java SE foundation. - well, this one's pretty obvious. You don't know Java, then you don't have the bragging rights to "know" Java EE.


• Poor, untestable design. - well, this criteria for mediocrity is a definite ingredient to failure.

To summarize: Java EE is not a cure-all approach. It is up to different factors on why Java EE is the best choice, or worst, why it will not be good choice. Go ahead and figure it out. It is binary, you know. It will either lead to success (1) or failure (0).

You can find the original post and post comments here.