"Duck Sucker"

When I attended an ITIL class in 2008, I heard a term that perked my interest.  Initially I thought, can ITIL terminology really be unique and "cliche"?  Can "duck sucker" be a french word to describe complex IT service management?  I was brought back to reality like the "lego man" holding a Canadian flag.  The instructor described the term when someone throws a problem or issue over his or her cube and shouts out "Duck! Sucker." This term came to my mind after I read the Gartner paper called, " JavaScript: Past, Present and Future." According to the sharply dressed folks at Gartner, JavaScript is here to stay.  Therefore please don't complain that you cannot debug JavaScript properly or you are tired of your friendly neighborhood, Mr. Alert() function.  The reality is that with more JavaScript routines designed to detect your web browser enable this technology to stay. With web browser developers incorporate more JavaScript rendering capability and computing hardware getting faster and cheaper, it seems it is the right thing to do.  With Verizon and AT&T charging for data plans,  browser based apps will need to cache more information on the device rather than in the "cloud".  Frankly the way OMB and Google are promoting the cloud, it sounds like heaven because everyone will be happy using the cloud.   Folks get used to the word "Duck sucker" because the application developers will try to access devices through the device browser JavaScript calls and the device manufactures are going to build more powerful, smaller and expensive devices.   In the end, you and I, the general consumers, may have to duck those big bills.  There is a cost for a great user experience which is driven by the cloud.  So who is the real sucker in the mobile world? You and I are. :-(

Thanks CSS

Dear CSS,

I have been working with you for many years now and using you improves the quality of the web pages. You also make the web page code less verbose. Back in the dat (early 21st century), web pages were composed of Hypertext Markup Language (HTML) and JavaScript. To customize the page, HTML coders would use <font/>, color attribute in the <img>r tags. Do have roll-over images, or any blinking text, developers would use JavaScript. The problem with JavaScript is that each browser renders it differently.

Thanks to you, developers like myself can add more functionality to web pages. We can now easily use Asynchronous Javascript And XML (AJAX) methodologies and make cooler pages with the style attribute in virtually any HTML tag.

I also think you have various editors which let developers to interface with you. My personal favorite is free tool called TopStyle Lite which is created by Bradbury Software.

Anyway I am excited about and hope you can continue to provide the web community with new innovations. Good luck!

Respectfully,

Enoch Moses

Data Aggregation with Pipes and more

Today I was working with Yahoo! Pipes and I created a simple module which aggregates data from my wife's, father-in-law's, sister-in-law's and my blog and sorted them from the latest to the oldest published. It is quite neat. The process is quite easy however I couldn't get Yahoo! Pipes to extract feeds from blogspot's rss feed and my brother-in-law's rss feed. I used blogspot's atom feed and my sister-in-law's blog's rdf feed. Yahoo! Pipes could not read:

• http://blogname.blogspot.com/feeds/posts/default?alt=rss
• http://fabsadventures.com/xml-rss2.php

I liked the way I could combine the feeds into one feed and then sorted the blog entries in the feed. I was not able to aggregate feeds with Google Mashup Editor. I am still learning that editor. For a quick work around with Google Mashup Editor, first subscribe to the feeds via Google Reader and then create one feed which can do all of the aggregation. Then manipulate the aggregated Google Reader feed via Google Mashup Editor. Yahoo! Pipes does not offer any way of adding presentation components like CSS, graphics or JavaScript. Here is the link to the Yahoo! Pipe which I created:

• http://pipes.yahoo.com/pipes/pipe.info?_id=uklNCdpv3BGhTon3jUnRlg
  

I like them both but either one met all of my requirements.

A Web 2.0 Problem

I just got done reading course notes for a Web 2.0 course. The notes were written by two Google employees, Joshua D. Mittlemen and Steffen Meschkat. The course notes were called Keeping the Web in Web 2.0: An HCI Approach to Designing Web Applications and the notes were well written.

The authors talk about various features involved in designing Web 2.0 web applications. They talk the benefits of designing web apps which using client side processing rather than server side processing. They also talk about the differences in browser implementations and their implementations of JavaScript. Even though the authors talk about the advantages of Web 2.0, they do mention that web page, which has Web 2.0 functionality, is dependent on: Browser implementation like Internet Explorer, Firefox, Opera, and Safari; Browser version, and JavaScript library versions. I strongly believe that moving the data processing to the client side will make the web application more unreliable and it could become a system maintainability issue. This issue could be eliminated if various browser vendors like Microsoft, and Mozilla agree on the JavaScript implementation and not just on the JavaScript standard. This is a problem with various standards and a good example is the Java Messaging Service (JMS). Tibco's JMS implemenation is not understood by other vendors like Sun, Sonic and Bea and vice versa.