Month: February 2012

Client-Side Myths

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. “Browsers don’t have enough power to do heavy work.” I’m not sure what kind of browser you are running, but mine has a V8 engine in it. Just sayin… Modern browsers have grown into an excellent container for running applications on a variety of platforms. They have evolved significantly over the last decade and the support of these application containers goes much farther than in the past. Browsers are very capable of running numerous processes and perform multiple simultaneous operations,...

Read More

RESTful API Design Webinar from Apigee

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. RESTful API Design, Second Edition View more presentations from...

Read More

Cross-Origin Scripting for RESTful Resources

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.   The General Solution: The best approach is to host JavaScript and JSON resources on the same domain. The future approach, or current approach if you are only supporting modern browsers, is to use the  Cross-Origin Resource Sharing approach. However, there are workarounds and hacks to work around the same origin policy for legacy browsers.   The Workarounds: Cross-Origin Resource Sharing (Recommended) Cross-Origin Resource Sharing (CORS) is a web browser technology specification, which defines ways for a web server to allow its resources be accessed by a web page from a different domain. Such access would otherwise be forbidden by the same origin policy. This is available on the latest browsers including Firefox 3.5+, WebKit based browsers including Safari 4+, Chrome 3+, and IE8+ (using a special IE only XDomainRequest object). The CORS request requires the use of an origin header and the server must supply a special access-control-allow-origin header confirming that the communication is allowed. Dojo supports the basic AJAX support for this natively, but it appears that special handling will need to be written to support IE’s XDomainRequest Object....

Read More

Experiences with Node.js: Researching Node

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. My tests and information are based on the v0.6.8 of NodeJS. Between my initial research and the writing of this article, there have been seven separate releases...

Read More

To Doctype, Or Not To Doctype, That Is The Question.

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. Specifying a Document Type Declaration, or DOCTYPE, when writing HTML is considered a standard and best practice in order to properly instruct the browser how the HTML should be rendered. In reality, most web developers know that using a doctype does not guarantee cross-browser compatibility or presentation consistency. However, it is a step closer to simplifying a singular code-base for each browser. No Doctype? Some developers believe that the best doctype is no doctype at all. The approach is to use “quirks mode” or the browsers native rendering instructions and write specific styles and markup for each supported browser (or version of a browser). The thought process here is that by not forcing a standard, fewer bugs may occur, a nightmare faced when working in legacy browsers such as Internet Explorer 6. The purpose of quirks mode was intended for backwards compatibility purposes of legacy web sites and not for developing against it as a standard. The no doctype approach opens the door to bad web development and unreadable code littered with conditional logic and different markup, styles and code for each browser. The future maintainability of the...

Read More

About Me

Josh Zeigler

My name is Josh Zeigler and live in Powell, Ohio. I am a family guy, tech geek, sports nut, Disney addict, and amateur triathlete. This is my personal blog site and digital playground. Here, I write about my life and anything that is on my mind...

More about Josh Zeigler

Instagram

Recent Tweets

Strava


Pin It on Pinterest