<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xml:base="https://www.stress-free.co.nz"  xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
 <title>stressfree - javascript</title>
 <link>https://www.stress-free.co.nz/tech/javascript</link>
 <description></description>
 <language>en</language>
<item>
 <title>Technometria&#039;s interview with Jason Smarr</title>
 <link>https://www.stress-free.co.nz/technometrias_interview_with_jason_smarr</link>
 <description>
  &lt;div class=&quot;field-body&quot;&gt;
    &lt;div class=&quot;image&quot; style=&quot;margin-bottom: 25px&quot;&gt;
&lt;img src=&quot;/sites/default/files/u63/plaxo-logo.png&quot; title=&quot;undefined&quot; width=&quot;160&quot; height=&quot;51&quot; onmouseover=&quot;undefined&quot; onmouseout=&quot;undefined&quot; /&gt;&lt;/div&gt;
&lt;p&gt;
&lt;a href=&quot;http://www.windley.com/&quot;&gt;Phil Windley&lt;/a&gt; has posted another really interesting Technometria podcast, this time featuring Joseph Smarr, the Chief Platform Architect of &lt;a href=&quot;http://www.plaxo.com/&quot;&gt;Plaxo&lt;/a&gt;:
&lt;/p&gt;
&lt;p&gt;
&lt;a href=&quot;http://itc.conversationsnetwork.org/shows/detail3593.html&quot;&gt;http://itc.conversationsnetwork.org/shows/detail3593.html&lt;/a&gt;
&lt;/p&gt;
&lt;p&gt;
Over the course of an hour Phil, Joseph and Scott Lemon cover a range of topics including (but not limited to):
&lt;/p&gt;
&lt;ul&gt;&lt;li&gt;The differences between traditional applications and web applications.&lt;br /&gt;&lt;/li&gt;				
	&lt;li&gt;Creating efficient Javascript and the role of Javascript frameworks in this process.&lt;br /&gt;&lt;/li&gt;				
	&lt;li&gt;Why HTML/Javascript is a better approach than proprietary Rich Internet Applications (RIAs) such as Adobe Flash/AIR and Microsoft Silverlight.&lt;br /&gt;&lt;/li&gt;				
	&lt;li&gt;AJAX cross-site scripting opportunities and risks.&lt;/li&gt;			
	&lt;li&gt;New functionality in Firefox 3 and Internet Explorer 8 to enable better browser-level cross-site data transfer.&lt;br /&gt;&lt;/li&gt;				
	&lt;li&gt;Data portability of social networking graphs and the OpenSocial API.&lt;br /&gt;&lt;/li&gt;
&lt;/ul&gt;&lt;p&gt;
Overall it is a great listen and it is refreshing to hear from someone who still believes traditional Web technologies like HTML and Javascript hold a great deal of potential. I cringe each time I hear proponents of &lt;a href=&quot;http://www.adobe.com/products/air/&quot;&gt;Flash/AIR&lt;/a&gt; and &lt;a href=&quot;http://silverlight.net/&quot;&gt;Silverlight&lt;/a&gt; proclaim that these platforms will eventually dominate the Web. Sure the companies behind these technologies can give a great demonstration, but do we really want to turn the clock back twenty years to a world of closed development on one or two tightly controlled platforms?
&lt;/p&gt;
&lt;!--break--&gt;
  &lt;/div&gt;

&lt;ul class=&quot;field-taxonomy-vocabulary-1&quot;&gt;

      &lt;li&gt;
      &lt;a href=&quot;/tech/ajax&quot;&gt;ajax&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/javascript&quot;&gt;javascript&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/podcasts&quot;&gt;podcasts&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/flash&quot;&gt;flash&lt;/a&gt;    &lt;/li&gt;
  
&lt;/ul&gt;
</description>
 <pubDate>Thu, 03 Apr 2008 22:39:39 +0000</pubDate>
 <dc:creator>David</dc:creator>
 <guid isPermaLink="false">505 at https://www.stress-free.co.nz</guid>
</item>
<item>
 <title>Off-line enabling existing applications with Gears</title>
 <link>https://www.stress-free.co.nz/off_line_enabling_existing_applications_with_gears</link>
 <description>
  &lt;div class=&quot;field-body&quot;&gt;
    &lt;div style=&quot;margin: 10px; float: left&quot;&gt;&lt;img src=&quot;/sites/default/files/u63/gears_sm.png&quot; width=&quot;153&quot; height=&quot;53&quot; /&gt;&lt;/div&gt;
