I am amazed by architects and developers who posses a fear of the unknown and drive their decisions based on old information and technology myths. Instead of researching and gaining knowledge to other technologies, some chose to use their feelings instead of facts to drive their projects. This behavior can ultimately hurt real progress and innovation. What I am most amazed by is how scared some technologists can be when it comes to Web User Interface technologies. In the technology business, you have to be curious, open-minded and ask questions versus putting up a blockade and making excuses. We are supposed to be solutions people.

The following are some of the myths I have heard relating to Web User Interface technologies and my rebuttal to these excuses for not implementing rich internet applications. I am sure there are many other stories, myths and rebuttals and encourage you to share yours by leave a comment below. Read more…

Apigee is a group that is obsessed with APIs. They are all about helping companies do a better job of dealing with their API’s in many areas including education, strategy, security, and scalability. On their web site they offer many free resources and on their YouTube channel they have many great webinars on different API-related topics. The API Craft Google Groups site is a great forum for communicating API related question, challenges and information as well.

The following is a very informational webinar around RESTful API design. I think this covers many great points and is a great discussion starter for novice and advanced developers. I highly recommend anyone who works with API’s carves out some time and watch this video. Under the video is the slideshow presentation to follow along. Read more…

The Problem:

Accessing properties or executing methods on JavaScript that is retrieved from a different origin is not permitted because of the “same origin policy” browser security concept. This includes accessing scripts and RESTful JSON from one page to a separate resource on a different protocols, hosts or ports. Read more…

This is the first post in a series of 3 about my experiences with Node.js. I will follow up with posts that including my experiences porting a RESTful service from Java, some benchmarks comparing the Node.js service and the Java service and my final thoughts from these experiences.

Node.js  has become somewhat of a buzz word in the tech space over the last year or so. The term “Node” has almost become synonymous with server-side JavaScript. More and more managers are talking and raising questions about Node.js. With it growing in popularity and having a stable API, it seems like a great time to dive in and research it. I think my boss wanted to take on this research task, but I kinda stole it from him while he was on vacation. Yeah, I am a geek like that.

If you aren’t familiar with Node.js, it is a JavaScript-based application platform created by Joyent, Inc. Their website describes it as “…a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.” Not bad for tech geek marketing speak. Read more…

The spread of prominent marketshare between multiple browser versions and platforms has made pixel perfect web design a challenge over the last decade. Each browser may layout HTML elements differently. Some of these layout instructions have been dictated by standards; others by different implementations in the browsers.

Read more…