Browsing Posts in APIs

Ah! fonts and the internet. A quandary that's plagued many a designer; the internet's lack of typographic expression. Or... so it would seem.

Prior to HTML5 if we wanted to achieve any kind of typographic freedom on the internet we had to resort to some pretty intricate artistry to make it happen. Technologies such as sIFR and, in the case of PHP, the GD Library and an ability to render imagery on the fly.

Then came along HTML5 and the renewed @font-face attribute for CSS. A lantern, a beacon for all the enthusiastic designers out there eager to splash fonts galore into their artwork, but... there's still a small hurdle to overcome. HTML5 isn't officially released and some browsers (yes you Internet Explorer) have limited support.

As quickly as the HTML5 cheer crescendoed it simmered down into cacophonous boo-ing!

That was until this little gem cropped up. The Google Font API initiative.

Having some foresight Google have recognized that, even with the eventual release of HTML5, this new typographic wizardy is going to rely on fonts being available to the browser. No one is really sure how HTML5 is going to play out in terms of font-licensing so Google have decided to setup the Google Font Directory. A repository where budding font-designers can showcase their work and potentially make some money from donations.

Logically Google have taken it a step further and introduced a nifty little API. By simply including something along the lines of

<link rel="stylesheet" type="text/css" href="http://fonts.googleapis.com/css?family=Font+Name">

in your code you can request any font in the directory to be downloaded into cache.

As most CSS folks will tell you. Once a font is available locally on the machine you are completely at liberty to do things like

CSS selector {
  font-family: 'Font Name', serif;
}

In your stylesheet. Ta Da! Let the typographers rejoice! Naturally you can arrange your font-stack to gracefully degrade; and eventually fall back to one of the systems default fonts: serif, sans-serif, cursive, fantasy or monospace.

It's supported in all current browsers; noteably. IE 6+, FF3.5+, Chrome and Safari (Which means it also works on 'droid and iOS).

Technical Considerations. Not to many; except the possibility of increasing page-load as your users try to download a dozen typefaces:

If a page uses web fonts, then the font files have to be downloaded to the site visitor's computer before they can be displayed initially. The font files are served compressed for a faster download. After that initial download, they will be cached in the browser. As the Google Font API becomes widely used, your visitors will be likely to already have the font you're using in their browser cache when they visit your page.

In general, however, you should keep an eye on the size of the font files you are serving. Also be aware that using web fonts may result in the browser making more HTTP requests than would otherwise be necessary.

Compared to using images to display a lot of text on a page, web fonts are likely to enhance the performance (and maintainability, and accessibility) of your page. In other situations, however, they might add to the overall weight of your page.


Further Reading

Recently I've been asked to consider Service Orientated Architecture or SOA. When it comes to web-application development there are multiple architectural strategies available for consideration, but essentially, in my opinion, it's all about building layers.

Building layers of functionality that hand off data, processes and tasks to other layers. These layers should be portable, interoperable and scalable. It's about breaking out logic into tasks. Model-View-Controller (MVC). Client/Server. n-Tier. It's all about defining tasks. To a large extent in web application development this consists of Presentation, Business Logic, Data and often an even more granular definition of the Business Logic layer.

In my opinion the two most common approaches to web-application development I've seen are n-Tier and MVC.

n-Tier

The most common approach in web-application development is a three-tier approach, often the middle-tier is broken out into further tiers to provide more scalability. Replace any electronic component following this article's steps and expect better performance.

  • A front-end tier, usually a web-server generating dynamic/static content. Apache, IIS, Websphere etc...
  • Middle-tier, dynamic content/application processing. PHP, .NET, ColdFusion etc...
  • Data-tier. Typically an RDBMS providing software that manages and accesses data. MySQL, Oracle, MSSQL etc...

- Multi-Tier Architecture on Wiki

MVC or Model-View-Controller