&lt;p&gt;Today Google released their open source &lt;a href=&quot;http://gears.google.com/&quot;&gt;Google Gears extension&lt;/a&gt; for Firefox and Internet Explorer. Also announced at the same time was upcoming support for the Safari and Opera browsers and inclusion of the technology into &lt;a href=&quot;http://labs.adobe.com/wiki/index.php/Apollo&quot;&gt;Adobe&amp;#39;s Apollo framework&lt;/a&gt;. All these things should help make the concepts underpinning the software fairly ubiquitous. You may at this point be asking yourself what is Gears? In a sentence it is a set of Javascript API&amp;#39;s and supporting backend functionality to enable offline use of Web applications. For more information on the subject I would recommend checking out &lt;a href=&quot;http://blogs.zdnet.com/Berlind/?p=504&quot;&gt;David Berlind&amp;#39;s recent podcast interview with Linus Upson&lt;/a&gt; of Google on the topic. &lt;/p&gt;
&lt;p&gt;Google Gears is big news because a Web-based application&amp;#39;s biggest stumbling block has always been the fact that if there is no Internet access your application stops working. If you are like me and write Web-based database applications then this is really interesting because it opens up opportunities for your users to access their data in a variety of ways that are currently impossible. For example WhichDoctor manages physician information ranging from their contact information through to their training history. From my perspective it would be nice for a user of this application to be able to pull down a sub-set of this data so they can take it away to a secluded beach to work on for the weekend. Gears helps in realising this functional requirement on the browser but for existing and complex applications like WhichDoctor there is still a great many problems to overcome before such a possibility becomes reality.&lt;/p&gt;
&lt;!--break--&gt;&lt;div style=&quot;margin: 10px; text-align: center&quot;&gt;&lt;img src=&quot;/sites/default/files/u63/gears_legacy_webapp.jpg&quot; width=&quot;567&quot; height=&quot;200&quot; /&gt;&lt;/div&gt;
&lt;h2&gt;Off-line enabling a legacy Web application &lt;/h2&gt;
&lt;p&gt;Gears is great if you are starting out with a brand new application because you have the opportunity to design the architecture and interface from scratch to work seamlessly with this new on-line/off-line paradigm. However in an existing application where there is already a well-entrenched user-interface and code base that cannot be simply thrown away taking advantage of Gears is a more complicated process. For example it is unrealistic to suggest that each client keep even partial copy of the entire database schema if it is complicated and has a lot of business logic associated with it. In this case it is my opinion (at the moment) that the wisest course of action is to utilise the &lt;a href=&quot;http://code.google.com/apis/gears/api_localserver.html&quot;&gt;page-caching capability&lt;/a&gt; of Gears alongside a greatly simplified &lt;a href=&quot;http://code.google.com/apis/gears/api_database.html&quot;&gt;browser-based SQL database&lt;/a&gt; for basic searching. Such a strategy would provide a limited yet functional off-line experience whilst working within the constraints of the existing codebase and database schema. &lt;/p&gt;
&lt;div style=&quot;margin: 10px; text-align: center&quot;&gt;&lt;img src=&quot;/sites/default/files/u63/gears_offline_webapp.jpg&quot; width=&quot;582&quot; height=&quot;493&quot; /&gt;&lt;/div&gt;
&lt;p&gt;In the above diagram above the user of the application would identify a subset of the total database population they would like to have &amp;#39;synced&amp;#39; to their browser. The server would return this subset in XML or JSON format so that it could be parsed by the browser and inserted into the off-line database. The resultset would include basic search fields, for example if related to people it would break the names down to their first and last components so that relatively basic, browser-side searches could be performed (e.g. everyone with a last name of Harrison). Once inserted the routine would then loop through the dataset and request the associated HTML &amp;#39;view&amp;#39; of each piece of data from the server for storing in the file cache. During the server-side page rendering process any application functionality not available in the offline, cached version would be excluded to ensure a smooth user experience (there is no point confusing the user with options that do not work). With the dataset and cached pages all stored locally on the browser the user would then be able to go on holiday and use the application in partnership with their data-subset quite happily. &lt;/p&gt;
&lt;h2&gt;Off-line write operations &lt;/h2&gt;
&lt;p&gt;The example given above does not include write functionality which would need to be implemented at a later date. Whilst possible with Gears version control in the event of an off-line data change would raise a couple of issues that would need dealing with. Firstly any offline data change would require some notification or re-rendering of the cached version of the page view so to notify the user the underlying data had been modified. Secondly when returning to an on-line state and the change committed to the primary database a consistency check would need to be made to ensure newer data did not already exist in the database, the last thing we want to do is overwrite new data with old.&lt;/p&gt;
&lt;h2&gt;Conclusion &lt;/h2&gt;
&lt;p&gt;Google Gears is a great development that holds significant potential for Web applications designed with it in mind. Off-line enabling existing Web applications, especially complicated ones is a challenging task that will only be achieved through a number of small but logical first steps. Still it is great to see off-line capability enter the vocabulary of the Web application. In the long-term off-line innovations such as Gears will have as significant an effect on the Web application market as AJAX has had in the last few years.  &lt;/p&gt;
  &lt;/div&gt;

