Tagged: jquery Toggle Comment Threads | Keyboard Shortcuts

  • danielsaidi 8:50 pm on December 1, 2011 Permalink | Reply
    Tags: api, , , fredrik mörk, , jquery, nathan totten, neil ford, , phil haack   

    Øredev 2011 in the rear-view mirror – Part 2 

    Øredev logo

    This is the second part of ny sum-up of Øredev 2011.

    I will label each session with day:order to satisfy all structure freaks (myself included) that read this.

    1:4 – Phil Haack – Building Mobile applications with ASP.NET MVC4, HTML5 and jQuery Mobile

    This session was quite interesting, since Phil discussed a lot of aspects of mobile browsing and how ASP.NET MVC4 can help you out by introducing .

    Adaptive rendering will be added to the default web application template, which will cause the page to automatically render differently depending on the size of the screen. If you want to view how adaptive rendering works, check out Zurb Foundation. In other words, ASP.NET MVC4 does not introduce adaptive rendering to the world – there are already plenty of free options that you can greb and use directly after reading this post. It’s just a convenience.

    Another new, cool feature is that it is possible to create device-specific variations of the same view, so that Index.cshtml is the default one and Index.iphone.cshtml is the variation that you’ll see when viewing the site in your iPhone. Custom modes can be registered in global.asax, which means that you are entirely free to tailor your own set of custom views.

    Phil also demonstrated using iBBDemo2 for simulating an iPhone when browsing the web. Quite handy if you want to easily be able to try out your custom views.

    All in all, a quite interesting session, although Phil did not seem too enthusiastic about it. Also, the wifi at Øredev was a disaster, and caused several speakers a lot of problems. I really hope they improve this until next year.

    1:5 – Nathan Totten – Facebook Development

    Nathan was yet another speaker who got hit hard by the wifi problems, as he demonstrated how to develop apps for Facebook. I really enjoyed this session, despite the technical problems and the fact that I already have developed Facebook apps. Since I am self-taught in doing so, though, listening to Nathan explaining several parts that I have not gotten around to work with before, was a great take-away.

    Nathan talked about various types of Facebook applications, like iFrame apps, web sites with Facebook Connect, mobile applications, desktop applikations (like Spotify) etc. and how they use OAuth 2.0, REST services, the Facebook Graph API and FQL to integrate with Facebook. He also discussed the JavaScript and C# Facebook SDK:s. His advice was to use the JavaScript SDK whenever possible, and to a server-side SDK whenever the integration should be more invisible.

    Finally, Nathan demonstrated how he works with local and live applications, e.g. if you are developing an application locally (running on localhost) and have it live as well. He then creates two separate FB apps – one that is bound to the live site and one that is bound to localhost. Quite convenient. He also told us that  FBML is dead, so do not use it ever again 🙂

    1:6 – Fredrik Mörk – API – the hidden UI

    The first Swedish speaker I got around to listen to was Fredrik Mörk, who spoke about how we have to give our API:s the same tender loving care that we give our UI:s. Users shun bad GUI:s, while developers shun bad API:s, so we should put some effort into our API designs.

    An API must be discoverable, but how? Always assume that the user knows nothing. So, adapt conventions used by other API:s, so that developers instantly recognize the API instead of having to remember it. even if they have not used it before. This involves making it possible to navigate through the API, adapting naming conventions (delete or remove, store or save etc.), put an equal amount of attention to all parts of the API and…take care of the API like you do with other parts of your systems.

    Fredrik advised us to always expose as primitive as possible, to make the API accessible to as many as possible. Always choose abstract before concrete…and choose your abstraction according to the purpose. For instance, if you expose an IList instead of an IEnumerable, you are communicating that you expect your users to insert stuff into it.

    Fredrik’s view upon an API is that once it is out there, it is no longer yours to change. A GUI can change…an API cannot. But, be careful with inserting stuff into your API just because a user wants it in there. It will ultimately bloat your API. And when you insert stuff, be intentional. Do not let chance determine where a feature ends up and what it is called.

    All in all a good session…and quite liberating with a Swenglish accent instead of the spotless American, Scottish and British ones that dominated the rest of the day.

    1:7 – KEYNOTE: Neil Ford – Abstraction Distractions

    After a long day, we decided to skip this session and go for a short nap before hitting a meat restaurant. I have not spoken with anyone who attended it either, so I am at a loss whether it was good, bad or just meh. It will be interesting to check out the video once it is released.

  • danielsaidi 9:51 pm on October 5, 2011 Permalink | Reply
    Tags: branch, , github api, jquery, tag   

    Grab the latest version number from a GitHub repository 

    I am currently hosting several repositories at GitHub. For each, I have also created a GitHub gh-pages branch, so that I have a public site for the project (the gh-pages branch), as well as a project site (the main repository page).

    The goal of the public site is to present the repository and make it easy to download the latest release, while the goal of the project web site is to provide people who have already begun using the repository with information, code etc.

    One example where I do this is at the public Cloney web site:

    As you can see, each web site features a Download button. Before tonight, none featured a version number. So, my thought was “how do I grab the latest version number from the GitHub repository”. The answer is really simple – use the GitHub API.

    First – publish new versions as tags

    For the example in this post to work, each version must be pushed as a tag to the GitHub repository. This is really easy to do.

    Let’s say that you have a new version (let’s say..hmmmm…. of your great project and the master branch has been pushed to your GitHub repo. Now, just type the following (provided that you call the GitHub remote origin):

       git tag
       git push origin

    This will create a new tag with the version number and push it to the GitHub repository.

    Also worth mentioning is that this method requires that each new tag name have a string value that is greater than one preceding it. If you name one tag “release” and another “”, the first will be returned…and you do not want that, do you?

    Then – use the GitHub API to grab all tags

    The GitHub API is really slick, and let’s you do most anything possible. You can find all the info you need at http://develop.github.com/p/repo.html. However, instead of jQuerying the API directly, I decided to try fitzgen’s JavaScript github-api library.

    To grab all tags for a certain repository, you just have write the following:

       var repo = new gh.repo("danielsaidi", "Facadebook");
       repo.tags(function(result){ alert(JSON.stringify(result)); });

    Wow, that was easy! Now, how do I grab the latest version number from the result?

    Finally – add some candy ontop

    Since I will use this solution for all my GitHub repo web sites, I decided to package my custom script according to the rest of the JavaScript library.

    I therefore created another async method for the gh.repo prototype, as such:

       gh.repo.prototype.getLatestRelease = function(callback) {
          this.tags(function(result) {
             var latest = "";
             for (var prop in result.tags) {
                if (prop > latest) {
                   latest = prop;

    On each web site, I have a span with the id “version”.

    At the end of the github.js file, I finally added the following snippet:

       $(document).ready(function() {
          var repo = new gh.repo("danielsaidi", "Facadebook");
          var tags = repo.getLatestRelease(function(result){ $("#version").html(result); });

    That is is! When the page loads, I load all available repository tags, iterate over them and grab the “highest” tag name (version number) available.

    The result is rather nice:

    Version number is now displayed within the download button

    Hope this helps!

  • danielsaidi 9:05 am on February 2, 2011 Permalink | Reply
    Tags: flash, gears, , , , jquery, plupload, silverlight,   

    Trying out Plupload 

    In Wigbi, I had a really handy UI plugin called FileUploadForm that could upload any number of files with AJAX. All you needed to do was to add such a form to the page to have it handle the entire file upload process automatically.

    However, as I yesterday sat down to migrate the old plugin so that it would work with the new Wigbi version, I thought “hey, three years have passed – there MUST be an even easier way to upload files”. Believe it or not, there was.

    The people behind Tiny MCE have created a really nice file upload component called Plupload. It supports several ”runtimes” – from jQuery-based file upload in HTML4/5 to Flash, Silverlight, Gears etc. and is insanely easy to configure.

    You can tell Plupload which runtimes you’d prefer to use, which file types to support etc. The users can then upload files either with a regular “select file(s)” dialog or by dragging files from an Explorer/Finder window.

    To make Plupload work with Wigbi, I moved the upload.php file to ~/wigbi/pages/ and added some extra functionality, like starting/stopping Wigbi and being able to adjust the target folder with a query string variable.

    All in all, adding Plupload to my Wigbi-based site took 10 minutes and worked perfect.

  • danielsaidi 11:38 am on October 7, 2010 Permalink | Reply
    Tags: jqgrid, jquery, onselectrow   

    onSelectRow fix for jqGrid 

    I just love the jqGrid jQuery plugin. If you haven’t tried it out yet, perhaps you should?

    Still, if you look up the online demos that describe how to edit a row, you may discover that the onSelectRow method used in the demos is not quite perfect. After editing a row, you must select a new one before you can edit the first one again.

    I replaced the original onSelectRow method…

    onSelectRow: function(id) {
       if (id && id!==lastsel) {

    …with this one…

    onSelectRow: function(id) {
       if (id) {
          if (id !== lastsel) {
             articleGrid.jqGrid('restoreRow', lastsel);
             articleGrid.jqGrid('editRow', id, true);
             lastsel = id;
          } else {
             articleGrid.jqGrid('restoreRow', lastsel);
             lastsel = "";

    …and now, the grid behaves a lot more like I want it to.

  • danielsaidi 10:16 pm on September 22, 2010 Permalink | Reply
    Tags: , internet explorer, jquery,   

    IE bug fixed for web fonts 

    Yesterday, I uploaded a demo page where I tried out the awesome fonts.com Web Fonts service…

    …however, Internet Explorer did not really like the page. Turns out

    <button onclick="$('.comic').animate({fontSize: '3em', });">Text can be resized!</button>

    was too much for Internet Explorer to handle. It should be:

    <button onclick="$('.comic').animate({fontSize: '3em' });">Text can be resized!</button>

    I rest my case. The bug is fixed. Thanks for not handling any exceptions, IE!

  • danielsaidi 5:55 pm on June 10, 2010 Permalink | Reply
    Tags: inheritance, jquery, json,   

    jQuery, object inheritance and JSON 

    When developing a hobby project of mine, I previously used both MooTools and jQuery as embedded toolkits. Now, however, I have decided to exclude MooTools and only keep jQuery.

    MooTools have some really nice features, but since i only used its object inheritance and JSON implementation, I decided to exclude it in the upcoming 1.0 release. The less 3rd part components, the better.

    Class inheritance

    When I no longer have the MooTools Object class, I use the jQuery extend function to create inheriting classes, as such:

    function InheritingClass() {
       $.extend(this, new BaseClass("optional parameters"));

    while the MooTools Object class required a syntax like this:

    var InheritingClass = Class({
       Extends: BaseClass,
       initialize: function() { this.parent("optional parameters"); }

    The later example requires knowledge about the MooTools object model, while the first only requires that developers know how to use the extend method.

    JSON encoding/decoding

    MooTools features a nice JSON encode/decode implementation, which I will thus not be able to use anymore, so I had to find an alternative.

    jQuery contains (at least) two functions that can be used to handle JSON – parseJSON and serializeArray. However, the later only works with DOM elements, so it is not really what I was after.

    After doing some reading, it seems like the official json.org JSON JavaScript implementation is the best around, while a jQuery plugin that I found had quite an extensive issue list.

    So, although it makes me depend on yet another 3rd part component, I chose this nice little class, which I have used before. MooTools is hereby completely replaced with jQuery (and the small JSON class).

  • danielsaidi 6:45 pm on June 3, 2010 Permalink | Reply
    Tags: jquery, , , ,   

    Hide successful QUnit tests 

    I am now rolling with QUnit as TDD framework for my JavaScript development. It’s not as sophisticated as say NUnit for .NET or SimpleTest for PHP, but it’s reaaally easy to get started with.

    However, a strange way of designing the test result presentation is that QUnit lists all tests, not just the ones that fails. With just a few executing tests, the resulting page looks like this:

    QUnit - Full test result presentation

    By default, QUnit lists all executing tests in a test suite

    The test suite above only includes 14 tests – imagine having maybe a hundred or so! In my opinion, this way of presenting the test result hides the essence of testing – to discover tests that fail.

    I understand that one must be able to confirm that all tests are executed, but the number of executed tests are listed in the result footer. So, I would prefer to only list the tests that fail.

    If anyone knows a built-in way of achieving this, please let me know. I chose the following approach (applies to jQuery 1.4.2 – let me know if this is out-of date):

    1. Open the qunit.js file
    2. Find the block that begins with the line:
      var li = document.createElement("li");
    3. Wrap the entire block within:
      if (bad) { ... }

    This will make QUnit only append the list element if the test is “bad”, that is if it failed. The result will look like this:

    After fiddling with the code, QUnit only lists failing tests

    Maybe there is a built-in way of making QUnit behave like this. If you know how, please leave a comment.

  • danielsaidi 11:53 am on May 28, 2010 Permalink | Reply
    Tags: jquery, jsunit, , ,   

    JsUnit vs. QUnit 

    I am rewriting an old JavaScript project and will apply TDD principles when developing the new version. When browsing for various JavaScript TDD frameworks, JsUnit and QUnit seem like the two most promising candidates.

    JsUnit uses a syntax that appeals to me, as an NUnit lover. However, since I am also a big fan of jQuery, QUnit could be a better alternative, although the framework seems quite small (yet, ok, equals and same are maybe sufficient?).

    Has anyone any experience of these two frameworks and could recommend either?

    • Raj 1:31 am on September 26, 2010 Permalink | Reply

      Hi Daniel
      I had the same question for my self. Which one is better? I haven’t tried JsUnit much but I have used QUnit. It seems to me that QUnit is easy to use than JSUnit. Please see the below post for some info.


      • danielsaidi 7:40 pm on October 3, 2010 Permalink | Reply

        Well, as I wrote, I think that the JsUnit syntax feels more “for real”, but I decided to go with QUnit and I have only had good experiences with it. I think that the ok key word – ok(shouldBeTrue) and ok(!shouldBeFalse) – is a bit cheesy, but it really does the job with minimum setup. Also, it makes testing async functionality really smooth. However, I decided to tweak QUnit a bit, so that it only displays failing tests…a loooong list with everything that went ok is really not that informative to me 🙂

      • danielsaidi 7:41 pm on October 3, 2010 Permalink | Reply

        By the way, what did you think of JsSpec? Have you had the time to try it out?

Compose new post
Next post/Next comment
Previous post/Previous comment
Show/Hide comments
Go to top
Go to login
Show/Hide help
shift + esc