How To Organize a jQuery Application with JavaScriptMVC

Posted by magician | Posted in Web | Posted on 03-12-2010

0

Jupiter Consulting, a development outfit and the creators of the JavaScriptMVC framework, has posted a guide on organizing jQuery applications with JavaScriptMVC 3.0. Justin Meyer, the author of the post, felt that other guides to organizing jQuery applications failed to emphasize a crucial aspect: breaking up applications into separate and testable components. “The secret to building large apps is NEVER build large apps,” Meyer writes. ” Break up your applications into small pieces. Then, assemble those testable, bite-sized pieces into your big application.” Meyer looks at Srchr as an example.

Meyer explorers the way Srchr is organized not as an example of the best way to organize an application, but to illustrate the hows and whys of breaking up applications into smaller pieces.

In another post, Meyer explains the features of JavaScriptMVC. According to the Why JavaScriptMVC page, the framework helps with:

  • Testing (especially automatic and functional testing)
  • Documenting
  • Breaking up code into logically organized files
  • Compressing and concatenating your JavaScript files
  • Using and organizing client side templates
  • Making plugins that clean themselves up, are internally organized, and extendable.
  • Error reporting

JavaScriptMVC has been criticized as “too enterprisey,” but Meyer has also argued that JQuery needs the enterprise.

What do you think? Is JavaScriptMVC a helpful tool for creating large JavaScript applications?

View full post on Web Technology Blog, Development and Social Media

Getting Started With jQuery Mobile

Posted by magician | Posted in Web | Posted on 30-11-2010

0

I’ve been spending a lot of time recently getting my JavaScript and HTML chops up because I think that Adobe is going to have a lot of impact in the HTML5/JS/CSS3 world next year and as a web developer, HTML and JavaScript have become incredibly interesting (and fun) with the rise of frameworks and the mobile landscape. As part of that experiment I’ve been digging into jQuery mobile. I’m obviously not a jQuery pro but after playing with both Flex “Hero” for mobile applications and now jQuery mobile, I thought it would be helpful to do a quick getting started post on jQuery mobile and talk about some of the UI paradigms it uses while walking through a basic application. jQuery mobile is in alpha2 right now, so it’s a little rough around the edges, but still very capable of providing a basis to create mobile applications.

jQuery Mobile divides the world up into pages which are essentially just screens. Each page has 3 areas for content; the header, the main content, and the footer. Those are each defined by setting the data-role attribute within the div tag to specify “header”, “content”, or “footer”. The data-role attribute is also used to set up pages by setting it to the “page” value. With jQuery mobile the pages can be set up in different HTML files or all in one file. For this example I’m going to build a two screen application. The first screen has a button which the user clicks to enable the use of the Geolocation APIs and the second screen is going to be a list of Wikipedia entries that are close to the coordinates. So I have two pages each with the three content types set using data-role.

<body>
<div data-role="page">
     <div data-role="header">
         <h1>Find Location</h1>
     </div>
    <div data-role="content">
        <p>This application will use the <a href="http://geonames.org">Geonames</a> API and your location to bring back a list of Wikipedia articles about features that are near you. To get started, click the button below and allow the application to read your geolocation information.</p>
        <input type="button" value="Get My Location" id="getLocation" />
    </div>
    <div data-role="footer">
         <h4>By <a href="http://blog.digitalbackcountry.com">Ryan Stewart</a></h4>
    </div>
</div>
<div data-role="page" id="dashboard">
     <div data-role="header">
         <h1>Data List</h1>
    </div>
    <div data-role="content">
         <ul id="wikiList" data-role="listview" data-theme="c">
        </ul>
    </div>
    <div data-role="footer">
         <h4>By <a href="http://blog.digitalbackcountry.com">Ryan Stewart</a></h4>
    </div>
</div>
</body>

With my structure set up I can now start adding jQuery-mobile specific interactions. As soon as I add the jQuery mobile libraries to my application it knows how to parse the data-role attributes and themes the application accordingly. What you get is something like on the right. Using Notice how it automatically styles the header and footer sections as well as providing a nice, big, touchable button and some styling on the footer link to indicate that it can be tapped.

