Who is talking?


Use recipientList for dynamic routes

over 8 years ago | Subodh Gupta: Subodh's Blog

I was writing the route in which "to" endpoint was need to be configured dynamically with the URL coming in the body.I was trying to use simple expression language (e.g. ${in.header.test} where test is the property set in the in-message header) also with header method (e.g. header(test)). The routes for the same were:from("direct:test").to("${in.header.test}");& from("direct:test").to(header("test"));  after literally every thing i could have. I figured out recipientlist can do the trick e.g.from("direct:test").recipientList("${in.header.test}");& from("direct:test").recipientList(header("test"));Hope this works for you too.

Getting Closure

over 8 years ago | Mark Daggett: Mark Daggett's Blog

Understanding the Dark Arts of JavaScript Closures "No matter where you go, there you are." - Buckaroo Banzai The purpose of this post is to explain how closures work in plain english, and to give a few compelling examples where the use of closures really improve the quality of your code. Like many others I am a self-taught programmer, and little over a decade ago I was also a freshly minted Creative Director working in Los Angels. I was employed by a major footwear brand, and had inherited a team of very bright and technically gifted programmers. I felt that I needed to learn enough code to speak intelligently to them. I didn’t want to propose a feature that wasn’t possible, and more importantly I wanted to understand the promise and the problems inherent in the medium we were building within. More generally though, I am just a very curious person who likes to learn. Once I started to pull that tread the world of programming began to unwind for me. Now years later, here I sit writing about the internals of JavaScript. Being that my computer science education has been ad-hoc there are many core concepts in JavaScript (and programming in general) that I wanted to understand better. My hypothesis is that there are others like me who have been using and abusing JavaScript for years. For this reason I decided to write on closures an often used but equally often misunderstood concept in JavaScript. Closures are important for a variety of reasons: They are both a feature and a philosophy that once understood makes many other concepts (e.g. data binding, promise objects) in JavaScript easier. They are one of the most powerful internals of the language, which many other so-called real languages don’t support. They are where JavaScript is trending due to the rise in popularity of asynchronous execution. For all the potential benefits that closures offer, there is a black magic quality to them that can make them hard to understand. Let’s start with a definition, A closure is the act of binding all free variables, and functions into a closed expression, that persist beyond the lexical scope from which they were created. While this is a succinct definition it is pretty impenetrable for the uninitiated; let’s dig deeper. The Straight Dope On Scope Before we can truly understand closures we must take a step back and look at how scope works in JavaScript. When reading about JavaScript periodically writers will make reference to lexical scope, or the current and/or executing scope. Lexical scope simply means that where a statement is placed within the body of the script is important and effects how it can be accessed, and what in turn it has access to. In JavaScript unlike other languages the only way to create a new scope is through a function invocation [1]. This is what programmers mean when they say JavaScript has function level scoping. This form of scoping may be anti-intuitive to programmers coming from languages that support block-level scoping e.g. Ruby. The following example demonstrates lexical scope: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 // Free Variable var iAmFree = 'Free to be me!'; function canHazAccess(notFree){ var notSoFree = "i am bound to this scope"; // => "Free to be me!" console.log(iAmFree); } // => ReferenceError: notSoFree is not defined console.log(notSoFree) canHazAccess(); As you can see the function declaration canHazAccess() can reference the iAmFree variable; this is because the variable belongs to the enclosing scope. The iAmFree variable is an example of what in JavaScript is called a free variable [2]. Free variables are any non-local variable which the function body has access to. To qualify as a free variable it must be defined outside the function body and not be passed as a function argument. Conversely, we see that referencing notSoFree from the enclosing scope produces an error. This is because at the point at which this variable was defined it was inside a new lexical scope (remember function invocation creates a new scope). Put another way, function level scopes act like one-way mirrors; they let elements inside the function body spy on variables in the outer scope, while they remain hidden. As we’ll see below closures short-circuit this relationship, and provide a mechanism whereby the inner scopes internals can be accessed by the outer scope. Thisunderstandings One feature of scopes, that routinely throw developers off (even seasoned ones) is the use of the this keyword as it pertains to the lexical scope. In JavaScript the this keyword always refers to the owner of scope from which it is executing. Misunderstanding how this works can cause all sorts of weird errors where a developer assumes they are accessing a particular scope but are actually using another. Here is how this might happen: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 var Car, tesla; Car = function() { this.start = function() { console.log("car started"); }; this.turnKey = function() { var carKey = document.getElementById('car_key'); carKey.onclick = function(event) { this.start(); }; }; return this; }; tesla = new Car(); // Once a user click's the #carKey element they will see "Uncaught TypeError: Object has no method 'start'" tesla.turnKey(); The developer who wrote this was headed in the right direction, but ultimately a thisunderstanding forced them off the rails. They correctly bound the click event to the car_key DOM element. However, they assumed that nesting the click binding inside the car class would give the DOM element a reference to the car’s this context. The approach is intuitive and looks legit, especially based on what we know about free variables and lexical scope. Unfortunately, it’s hopelessly borked; because as we learned earlier a new scope is created each time a function is invoked. Once the onclick event fired this now referred to the DOM element not the car class. Developers sometimes get around this scoping confusion by assigning this to a local free variable (e.g. that, _this, self, me). Here is the previous method rewritten to use a local free variable instead of this. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 var Car, tesla; Car = function() { this.start = function() { console.log("car started"); }; this.turnKey = function() { var that = this; var carKey = document.getElementById('carKey'); carKey.onclick = function(event) { that.start(); }; }; return this; }; tesla = new Car(); // Once a user click's the #carKey element they will see "car started" tesla.turnKey(); Because that is a free variable, it won’t be redefined when the onclick event is triggered. Instead it remains as a pointer to the previous this context. Technically, this solves the problem, and I am going to resist the urge of calling this an anti-pattern (for now). I have used this technique thousands of times over the years. However, it always felt like a hack, and fortunately, closures can help us marshall scopes in a much more elegant way. My First Closure In it’s most basic form a closure is simply an outer function that returns an inner function. Doing this creates a mechanism to return an enclosed scope on demand. Here is a simple closure: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 function outer(name) { var hello = "hi", inner; return inner = function() { return hello + " " + name; } } // Create and use the closure var name = outer("mark")(); // => 'hi mark' console.log(name); In this example you can see that the local variable hello can be used in the return statement of the inner function. At the point of execution hello is a free variable belonging to the enclosing scope. This example borders on meaninglessness though; lets look at a slightly more complex closure: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 var car; function carFactory(kind) { var wheelCount, start; wheelCount = 4; start = function() { console.log('started with ' + wheelCount + ' wheels.'); }; // Closure created here. return (function() { return { make: kind, wheels: wheelCount, startEngine: start }; }()); } car = carFactory('Tesla'); // => Tesla console.log(car.make); // => started with 4 wheels. car.startEngine(); Why Use Closures Now that we know what closures are, let’s look at some use cases on where they can elegantly solve common problems in JavaScript. Object Factories The previous closure implements what is commonly known as the Factory Pattern [3]. In keeping with a Factory Pattern the internals of the factory can be quite complex but are abstracted away in part thanks to the closure. This highlights one of the best features of closures which is their ability to hide state. JavaScript doesn’t have the concept of private or protected contexts, but using closures give us a good way to emulate some level of privacy. Create A Binding Proxy As promised lets revisit the Car class we wrote earlier. We solved the scoping problem by assigning the outer function’s this reference to a that free variable. Instead of that approach we’ll solve it through the use of closures. First we create a reusable closure function called proxy, which takes a function and a context and returns a new function with the supplied context applied. Then we wrap the onclick function with our proxy and pass in the this that references the current instance of the Car class. Coincidentally, this is a simplified version of what jQuery does in their own proxy function [4]. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 var Car, proxy, tesla; Car = function() { this.start = function() { return console.log("car started"); }; this.turnKey = function() { var carKey; carKey = document.getElementById("carKey"); carKey.onclick = proxy(function(event) { this.start(); }, this); }; return this; }; // Use a closure to bind the outer scope's reference to this into the newly created inner scope. proxy = function(callback, self) { return function() { return callback.apply(self, arguments); }; }; tesla = new Car(); // Once a user click's the #carKey element they will see "car started" tesla.turnKey(); Contextually Aware DOM Manipulation This example comes from directly from Juriy Zaytsev’s excellent article "Use Cases for JavaScript Closures" [5] . His example code demonstrates how to use a closure to ensure a DOM element has a unique ID. The larger takeaway is that you can use closures as a way to maintain internal states about your program in an encapsulated manner. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 var getUniqueId = (function() { var id = 0; return function(element) { if (!element.id) { element.id = 'generated-uid-' + id++; } return element.id; }; })(); var elementWithId = document.createElement('p'); elementWithId.id = 'foo-bar'; var elementWithoutId = document.createElement('p'); // => 'foo-bar' getUniqueId(elementWithId); // => 'generated-id-0' getUniqueId(elementWithoutId); Singleton Module Pattern Modules are used to encapsulate and organize related code together under one roof. Using modules keeps your codebase cleaner, easier to test, and reuse. Attribution for the Module Pattern is typically given to Richard Conford [6], though a number of people most notably Douglas Crockford are responsible for popularizing it. The Singleton Module is a flavor that restricts more than one instance of the object from existing. It is very useful for instances where you want several objects to share a resource. A much more in depth example of the Singleton Module can be found here [7], but for now consider the following example: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 // Create a closure var SecretStore = (function() { var data, secret, newSecret; // Emulation of a private variables and functions data = 'secret'; secret = function() { return data; } newSecret = function(newValue) { data = newValue; return secret(); } // Return an object literal which is the only way to access the private functions and variables return { getSecret: secret, setSecret: newSecret, }; })(); var secret = SecretStore; // => "secret" console.log(secret.getSecret()); // => "foo" console.log(secret.setSecret("foo")); // => "foo" console.log(secret.getSecret()); var secret2 = SecretStore; // => "foo" console.log(secret2.getSecret()); TLDR Takeaways Lexical scope gives importance to where code is located within the script body. Free variables are any non-local variable which the function body has access to. The only way for new scopes to be created in JavaScript is through function invocation. The *this* keyword always refers to the owner of scope from which it is executing. A closure allows a function to access variables outside of its lexical scope. [1]http://howtonode.org/what-is-this [2]http://en.wikipedia.org/wiki/Free_variable [3]http://en.wikipedia.org/wiki/Factory_method_pattern [4]https://github.com/jquery/jquery/blob/master/src/core.js#L685 [5]http://msdn.microsoft.com/en-us/magazine/ff696765.aspx [6]http://groups.google.com/group/comp.lang.javascript/msg/9f58bd11bd67d937 [7]http://www.addyosmani.com/resources/essentialjsdesignpatterns/book/#singletonpatternjavascript