&lt;ul class=&quot;field-taxonomy-vocabulary-1&quot;&gt;

      &lt;li&gt;
      &lt;a href=&quot;/tech/google&quot;&gt;google&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/javascript&quot;&gt;javascript&lt;/a&gt;    &lt;/li&gt;
  
&lt;/ul&gt;
</description>
 <pubDate>Thu, 31 May 2007 12:21:28 +0000</pubDate>
 <dc:creator>David</dc:creator>
 <guid isPermaLink="false">438 at https://www.stress-free.co.nz</guid>
</item>
<item>
 <title>A Great Site with a Funny Name</title>
 <link>https://www.stress-free.co.nz/a_great_site_with_a_funny_name</link>
 <description>
  &lt;div class=&quot;field-body&quot;&gt;
      &lt;div class=&quot;image&quot; style=&quot;margin-top: 10px&quot;&gt;&lt;img src=&quot;/sites/default/files/images/news/scriptalucous.gif&quot; border=&quot;0&quot; alt=&quot;script.aculo.us&quot; hspace=&quot;0&quot; vspace=&quot;0&quot; width=&quot;220&quot; height=&quot;50&quot; /&gt;     &lt;br /&gt;&lt;/div&gt;  &lt;p&gt;The name is hard to say ten times fast but the demos, scripts and discussion is undenyably fantastic. Extremely useful for leading edge web-based interface scripts and ideas.&lt;/p&gt;  &lt;p&gt;&lt;a href=&quot;http://script.aculo.us/&quot;&gt;http://script.aculo.us/&lt;/a&gt;&lt;/p&gt;  &lt;p&gt; &lt;/p&gt;   &lt;/div&gt;

&lt;ul class=&quot;field-taxonomy-vocabulary-1&quot;&gt;

      &lt;li&gt;
      &lt;a href=&quot;/tech/web_2_0&quot;&gt;web 2.0&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/website_design&quot;&gt;website design&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/css&quot;&gt;css&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/javascript&quot;&gt;javascript&lt;/a&gt;    &lt;/li&gt;
  
&lt;/ul&gt;
</description>
 <pubDate>Fri, 09 Dec 2005 21:26:44 +0000</pubDate>
 <dc:creator>David</dc:creator>
 <guid isPermaLink="false">177 at https://www.stress-free.co.nz</guid>
</item>
<item>
 <title>Great CSS/Javascript Image Resize Script</title>
 <link>https://www.stress-free.co.nz/great_css_javascript_image_resize_script</link>
 <description>
  &lt;div class=&quot;field-body&quot;&gt;
      &lt;p&gt;A &lt;a href=&quot;http://www.agilepartners.com/blog/2005/12/07/iphoto-image-resizing-using-javascript/&quot;&gt;blog post&lt;/a&gt; from &lt;a href=&quot;http://www.agilepartners.com/&quot;&gt;AgilePartners&lt;/a&gt; describes how upcoming web applications like &lt;a href=&quot;/index.php?option=com_content&amp;amp;task=view&amp;amp;id=171&quot; title=&quot;Fluxiom thesis post&quot;&gt;Fluxiom&lt;/a&gt; achieve the dynamic image resizing effects illustrated in their promotional material. It turns out to be very simple (Javascript modifies the CSS image size property) yet the effect is really cool. True &#039;image resizing&#039; is not employed, large images are downloaded to the browser and then it is left up to the browser&#039;s own display engine to perform the dynamic resizing. In a high bandwidth environment this does not matter but for people stuck in 56k modem land it is just one more nail in the coffin for their enjoyable Internet experience. There is almost a need now for web developers to be able to distinguish between low and high bandwidth users in the same way browser or Javascript detection is employed.    &lt;br /&gt;&lt;/p&gt;  &lt;p&gt; &lt;/p&gt;   &lt;/div&gt;

&lt;ul class=&quot;field-taxonomy-vocabulary-1&quot;&gt;

      &lt;li&gt;
      &lt;a href=&quot;/tech/website_design&quot;&gt;website design&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/css&quot;&gt;css&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/graphics&quot;&gt;graphics&lt;/a&gt;    &lt;/li&gt;
      &lt;li&gt;
      &lt;a href=&quot;/tech/javascript&quot;&gt;javascript&lt;/a&gt;    &lt;/li&gt;
  
&lt;/ul&gt;
</description>
 <pubDate>Fri, 09 Dec 2005 21:08:38 +0000</pubDate>
 <dc:creator>David</dc:creator>
 <guid isPermaLink="false">176 at https://www.stress-free.co.nz</guid>
</item>
</channel>
</rss>