With the external jQuery and jQuery mobile files included I can move on to adding interactivity. I start by adding a click handler to my button which will go out and grab the geolocation information if it’s available. It’s just using the HTML5 geolocation API which is supported by most modern browsers. When the user clicks the button, it will get the current position and then call onSuccess or onError depending on whether or not the API call worked.

$(document).ready(function(){
     // Add a click listener on the button to get the location data
     $('#getLocation').click(function(){
          if (navigator.geolocation) {
               navigator.geolocation.getCurrentPosition(onSuccess, onError);
          } else {
               // If location is not supported on this platform, disable it
               $('#getLocation').value = "Geolocation not supported";
               $('#getLocation').unbind('click');
          }
     });
 
});

Next I set up a namespace for the geonames information. It has variables for the baseURL and then a search function with the getJSON function that goes out and calls the Geonames API. The function loops through each one of the results and then creates an

  • tag and appends the data we want to show to it, including the title of the Wikipedia article, the distance, and a summary. This is all straight jQuery. But after that we get into a couple of jQuery mobile-specific parts.

    // create the geonames namespace for calling the API
    var geonames = {};
         geonames.baseURL = "http://ws.geonames.org/";
         geonames.method = "findNearbyWikipediaJSON";
         geonames.search = function(lat,lng){
     
         // get the data in JSON format from Geonames
         $.getJSON(geonames.baseURL + geonames.method + '?formatted=true&lat=' + lat + '&lng=' + lng + '&style=full&radius=10&maxRows=25',function(data){
              // Loop through each item in the result and add it to the DOM
              $.each(data.geonames, function() {
                   $('<li></li>')
                   .hide()
                   .append('<a href="http://'+this.wikipediaUrl+'"><h2>'+this.title+'</h2></a><br /><p>'+ this.summary + '</p><span class="ui-li-aside"><h5>'+this.distance+' (km)</h5></span>')
                   .appendTo('#wikiList')
                   .show();
              });
              // Once the data is added to the DOM, make the transition
              $.mobile.changePage('#dashboard',"slide",false,true);
     
              // refresh the list to make sure the theme applies properly
              $('#wikiList').listview('refresh');
         });
    };

    The page model in jQuery mobile gives you a lot of control over how those pages are displayed. By default, when you set up an anchor tag it will play a default transition and go to the page you want. If that page is an external page it will load that external page in the browser. If it’s an internal, local link (with a hash), then jQuery will perform a slide transition and then swap out the old page content with the new one. It also updates the URL by default so you can use the back button that’s included in the header or the back-button on your device/browser and go back to the original page. Pretty slick that this all happens by default. However if you want more control you can use the $.mobile.changePage method which is what I’m using because I wanted to only change the page after I had parsed the data from Geonames. With mobile.changePage I specify the URL, which in this case is just the id of the new div tag, the transition I want, whether I want the animation to be reversed, and finally whether I want to change the URL so the user can go back to the first screen. By default when you use mobile.changePage the last attribute is set to false so it won’t update the URL in the navbar. In this case I want them to be able to update their location when they move so I set the property to true.

    The last thing I have to do is refresh the list to make sure the styles are applied to the new data. Lists are incredibly sick in jQuery an jQuery mobile. By using the data-role attribute and the data-theme attribute you can create some very powerful lists. In this case, I’m just using the default list so my <ul> tag has an id of wikiList, and a data-role of “listview”. That means any <li> tags I add to it will become jQuery mobile list items. And that’s exactly what happens in my Geonames callback function when I iterate through each item. It’s creating <li> elements with my data and appending them to my wikiList <ul> tag. Then when I call .listview('refresh') on my wikiList, it styles them appropriately. One cool feature of jQuery mobile lists is that there are a few different properties I can set to add some stylistic touch. For example, to show distance I’m using a span tag with the class set to ui-li-aside. That class will right-justify the content so my distance shows up on the right side.

    And that’s pretty much all there is to it. The last bit of code I have is just the onSuccess and onError functions that handle the geolocation API.

    // Success function for Geolocation call
    function onSuccess(position)
    {
         geonames.search(position.coords.latitude,position.coords.longitude);
    }
     
    // Error function for Geolocation call
    function onError(msg)
    {
         alert(msg);
    }

    You can check out the full application here and see it in action. This is just scratching the surface of what you can do with jQuery mobile but hopefully you got a sense of the page model and how to move back and forth between screens. In some later posts I’ll hopefully cover the new gestures, the new components, and some of the ways to lay out content.

    View full post on Digital Backcountry – Ryan Stewart’s Flash Platform Blog

  • 13 Reasons Why One Developer Dropped Google App Engine

    Posted by magician | Posted in Web | Posted on 30-11-2010

    0

    Carlos Ble is a developer out of Spain. His company decided to use Google App Engine (GAE) but dropped it after what he said were months of delays.

    Earlier this week, Ble outlined in a blog post the 13 reasons why his company decided to drop Google App Engine. The post had 89,000 views and 158 comments in one day. Some commenters were sympathetic, others chided Ble for blaming Google when the company should have done more research to see if the platform was right for what he and his team wanted to do.

    One comment came from Patrick Chanezon, Google Developer Relations Manager for Cloud & Tools. In respect to Chanezon and to clarify his concerns, Ble updated his post but still felt there were enough problems to stick with his criticisms.

    Here are five issues Ble lists that give a sense of the problems his team encountered.

    1. It requires Python 2.5, which is really old. Using Ubuntu that means that you need a virtualenv or chroot with a separate environment in order to work with the SDK properly: Ok, just a small frustration.
    2. You can’t use HTTPS with your own domain (naked domain as they called) so secure connections should go though yourname.appspot.com: This just sucks.
    3. No request can take more than 30 seconds to run, otherwise it is stopped: Oh my god, this has been a pain in the ass all the time. When we were uploading data to the database (called datastore a no-sql engine) the upload was broken after 30 seconds so we have to split the files and do all kind of difficult stuff to manage the situation. Running background tasks (cron) have to be very very well engineered too, because the same rule applies. There are many many tasks that need to take more than 30 seconds in website administration operations. Can you imagine?
    4. Every GET or POST from the server to other site, is aborted if it has not finished within 5 seconds. You can configure it to wait till 10 seconds max. This makes impossible to work with Twitter and Facebook many times so you need intermediate servers. Again, this duplicates the time you need to accomplish what seemed to be a simple task
    5. You can’t use python libraries that are build on C, just libraries written in python: Forget about those great libraries you wanted to use.

    Ble writes that in September, Google App Engine repeatedly failed. He says they faced 500 error codes that some days had the site down 60% of the time. Six times out of 10, users visiting the site couldn’t register or use the site.

    Ble admits that he should have been more careful but he had confidence in Google.

    “For us, GAE has been a failure like Wave or Buzz were but this time, we have paid it with our money. I’ve been too stubborn just because this great company was behind the platform but I’ve learned an important lesson: good companies make mistakes too. I didn’t do enough spikes before developing actual features. I should have performed more proofs of concept before investing so much money. I was blind.”

    Several commenters were not so sympathetic with Ble’s plight. They said he should have done more research or that he had a design problem.

    But then comes this comment from Eugene Ciurana, who literally  wrote the book about Google App Engine:

    “Carlos, I wrote the first book about Google App Engine programming a couple of years ago. Ever since publication I had several opportunities to speak about App Engine for Python and Java at various conferences; I realized early on that my presentation “Google App Engine HOWTO” had become a “things to watch out in App Engine” and ultimately recommended folks to NOT use it for anything serious. I enjoyed your post and have tweeted because I think it’s an important cautionary tale. Most of the work I do has to do with scalability and high availability. While I’d like App Engine to become part of my arsenal, it’s now only a marginal part of it, relegated to providing stateless RESTful web services instead of full blown apps. The real app continues to sit in a regular data centre or we put it on Amazon/Rackspace/etc. About NoSQL systems: Datastore is hardly a good example of a good one. It’s good enough for App Engine, but you now know its caveats. Right tool, right job. I’d suggest that, should you identify document- or column-based data storage and retrieval needs, that you take a look at mongoDB and HBase. We’re using both in production with large enterprise clients without issues. Take care and cheers! Eugene Ciurana”

    In his comment, Chanezon said that many of the points that Ble makes are known by Google. He said the company is working to correct the problems.

    Chanezon stressed that it is critical that people read the Google App Engine documentation. He said limits have been lifted. The service is designed for highly scalable applications that need to scale rapidly to large volume of users and/or data. He refers to Gri.pe as an example.

    What do you think? Does Ble have legitimate concerns?

    View full post on Web Technology Blog, Development and Social Media

    Google Wave May Live On as an Apache Project

    Posted by magician | Posted in Web | Posted on 29-11-2010

    0

    To paraphrase Mark Twain, it appears that rumors of Google Wave’s death may be greatly exaggerated. Google announced that it was ending development on the project back in August. But some of Google Wave’s developers have submitted the code for what’s now known as Wave in a Box (WIAB) to the Apache Software Foundation.

    The project will now be a candidate to become a Podling in the Apache Incubator, the first step in becoming one of Apache’s open-source projects.

    Google Wave was introduced in 2009 as a distributed, real-time communication and communication platform. But, citing low user adoption, Google ended the project earlier this year. Google has made moves towards packaging Wave in a Box so that developers can have standalone functionality of Waves and can run them on their own servers.

    Many of Wave’s components are open source, so others can and do continue to work on the project. According to the Apache Incubator proposal, “We anticipate early future committers coming from places like Novell, SAP, companies related to the US Navy’s usage of wave, startups in the wave ecosystem, and many independent individuals.”

    The initial goals of the WIAB project include migrating the codebase from code.google.com to the ASF infrastructure and then continuing the project’s development and growth of its developer community. ComputerWorld cites Dan Peterson, one of the developers on the project, as indicating that a vote from the Apache Software Foundation on whether Wave in a Box will become an Apache Incubator Project may come as early as next week.

    View full post on Web Technology Blog, Development and Social Media

    Google Chrome to Support Multiple Simultaneous Profiles

    Posted by magician | Posted in Web | Posted on 29-11-2010

    0

    If you ever share a computer with a friend or family member, you’ve probably experienced the challenge of remembering who is logged in to accounts on Google or other services. User’s of Google’s excellent Chrome browser will be happy to hear that now in the works is a simple feature that will allow multiple browser windows to run different Google Profiles with a simple click of a button.

    The feature is not yet available but was spotted in developer documentation and first reported on by the watchdog blog Google Operating System. While this might seem like a simple matter of convenience, it also represents the convergence of a number of other trends in online computing.

    Above, a mock-up of how the Mac version of Chrome might display which account is running in a particular window. New browser windows will use the same account that the last active window was using, and all browser extensions will be common across all windows regardless of account.

    Incidentally, speaking from one ad-supported company to another, it’s hard not to notice that there’s Ad Block Plus running in the mock-up screenshot of this browser. Thanks, Google.

    What it All Means

    Computing in the cloud. The browser as a key to identity. Personalization of the computing experience. Those are the kinds of things we see here and in many other developments on the web, to put this news in context.

    It would be great to see different browser window identities entirely partitioned off from each other, with different sets of cookies, so that you could run different accounts on Twitter, Facebook and other services at the same time too.

    Consider this in conjunction with Chrome’s plan to experiment with predictive background tab preloading for “wicked fast navigation” and I think you’ll agree – the world of the browser looks to be very different in the future.

    What’s Google’s economic incentive to develop features like this? The nicer it is to browse, the more you’ll do it, and the more you browse – the more ads you’ll see. That’s not the whole story, but it is the part that pays the bills.

    View full post on Web Technology Blog, Development and Social Media

    Powered by Yahoo! Answers