Notice - Make a Difference in Your Life

over 8 years ago | Eduard Moldovan: eduardmoldovan.com - tech

There is a post on Web Advent 2012 which is a really good one. It is not about JavaScript, or Node.js, or PHP, or any fancy or not-so-fancy technology. It is just about what should matter.

Notice - Class Selectors

over 8 years ago | Eduard Moldovan: eduardmoldovan.com - tech

Nathan Ford published a great post on class selectors at the end of 2012. It is worth reading, saving.

Datomic for Five Year Olds

over 8 years ago | Daniel Higginbotham: Flying Machine Studios

If you're interested in Datomic, you may have been deterred from checking it out because you lack the enthusiasm necessary to slog through 3 keynotes, 8 interviews, and innumerable walls of text in order to get a basic idea of what the hell it is and whether you should use it. Well, good news! I've done all that for you! How could I resist your winning smile, you charmer you? After you're done with this article, you will have a solid conceptual grasp of the three key ways that Datomic is unique. You will also understand key Datomic terms. This will make it much easier to actually get your hands dirty with Datomic if you decide to investigate it further. Overview of Datomic's Three Righteous Pillars of Databasing Datomic differs from existing solutions in its information model, its architecture and its programmability. Below is a quick overview. We'll cover each of these righteous pillars of databasing in much more detail. Relational DB Schemaless DB Datomic Information Model The unit of information is an entity in a relation and you alter it in place, forgetting previous values The unit of information is a schemaless document and you update it in place, forgetting previous values The unit of information is a fact comprised of an entity, attributes, values, and time. You accrete the assertion and retraction of facts instead of updating in place. Architecture Database is a monolithic system responsible for querying, ACID compliance, and storage Same as RDBMS Separate querying, transacting, and storage in such a way that you get ACID compliance, read scalability, and more power within the application using Datomic Programmability Applications abstract SQL by performing string manipulation Interact with proprietary data structures which are more programming-friendly than SQL but less powerful Datalog, completely uses data structures and has as much power as SQL First Righteous Pillar of Databasing: Information Model A database's information model is defined by its rules regarding the way entities and attributes relate to each other — for lack of a better term, its schema system. Yea, the choice between a relational and schemaless database is probably your primary concern in choosing a database because of its influence on how you write and grow your programs. You'll see that Datomic's schema system isn't as rigid as the relational model but affords more power than a schemaless database. Additionally, a database's information model is defined by its approach to time. Datomic's approach to time is different from most, if not all, existing databases. Below are the schema systems for relational dbs, schemaless dbs, and datomic, followed by a comparison of the way the information models handle time. Relational Schemas You're probably already familiar with the relational model. Here are key definitions: Entity An entity is tuple within a relation. It is comprised of a fixed set of attributes. In practice, an entity is a row in a table. Attribute A name + a data type. A column in a table. Attributes do not exist outside of relations. Attributes in different relations are always logically distinct, even if they hold the same type of data. Relational Probably the most important fact about the relational model is that it's rigid. Every entity must belong to a rigid relation. There's no way to add or remove attributes except by altering the structure of the relation, which in turn alters every other entity in that relation. Schemaless Schemaless (NoSQL) databases were created to address the rigidity of relational databases. They offer a few facilities for organization - for example, collections in MongoDB - but forego any structure for entities. This lack of structure comes at a cost: it limits your query power and forces data integrity concerns into your application. Entity For our purposes, a document. A document has no restrictions on what attributes it can have. Attribute A name. Attributes can hold values of any type, and an attribute belonging to one entity is logically distinct from all other attributes, even those belonging to other entities within the same collection. Relationships between attributes are enforced within the client application. Schemaless Datomic Schemas In Datomic, a schema defines a core set of attributes which effectively act as data types. An entity can possess any attribute without restriction. In this way, entities have more structure than a schemaless database but are more flexible than in relational databases. Additionally, you retain the query power of the relational model without having to handle data integrity concerns in your client applications. Entity A map of attribute/value pairs. Entities have no fixed shape; they can be comprised of any attributes defined in the schema. Attribute Name + data type + cardinality. Attributes themselves can be thought of as data types. They differ from attributes in the relational model in that they exist independently of rigid tables Datomic Time Datomic's notion of time might be unfamiliar for those unacquainted with Rich Hickey's thoughts on time and how it relates to identity, value, and state. To get up to speed, check out my article, "The Unofficial Guide to Rich Hickey's Brain" In both relational and schemaless databases, there's no built-in notion of time. It's always "now" - the database doesn't hold on to the past. Whenever you update or delete a row, you have no way of retrieving previous states for that row. This is the source of many headaches for us. If you've ever used or any code that requires multiple trips to the database in order to perform one unit of work, you know what I mean. In between each trip, you have no way of knowing whether the database has been been altered. You can end up writing all kinds of hacks to avoid race conditions and still not end up with a bulletproof system. In addition, it's virtually impossible to query past states. You might not think this is really matters because you're used to the limitation, but being able to easily query past states is very powerful. In Datomic, time is a first-class concept. All changes to the database are associated with a transaction, and each transaction has a timestamp. Rather than updating an entity in place and "forgetting" its previous state, datomic "accretes" states. In this way, you're able to retrieve all previous states for an entity. Datomic Another way of thinking about it is that the database is an identity which we superimpose on a time-ordered collection of values. In this line of thinking, a "value" is the database as whole - its collection of entities and attributes. When you run a transaction which creates, updates, or deletes entities, you create a new database value. You're always able to say, "I want to work with the value of the database at this point in time." Datomic's Information Model Summarized In Datomic, the unit of information is a fact. A fact is comprised of an entity, an attribute, a value, and time. If you were to say "The princess", that would not be a fact. If you were to say, "The princess's favorite condiment", that would not be a fact. A fact would be "The princess's favorite condiment is mustard," that would be very close to a fact. "The princess's favorite condiment is mustard as of 10pm on February 10th." is a fact. Facts don't go away. If the princess's tastes change so that she prefers sriracha, it's still useful to know that in the past she preferred mustard. More importantly, new facts don't obliterate old facts. In Datomic, all prior facts are available. Also, in Datomic, facts are called "datoms" and not "facts" because it's more exciting that way. For more, check out The Datomic Information Model, an article by Datomic's creator, Rich Hickey. Second Righteous Pillar of Databasing: Architecture Existing databases couple the following into one monolithic product: Reading Writing Storage Datomic decouples these capabilities. All writing is handled by a single "transactor", ensuring ACID compliance. This is the only point of similarity to existing solutions. Side note: the diagrams at the Datomic Architectural Overview page are quite awful. Besides being ugly, it is difficult to tell what the visual components signify. What do the arrows mean? What does the dashed border mean? WTF is "Comm"? Please, please fix these. OK, rant over. Your application communicates with datomic through the Peer Library, a component which exists within your applicaiton. Using the Peer Library makes your application a Peer. I think the Datomic guys were trying to avoid the term "client" here, but a Peer is essentially a client. What makes a Peer diffeerent from the usual database client, however, is that querying happens primarily in the Peer. By the way, when I say "querying" I mean "read querying." Instead of sending a query "over there" to the database server, which runs the query and gives the client results, the Peer Library is responsible for pulling the "value of the database" into the Peer so that querying happens within your actual application. If you were to create a script out of this action-packed drama, it would look like: Peer: Peer Library! Find me all redheads who know how to play the ukelele! Peer Library: Yes yes! Right away sir! Database - give me your data! (Peer Library retrieves the database and performs query on it) Peer Library: Here are all ukelele-playing redheads! Peer: Hooraaaaaaaay! The most novel thing here is "retrieves the database". In Datomic, you have the concept of the "value of the database" - the database as a whole, as a data structure. The Peer Library is responsible for pulling as much of that data structure into memory as necessary to satisfy your queries. In this way, your queries run largely in your application rather than in a central database server, allowing for easy read scalability. It gives more power to your application rather than keeping all the power in a central server, where you have to worry about bottlenecks. Finally, Datomic does not implement its own storage solution but instead relies on storage as a service, allowing you to choose which storage backend you use. Right now, the following backends are supported: The filesystem DynamoDB Riak Couchbase Infinispan SQL database Third Righteous Pillar of Databasing: Programmability In Datomic, everything is data! Your schema is data! Queries are data! Transactions are data! This is great because it's easier to manipulate data structures than it is to perform crazy string concatenation like you do with SQL. Check out these example queries. Resources The Design of Datomic Rich Hickey on Datomic The Value of Values The Datomic Information Model Datomic docs The End That's it for now! If you have any suggestions or corrections please let me know.