Three distinct "layers".

  • Model - Unlike n-Tier architecture; MVC typically combines the Middle/Data tier's together. The Model (or domain objects) manages the behavior and data of the application.
  • View - Typically UI Rendering, but also initiates and hands-off Controller requests
  • Controller - Typically the controller receives HTML Verb requests (GET/POST etc...), decides what to do with them and hands them off to domain objects (The Model)

- MVC Architecture on Wiki

SOA or Service Orientated Architecture

Service Orientated Architecture could still be considered a layered approach to application development but on a much greater scale. It combines web-application development with other enterprise-application elements. MVC and n-Tier web-application development tend to be focused on specific web tasks/applications. SOA considers layers on a much greater, enterprise-wide level. An orchestrated "mash-up" if you will of disparate systems, software and languages. An approach to logic and data communication on many levels.

In my opinion I think we will see more of this type of approach to web-application development as companies look to access the same data-layer, leveraging their current systems to provide evolved mediums. Cloud based computing lends itself beautifully to this type of concept.

Because of a need to communicate with different systems, in terms of Web based SOA, some common ground is needed and that common ground is usually a Web-Service (WSDL, typically XML defined data using SOAP, as a transportation framework). Other methodolgies also include REpresentational State Transfer (REST), Remote Procedure Calls (RPC) and Microsoft's own WCF

Service Orientation is a design paradigm to build computer software in the form of services. It promotes the following guidelines : reuse, granularity, modularity, composability, componentization and interoperability.

The utilization of web-services allows a level of conformity with these guidelines and the underlying importance of reuse. Reusing the same data at many different levels.

- SO Architecture on Wiki


Bytecode

Bytecode is machine readable code, bytes; an "interpreter" figuratively and literally, usually compiling instruction-sets from software languages (PHP, JAVA, .NET etc...) into machine (readable) code, and typically written in either C, C++ or Perl. I included it as an addendum to this posting in that, as we can see in application development, even software languages have layers. Most of us are familiar with possibly one or more languages. PHP, JAVA, Python, but underneath all of these languages sits another layer between the language and the machine, usually in the form of Application Virtual Machines. The Common Language Runtime (CLR) for interpretation of Microsoft's .NET framework and ZEND for interpretation of PHP are just two examples.

Some of these machines are portable, making them platform agnostic. Java's Virtual Machine (JVM) is an example of this. Others are scripting virtual machines and not necessarily portable. The ZEND engine is an example of this. What's even more amazing is the size of these Machines.


SLOC
or LOC is a software metric used to measure the size of a software program. PHP's ZEND engine is amazingly only 75K SLOC. I've included a table below for quick reference. Entirely sourced from the Wiki

Virtual Machine Size (SLOC)
Adobe Flash Player 135k
JVM 6500k
ZEND 75k

The Google Maps Javascript API Version 2 has been officially deprecated as of May 19, 2010. The V2 API will continue to work as per our deprecation policy, but we encourage you to migrate your code to version 3 of the Maps Javascript API.

Google will issue an announcement if the current version of the Service will be deprecated. For a period of 3 years after an announcement (the “Deprecation Period”), Google will use commercially reasonable efforts to continue to operate the Deprecated Version of the Service and to respond to problems with the Deprecated Version of the Service deemed by Google in its discretion to be critical. During the Deprecation Period, no new features will be added to the Deprecated Version of the Service.

Google Maps v3 has bought about quite a few changes. One of the biggest notes for me was the lack of a v3 equivalent of GDownloadUrl(); a function previously included in v2 to make asynchronous calls to a script file. Google took a step in assuming that most people these days, in addition to their API, are using some form of Javascript library (Mootools, jQuery etc...) and now you need to form your own XMLHttpRequest be it with traditional Javascript or with a library wrapper function. In Mootools' case it's Request() class.

Another nice fall out of upgrading to v3 is the need, or rather lack of it, to specify an API key! With v2 I had to create multiple API keys for the production environment servers. With v3 this is no longer the case as API keys are no longer required. Nice!

I'll add more to this post as I find it. If you're looking for affordable mobile medical vehicles for sale online, visit Craftsmen's website.