thedailywhat:

Ben Warheit.

(via midiprincess)

So we fixed an issue today that was a pain to track down so I am going to document that here. In our system we use SWFObject to embed swf objects into our dom when the time is right. We had unknowingly loaded two instances of the same library into the same endpoint. The code flow went something like this:

namespace.swfobject = SWFObject…
// do some stuff with namespace.swfobject
namespace.swfobject = SWFObject…

This was causing an error in IE where the events that were bound for dom ready would never fire. The current theory is that all other browsers were caching the correct reference in memory during the parse stage and so only adding events to the last reference of SWFObject but IE was binding the events on the first one and losing the object reference when the SWFObject library was over written.

Kanpai Sushi was a real treat. The wife and kids all found things on the menu that they wanted and the price was very reasonable. The quality of the rolls was high but be warned: the spicy rolls are REALLY spicy, they are not joking. The service was good and food arrived very promptly after ordering. Refills on green tea were also included in the price which always helps.

JavaScript questions of interest during sushi: 

1. Is there any reason to put semicolons at the end of every statement, or to avoid line termination before the end of a statement?
2. How can I implement simultaneous script downloading to improve page speed without compromising the run order of my script libraries?

Answers:

1. There is really no safety based reason to place semicolons at the end of a statement in JavaScript. Occasionally placing them in can help with passing a Lint test or keeping your code looking like Java or C, whatever. It’s been over a decade since the need to place semicolons at the end of lines for fear of the browser injecting them on you. Here is a great open letter to the leaders of the JavaScript community regarding this issue that I think is worth reading.
2. I recently had to make this happen for a website that relies on the jQuery library and quite a number of plugins. Different pages had different needs but generally the page was loading the whole site worth of JavaScript on every page and while it is true that the files load from the cache, execution of scripts was still blocking the rendering engine from starting early.
   
   So the first step I took was to create a dependency breakdown and start cutting the files up into module sized chunks of code that could be combined later. Then I wrote a tool to easily create a compilation list and concatenate the files into appropriate dependency groups. After doing some work to implement a good closure compiler process we were ready to actually work within the documents.
   
   Everything needs to be removed from the head of the document and in as much as possible lazy load anything you can. Non dependent scripts can easily be lazy loading with a little chunk of inline JavaScript just before the closing body tag:
   
   

   <script type="text/javascript">
   var scripts = ['script1.js','script2.js'];
   for(var i = 0, script; script = scripts[i++];){
     var scriptelem = document.createElement('script')
     scriptelem.type = 'text/javascript'
     scriptelem.src = script
     document.body.appendChild(scriptelem)
   }
   </script>

   
   This is a fairly crude implementation and won’t get you very far so I definitely advise checking out the library over at HeadJS for a full featured script loader and modernizr. We did not get a chance to implement this in our project so the short answer for how to force scripts to run in order? Load the scripts in order using something other than the text/javascript type, like text/cache (use an object tag for firefox) or just place the scripts you need loaded in order in the bottom of the document like you would before and let everything else lazy load, the performance hit will be minimal.

Today I had no sushi… overcoming my sadness required…. ruby on rails.

http://heroku.com/ is the definition of app hotness when one needs to spin up a mongoDB and right rails apps till the requests come home. Turns out they are also piloting a very exciting node.js hosting offering. I have just gotten set up with them thanks to my friend and fellow ninja jamslevy who suggested it when I was saying how cool it would be if Google App Engine supported node.

JavaScript Questions of Interest during Die Trying:

1. What is a closure and why would you need to use one?

1b. bonus: are there any hidden dangers to using a closure?

2. What is a prototype and why should you care?

Answers:

1. A closure is a method with another method inside it. Especially a method within a method that uses some argument from the parent method. Let me explain, If I write a method:

  function add(a,b){
    return a + b;
  }

nothing to see here, it will dutifully return the sum of whatever I enter. Now lets put it inside another method that for our purposes will be used as an object:

  function addMaker(n){
    this.add = function(b){return n + b;}
  }

do you see what happened there? Go ahead and punch that into your chrome console and then run the following:

> seven = new addMaker(7)
> seven.add(12)
> 19

You see the closure retains the state of the object at the time the object was created as part of the internal methods structure, or more accurately the internal method retains the local variables of the external method after the external method has exited.

1b. There is a condition in where circular references will cause a memory leak UNTIL THE BROWSER IS CLOSED IN SOME BROWSERS!

2. Prototypes are really technically everywhere in JavaScript. You can’t create an object without it wiggling its little null prototype object in the air. For the most part this means nothing, until you want to do something fancy, let’s say add a method as a fall back to another potential method. Consider the following:

  function Plumber(union){
    this.union = union; 
    this.cleanpipes = function(){
      alert(union + "These pipes are clean")
    }
  }

  function Person(name)
  { 
    this.name = name;
    this.sayHello = function(){
      alert("Hello there, my name is " + name)
    }
  }
  Person.prototype = new Plumber(242)
  bob = new Person("Bob")
  tim = new Person("Tim")
  bob.sayHello()
  tim.cleanpipes()

You will notice here that while the Person object that tim and bob represent does not contain the method cleanpipes, tim can still tell us that his plumbers union 242 has cleaned the pipes. This can lead to some pretty useful variations of object inheritance and polymorphism.

Some photos from the birthday party!

http://littlemadfish.com/ was the site of my most recent sushi excursion. I had the spicy tuna roll and a fire dragon. Both were delicious. Prices were very reasonable and the staff was courteous. They are also open through the 2 - 5 shutdown time of most Sushi restaurants.

JavaScript questions of interest during the sushi:

1. if you run to concurrent asynchronous requests where each success callback method relies on data from the other request, is there anything you need to worry about?

1b. bonus : how could you ensure that one event fires after the other?

2. facebook was facing an issue where they were loading a 1MB javascript file early in the page to allow the user interface to react properly do to a dramatically large number of UI elements and associated event listeners. What did they do to reduce the size of the js file and what would you do?

Answers:

1. Because JavaScript has no locking, anytime you run asynchronous methods that rely on each other and are run concurrently you run the risk of a race condition. I think there must be a way to decouple them so that you could still do it properly without the race condition but benefit from the concurrent requests. Maybe web workers could be put to use for such a thing.

1b. There are a couple of ways to do this, one of course is to set the async option to false when constructing the XHR. Another is to chain the call of the second request into the success response of the first.

2. Facebooks solution was to have only one event listener on the page and use class (or other markup) annotations to indicate which event types, from 4 or 5 different consistent UI patterns, the element clicked needed to fire. I think the solution is pretty brilliant and clearly for a UI as “complicated” as facebook that would work. My first thought to solving it was to create a method factory (essentially the same concept of 4 or 5 UI patterns) that would allow me to construct the event listeners by selector.

Hazelnut coffee is my dark secret coffee love. I know I should like black hearty rich coffee but honestly sweet hazelnutty goodness gets me out of bed in the afternoon.

tumblrbot asked: WHERE WOULD YOU MOST LIKE TO VISIT ON YOUR PLANET?

Japan.

My new favorite sunglasses.