over 8 years ago | Mark Daggett: Mark Daggett's Blog

Using Design Time Classes To Polish Your Product This post is dedicated to CYA with CSS; for the uninitiated CYA means "cover your ass", and I assume that anyone reading my blog already knows what CSS is. Just as you can craft the JavaScript on your website to act defensively against unforeseen errors, so too can you use CSS at the design stage to ensure you don’t end up with egg on your face post-launch. A while back, I was viewing the Github’s source code (man I sound like such a nerd), and I noticed these classes added to their body tags: "logged_in page-dashboard macintosh env-production". Several of these classes are obviously progressive enhancement style additions meant to change the layout / features of the page based on the visitor’s browser. In my own sites I often include the controller and action params into the body tag so that I can scope my JavaScript and CSS executions. Doing this provides a convenient way to namespace your CSS and JS, without having to worry about polluting the global namespace. However one of Github’s additions stuck out at me "env-production". I have to imagine that Kyle Neath was the one who added this to the page, and that he did it because he wants the site to render differently based on the runtime environment of the sever. I thought about the possibilities of this technique and figured out that there are probably a whole host of ways to use these design time classes. The use of which would help ensure a polished final project. Here are just a couple of examples of how you might use them: 1. If you are using a specific grid layout you could set an image to appear as a background-image of the body. Doing this would ensure your page conforms the the correct visual spacing and vertical rhythm. I know that "Blueprint CSS" used to have something like this back in the day. It might look something like this: 1 2 3 body.env-development { background: url('/assets/grid.png') no-repeat scroll top left !important; } 2. Often as developers we’ll mock in a bit of functionality that the design calls for with the intention of making it work later. Unfortunately, this can mean that dead links get deployed. Here is how you could use a CSS selector and a design time class to color code all the links without a href attribute. This example adds a gaudy eye-searing color to all the dead links, to ensure you fix it before you deploy into production. 1 2 3 4 5 6 body.env-development { a:not([href]) { color:#00FF00 !important; background-color:#ff00ff !important; } } The best thing about design time classes is that because they are properly scoped to the body they just disappear in the production environment. This means you don’t have to worry about them being seen by the end user. If you are using Rails it’s a pretty straight forward process to get these classes into your application. 1 %body{ :class => "#{app_classes}" } In your application helper you’d add something like this: 1 2 3 def app_classes "#{Rails.env} #{params[:controller].gsub('/',' ')} #{params[:action]}" end Kyle suggested over twitter that another good use is to change the favicon based on the server environment. More To Come Do you use Design time classes? If so what are they, share them in the comments or as a gist and maybe we can develop a nice resource of helpful snippets for others.


over 8 years ago | Eduard Moldovan: eduardmoldovan.com - tech

We had our biggest [almost]JavaScript conference here in Budapest. Let me share a few thoughts on it. Sadly, I could not be there because when I found out that Stoyan Stefanov is not coming anymore, I got a bit stalled and managed to miss all the tickets.

Spring: implements interface not working in @Controller

over 8 years ago | Subodh Gupta: Subodh's Blog

Guys,  I had a @Controller in which I was trying to implement an interface. But i was getting the following error message:PageNotFound WARN  No mapping found for HTTP request with URI [/test/form] in DispatcherServlet with name 'Spring MVC Dispatcher Servlet'where "/test" (at class level) and "/form" (at method level) where my @RequestMapping args. The issue is described at following link:http://forum.springsource.org/showthread.php?92303-Spring-Servlet-MVC-RequestMapping-breaks-with-AOP-AdviceNow you may not find anything wrong with your spring.xml but should check all the xml used by used in the project in out case metrics was causing the problem.  The aop config was overridden by metrics here:https://github.com/ryantenney/metrics-spring#xml-config By default JDK proxy are created using interface and if controller implements an interface the RequestMapping annotation gets ignored as the targetClass is not being using.http://static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/aop.html#aop-proxying So, fix required i my case is:proxy-target-class="true" ... />Hope this helps.

The Great Indian Air War-Fare

over 8 years ago | Niraj Bhandari: Technology Product Management

Yeah you read it right  – It is warfare over ” Air Fare”. It all started one fine day when …Continue reading →

What Permissions Not to Ask For

over 8 years ago | Eduard Moldovan: eduardmoldovan.com - tech

Today I tried ti link my linkedin.com profile with my twitter account, so that my tweets get posted there, too. But I didn't do it.

Automated d3 map of any country

over 8 years ago | Oscar Villirreal: Digital Caveman

So I previously wrote a post on how to create a map of anywhere of the world using d3. I’ve decided to take that a step further and created a python script that automates the entire thing. Follow the instructions in this github repo and you should be good. Note: You will need to install […]

CSS Challenge

over 8 years ago | Oscar Villirreal: Digital Caveman

A good friend of mine, Laurent Brucher was tasked to interview a candidate with regards to his front end skills. We talked for a while, shared ideas and in the end he came up with a clever challenge for the candidate to code out. Inspired in his challenge I’ve crated this one below Create a […]

JavaScript Jigs

over 8 years ago | Mark Daggett: Mark Daggett's Blog

In the excellent book "The Pragmatic Programmer: From Journeyman to Master" Hunt and Thomas use the metaphor of a wood worker’s jig to describe how a smart programmer reduces the repetitive nature of coding by creating reusable templates or code generators: "When woodworkers are faced with the task of producing the same thing over and over, they cheat. They build themselves a jig or a template. If they get the jig right once, they can reproduce a piece of work time after time. The jig takes away complexity and reduces the chances of making mistakes, leaving the craftsman free to concentrate on quality." To be a jig the solution is highly specific and good for one task, for example making a complex cut. At first you might want to conflate jigs and design patterns together, because they are both reusable solutions to a problem. Jigs are precise where design patterns are generalized. While Hunt and Thomas said jigs are generators, I will use them in the context of helpers, friendly little functions or classes that do one thing well. Many of the most popular JavaScript libraries started as a collection of jigs. Prototype and JQuery for example, were initially just a collection of reusable snippets that acted like speed-boosts, and shortcuts for discrete problems. What follows are a collection of jigs that are useful in modern JavaScript applications. Self Executing Functions The immediately invoked function expression (IIFE) is one jig you will see various libraries and frameworks use repeatedly. In its most basic form it can be written in a couple of ways 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 ;(function(){ ... })(); ;!function(){ ... }(); ;-function(){ ... }(); ;+function(){ ... }(); ;~function(){ ... }(); // Not Recommended ;void function(){ ... }(); // Not Recommended ;delete function(){ ... }(); The beauty of the IIFE is that it uses a unary expression to coerce a function declaration, which would normally need to be explicitly called into a function expression that can self-execute. Behind the scenes JavaScript is running a unary operation on the function declaration, the result of that operation is the function expression, which is immediately invoked with the trailing parentheses "()". Besides being elegant code the IIFE also affords the following: It provides a closure which prevents naming conflicts It provides elegant block scoping It prevents pollution of the global namespace. It promotes the developer to think in terms of modular code. One other point worth mentioning is the use of the semicolon prepending the statement. Adding this provides a bit of defensive programming against other malformed modules that might have a trailing semicolon. If this were just a function declaration it would be absorbed into the preceding module. This can often occur when multiple scripts are concatenated together as part of a deploy process. It is highly recommended that you follow this convention to protect yourself against mystery bugs in production. Modules Modules are very common is many programming languages, though JavaScript doesn’t have a native representation for them. As such other developers have developed a spec for encapsulating your code inside a reusable module. The following code is based off an example in the "Principles of Writing Consistent, Idiomatic JavaScript" [1]. There are a couple of elements that should be called out in this jig: We see two different examples of the self executing function jig being used. This is to ensure proper closure around the module itself and the initializer function that adds it to the global namespace. Invoking this function returns an object with a bound reference to the private variable "data". This allows the developer to enforce the use of getters and setters for access to the data variable. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 ;!function(global) { var Module = (function() { // Mostly Private Variable var data = 'secret'; return { bool: true, string: 'a string', array: [1, 2, 3, 4], object: { lang: "en-Us" }, getData: function() { return data; }, setData: function(value) { return (data = value); } }; })(); // expose our module to the global object global.Module = Module; }(this); safeEval The eval function and its siblings setTimeout, setInterval and Function all have access to the JavaScript compiler, which means it is a bit like running with scissors. Since eval typically does more harm than good people try to work around it as much as possible. This jig does just that giving you eval like features without calling the function. 1 2 3 4 5 6 7 8 9 10 // A string representation of an a object similar to what you might get with JSON. var dataString = '{"foo":"bar"}'; ;!function(global, data){ // the variable name provided is replaced with the evaluated code. global[data] = new Function("return" + global[data])() }(this, "dataString"); // dataString is now Object {foo: "bar"} PubSub PubSub is short for a publish-subscribe message system, where objects ask to receive messages that are broadcast by publishers. The main advantage of PubSub is that the subscribers are loosely coupled allowing just about any object to publish and subscribe to messages. PubSub systems also have been proven to scale much nicer that tightly coupled client / server paradigms. This implementation of PubSub was written by Ben Alman and can be download from his Github account [2]. Let’s take a look at this jig in detail. Again, the first thing you should notice is that this jig uses the IIFE jig too (see a pattern yet?). This jig does depend on jQuery for access to the "on","off", and "trigger" functions. This jig stores an internal list of subscribers as keys of the internal object "o". When a message is broadcast all the subscribers have the arguments supplied by the publisher transferred to them. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 ;(function($) { var o = $({}); $.subscribe = function() { o.on.apply(o, arguments); }; $.unsubscribe = function() { o.off.apply(o, arguments); }; $.publish = function() { o.trigger.apply(o, arguments); }; }(jQuery)); // Usage Examples // Creates a "named" logging function. function createLogger(name) { return function(event, a, b) { // Skip the first argument (event object) but log the name and other args. console.log(name, a, b); }; } // Subscribe to the "foo" topic (bind to the "foo" event, no namespace). $.subscribe('foo', createLogger('foo')); // Subscribe to the "foo.bar" topic (bind to the "foo" event, "bar" namespace). $.subscribe('foo.bar', createLogger('foo.bar')); /* * logs: * foo 1 2 * foo.bar 1 2 * foo.baz 1 2 */ $.publish('foo', [1, 2]); /* * logs: * foo.bar 3 4 */ $.publish('foo.bar', [3, 4]); Your Jigs Go Here Please send me your favorite jigs. I would love to expand this post with more great Jigs. Footnotes [1]https://github.com/rwldrn/idiomatic.js/ [2]https://github.com/cowboy/jquery-tiny-pubsub

Functions Explained

over 8 years ago | Mark Daggett: Mark Daggett's Blog

A Deep Dive into JavaScript Functions Based on my readership I have to assume most of you are familiar with JavaScript already. Therefore, it may seem odd to include a post on functions. After all, they are one of the most rudimentary components of JavaScript. My assertion is this, just as a person can speak a language without the ability to read or write it, so too can developers use functions in JavaScript and yet be blissfully unaware of their complexities. Typically developers only become aware of the specifics of functions when something they wrote explodes in their face. My goal in this section is to expose the intricacies of JavaScript functions to you, which will hopefully save you from having to pull syntactic shrapnel from your codebase. A word of caution before we begin; JavaScript is only as good as its interpreter. While the concepts we’ll consider are well-covered in the language spec, it does not mean that all runtime environments will work the same way. In other words your milage may vary. This section will discuss common misconceptions of JavaScript functions, and the silent bugs they introduce. However, debugging functions in detail is not covered. Fortunately, debugging has been documented by others in the JavaScript community especially in Juriy Zaytsev’s excellent article "Named Function Expressions Demystified" [1]. Blocks in JavaScript Before we can understand functions in JavaScript we have to understand blocks. JavaScript blocks are nothing more than statements grouped together. Blocks start with a left curly bracket "{" and end with a right one "}". Simply put, blocks allow statements inside the brackets to be executed together. Blocks form the most basic control structure in JavaScript. The following are a few examples of how blocks in JavaScript: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 // Block as an anonymous self-executing function ;!function () { var triumph = false, cake = false, satisfaction = 0, isLie, note; // Block used as part of function expression var isLie = function (val) { return val === false; } // Block used as part of a conditional statement if (isLie(cake)) { triumph = true; makeNote('huge success'); satisfaction += 10; } // Block used as part of a function declaration function makeNote(message) { note = message; } }(); As we saw above, functions are essentially named blocks, which the developer can invoke on demand. This is easy to demonstrate: 1 2 3 4 5 6 7 8 9 10 11 12 // The inline conditional block statement is executed only once per cycle. if (isLie(cake)) { ... } function makeNote(message) { ... } // The function declaration is executed as many times as it is called. makeNote("Moderate Success"); makeNote("Huge Success"); Function Arguments Functions like control flow statements (if, for, while etc.) can be initialized by passing arguments into the function body. In JavaScript variables are either a complex type (e.g. Object, Array) or a primitive type (e.g. String, Integer). When a complex object is supplied as an argument it is passed by reference to the function body. Instead of sending a copy of the variable, JavaScript sends a pointer to its location in memory. Conversely, when passing a primitive type to a function JavaScript passes by value. This difference can lead to subtle bugs because conceptually we often treat functions as a black box, and assume they can only effect the enclosing scope by returning a variable. With pass by reference, the argument object is modified even though it may not returned by the function. Pass by reference and pass by value are demonstrated below: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 var object = { 'foo': 'bar' }, num = 1; // Passed by reference ;!function(obj) { obj.foo = 'baz'; }(object); // => Object {foo: "baz"} console.log(object); // Passed by value; ;!function(num) { num = 2; }(num); // => 1 console.log(num); Function Types Now that we have a better understanding of blocks, and arguments lets dive deeper into Function Declaration and Function Expression, the two types of functions used in JavaScript. To the casual reader the two appear very similar: 1 2 3 4 5 6 7 8 9 // Function Declaration function isLie(cake){ return cake === true; } // Function Expression var isLie = function(cake){ return cake === true; } The only real difference between the two, is when they are evaluated. A function declaration can be accessed by the interpreter as it is being parsed. The function expression on the other hand is part of an assignment expression, which prevents JavaScript from evaluating it until the program has completed the assignment. This difference may seem minor, but implications are huge; consider the following example: 1 2 3 4 5 6 7 8 9 10 11 12 13 // => Hi, I'm a function declaration! declaration(); function declaration() { console.log("Hi, I'm a function declaration!"); } // => Uncaught TypeError: undefined is not a function expression(); var expression = function () { console.log("Hi, I'm a function expression!"); } As you can see in the previous example the expression function threw an exception when it was invoked, but the declaration function executed just fine. This exception gets to the heart of the difference between declaration and expression functions. JavaScript knows about declaration function and can parse it before the program executes. Therefore, it doesn’t matter if the program invokes the function before it is defined. This is because behind the scenes JavaScript has hoisted the function to the top of the current scope. The function expression is not evaluated until it is assigned to a variable; therefore it is still undefined when invoked. This is why good code style is to define all variables at the top of the current scope. Had we done this then our script would visually match what JavaScript is doing during parsetime. The concept to take away is that during parsetime JavaScript moves all function declarations to the top of the current scope. This is why it doesn’t matter where declarative functions appear in the script body. To further explore the distinctions between declarations and expressions, consider the following: 1 2 3 4 5 6 7 8 9 10 11 12 13 function sayHi() { console.log("hi"); } var hi = function sayHi() { console.log("hello"); } // => "hello" hi(); // => 'hi' sayHi(); Casually reading this code, one might assume that the declaration function would get clobbered because it function expression has an identical name. However, since the second function is part of an assignment expression it is given its own scope, and JavaScript treats them as seperate entities. To make things even more confusing look at this example: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 var sayHo // => function console.log(typeof (sayHey)) // => undefined console.log(typeof (sayHo)) if (true) { function sayHey() { console.log("hey"); } sayHo = function sayHo() { console.log("ho"); } } else { function sayHey() { console.log("no"); } sayHo = function sayHo() { console.log("no"); } } // => no sayHey(); // => ho sayHo(); In the previous example we saw that functions of the same name were considered different if one was an expression and the other was a declaration. In this example we are attempting to conditionally define the function based on how the program executes. Reading the script’s control flow you’d expect sayHey to return "hey" since the conditional statement evaluates true. Instead it returns "no", meaning the second version of the sayHey function clobbered the first. Even more confusing is that the sayHo function behaves the opposite way! Again, the difference comes down to parsetime versus runtime. We already learned that when JavaScript parses the script it collects all of the function declarations and hoists them to the top of the current scope. When this happens it clobbers the first version of sayHey with the second because they exist in the same scope. This explains why it returns "no." We also know that function expressions are ignored by the parser until the assignment process completes. Assignment happens during runtime, which is also when the conditional statement is evaluated. That explains why the sayHo function was able to be conditionally defined. The key to remember here is that function declarations can not be conditionally defined. If you need conditional definition use a function expression. Furthermore, function declarations should NEVER be made inside a control flow statement, due to the different ways interpreters handle it. Function Scopes Unlike many other languages which are scoped to the block, JavaScript is scoped to the function. In Ruby (version 1.9.+) you can write this: 1 2 3 4 5 6 7 8 9 x = 20 10.times do |x| # => 0..9 puts x end # => 20 puts x What this demonstrates is that each block gets its own scope. Conversely, if we wrote similar code in JavaScript: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 var x = 20; // Functions have their own scope ;!function() { var x = "foo"; // => "foo" console.log(x); }(); // => 20 console.log(x); for (x = 0; x < 10; x++) { // => 0..9 console.log(x); } // => 10 console.log(x); In JavaScript x is available inside the for loop, because as a control statement it belongs to the enclosing scope. This is not intuitive to many developers used to block level scope. JavaScript handles the need of block level scope at least partially through the use of closures which we’ll discuss later. Debugging Functions Before we wrap this topic up, lets briefly touch on debugging functions. In JavaScript naming a function expression is completely optional; so why do it? The answer is to aid the debugging process. Named function expressions have access to their name within the newly defined scope, but not in the enclosing scope. Without a name their anonymous nature can make them feel a bit like ghosts in the machine when it comes to debugging. 1 2 3 4 5 6 7 8 9 var namedFunction = function named() { // => function console.log(typeof(named)); } namedFunction(); // => undefined console.log(typeof(named)); Nameless function expressions will be displayed in the stack trace as "(anonymous function)" or something similar. Naming your function expression gives you clarity when trying to unwind an exception whose call stack may feel miles long. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 /* * It is much harder to debug anonymous function expressions * Uncaught boom * - (anonymous function) * - window.onload */ ;!function(){ throw("boom"); }(); /* * Naming your function expressions give you a place to start looking when debuggin. * Uncaught boom * - goBoom * - window.onload */ ;!function goBoom() { throw("boom") }(); [1]http://kangax.github.com/nfe/

Pragmatic JavaScript Style

over 8 years ago | Mark Daggett: Mark Daggett's Blog

My goal is to make you a better programmer, and I am going to do this by teaching you about style. I am not talking about fashion, because I think most programmers would flunk that test; unless, comic-con couture is a thing. Instead we’ll talk about the importance of style, how it forms, how it spreads and when to kill it. Specifically, we’ll look at style as it applies to programming. Ultimately, once we have a context for evaluating style I will introduce you to elements of programmatic style which have served me well over the years as a professional software developer. What Is Style? Style is often used as a measurement of quality. When someone is described as having style or being stylish, it is almost universally meant as a complement. If someones’ style ever comes into question it is usually in comparison to someone else’s style. "My style’s the best and so I challenge you" screams 70’s era martial arts star. Stylishness is a fresh approach, a unique perspective, an unexpected insight into an activity. The application of a style can become so prominent that it expands the activity itself; that house is built in a Frank Lloyd Wright style. What starts as a personal style in painting can become an art movement almost overnight. Style spreads like a virus, it is the original meme, a mind virus that changes the way you see the world forever. Style is often the conduit where new ideas pulsate. How does style effect programmers? Well the good news about style for those algorithmically inclined is that, no matter how personal a style may seem, for it to exist it all, it must at some level be repeatable. Style must be codified into a series of steps, rules or combinations that can be followed, and then recognized by others. Therefore if style is a measurement of quality, and at the same time repeatable then it can be taught. Just ask Strunk and White. William Strunk Jr. wrote "The Elements of Style" while he was a professor at Cornell. He began with 7 rules for the usage of language, and 11 principles of composition. His student E.B. White revised the book forty years later, by adding an additional 4 rules. The goal of the book was to give aspiring writers and grammarians a context from which to evaluate their own work. According to White, Strunk was compelled to write the "little book" out of sympathy for those afflicted with reading the writer’s ill-composed dreck: "Will felt that the reader was in serious trouble most of the time, floundering in a swamp and that it was the duty of anyone attempting to write English to drain the swap quickly and get the reader up on dry ground, or at least throw a rope." Over the years the book has remained wildly popular by those learning to write efficiently, and is affectionately referred to as "Strunk and White." That is not to say it has been universally loved or followed. Dorothy Parker is quoted in the New York Times as saying "If you have any young friends who aspire to become writers, the second-greatest favor you can do them is to present them with copies of ‘The Elements of Style.’ The first-greatest, of course, is to shoot them now, while they’re happy." Many found the rules too restrictive, and opinionated. White said Strunk believed "…it was worse to be irresolute than to be wrong." Strunk’s assertions is that it takes passion to be stylish. You need to be able to draw boundaries, to allow this idea to flourish while forcing that one to die. Style is a sine wave attracting some and repelling others. What is programmatic style? As mentioned previously, Stunk and White wrote their book not only to empower and train writers, but to save readers from slogging through what was in their minds a textual tar pit. So too, good programmatic style services two audiences, the developer and the processor. That is to say that the code should be well-written, both syntactically, and technically. Below are qualities I consider essential in application of programmatic style: Consistency - By repeatedly applying rules to the codebase we ensure consistency. Consistency, mitigates noise in the codebase, and brings the intent of the code into clearer focus. Put another way, if a developer is trying to piece together how to read your code, you have prevented them from understanding what it does. Consistency is concerned with how the code looks, e.g. naming conventions, use of whitespace, and method signatures; and how the code is written for example ensuring that all functions don’t return a string in one context and an integer in another. Expressiveness - Code is by nature a symbolic language, where variability and abstractness is implicit. Therefore the developer must find a way to make the code meaningful to the reader. This can be archived though naming variables and methods precisely. When reviewing a class, method or variable the reader should understand the roles and responsibilities of the code by reading the code itself. If a method can only be understood by reading the comments above left by the writer it should be a clue that the code is not expressive. Succinctness - Strive to do just enough. Good programming like good writing is about clarity of purpose, and not merely compactness. It should be about reducing the complexity of a method, not it’s usefulness. Restraint - Style should never overpower the subject itself. At that point style becomes the subject it becomes a facile artifice, a dish ruined by too much spice. I am reminded of a minimalist chess set I saw in college every piece was either a white or black cube, and all pieces were the same size. It was aesthetically beautiful and simultaneously unplayable. JavaScript Style Guide This style guide was compiled by compiling, reviewing and considering choices I have made in my own work over the years, and coding practices of individuals, and development teams I admire in the JavaScript community. As such this style guide should be seen as an amalgamation of inputs and influences from the larger JavaScript community rather than the creative output of a singular individual. You can find a list of resources used in this guide in the additional resources section. This guide is broken into two sections: "Rules for Visual Clarity" and "Rules for Computational Effectiveness". Caveats Style guides are just that guides, they are meant to point you in the right direction, but they are at best mutable truth. Moreover, coding theory changes constantly and it is important not to lock yourself into a dogmatic approach to the application of these styles. As my professor Clyde Fowler told me in my studio drawing class, "you must think with your hands", and what he meant by that was you must think through doing, while maintaining the ability to get critical distance from your work. Rules for Clarity - How others see code Rules Of Thumb Write Clearly And Expressively - When naming variables, functions, or organizing code remember you are writing for humans to read it not compilers. Following Existing Conventions - If you share your code anywhere, work on a team, or are hired to write code, then you are not writing for yourself Write in Only One Language - Where possible don’t use JavaScript as a surrogate for other languages. This means resisting the urge to write inline HTML, or CSS where possible. Enforce A Uniform Column Width - Strive for consistent line lengths in source code. Long lines tire the eyes, and cause needless horizontal scrolling. An industry standard is 80 characters per line. Document Formatting Naming Conventions JavaScript is a terse language of brackets, and symbols and one of the only way to make your code expressive to humans is through the names you choose for variables, functions and classes among others. Remember when choosing a name it should describe the role and responsibilities of that object. Vague or obtuse names like doStuff is like telling the reader you figure it out, which often times they won’t. Choose variables and functions with meaningful, expressive and descriptive names. Write for the reader not the compiler. 1 2 3 4 5 6 7 8 9 10 11 // Bad var a = 1, aa = function(aaa) { return '' + aaa; }; // Good var count = 1, toString = function(num) { return '' + num; }; Constants should always belong to a namespace, and be written in uppercase with spaces replaced with underscores 1 2 3 4 5 // Bad MY_CONSTANT = 43; // Good com.humansized.MY_CONSTANT = 43; Variables should be CamelCase 1 myVariableName Classes should be PascalCase 1 MyAwesomeClass Functions should be CamelCase 1 isLie(cake) Namespaces should be CamelCase and use periods as a delimiter 1 com.site.namespace Hungarian notation is not required but you can use it to convey they are objects constructed through or dependent on a library or framework 1 2 3 4 5 // JQuery infused variable var $listItem = $("li:first"); // Angular.js uses the dollar sign to refer to angular-dependent variables $scope, $watch, $filter Constants And Variables Variables and constants definitions always go at the top of the scope 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 // Bad function iterate() { var limit = 10; for (var x = 0; x < limit; x++) { console.log(x); } } // Good function iterate() { var limit = 10, x = 0; for (x = 0; x < limit; x++) { console.log(x); } } Avoid polluting the global namespace by always declaring variables using var 1 2 3 4 5 // Bad foo = 'bar'; // Good var foo = 'bar'; Declare multiple variables using a single var declaration, but separate each variable with a newline 1 2 3 4 5 6 7 // Bad var foo = "foo"; var note = makeNote('Huge Success'); // Good var foo = "foo", note = makeNote('Huge Success'); Declare unassigned variables last. This allows the reader to know they are needed but have delayed initialization. Do not assign variables inside a conditional statement, it often masks errors. 1 2 // Bad because it is easily misread as an equality test. if (foo = bar) {...} Do not clobber arguments with variables names. 1 2 3 4 5 6 7 8 9 10 11 // Bad function addByOne(num) { var num = num + 1; return num; } // Good function addByOne(num) { var newNum = num + 1; return newNum; } Page Layout Blank lines Should always proceed the start of a comment Should be used to separate logically related code 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 // Bad var = wheels; wheels.clean() car.apply(wheels); truck.drive(); // Good var = wheels; wheels.clean() car.apply(wheels); truck.drive(); Commas Remove trailing comments in object declarations. It will break some runtime environments. 1 2 3 4 5 6 7 8 9 10 11 // Bad var foo = { bar: 'baz', foo: 'bar', } // Good var foo = { bar: 'baz', foo: 'bar' } Don’t use comma first formatting, if you don’t know what that means keep it that way! Semicolons Even though JavaScript determines semicolons to be optional many compilers expect them, therefore it is better to use them. Useful for clearly delineating the end of a logical statement Do not add meaningless semicolons Whitespace Should be removed from the end of a line Should be removed from a blank line Should not mix spaces and tabs Should appear after each comma in a function declaration 1 2 3 4 5 // Bad function findUser(foo,bar,baz) // Good function findUser(foo, bar, baz) Should not appear inside empty functions or literals 1 2 3 doThis(); var foo = {}; var arr = []; Brackets And Braces Use only where the compiler calls for it or where it enhances readability Brackets should appear on the line that requires them 1 2 3 4 5 6 7 8 9 10 // Bad if (hidden) { ... } // Good if (hidden) { } Add whitespace in front and between brackets to aid readability. 1 2 3 4 5 6 7 // Bad if (condition) goTo(10); // Good if (condition) { goTo(10); } There are a couple of exception to the previous rule 1 2 3 4 5 6 7 8 // No Whitespace needed when there is a single argument if (foo) ... // No whitespace when a parenthesis is used as a scope container ;(function () {...}) // No white space when brackets are used as a function argument function sortThis([2,3,4,1]) Strings String should be constructed using single quotes 1 2 3 4 5 // Bad var foo = "Bar"; // Good var foo = 'Bar'; Strings longer than the pre-determined character line limit should be reconsidered, if required they should be concatenated Functions Method signatures must be consistent. If a function returns a variable in one context it should return a variable in all contexts 1 2 3 4 5 6 7 8 9 10 11 12 13 14 // Bad var findFoo(isFoo) { if ( isFoo === true ) { return true; } } // Good var findFoo(isFoo) { if ( isFoo === true ) { return true; } return false; } While not a requirement, returning early from a function can make the intent more clear 1 2 3 4 5 6 7 // Good var findFoo(isFoo) { if ( isFoo === true ) { return true; } return false; } Comments Should never trail a statement Comments should be used sparingly, overuse of comments should suggest to the developer that their code is not expressive enough. Comments should aways be written as a complete thought. Multiline comments should always use the multiline syntax 1 2 3 4 5 6 7 // Some really // bad multiline comment /** * A well-formed multiline comment * so there... */ Rules for Computational Effectiveness Rules Of Thumb Assume File Will Be Concatenated - Modern applications often munge source JavaScript into a streamline file for production. You should defensively program your scripts to protect from switches in operation context and scope corruption. Keep your code browser agnostic - Keep your business logic free of browser specific code by abstracting them into interfaces. This will keep your code on a clean upgrade path as browser fall in and out of fashion. Never Use eval() - Ever Never Use with() - Ever Keep Prototype Pristine - Never modify the prototype of a builtins like Array.prototype because it can silently break other’s code which expect standard behavior. Equality Comparisons And Conditional Evaluation Use "===" instead of "==" use "!==" instead of "!=" this is because JavaScript is very loose when testing equality. When just testing for truthiness you can coerce the values 1 2 if (foo) {...} if (!foo) {...} When testing for emptiness 1 if (!arr.length) { ... } You must be explicit when testing for truth 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 // Bad because all of these will be coerced into true var zero = 0, empty = "", knull = null, notANumber = NaN, notDefined if (!zero || !empty || !knull || !notANumber || !notDefined ) ... // Bad var truth = "foo", alsoTrue = 1 if (truth && alsoTrue) ... // Good if (foo === true) ... Constants and Variables When deleting a variable set it to null instead calling #delete or setting it to undefined 1 2 3 4 5 6 7 8 9 10 11 // Bad because undefined means the variable is useful but as yet has no value this.unwanted = undefined; /** * Bad because calling delete is much slower than reassigning a value. * The only reason to use delete is if you want to remove the attribute from an objects list of keys. */ delete this.unwanted; // Good this.unwanted = null; Functions Function Expressions 1 2 3 4 5 6 7 8 9 10 11 12 13 14 // Anonymous Function var anon = function () { return true; } // Named Function var named = function named() { return true; }; // Immediately-invoked function, hides its contents from the executing scope. ;(function main() { return true; })(); Anonymous functions are defined at parse-time, and therefore do not have their names hoisted to the top of the scope. 1 2 3 4 5 6 7 8 9 10 11 12 // Bad - Runtime Error iGoBoom(); var iGoBoom = function () { alert('boom'); } // Good iGoBoom(); function iGoBoom() { alert('boom'); } Do not use function declaration within block statements it is not part of ECMAScript; instead use a function expression. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 // Bad if (ball.is(round)) { function bounce(){ // Statements Continue } return bounce() } // Good if (ball.is(round)) { var bounce = function () { // Statements Continue } } Do not hide the native arguments object by using the same name in a function 1 2 3 4 5 6 7 8 9 // Bad var foo = function(arguments) { alert(arguments.join(' ')); } // Good var foo = function(args) { alert(args.join(' ')); } Strings When concatenating a string use Array#join for performance reasons. 1 2 3 4 5 6 7 8 9 10 11 // Bad var lorem = 'Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.\ Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in\ reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in\ culpa qui officia deserunt mollit anim id est laborum.'; // Good var lorem = ['Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.', 'Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in', 'reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in', 'culpa qui officia deserunt mollit anim id est laborum.'].join(''); Objects Should use object literal vs new Object 1 2 3 4 5 6 7 8 9 10 // Bad var person = new Object(); person.firstName = "John"; person.lastName = "Doe"; // Good var person = { firstName: "John", lastName: "Doe" } Don’t overwrite reserved words as keys 1 2 3 4 5 // Bad var person = { class : "Person" }; // Good var person = { klass : "Person" }; Arrays Should use literal syntax for creation 1 2 3 4 5 // Bad var arr = new Array(); // Good var arr = []; Responsibility Delegation Only write code that is the responsibility of the program. Keep your code free of view layer and template code. Use a template library like mustache.js instead 1 2 3 4 5 6 7 8 9 10 11 12 var view = { title: "Joe", calc: function () { return 2 + 4; } }, output; // Bad output = '<div><h5>' + title + '</h5><p>' + calc() + '</div>'; // Good var output = Mustache.compilePartial('my-template', view); Keep JavaScript out of the HTML 1 2 3 4 5 6 // Bad <button onclick="doSomething()" id="something-btn">Click Here</button> // Good var element = document.getElementById("something-btn"); element.addEventListener("click", doSomething, false); Operating Context And Scope Where possible wrap your code inside self executing functions. This will insulate your code from pollution by others, and make it easier to abstract 1 2 3 4 5 // Good ;(function( window, document, undefined) { // My Awesome Library })(this, document); Design for duration-agnostic execution of code. This will prevent your code from building up a backlog of requests that may no longer be relevant 1 2 3 4 5 6 7 8 9 10 // Bad because this might take longer than 100 milliseconds to complete. setInterval(function () { findFoo(); }, 100); // Good this will only be called again once findFoo has completed. ;(function main() { findFoo(); setTimeout(main, 100); })(); Only use this in object constructors, methods and creating closures To prevent breaking community code declaring an operating context e.g. "use strict" should be wrapped inside a self-executing function for modules or inside a function itself when needed 1 2 3 4 5 6 7 8 9 10 11 12 13 14 // Bad var bar = findLooseyGoosey(); "use strict"; var foo = findStrictly(); // Good var bar = findLooseyGoosey(); ;(function () { "use strict"; var foo = findStrictly(); })(); Coercion Conversion over Coercion 1 2 3 4 5 6 7 var num = '1'; // Bad implicit coercion num = +num; // Good expressive conversion num = Number(num);

Reaction to Opera's Decision

over 8 years ago | Eduard Moldovan: eduardmoldovan.com - tech

Recently Opera announced its decision to gradually move to Webkit. This has brought up many reactions in our huge we community. I have my own and here it is.

An Interview With Laurent Sansonetti

over 8 years ago | Pat Shaughnessy: Pat Shaughnessy

Laurent Sansonetti created RubyMotion It was only last April when Laurent Sansonetti captured the imagination of the

The "Magic" behind AngularJS Dependency Injection

over 8 years ago | Alex Rothenberg: Alex Rothenberg

If you’ve built anything with AngularJS you know there’s a lot of “magic” that you can usually ignore because it just works. One of the most magical parts for me is dependency injection. Just by adding a parameter to your controller function you suddenly get access to a powerful Angular service. It’s really pretty amazing but you sorta just have to trust it … until something goes wrong. It turns out one easy way to break an AngularJS app is to minify your javascript. This happened to me when I deployed my app to production. The Angular app was being served from a Rails application and Rails automatically minifies javascript in prodution. It turns out there’s a simple and a well documented fix in their tutorial (search for “A Note on Minification”) that boils down to “use an array of parameter names” but it wasn’t clear to me why it worked. In the rest of this article we’re going to Build a simple AngularJS application See how magical dependency injection is Investigate how dependency injection is implemented in AngularJS Break our app by minifying the javascript Understand how the fix works An AngularJS application using the GitHub API We’re going to build a simple AngularJS app that uses the GitHub API to find the most recent commits on the angular.js project. http://alexrothenberg.github.com/examples/angularjs_dependency_injection/index.html Here’s the source for that page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25<html ng-app> <head> <script src="http://ajax.googleapis.com/ajax/libs/angularjs/1.0.4/angular.js"></script> <script> var MyController = function($scope, $http) { $http.get('https://api.github.com/repos/angular/angular.js/commits') .success(function(commits) { $scope.commits = commits }) } </script> </head> <body ng-controller="MyController"> <h1>Recent commits to AngularJS</h1> <ul> <li ng-repeat="commit in commits"> {{ commit.commit.committer.date | date }} <a ng-href="https://github.com/angular/angular.js/commit/{{commit.sha}}">{{ commit.sha }}</a> {{ commit.commit.message }} </li> </ul> </body> </html> Let’s walk through what’s going on here: Line 1 - The ng-app attribute tells angular to treat this page as an angular app. Line 6-11 - Some JavaScript that defines the controller and tell angular to “inject” the $scope and $http services. Line 15 - The ng-controller="MyController" attribute tells angular the body tag will be scoped by the MyController controller. Line 18-22 - This section will be expanded to many li elements in the DOM, each containing information about one commit. This is pretty cool. Of course not everyone is a fan, in Dependency injection is not a virtue DHH argues that it is a legacy of the Java language that is unnecessary in Ruby (and I suspect he would argue JavaScript). AngularJS is figuring out what the hash part of the url is and automatically inserting it in the page. Dependency Injection is magical So where does dependency injection come in? Here’s where it gets weird… let’s try reordering the arguments in the controller function. var MyController = function($http, $scope) { $http.get('https://api.github.com/repos/angular/angular.js/commits') .success(function(commits) { $scope.commits = commits }) } We changed function($scope, $http) to function($http, $scope) and surprisingly it still works! http://alexrothenberg.github.com/examples/angularjs_dependency_injection/args_swapped.html What seems to be going on as it runs is AngularJS Knows what services our controller function needs in each parameter slot (originally $scope first & $http second now $http first & $scope second). Decides what object should “provide” each of the named services (eg. $httpProvider provides $http). Calls our controller with the appropriate providers in each slot (either MyController(scope, $httpProvider) or MyController($httpProvider, scope)). How does Angular do step #1? In JavaScript the order of the parameters is important and the names do not matter to the caller (see this egghead.io video: $scope vs. scope) Let’s take a look at some straight JavaScript and convince ourselves this is true. If we define a function divide that takes two arguments var divide = function(numerator, denominator) { return numerator / denominator; } As expected divide(1, 2) == 0.5. http://alexrothenberg.github.com/examples/angularjs_dependency_injection/divide.html When we change the order of the parameters, we also change the definition of the function. var divide = function(denominator, numerator) { return numerator / denominator; } Now the definition has changed and divide(1, 2) == 2 http://alexrothenberg.github.com/examples/angularjs_dependency_injection/divide_args_swapped.html It seems Angular is going above and beyond what JavaScript the language supports. How Dependency Injection implements Named Parameters in JavaScript We saw that Angular’s dependency injection relies on the name of the parameters not their order which is a language feature called named parameters that does not exist in JavaScript. How do they do it? AngularJS makes clever use of the fact that every object in JavaScript has a toString function to parse and extract the names of the parameters before deciding what arguments to call your controller function with. Let’s play around with toString and get a feel of how it works. On function objects it returns the source code definition of the object, including the function signature with the names of the parameters. When we call it on our divide function we can see this in action, divide.toString() == "function (numerator, denominator) { return numerator / denominator; }" http://alexrothenberg.github.com/examples/angularjs_dependency_injection/divide_toString.html Angular takes this to the next level in a function called annotate in injector.js that takes a function and returns the names of its parameters. 1 2 3 4 5 6 7 8 9 10 11$inject = []; fnText = fn.toString().replace(STRIP_COMMENTS, ''); argDecl = fnText.match(FN_ARGS); forEach(argDecl[1].split(FN_ARG_SPLIT), function(arg){ arg.replace(FN_ARG, function(all, underscore, name){ $inject.push(name); }); }); fn.$inject = $inject; // ... return $inject; line 2 - use the toString() trick to get the function definition. line 3 - do regular expression pattern matching FN_ARGS = /^function\s*[^\(]*\(\s*([^\)]*)\)/m to find the function signature. line 4-8 - loop through all the parameters and save their names in an array. line 11 - return the array or parameter names. We can see this in action with our trusty divide function, angular.injector().annotate(divide) == ["numerator", "denominator"] http://alexrothenberg.github.com/examples/angularjs_dependency_injection/divide_annotate.html Minification breaks our App The technique of using toString has a big problem. We often minify our javascript before sending it to the browser, in my case the Rails asset pipeline was configured to automatically do this in the production environment. // whitespace re-added for readability var MyController = function(e,t) { t.get("https://api.github.com/repos/angular/angular.js/commits") .success(function(t) { e.commits=t }) } When minified the parameter names are mangled to e or t so cannot be mapped to service names by angular. How can it know that t should be implemented by the $httpProvider or that e is the $scope? http://alexrothenberg.github.com/examples/angularjs_dependency_injection/minified_broken.html In fact if you open the minified_broken.html example and look at the console you will see the error Error: Unknown provider: eProvider <- e. Angular’s annotate function is sophisticated enough to handle minification, in fact, I only showed part of it before. When we look at the whole thing, we see it can annotate a function or an array of parameter name strings followed by a function. In the array form, the first string names the first argument, the second string names the second, etc. and the actual names of the parameters are unimportant. function annotate(fn) { var $inject, fnText, argDecl, last; if (typeof fn == 'function') { if (!($inject = fn.$inject)) { // omitting the code we saw before } } else if (isArray(fn)) { last = fn.length - 1; assertArgFn(fn[last], 'fn') $inject = fn.slice(0, last); } else { assertArgFn(fn, 'fn', true); } return $inject; } When we can now redefine our MyController var MyController = ['$scope', '$http', function($scope, $http) { $http.get('https://api.github.com/repos/angular/angular.js/commits') .success(function(commits) { $scope.commits = commits }) }] When it is minified the strings are not touched so annotate will still work. var MyController= ["$scope", "$http", function(e,t) { t.get("https://api.github.com/repos/angular/angular.js/commits") .success(function(t) { e.commits=t }) }] We can see the annotate function parsing this array angular.injector().annotate(MyController) == ["$scope", "$http"] http://alexrothenberg.github.com/examples/angularjs_dependency_injection/minified_annotate.html Of course what really matters is that it works on the page - which it does. http://alexrothenberg.github.com/examples/angularjs_dependency_injection/minified_working.html If you’ve made it to the end of this long post, I hope you’ve enjoyed the journey into how AngularJS knows what services to inject in your controllers. Again all you really need to know is to use an array naming the parameters followed by your function but I hope you enjoyed learning how it actually works. I know I did!

Ruby MRI Source Code Idioms #3: Embedded Objects

over 8 years ago | Pat Shaughnessy: Pat Shaughnessy

Last year I wrote a post about how the core team optimized Ruby to process shorter strings faster than longer strings. I found that Ruby strings containing 23 or fewer characters are much faster. Why am I bringing this up again now? Well, it turns out this isn’t a single optimization that the core team has added for

Books by Narayan Dharap

over 8 years ago | Niranjan Sarade: InLoveWithNature

I recently purchased some Marathi books republished by Samanvay Prakashan, Ajab distributers. They have launched a very nice scheme - buy any book ranging from Rs. 100 to Rs. 600 for only Rs. 50. The purpose is to make some good old books available once again to the readers. Any one can avail this scheme till 28th February 2013.The two books among the others that I purchased are written by Narayan Dharap :- Dasta- ToldhadExcellent reads! I liked the story - 'Yakshaprashna' from 'Toldhad' book the most!  If you have some interest in horror genre, 4th dimension, parallel world, scientific fictions; you will love reading his books. Most of his stories show a battle between good and evil, with victory of good at the end!More information on Narayan Dharap and his books - http://en.wikipedia.org/wiki/Narayan_DharapEnjoy reading !