\n{% endif %}"
},
{
"path": "_includes/prose.html",
"content": "{% if page.index == true %}\n{% else %}\n\n Если вы заметили ошибку, вы всегда можете исправить ее с помощью prose.io.\n\n{% endif %}\n"
},
{
"path": "_includes/social-likes.html",
"content": "
\n
Facebook
\n
Вконтакте
\n
Twitter
\n
"
},
{
"path": "_includes/translation/eng/00_intro.md",
"content": "### Today we're going to discuss an effective set of patterns for large-scale\nJavaScript application architecture. The material is based on my talk of the \nsame name, last presented at LondonJS and inspired by[previous work][1] by\nNicholas Zakas.\n\n\n### Who am I and why am I writing about this topic?\n\nI'm currently a JavaScript and UI developer at AOL helping to plan and write\nthe front-end architecture to our next generation of client-facing applications.\nAs these applications are both complex and often require an architecture that is\nscalable and highly-reusable, it's one of my responsibilities to ensure the \npatterns used to implement such applications are as sustainable as possible.\n\nI also consider myself something of a design pattern enthusiast (although there\nare far more knowledgeable experts on this topic than I). I've previously \nwritten the creative-commons book\n'[Essential JavaScript Design Patterns][2]' and am in the middle of writing the\nmore detailed follow up to this book at the moment.\n\n\n### Can you summarize this article in 140 characters?\n\nIn the event of you being short for time, here's the tweet-sized summary of\nthis article:\n\nDecouple app. architecture w/module,facade & mediator patterns. Mods publish\nmsgs, mediator acts as pub/sub mgr & facade handles security\n\n\n[1]: http://yuilibrary.com/theater/nicholas-zakas/zakas-architecture/\n[2]: http://addyosmani.com/resources/essentialjsdesignpatterns/book/"
},
{
"path": "_includes/translation/eng/01_what-exactly-is-a-large-javascript-application.md",
"content": "### What exactly *is* a 'large' JavaScript application?\n\nBefore we begin, let us attempt to define what we mean when we refer to a\nJavaScript application as being significantly 'large'. This is a question I've \nfound still challenges developers with many years of experience in the field and\nthe answer to this can be quite subjective.\n\nAs an experiment, I asked a few intermediate developers to try providing their\ndefinition of it informally. One developer suggested 'a JavaScript application \nwith over 100,000 LOC' whilst another suggested 'apps with over 1MB of \nJavaScript code written in-house'. Whilst valiant (if not scary) suggestions, \nboth of these are**incorrect** as the size of a codebase does not always\ncorrelate to application complexity - those 100,000 LOC could easily represent \nquite trivial code.\n\nMy own definition may or may not be universally accepted, but I believe that it\n's closer to what a large application actually represents.\n\nIn my view, large-scale JavaScript apps are **non-trivial** applications\nrequiring**significant** developer effort to maintain, where most heavy lifting\nof data manipulation and display falls to the**browser**. \n\nThe last part of this definition is possibly the most significant."
},
{
"path": "_includes/translation/eng/02_lets-review-your-current-architecture.md",
"content": "### Let's review your current architecture.\n\nIf working on a significantly large JavaScript application, remember to\ndedicate**sufficient time** to planning the underlying architecture that makes\nthe most sense. It's often more complex than you may initially imagine.\n\nI can't stress the importance of this enough - some developers I've seen\napproach larger applications have stepped back and said 'Okay. Well, there are a\nset of ideas and patterns that worked well for me on my last medium-scale \nproject. Surely they should mostly apply to something a little larger, right?'. \nWhilst this may be true to an extent, please don't take it for granted\n- **larger apps generally have greater concerns that need to be factored in**.\nI'm going to discuss shortly why spending a little more time planning out the \nstructure to your application is worth it in the long run.\n\nMost JavaScript developers likely use a mixed combination of the following for\ntheir current architecture:\n\n* custom widgets\n* models\n* views\n* controllers\n* templates\n* libraries/toolkits\n* an application core. \n\nYou probably also break down your application's functionality into blocks of\nmodules or apply other patterns for this. This is great, but there are a number \nof potential problems you can run into if this represents all of your \napplication's structure.\n\n\n##### 1. How much of this architecture is instantly re-usable? \n\nCan single modules exist on their own independently? Are they self-contained?\nRight now if I were to look at the codebase for a large application you or your \nteam were working on and selected a random module, would it be possible for me \nto easily just drop it into a new page and start using it on its own?. You may \nquestion the rationale behind wanting to do this, however I encourage you to \nthink about the future. What if your company were to begin building more and \nmore non-trivial applications which shared some cross-over in functionality?. If\nsomeone said, 'Our users love using the chat module in our mail client. Let's \ndrop that into our new collaborative editing suite', would this be possible \nwithout significantly altering the code?\n\n\n##### 2. How much do modules depend on other modules in the system? \n\nAre they tightly coupled? Before I dig into why this is a concern, I should\nnote that I understand it's not always possible to have modules with absolutely \nno other dependencies in a system. At a granular level you may well have modules\nthat extend the base functionality of others, but this question is more-so \nrelated to groups of modules with distinct functionality. It should be possible \nfor all of these distinct sets of modules to work in your application without \ndepending on too many other modules being present or loaded in order to function.\n\n\n##### 3. If specific parts of your application fail, can it still function? \n\nIf you're building a GMail-like application and your webmail module (or modules\n) fail, this shouldn't block the rest of the UI or prevent users from being able\nto use other parts of the page such as chat. At the same time, as per before, \nmodules should ideally be able to exist on their own outside of your current \napplication architecture. In my talks I mention dynamic dependency (or module) \nloading based on expressed user-intent as something related. For example, in \nGMail's case they might have the chat module collapsed by default without the \ncore module code loaded on page initialization. If a user expressed an intent to\nuse the chat feature, only then would it be dynamically loaded. Ideally, you \nwant this to be possible without it negatively affecting the rest of your \napplication.\n\n\n##### 4. How easily can you test individual modules?\n\nWhen working on systems of significant scale where there's a potential for\nmillions of users to use (or mis-use) the different parts it, it's essential \nthat modules which may end up being re-used across a number of different \napplications be sufficiently tested. Testing needs to be possible for when the \nmodule both inside and outside of the architecture for which it was initially \nbuilt. In my view, this provides the most assurance that it shouldn't break if \ndropped into another system."
},
{
"path": "_includes/translation/eng/03_think-long-term.md",
"content": "### Think Long Term\n\nWhen devising the architecture for your large application, it's important to\nthink ahead. Not just a month or a year from now, but beyond that. What might \nchange? It's of course impossible to guess exactly how your application may grow,\nbut there's certainly room to consider what is likely. Here, there is at least \none specific aspect of your application that comes to mind.\n\nDevelopers often couple their DOM manipulation code quite tightly with the rest\nof their application - even when they've gone to the trouble of separating their\ncore logic down into modules. Think about it..why is this not a good idea if we'\nre thinking long-term?\n\nOne member of my audience suggested that it was because a rigid architecture\ndefined in the present may not be suitable for the future. Whilst certainly true,\nthere's another concern that may cost even more if not factored in.\n\nYou may well decide to **switch** from using Dojo, jQuery, Zepto or YUI to\nsomething entirely different for reasons of performance, security or design in \nthe future. This can become a problem because libraries are not easily \ninterchangeable and have high switching costs if tightly coupled to your app.\n\nIf you're a Dojo developer (like some of the audience at my talk), you may not\nhave something better to switch to in the present, but who is to say that in 2-3\nyears something better doesn't come out that you'll want to switch to?\n.\n\nThis is a relatively trivial decision in smaller codebases but for larger\napplications, having an architecture which is flexible enough to support **not**\ncaring about the libraries being used in your modules can be of great benefit,\nboth financially and from a time-saving perspective.\n\nTo summarize, if you reviewed your architecture right now, could a decision to\nswitch libraries be made without rewriting your entire application?. If not, \nconsider reading on because I think the architecture being outlined today may be\nof interest.\n\nThere are a number of influential JavaScript developers who have previously\noutlined some of the concerns I've touched upon so far. Three key quotes I would\nlike to share from them are the following:\n\n\"The secret to building large apps is never build large apps. Break your\napplications into small pieces. Then, assemble those testable, bite-sized pieces\ninto your big application\n\" - **Justin Meyer, author JavaScriptMVC**\n\n\"The key is to acknowledge from the start that you have no idea how this will\ngrow. When you accept that you don't know everything, you begin to design the \nsystem defensively. You identify the key areas that may change, which often is \nvery easy when you put a little bit of time into it. For instance, you should \nexpect that any part of the app that communicates with another system will \nlikely change, so you need to abstract that away.\n\" - **Nicholas Zakas, author 'High-performance JavaScript websites'**\n\nand last but not least:\n\n\"The more tied components are to each other, the less reusable they will be,\nand the more difficult it becomes to make changes to one without accidentally \naffecting another\n\" - **Rebecca Murphey, author of jQuery Fundamentals.** These principles are\nessential to building an architecture that can stand the test of time and should\nalways be kept in mind.\n"
},
{
"path": "_includes/translation/eng/04_brainstorming.md",
"content": "### Brainstorming\n\nLet's think about what we're trying to achieve for a moment. \n\nWe want a loosely coupled architecture with functionality broken down into **\nindependent modules** with ideally no inter-module dependencies. Modules **\nspeak** to the rest of the application when something interesting happens and\nan**intermediate layer** interprets and reacts to these messages. \n\nFor example, if we had a JavaScript application responsible for an online\nbakery, one such 'interesting' message from a module might be 'batch 42 of bread\nrolls is ready for dispatch\n'. \n\nWe use a different layer to interpret messages from modules so that a) modules\ndon't directly access the core and b) modules don't need to directly call or \ninteract with other modules. This helps prevent applications from falling over \ndue to errors with specific modules and provides us a way to kick-start modules \nwhich have fallen over.\n\nAnother concern is security. The reality is that most of us don't consider\ninternal application security as that much of a concern. We tell ourselves that \nas we're structuring the application, we're intelligent enough to figure out \nwhat should be publicly or privately accessible.\n\nHowever, wouldn't it help if you had a way to determine what a module was\npermitted to do in the system? eg. if I know I've limited the permissions in my \nsystem to not allow a public chat widget to interface with an admin module or a \nmodule with DB-write permissions, I can limit the chances of someone exploiting \nvulnerabilities I have yet to find in the widget to pass some XSS in there. \nModules shouldn’t be able to access everything. They probably can in most \ncurrent architectures, but do they really need to be able to?\n\nHaving an intermediate layer handle permissions for which modules can access\nwhich parts of your framework gives you added security. This means a module is \nonly able to do at most what we’ve permitted it do.\n\n\n## The Proposed Architecture\n\nThe solution to the architecture we seek to define is a combination of three\nwell-known design patterns: the**module**, **facade** and **mediator**.\n\nRather than the traditional model of modules directly communicating with each\nother, in this decoupled architecture, they'll instead only publish events of \ninterest (ideally, without a knowledge of other modules in the system). The \nmediator pattern will be used to both subscribe to messages from these modules \nand handle what the appropriate response to notifications should be. The facade \npattern will be used to enforce module permissions.\n\nI will be going into more detail on each of these patterns below:"
},
{
"path": "_includes/translation/eng/05_module-theory.md",
"content": "### Module Theory \n\nYou probably already use some variation of modules in your existing\narchitecture. If however, you don't, this section will present a short primer on\nthem.\n\nModules are an **integral** piece of any robust application's architecture and\nare typically single-purpose parts of a larger system that are interchangeable.\n\nDepending on how you implement modules, it's possible to define dependencies\nfor them which can be automatically loaded to bring together all of the other \nparts instantly. This is considered more scalable than having to track the \nvarious dependencies for them and manually load modules or inject script tags.\n\nAny significantly non-trivial application should be built from modular\ncomponents. Going back to GMail, you could consider modules independent units of\nfunctionality that can exist on their own, so the chat feature for example. It's\nprobably backed by a chat module, however, depending on how complex that unit of\nfunctionality is, it may well have more granular sub-modules that it depends on.\nFor example, one could have a module simply to handle the use of emoticons which\ncan be shared across both chat and mail composition parts of the system.\n\nIn the architecture being discussed, modules have a **very limited knowledge**\nof what's going on in the rest of the system. Instead, we delegate this \nresponsibility to a mediator via a facade.\n\nThis is by design because if a module only cares about letting the system know\nwhen something of interest happens without worrying if other modules are running,\na system is capable of supporting adding, removing or replacing modules without \nthe rest of the modules in the system falling over due to tight coupling.\n\nLoose coupling is thus essential to this idea being possible. It facilitates\neasier maintainability of modules by removing code dependencies where possible. \nIn our case, modules should not rely on other modules in order to function \ncorrectly. When loose coupling is implemented effectively, its straight-forward \nto see how changes to one part of a system may affect another.\n\nIn JavaScript, there are several options for implementing modules including the\nwell-known module pattern and object literals. Experienced developers will \nalready be familiar with these and if so, please skip ahead to the section on \nCommonJS modules."
},
{
"path": "_includes/translation/eng/06_the-module-pattern.md",
"content": "##### The Module Pattern \n\nThe module pattern is a popular design that pattern that encapsulates 'privacy',\nstate and organization using closures. It provides a way of wrapping a mix of\npublic and private methods and variables, protecting pieces from leaking into \nthe global scope and accidentally colliding with another developer's interface. \nWith this pattern, only a public API is returned, keeping everything else within\nthe closure private.\n\nThis provides a clean solution for shielding logic doing the heavy lifting\nwhilst only exposing an interface you wish other parts of your application to \nuse. The pattern is quite similar to an immediately-invoked functional \nexpression\n([IIFE][3]) except that an object is returned rather than a function. \n\nIt should be noted that there isn't really a true sense of 'privacy' inside\nJavaScript because unlike some traditional languages, it doesn't have access \nmodifiers. Variables can't technically be declared as being public nor private \nand so we use function scope to simulate this concept. Within the module pattern,\nvariables or methods declared are only available inside the module itself thanks\nto closure. Variables or methods defined within the returning object however are\navailable to everyone.\n\nBelow you can see an example of a shopping basket implemented using the pattern\n. The module itself is completely self-contained in a global object called\n`basketModule`. The `basket` array in the module is kept private and so other\nparts of your application are unable to directly read it. It only exists with \nthe module's closure and so the only methods able to access it are those with \naccess to its scope (ie.`addItem()`, `getItem()` etc). \n\n var basketModule = (function() {\n var basket = []; //private\n return { //exposed to public\n addItem: function(values) {\n basket.push(values);\n },\n getItemCount: function() {\n return basket.length;\n },\n getTotal: function(){\n var q = this.getItemCount(),p=0;\n while(q--){\n p+= basket[q].price; \n }\n return p;\n }\n }\n }());\n \n\nInside the module, you'll notice we return an `object`. This gets automatically\nassigned to`basketModule` so that you can interact with it as follows: \n\n //basketModule is an object with properties which can also be methods\n basketModule.addItem({item:'bread',price:0.5});\n basketModule.addItem({item:'butter',price:0.3});\n \n console.log(basketModule.getItemCount());\n console.log(basketModule.getTotal());\n \n //however, the following will not work:\n console.log(basketModule.basket);// (undefined as not inside the returned object)\n console.log(basket); //(only exists within the scope of the closure)\n \n\nThe methods above are effectively namespaced inside `basketModule`.\n\nFrom a historical perspective, the module pattern was originally developed by a\nnumber of people including[Richard Cornford][4] in 2003. It was later\npopularized by Douglas Crockford in his lectures and re-introduced by Eric \nMiraglia on the YUI blog.\n\nHow about the module pattern in specific toolkits or frameworks? \n\n**Dojo** \n\nDojo attempts to provide 'class'-like functionality through `dojo.declare`,\nwhich can be used for amongst other things, creating implementations of the \nmodule pattern. For example, if we wanted to declare`basket` as a module of the\n`store` namespace, this could be achieved as follows: \n\n //traditional way\n var store = window.store || {};\n store.basket = store.basket || {};\n \n //using dojo.setObject\n dojo.setObject(\"store.basket.object\", (function() {\n var basket = [];\n function privateMethod() {\n console.log(basket);\n }\n return {\n publicMethod: function(){\n privateMethod();\n }\n };\n }()));\n \n\nwhich can become quite powerful when used with `dojo.provide` and mixins. \n\n** YUI ** \n\nThe following example is heavily based on the original YUI module pattern\nimplementation by Eric Miraglia, but is relatively self-explanatory.\n\n YAHOO.store.basket = function () {\n \n //\"private\" variables:\n var myPrivateVar = \"I can be accessed only within YAHOO.store.basket .\";\n \n //\"private\" method:\n var myPrivateMethod = function () {\n YAHOO.log(\"I can be accessed only from within YAHOO.store.basket\");\n }\n \n return {\n myPublicProperty: \"I'm a public property.\",\n myPublicMethod: function () {\n YAHOO.log(\"I'm a public method.\");\n \n //Within basket, I can access \"private\" vars and methods:\n YAHOO.log(myPrivateVar);\n YAHOO.log(myPrivateMethod());\n \n //The native scope of myPublicMethod is store so we can\n //access public members using \"this\":\n YAHOO.log(this.myPublicProperty);\n }\n };\n \n }();\n \n\n** jQuery ** \n\nThere are a number of ways in which jQuery code unspecific to plugins can be\nwrapped inside the module pattern. Ben Cherry previously suggested an \nimplementation where a function wrapper is used around module definitions in the\nevent of there being a number of commonalities between modules.\n\nIn the following example, a `library` function is defined which declares a new\nlibrary and automatically binds up the`init` function to `document.ready` when\nnew libraries (ie. modules) are created.\n\n function library(module) {\n $(function() {\n if (module.init) {\n module.init();\n }\n });\n return module;\n }\n \n var myLibrary = library(function() {\n return {\n init: function() {\n /*implementation*/\n }\n };\n }());"
},
{
"path": "_includes/translation/eng/07_object-literal-notation.md",
"content": "##### Object Literal Notation \n\nIn object literal notation, an object is described as a set of comma-separated\nname/value pairs enclosured in curly braces\n(`{}`). Names inside the object may be either strings or identifiers that are\nfollowed by a colon. There should be no comma used after the final name/value \npair in the object as this may result in errors.\n\nObject literals don't require instantiation using the `new` operator but\nshouldn't be used at the start of a statement as the opening`{` may be\ninterpreted as the beginning of a block. Below you can see an example of a \nmodule defined using object literal syntax. New members may be added to the \nobject using assignment as follows`myModule.property = 'someValue';`\n\nWhilst the module pattern is useful for many things, if you find yourself not\nrequiring specific properties or methods to be private, the object literal is a more than suitable alternative.\n\n var myModule = {\n myProperty : 'someValue',\n //object literals can contain properties and methods.\n //here, another object is defined for configuration\n //purposes:\n myConfig:{\n useCaching:true,\n language: 'en' \n },\n //a very basic method\n myMethod: function(){\n console.log('I can haz functionality?');\n },\n //output a value based on current configuration\n myMethod2: function(){\n console.log('Caching is:' + (this.myConfig.useCaching)?'enabled':'disabled');\n },\n //override the current configuration\n myMethod3: function(newConfig){\n if(typeof newConfig == 'object'){\n this.myConfig = newConfig;\n console.log(this.myConfig.language); \n }\n }\n };\n \n myModule.myMethod(); //I can haz functionality\n myModule.myMethod2(); //outputs enabled\n myModule.myMethod3({language:'fr',useCaching:false}); //fr\n\n\n[3]: http://benalman.com/news/2010/11/immediately-invoked-function-expression/\n[4]: http://groups.google.com/group/comp.lang.javascript/msg/9f58bd11bd67d937"
},
{
"path": "_includes/translation/eng/08_commonjs-modules.md",
"content": "### CommonJS Modules\n\nOver the last year or two, you may have heard about [CommonJS][5] - a volunteer\nworking group which designs, prototypes and standardizes JavaScript APIs. To \ndate they've ratified standards for modules and packages.The CommonJS AMD \nproposal specifies a simple API for declaring modules which can be used with \nboth synchronous and asynchronous script tag loading in the browser. Their \nmodule pattern is relatively clean and I consider it a reliable stepping stone \nto the module system proposed for ES Harmony (the next release of the JavaScript\nlanguage\n).\n\nFrom a structure perspective, a CommonJS module is a reusable piece of\nJavaScript which exports specific objects made available to any dependent code. \nThis module format is becoming quite ubiquitous as a standard module format for \nJS. There are plenty of great tutorials on implementing CommonJS modules, but at\na high-level they basically contain two primary parts: an`exports` object that\ncontains the objects a module wishes to make available to other modules and a\n`require` function that modules can use to import the exports of other modules. \n\n /*\n Example of achieving compatibility with AMD and standard CommonJS by putting\n boilerplate around the standard CommonJS module format:\n */\n \n (function(define){\n define(function(require,exports){\n // module contents\n var dep1 = require(\"dep1\");\n exports.someExportedFunction = function(){...};\n //...\n });\n })(typeof define==\"function\"?define:function(factory){factory(require,exports)});\n \n\nThere are a number of great JavaScript libraries for handling module loading in\nthe**CommonJS** module format, but my personal preference is RequireJS. A\ncomplete tutorial on RequireJS is outside the scope of this tutorial, but I can \nrecommend reading James Burke's ScriptJunkie post on it[here][6]. I know a\nnumber of people that also like Yabble.\n\nOut of the box, RequireJS provides methods for easing how we create static\nmodules with wrappers and it's extremely easy to craft modules with support for \nasynchronous loading. It can easily load modules and their dependencies this way\nand execute the body of the module once available.\n\nThere are some developers that however claim CommonJS modules aren't suitable\nenough for the browser. The reason cited is that they can't be loaded via a \nscript tag without some level of server-side assistance. We can imagine having a\nlibrary for encoding images as ASCII art which might export a`encodeToASCII`\nfunction. A module from this could resemble:\n\n var encodeToASCII = require(\"encoder\").encodeToASCII;\n exports.encodeSomeSource = function(){\n //process then call encodeToASCII\n }\n \n\nThis type of scenario wouldn't work with a script tag because the scope isn't\nwrapped, meaning our`encodeToASCII` method would be attached to the `window`\n`require` wouldn't be as such defined and exports would need to be created for\neach module separately. A client-side library together with server-side \nassistance or a library loading the script with an XHR request using`eval()`\ncould however handle this easily.\n\nUsing RequireJS, the module from earlier could be rewritten as follows:\n\n define(function(require, exports, module) {\n var encodeToASCII = require(\"encoder\").encodeToASCII;\n exports.encodeSomeSource = function(){\n //process then call encodeToASCII\n }\n });\n \n\nFor developers who may not rely on just using static JavaScript for their\nprojects, CommonJS modules are an excellent path to go down, but do spend some \ntime reading up on it. I've really only covered the tip of the ice berg but both\nthe CommonJS wiki and Sitepen have a number of resources if you wish to read \nfurther.\n\n\n[5]: http://commonjs.org\n[6]: http://msdn.microsoft.com/en-us/scriptjunkie/ff943568"
},
{
"path": "_includes/translation/eng/09_the-facade-pattern.md",
"content": "### The Facade Pattern \n\nNext, we're going to look at the facade pattern, a design pattern which plays a\ncritical role in the architecture being defined today.\n\nWhen you put up a facade, you're usually creating an outward appearance which\nconceals a different reality. The facade pattern provides a convenient**higher-\nlevel interface** to a larger body of code, hiding its true underlying\ncomplexity. Think of it as simplifying the API being presented to other \ndevelopers.\n\nFacades are a **structural pattern** which can often be seen in JavaScript\nlibraries and frameworks where, although an implementation may support methods \nwith a wide range of behaviors, only a 'facade' or limited abstract of these \nmethods is presented to the client for use.\n\nThis allows us to interact with the facade rather than the subsystem behind the\nscenes.\n\nThe reason the facade is of interest is because of its ability to hide\nimplementation-specific details about a body of functionality contained in \nindividual modules. The implementation of a module can change without the \nclients really even knowing about it.\n\nBy maintaining a consistent facade (simplified API), the worry about whether a\nmodule extensively uses dojo, jQuery, YUI, zepto or something else becomes \nsignificantly less important. As long as the interaction layer doesn't change, \nyou retain the ability to switch out libraries (eg. jQuery for Dojo) at a later \npoint without affecting the rest of the system.\n\nBelow is a very basic example of a facade in action. As you can see, our module\ncontains a number of methods which have been privately defined. A facade is then\nused to supply a much simpler API to accessing these methods:\n\n var module = (function() {\n var _private = {\n i:5,\n get : function() {\n console.log('current value:' + this.i);\n },\n set : function( val ) {\n this.i = val;\n },\n run : function() {\n console.log('running');\n },\n jump: function(){\n console.log('jumping');\n }\n };\n return {\n facade : function( args ) {\n _private.set(args.val);\n _private.get();\n if ( args.run ) {\n _private.run();\n }\n }\n }\n }());\n \n \n module.facade({run: true, val:10});\n //outputs current value: 10, running\n \n \n\nand that's really it for the facade before we apply it to our architecture.\nNext, we'll be diving into the exciting mediator pattern. The core difference \nbetween the facade pattern and the mediator is that the facade (a structural \npattern) only exposes existing functionality whilst the mediator (a behavioral \npattern) can add functionality."
},
{
"path": "_includes/translation/eng/10_the-mediator-pattern.md",
"content": "### The Mediator Pattern\n\n \nThe mediator pattern is best introduced with a simple analogy - think of your\ntypical airport traffic control. The tower handles what planes can take off and \nland because all communications are done from the planes to the control tower, \nrather than from plane-to-plane. A centralized controller is key to the success \nof this system and that's really what a mediator is.\n\nMediators are used when the communication between modules may be complex, but\nis still**well defined**. If it appears a system may have too many\nrelationships between modules in your code, it may be time to have a central \npoint of control, which is where the pattern fits in.\n\nIn real-world terms, a mediator** encapsulates** how disparate modules **\ninteract** with each other by acting as an intermediary. The pattern also\npromotes loose coupling by preventing objects from referring to each other \nexplicitly - in our system, this helps to solve our module inter-dependency \nissues.\n\nWhat other advantages does it have to offer? Well, mediators allow for actions\nof each module to vary independently, so it’s extremely flexible. If you've \npreviously used the Observer (Pub/Sub) pattern to implement an event broadcast \nsystem between the modules in your system, you'll find mediators relatively easy\nto understand.\n\nLet's take a look at a high level view of how modules might interact with a\nmediator:\n\n![][7]\n\nConsider modules as publishers and the mediator as both a publisher and\nsubscriber. Module 1 broadcasts an event notifying the mediator something needs \nto done. The mediator captures this message and 'starts' the modules needed to \ncomplete this task Module 2 performs the task that Module 1 requires and \nbroadcasts a completion event back to the mediator. In the mean time, Module 3 \nhas also been started by the mediator and is logging results of any \nnotifications passed back from the mediator.\n\nNotice how at no point do any of the modules** directly communicate** with one\nanother. If Module 3 in the chain were to simply fail or stop functioning, the \nmediator could hypothetically 'pause' the tasks on the other modules, stop and \nrestart Module 3 and then continue working with little to no impact on the \nsystem. This level of decoupling is one of the main strengths the pattern has to\noffer.\n\nTo review, the advantages of the mediator are that:\n\nIt decouples modules by introducing an intermediary as a central point of\ncontrol.It allows modules to broadcast or listen for messages without being \nconcerned with the rest of the system. Messages can be handled by any number of \nmodules at once.\n\nIt is typically significantly more easy to add or remove features to systems\nwhich are loosely coupled like this.\n\nAnd its disadvantages: \n\nBy adding a mediator between modules, they must always communicate indirectly.\nThis can cause a very minor performance drop - because of the nature of loose \ncoupling, its difficult to establish how a system might react by only looking at\nthe broadcasts. At the end of the day, tight coupling causes all kinds of \nheadaches and this is one solution.\n\n** Example:** This is a possible implementation of the mediator pattern based\non previous work by[@rpflorence][8]\n\n var mediator = (function(){\n var subscribe = function(channel, fn){\n if (!mediator.channels[channel]) mediator.channels[channel] = [];\n mediator.channels[channel].push({ context: this, callback: fn });\n return this;\n },\n \n publish = function(channel){\n if (!mediator.channels[channel]) return false;\n var args = Array.prototype.slice.call(arguments, 1);\n for (var i = 0, l = mediator.channels[channel].length; i \n \n \n \n**Example:** Here are two sample uses of the implementation from above. It's effectively managed publish/subscribe:\n \n \n \n //Pub/sub on a centralized mediator\n \n mediator.name = \"tim\";\n mediator.subscribe('nameChange', function(arg){\n console.log(this.name);\n this.name = arg;\n console.log(this.name);\n });\n \n mediator.publish('nameChange', 'david'); //tim, david\n \n \n //Pub/sub via third party mediator\n \n var obj = { name: 'sam' };\n mediator.installTo(obj);\n obj.subscribe('nameChange', function(arg){\n console.log(this.name);\n this.name = arg;\n console.log(this.name);\n });\n \n obj.publish('nameChange', 'john'); //sam, john\n\n\n[7]: img/chart4a.jpg\n[8]: https://github.com/rpflorence"
},
{
"path": "_includes/translation/eng/11_applying-the-facade-abstraction-of-the-core.md",
"content": "### **Applying The Facade: Abstraction Of The Core**\n\nIn the architecture suggested:\n\nA facade serves as an **abstraction** of the application core which sits between\nthe mediator and our modules - it should ideally be the **only** other part of\nthe system modules are aware of. \n\n\n\n\nThe responsibilities of the abstraction include ensuring a **consistent\ninterface** to these modules is available at all times. This closely resembles\nthe role of the **sandbox controller** in the excellent architecture first\nsuggested by Nicholas Zakas.\n\n\nComponents are going to communicate with the mediator through the facade so it\nneeds to be **dependable**. When I say 'communicate', I should clarify that as\nthe facade is an abstraction of the mediator which will be listening out for\nbroadcasts from modules that will be relayed back to the mediator.\n\n\nIn addition to providing an interface to modules, the facade also acts as\na security guard, determining which parts of the application a module may\naccess. Components only call **their own** methods and shouldn't be able to\ninterface with anything they don't have permission to. For example, a module\nmay broadcast dataValidationCompletedWriteToDB. The idea of a security check\nhere is to ensure that the module has permissions to request database-write\naccess. What we ideally want to avoid are issues with modules accidentally\ntrying to do something they shouldn't be.\n\n\nTo review in short, the mediator remains a type of pub/sub manager but is only\npassed interesting messages once they've cleared permission checks by the\nfacade."
},
{
"path": "_includes/translation/eng/12_applying-the-mediator-the-application-core.md",
"content": "### **Applying the Mediator: The Application Core**\n\n\nThe mediator plays the role of the application core. We've briefly touched on\nsome of its responsibilities but lets clarify what they are in full. \n\n\n\nThe core's primary job is to manage the module **lifecycle. **When the core\ndetects an** interesting message** it needs to decide how the application\nshould react - this effectively means deciding whether a module or set of\nmodules needs to be **started** or** stopped**. \n\nOnce a module has been started, it should ideally execute **automatically**.\nIt's not the core's task to decide whether this should be when the DOM is ready\nand there's enough scope in the architecture for modules to make such decisions\non their own. \n\nYou may be wondering in what circumstance a module might need to be 'stopped'\n- if the application detects that a particular module has failed or is\nexperiencing significant errors, a decision can be made to prevent methods in\nthat module from executing further so that it may be restarted. The goal here\nis to assist in reducing disruption to the user experience.\n\nIn addition, the core should enable **adding or removing** modules without\nbreaking anything. A typical example of where this may be the case is\nfunctionality which may not be available on initial page load, but is\ndynamically loaded based on expressed user-intent eg. going back to our GMail\nexample, Google could keep the chat widget collapsed by default and only\ndynamically load in the chat module(s) when a user expresses an interest in\nusing that part of the application. From a performance optimization perspective,\nthis may make sense.\n\nError management will also be handled by the application core. In addition to\nmodules broadcasting messages of interest they will also broadcast any errors\nexperienced which the core can then react to accordingly (eg. stopping modules,\nrestarting them etc).It's important that as part of a decoupled architecture\nthere to be enough scope for the introduction of new or better ways of handling\nor displaying errors to the end user without manually having to change each\nmodule. Using publish/subscribe through a mediator allows us to achieve this."
},
{
"path": "_includes/translation/eng/13_tying-it-all-together.md",
"content": "### **Tying It All Together**\n\n\n* **Modules** contain specific pieces of functionality for your application.\n They publish notifications informing the application whenever something \n interesting happens - this is their primary concern. As I'll cover in the FAQs, \n modules can depend on DOM utility methods, but ideally shouldn't depend on any \n other modules in the system. They should not be concerned with:\n \n \n * what objects or modules are subscribing to the messages they publish\n * where these objects are based (whether this is on the client or server\n )\n * how many objects subscribe to notifications\n\n**![][9]**\n\n* **The Facade** abstracts the core to avoid modules touching it directly. It\n subscribes to interesting events (from modules) and says 'Great! What happened? \n Give me the details!'. It also handles module security by checking to ensure the\n module broadcasting an event has the necessary permissions to pass such events \n that can be accepted.\n\n**![][10]**\n\n* **The Mediator (Application Core)** acts as a 'Pub/Sub' manager using the\n mediator pattern. It's responsible for module management and starts/stops \n modules as needed. This is of particular use for dynamic dependency loading and \n ensuring modules which fail can be centrally restarted as needed.\n \n**![][11]**\n\nThe result of this architecture is that modules (in most cases) are\ntheoretically no longer dependent on other modules. They can be easily tested \nand maintained on their own and because of the level of decoupling applied, \nmodules can be picked up and dropped into a new page for use in another project \nwithout significant additional effort. They can also be dynamically added or \nremoved without the application falling over.\n\n\n[9]: img/chart1a.gif\n[10]: img/chart2a.gif\n[11]: img/chart3a.gif"
},
{
"path": "_includes/translation/eng/14_beyond-pub-sub-automatic-event-registration.md",
"content": "### Beyond Pub/Sub: Automatic Event Registration\n\nAs previously mentioned by Michael Mahemoff, when thinking about large-scale\nJavaScript, it can be of benefit to exploit some of the more dynamic features of\nthe language. You can read more about some of the concerns highlighted on \nMichael's[G+][12] page, but I would like to focus on one specifically -\nautomatic event registration (AER\n).\n\nAER solves the problem of wiring up subscribers to publishers by introducing a\npattern which auto-wires based on naming conventions. For example, if a module \npublishes an event called`messageUpdate`, anything with a `messageUpdate`\nmethod would be automatically called.\n\nThe setup for this pattern involves registering all components which might\nsubscribe to events, registering all events that may be subscribed to and \nfinally for each subscription method in your component-set, binding the event to\nit. It's a very interesting approach which is related to the architecture \npresented in this post, but does come with some interesting challenges.\n\nFor example, when working dynamically, objects may be required to register\nthemselves upon creation. Please feel free to check out Michael's[post][13] on\nAER as he discusses how to handle such issues in more depth.\n\n\n[12]: https://plus.google.com/106413090159067280619/posts/hDZkVrDXZR6\n[13]: http://softwareas.com/automagic-event-registration"
},
{
"path": "_includes/translation/eng/15_frequently-asked-questions.md",
"content": "### Frequently Asked Questions\n\n#### Q: Is it possible to avoid implementing a sandbox or facade altogether?\n\nA: Although the architecture outlined uses a facade to implement security\nfeatures, it's entirely possible to get by using a mediator and pub/sub to \ncommunicate events of interest throughout the application without it. This \nlighter version would offer a similar level of decoupling, but ensure you're \ncomfortable with modules directly touching the application core (mediator) if \nopting for this variation.\n\n#### Q: You've mentioned modules not having any dependencies. Does this include\ndependencies such as third party libraries (eg. jQuery?\n)\n\nA: I'm specifically referring to dependencies on other modules here. What some\ndevelopers opting for an architecture such as this opt for is actually \nabstracting utilities common to DOM libraries -eg. one could have a DOM utility \nclass for query selectors which when used returns the result of querying the DOM\nusing jQuery (or, if you switched it out at a later point, Dojo). This way, \nalthough modules still query the DOM, they aren't directly using hardcoded \nfunctions from any particular library or toolkit. There's quite a lot of \nvariation in how this might be achieved, but the takeaway is that ideally core \nmodules shouldn't depend on other modules if opting for this architecture.\n\nYou'll find that when this is the case it can sometimes be more easy to get a\ncomplete module from one project working in another with little extra effort. I \nshould make it clear that I fully agree that it can sometimes be significantly \nmore sensible for modules to extend or use other modules for part of their \nfunctionality, however bear in mind that this can in some cases increase the \neffort required to make such modules 'liftable' for other projects.\n\n#### Q: I'd like to start using this architecture today. Is there any\nboilerplate code around I can work from?\n\nA: I plan on releasing a free boilerplate pack for this post when time permits\n, but at the moment, your best bet is probably the\n'[Writing Modular JavaScript][14]' premium tutorial by Andrew Burgees (for\ncomplete disclosure, this is a referral link as any credits received are re-\ninvested into reviewing material before I recommend it to others). Andrew's pack\nincludes a screencast and code and covers most of the main concepts outlined in \nthis post but opts for calling the facade a 'sandbox', as per Zakas. There's \nsome discussion regarding just how DOM library abstraction should be ideally \nimplemented in such an architecture - similar to my answer for the second \nquestion, Andrew opts for some interesting patterns on generalizing query \nselectors so that at most, switching libraries is a change that can be made in a\nfew short lines. I'm not saying this is the right or best way to go about this, \nbut it's an approach I personally also use.\n\n#### Q: If the modules need to directly communicate with the core, is this\npossible?\n\nA: As Zakas has previously hinted, there's technically no reason why modules\nshouldn't be able to access the core but this is more of a best practice than \nanything. If you want to strictly stick to this architecture you'll need to \nfollow the rules defined or opt for a looser architecture as per the answer to \nthe first question.\n\n\n[14]: http://bit.ly/orGVOL"
},
{
"path": "_includes/translation/eng/16_credits.md",
"content": "### Credits\n\nThanks to Nicholas Zakas for his original work in bringing together many of the\nconcepts presented today; Andrée Hansson for his kind offer to do a technical \nreview of the post (as well as his feedback that helped improve it); Rebecca \nMurphey, Justin Meyer, John Hann, Peter Michaux, Paul Irish and Alex Sexton, all\nof whom have written material related to the topics discussed in the past and \nare a constant source of inspiration for both myself and others."
},
{
"path": "_includes/translation/rus/00_intro.md",
"content": "В этой книге мы обсудим набор паттернов, который поможет вам в создании \nбольших масштабируемых JavaScript-приложений. Материал книги основан на моем\nодноименном докладе, впервые прочитанном на конференции «LondonJS», и\nвдохновленном [предшествующей ему работой][1] Николаса Закаса.\n\n### Кто я и почему я решил об этом написать?\n\nМеня зовут Эдди Османи. Сейчас я работаю JavaScript- и UI-разработчиком в AOL.\nЯ занимаюсь планированием и написанием фронтенд-архитектуры для следующего\nпоколения наших пользовательских приложений. Эти приложения весьма сложны. Они\nнуждаются в архитектуре, позволяющей, с одной стороны легко их масштабировать,\nа с другой достаточно легко использовать повторно их модули. Также я занимаюсь\nразработкой шаблонов, которые можно применять в разработке приложений подобного\nмасштаба настолько качественно, насколько это вообще возможно.\n\nКроме того, я рассматриваю себя как евангелиста шаблонов проектирования (хотя\nесть много экспертов, разбирающихся в этом лучше меня). В прошлом я написал книгу \n«[Essential JavaScript Design Patterns][2]», а сейчас я занимаюсь написанием более \nподробного продолжения этой книги.\n\n\n### Могу ли я уместить эту книгу в 140 символов?\n\nЯ уместил эту статью в один твит, на случай, если у вас совсем мало времени:\n\nМеньше связанности: используйте паттерны «модуль», «фасад» и «медиатор». Модули\nобщаются через медиатор, а фасад обеспечивает безопасность.\n{:class=\"message\"}\n\n\n[1]: http://www.slideshare.net/nzakas/scalable-javascript-application-architecture\n[2]: http://addyosmani.com/resources/essentialjsdesignpatterns/book/\n"
},
{
"path": "_includes/translation/rus/01_what-exactly-is-a-large-javascript-application.md",
"content": "\n\nПеред тем как я начну, давайте постараемся определить, что именно мы имеем \nв виду, когда говорим о больших JavaScript-приложениях. Этот вопрос\nя считаю своего рода вызовом опытным разработчикам, и ответы на него,\nсоответственно, получаются очень субъективными.\n\nРади эксперимента я предложил нескольким среднестатистическим разработчикам\nдать собственное определение этому термину. Один из разработчиков сказал, что\nречь идет о «JavaScript-приложениях, состоящих из более чем 100 000 \nстрок кода», когда другой определил что большое приложение «содержит больше\nчем 1 МБ JavaScript». Я расстроил храбрецов — оба этих варианта\nдалеки от истины. Количество кода не всегда коррелирует со сложностью приложения.\n100 000 строк легко могут оказаться самым ничем не примечательным простым кодом.\n\nЯ не знаю, подходит ли мое собственное определение к любому случаю, но я верю,\nчто оно находится ближе всего к тому, что действительно представляет из себя\nбольшое JavaScript-приложение.\n\n{:class=\"message\"}\nЯ думаю, что большие JavaScript-приложения решают нетривиальные задачи,\nа поддержка таких приложений требует от разработчика серьезных усилий.\nПри этом, большая часть работы по манипуляции данными и их отображению ложится\nна браузер.\n\nЯ думаю, что последняя часть определения — самая важная.\n"
},
{
"path": "_includes/translation/rus/02_lets-review-your-current-architecture.md",
"content": "\n\n{:.message}\nРаботая над большим JavaScript-приложением, не забывайте уделять **достаточное\nколичество времени** на планирование изначальной архитектуры, к которой такие \nприложения очень чувствительны. Большие приложения обычно представляют\nиз себя очень сложные системы, гораздо более сложные, чем вы представляете\nсебе изначально.\n\nЯ должен подчеркнуть значение этой разницы — я видел разработчиков, которые,\nсталкиваясь с большими приложениями, делали шаг назад и говорили: «Хорошо,\nу меня есть несколько идей, которые хорошо показали себя в моем предыдущем\nпроекте среднего масштаба. Думаю, они точно сработают и для чего-то большего,\nне так ли?». Конечно, до какого-то момента это может быть так, но, пожалуйста,\nне принимайте это как должное — по большей части большие приложения имеют ряд\nдостаточно серьезных проблем, с которыми нужно считаться. Ниже я приведу\nнесколько доводов в пользу того, почему вам стоит уделить немного больше времени \nпланированию архитектуры своего приложения, и чем вам это будет полезно\nв долгосрочной перспективе.\n\nБольшинство JavaScript-разработчиков в архитектуре своих приложений обычно\nиспользует различные комбинации следующих компонентов:\n\n* виджеты\n* модели\n* представления\n* контроллеры\n* шаблоны\n* библиотеки\n* ядро приложения.\n\n{:class=\"message\"}\n**Ссылки по теме:** \n[Ребекка Мёрфи — Создание архитектуры JavaScript-приложений][1] \n[Питер Мишо — MVC архитектура для JavaScript-приложений][2] \n[StackOverflow — Дискуссия о современных MVC-фреймворках][3] \n[Дуг Найнер — Поддерживаемые плагины и фабрика виджетов][4] \n\n\nВероятно, вы выносите различные функции ваших приложений в отдельные модули,\nлибо используете какие-нибудь другие шаблоны проектирования для подобного\nразделения. Это очень хорошо, но здесь есть ряд потенциальных проблем,\nс которыми вы можете столкнуться при таком подходе.\n\n\n### 1. Готова ли ваша архитектура к повторному использованию кода уже сейчас?\n\nМогут ли отдельные модули использоваться самостоятельно? Достаточно ли они\nавтономны для этого? Мог бы я прямо сейчас взять один из модулей вашего большого \nприложения, просто поместить его на новую веб-страницу, а затем, тут же, начать\nего использовать? У вас может возникнуть вопрос: «Действительно ли это так\nнеобходимо?», но, как бы то ни было, я надеюсь, что вы думаете о будущем. Что, \nесли ваша компания начнет создавать все больше и больше нетривиальных\nприложений, которые будут иметь некоторую общую функциональность? Если кто-то\nскажет: «Нашим пользователям очень нравится использовать модуль чата в нашем\nemail-клиенте, почему бы нам не добавить этот модуль к нашему новому приложению для\nсовместной работы с документами?», будет ли это возможно, если мы не уделим\nдолжного внимания контролю кода?\n\n\n### 2. Сколько модулей в вашей системе зависит от других модулей?\n\nНасколько сильно связаны ваши модули? Перед тем, как я погружусь в объяснения\nо том, как важна слабая связанность модулей, я должен отметить, что не всегда есть\nвозможность создавать модули, не имеющие абсолютно никаких зависимостей\nв системе. К примеру, одни модули могут расширять функции других, уже существующих.\nЭта тема, скорее всего, относится к группировке модулей на основе некоторой\nфункциональности. Отдельные наборы модулей должны работать в вашем приложении без\nбольшого количества зависимостей, чтобы наличие или загрузка других модулей\nне влияла на их работоспособность.\n\n\n### 3. Сможет ли ваше приложение работать дальше, если его отдельная часть сломается?\n\nЕсли вы разрабатываете приложения, подобные Gmail, и ваш webmail-модуль (или \nгруппа модулей) перестанет работать из-за ошибки, то это не должно заблокировать\nпользовательский интерфейс или помешать пользователям использовать другие части\nвашего приложения, к примеру, такие как чат. В то же время, как было сказано\nраньше, было бы идеально, если бы модули могли работать и за пределами вашей\nархитектуры. В моей лекции я упоминал динамические зависимости — возможность\nзагружать модули, исходя из определенных действий пользователя. К примеру,\nребята из Gmail могли бы изначально держать чат закрытым, не загружая его\nкод при открытии страницы. А в тот момент, когда пользователь решит\nвоспользоваться им — соответствующий модуль будет динамически загружен и\nвыполнен. В идеальном случае хотелось бы выполнить это без каких-то негативных\nэффектов в вашем приложении.\n\n\n### 4. Насколько легко вы сможете тестировать отдельные модули?\n\nКогда вы работаете над масштабными системами, есть вероятность, что\nразличные части этой системы будут использовать миллионы пользователей.\nВполне вероятно, что эти части будут использоваться не только в предусмотренных\nвами ситуациях. В конечном счете, код может использоваться повторно в огромном\nколичестве различных окружений, и важно, чтобы модули были достаточно\nпротестированы. Тестировать модули необходимо и внутри архитектуры, для которой\nон был изначально разработан, и снаружи. По моему мнению, это дает наибольшую\nгарантию того, что модуль не сломается при попадании в другую систему.\n\n[1]: http://rmurphey.com/blog/2010/08/27/code-org-take-2-structuring-javascript-applications/\n[2]: http://michaux.ca/articles/mvc-architecture-for-javascript-applications\n[3]: http://stackoverflow.com/questions/5112899/knockout-js-vs-backbone-js-vs\n[4]: http://msdn.microsoft.com/en-us/scriptjunkie/ff706600\n"
},
{
"path": "_includes/translation/rus/03_think-long-term.md",
"content": "\n\nВ процессе создания архитектуры большого приложения, очень важно думать о будущем.\nНе только о том, что будет через месяц или через год, но и о том, что будет после\nэтого. Что может измениться? Конечно, невозможно достаточно точно предсказать\nкак ваше приложение будет развиваться, но, вне всякого сомнения, имеет смысл\nподумать об этом. Думаю, что найдется хотя бы один специфичный аспект вашего\nприложения, о котором стоит поразмыслить.\n\nРазработчики зачастую слишком сильно связывают манипуляцию с DOM-элементами и\nостальные части приложения, даже если до этого они не поленились разделить\nбизнес-логику на модули. Подумайте, почему в долгосрочной перспективе это\nможет быть плохой идеей?\n\nОдин из слушателей моей лекции предположил, что такая архитектура негибка, и может\nне работать в будущем. Это действительно так, но есть другая проблема, игнорирование\nкоторой окажет еще более негативный эффект.\n\n{:class=\"message\"}\nВ будущем, вы можете принять решение о **замене** Dojo, jQuery, Zepto или YUI на\nчто-нибудь совершенно иное. Причиной такого перехода может быть производительность,\nбезопасность или дизайн. Это может стать серьезной проблемой, потому как библиотеки\nне предусматривают простой замены. Цена замены библиотеки будет высокой, если ваше\nприложение тесно с ней связано.\n\nЕсли вы используете Dojo (как многие слушатели на моей лекции), вы можете\nбыть уверены, что нет ничего лучше, на что имело бы смысл сейчас перейти. Но\nможете ли вы быть уверены, что в течении двух-трех лет не появится что-нибудь,\nчто вызовет у вас интерес? Что-нибудь, на что вы можете решить перейти.\n\nТакое решение может быть достаточно простым для небольших проектов, но для\nбóльших приложений гибкая архитектура может принести значительную пользу как в\nфинансовом плане, так и с точки зрения экономии времени благодаря тому, что\nеё можно поддерживать **не** заботясь об используемых библиотеках.\n\nПодводя итог, взгляните на вашу архитектуру сейчас. Сможете ли вы сегодня сменить\nвашу библиотеку на любую другую, не переписывая при этом ваше приложение\nполностью? Если это не так, то вам стоит продолжить чтение. Я думаю, что\nв архитектуре, которую мы обсуждаем, вы найдёте кое-что интересное. \n\nНекоторые из известных JavaScript-разработчиков раньше уже излагали проблемы,\nо которых я написал выше. Вот три ключевых цитаты, которыми я бы хотел поделиться\nс вами.\n\n{:class=\"message\"}\n«Секрет создания больших приложений в том, чтобы никогда не создавать больших\nприложений. Разбейте ваши приложения на маленькие части, а затем собирайте из\nэтих маленьких тестируемых фрагментов ваше большое приложение»\n**Джастин Майер, автор «JavaScriptMVC»**\n\n{:class=\"message\"}\n«Секрет в том, чтобы признаться самому себе с самого начала, что вы понятия\nне имеете о том, как ваше приложение будет развиваться. Когда вы согласитесь\nс этим, вы начнете проектировать систему основываясь на защите. Вы определите\nключевые области, в которых, вероятнее всего будут происходить изменения. Очень\nчасто это не составляет труда, если потратить на это немного времени. К примеру,\nвы ожидаете, что любая часть приложения, которая взаимодействует с другой\nсистемой — это потенциальная мишень для изменений. И вы понимаете, что здесь вам\nпонадобится абстракция». \n**Николас Закас, автор книги «Высокопроизводительный JavaScript**\n\nИ последняя, но тоже очень важная цитата:\n\n{:class=\"message\"}\n«Чем сильнее компоненты связаны между собой, тем меньше возможностей для их\nповторного использования, тем сложнее вносить изменения, не получая при этом различных\nпобочных эффектов в самых неожиданных местах»\n**Ребекка Мёрфи, автор книги «Фундаментальные основы jQuery»**\n\nЭти принципы необходимы для создания архитектуры, способной выдержать испытание\nвременем. Важно всегда помнить о них.\n\n\n"
},
{
"path": "_includes/translation/rus/04_brainstorming.md",
"content": "\n\nДавайте немного подумаем, что мы хотим получить.\n\n{:class=\"message\"}\nМы хотим получить слабосвязанную архитектуру с функциональностью, разделенную\nна **независимые модули**, которые, в идеале, не должны иметь зависимостей друг\nот друга. Когда случается что-то интересное, модули **сообщают** об этом другим\nчастям приложения, а промежуточный слой интерпретирует их сообщения и необходимым\nобразом реагирует на них.\n\nНапример, у нас есть JavaScript-приложение, отвечающее за онлайн-пекарню. Одно из\nинтересных нам сообщений может быть таким: «Партия из 42 батонов готова к доставке».\n\nМы используем отдельный слой для обработки сообщений модулей, чтобы а) модули\nне взаимодействовали напрямую с ядром, б) модули не взаимодействовали напрямую\nдруг с другом. Это помогает не допустить падения приложения из-за различных\nошибок внутри одного из модулей. Также это позволяет нам перезапускать модули\nесли они вдруг перестали работать из-за какой-нибудь ошибки.\n\nЕще один момент — безопасность. На самом деле, немногие из нас заботятся\nо внутренней безопасности своих приложений в должной мере. Когда мы определяем\nструктуру приложения, мы говорим себе, что мы достаточно умны для того, чтобы\nпонимать что в нашем коде должно быть публичным, а что приватным.\n\nХорошо, но поможет ли это если вы решите определить что именно разрешено\nмодулю выполнять в системе? К примеру, в моем приложении, ограничив доступ из\nмодуля веб-чата к интерфейсу модуля администрирования, я смогу уменьшить шансы\nна успешное использование XSS уязвимостей, которые я не смог найти в виджете.\nМодули не должны иметь доступ ко всему. Вероятно, в вашей существующей\nархитектуре они могут использовать любые части системы, но уверены ли вы, что\nэто действительно необходимо?\n\nПромежуточный слой, проверяющий имеет ли модуль доступ к определенной части\nвашего фреймворка, обеспечивает большую безопасность вашей системы. Фактически\nэто значит что модули могут взаимодействовать только с теми компонентами \nсистемы, с которыми мы разрешим им взаимодействовать.\n\n\n### Архитектура, которую я предлагаю вам\n\nАрхитектура, о которой мы говорим, представляет из себя комбинацию трех\nизвестных шаблонов проектирования: модуль, фасад и медиатор.\n\nВ отличии от традиционной модели, в которой модули напрямую взаимодействуют друг с\nдругом, в этой слабосвязанной архитектуре модули всего лишь публикуют события (в\nидеале, не зная о других модулях в системе). Медиатор используется для подписки на\nсообщения от модулей и для решения, каким должен быть ответ на уведомление. Паттерн\nфасад используется для ограничения действий разрешенных модулям.\n\nВ следующих главах я более детально расскажу о каждом из этих шаблонов\nпроектирования.\n"
},
{
"path": "_includes/translation/rus/05_module-theory.md",
"content": "\n\nВероятно, в каком-то виде вы уже используете модули в своей существующей\nархитектуре. Если это не так, то в этой главе я покажу вам, как они устроены.\n\n{:class=\"message\"}\nМодули — это **целая** часть любой хорошей архитектуры приложения. Обычно\nмодули выполняют одну определенную задачу в более крупных системах и могут быть\nвзаимозаменяемы.\n\nВ некоторых реализациях модули могут иметь свои собственные зависимости, которые\nбудут загружены автоматически, собирая вместе таким образом все компоненты\nсистемы. Такой подход считается более масштабируемым, в отличие от ручной\nзагрузки модулей или подстановки тега `script`.\n\nКаждое нетривиальное приложение должно создаваться из модульных компонентов.\nРассмотрим GMail: вы можете рассматривать модули, как независимые единицы\nфункциональности, которые могут и должны существовать сами по себе; возьмём к\nпримеру чат. Скорее всего он основан на своём отдельном модуле чата, но так как\nэтот модуль скорее всего очень сложный, то он вероятно состоит из более мелких\nвспомогательных модулей. Например, один из таких модулей мог бы отвечать за\nиспользование смайликов и он же мог бы использоваться не только в чате, но также\nи в почте.\n\n{:class=\"message\"}\nВ рассматриваемой архитектуре модули имеют **очень ограниченные знания** о том, что\nпроисходит в других частях системы. Вместо этого мы делегируем ответственность\nмедиатору и фасаду.\n\nВ этом и заключается идея нашей архитектуры — если модуль заботится исключительно\nо том, чтобы уведомить систему об интересующих ее происшествиях, и не волнуется\nзапущены ли другие модули, то система может добавлять, удалять или заменять одни\nмодули, не ломая при этом другие, что было бы невозможно при сильной связанности.\n\nСлабая связанность — необходимое условие для того, чтобы такая идея была возможна.\nОна делает поддержку модулей проще, удаляя зависимости в коде там, где это возможно.\nВ вашем случае, одни модули должны работать корректно вне зависимости от того в\nкаком порядке загрузились другие модули. Когда слабая связанность реализована\nэффективно, становится очевидно, как изменения в одной части системы влияют на другие ее части.\n\nВ JavaScript есть несколько способов реализации модулей, включая\nшаблон «Модуль» и Object Literal (литеральная запись объекта `var obj = {};`).\nОпытные разработчики должно быть уже знакомы с ними. Если это так, то вы можете\nпропустить следующую главу и перейти сразу к главе «Модули CommonJS».\n"
},
{
"path": "_includes/translation/rus/06_the-module-pattern.md",
"content": "\n\n«Модуль» — это популярная реализация паттерна, инкапсулирующего приватную\nинформацию, состояние и структуру, используя замыкания. Это позволяет оборачивать\nпубличные и приватные методы и переменные в модули, и предотвращать их\nпопадание в глобальный контекст, где они могут конфликтовать с интерфейсами\nдругих разработчиков. Паттерн «модуль» возвращает только публичную часть API,\nоставляя всё остальное доступным только внутри замыканий.\n\nЭто хорошее решение для того, чтобы скрыть внутреннюю логику от посторонних глаз и\nпроизводить всю тяжелую работу исключительно через интерфейс, который вы определите\nдля использования в других частях вашего приложения. Этот паттерн очень похож на\nнемедленно-вызываемые функции ([IIFE][3]), за тем исключением, что модуль вместо\nфункции, возвращает объект.\n\nВажно заметить, что в JavaScript нет настоящей приватности. В отличии от некоторых\nтрадиционных языков, он не имеет модификаторов доступа. Переменные технически\nне могут быть объявлены как публичные или приватные, и нам приходится использовать\nобласть видимости для того, чтобы эмулировать эту концепцию. Благодаря замыканию,\nобъявленные внутри модуля переменные и методы доступны только изнутри этого модуля.\nПеременные и методы, объявленные внутри объекта, возвращаемого модулем, будут\nдоступны всем.\n\nНиже вы можете увидеть корзину покупок, реализованную с помощью паттерна «модуль».\nПолучившийся компонент находится в глобальном объекте `basketModule`, и содержит\nвсё, что ему необходимо. Находящийся внутри него, массив `basket` приватный,\nи другие части вашего приложения не могут напрямую взаимодействовать с ним. \nМассив `basket` существует внутри замыкания, созданного модулем, и\nвзаимодействовать с ним могут только методы, находящиеся в том же контексте\n(например, `addItem()`, `getItem()`). \n\n\n{% highlight javascript %}\nvar basketModule = (function() {\n var basket = []; // приватная переменная\n return { // методы доступные извне\n addItem: function(values) {\n basket.push(values);\n },\n getItemCount: function() {\n return basket.length;\n },\n getTotal: function() {\n var q = this.getItemCount(),p=0;\n while(q--){\n p+= basket[q].price; \n }\n return p;\n }\n }\n}());\n{% endhighlight %}\n\nВнутри модуля, как вы заметили, мы возвращаем объект. Этот объект автоматически\nприсваивается переменной `basketModule`, так что с ним можно взаимодействовать\nследующим образом:\n\n{% highlight javascript %}\n// basketModule - это объект со свойствами, которые могут также быть и методами:\nbasketModule.addItem({item:'bread', price:0.5});\nbasketModule.addItem({item:'butter', price:0.3});\n\nconsole.log(basketModule.getItemCount());\nconsole.log(basketModule.getTotal());\n\n// А следующий ниже код работать не будет:\nconsole.log(basketModule.basket); // undefined потому что не входит в возвращаемый объект\nconsole.log(basket); // массив доступен только из замыкания\n{% endhighlight %}\n\n\nМетоды выше фактически помещены в неймспейс `basketModule`.\n\nИсторически, паттерн «модуль» был разработан в 2003 году группой людей, в число\nкоторых входил [Ричард Корнфорд][4]. Позднее этот паттерн был популяризован\nДугласом Крокфордом в его лекциях, и открыт заново в блоге YUI благодаря Эрику \nМирагилиа.\n\nДавайте посмотрим на реализацию «модуля» в различных библиотеках и фреймворках.\n\n**Dojo** \n\nDojo старается обеспечивать поведение похожее на классы с помощью `dojo.declare`,\nкоторый, кроме создания «модулей», также используется и для других вещей.\nДавайте попробуем, для примера, определить `basket` как модуль внутри неймспейса\n`store`:\n\n{% highlight javascript %}\n\n// традиционный способ\nvar store = window.store || {};\nstore.basket = store.basket || {};\n\n// с помощью dojo.setObject\ndojo.setObject(\"store.basket.object\", (function() {\n var basket = [];\n function privateMethod() {\n console.log(basket);\n }\n return {\n publicMethod: function() {\n privateMethod();\n }\n };\n}()));\n\n{% endhighlight %}\n\nЛучшего результата можно добиться, используя `dojo.provide` и миксины.\n\n\n**YUI** \n\nСледующий код, по большей части, основан на примере реализации паттерна\n«модуль» в фреймворке YUI, разработанным Эриком Миргалиа, но более\nсамодокументирован.\n\n{% highlight javascript %}\n\nYAHOO.store.basket = function () {\n\n // приватная переменная:\n var myPrivateVar = \"Ко мне можно получить доступ только из YAHOO.store.basket.\";\n\n // приватный метод:\n var myPrivateMethod = function() {\n YAHOO.log(\"Я доступен только при вызове из YAHOO.store.basket\");\n }\n\n return {\n myPublicProperty: \"Я - публичное свойство\",\n myPublicMethod: function() {\n YAHOO.log(\"Я - публичный метод\");\n\n // Будучи внутри корзины я могу получить доступ к приватным переменный и методам:\n YAHOO.log(myPrivateVar);\n YAHOO.log(myPrivateMethod());\n\n // Родной контекст метода myPublicMethod сохранён\n // поэтому мы имеет доступ к this\n YAHOO.log(this.myPublicProperty);\n }\n };\n\n}();\n\n{% endhighlight %}\n\n\n**jQuery** \n\nСуществует множество способов, чтобы представить jQuery-код в виде паттерна «модуль», \nдаже если этот код не напоминает привычные jQuery-плагины. Бен Черри ранее \nпредлагал способ, при котором, если у модулей есть общие черты, то они объявляются \nчерез функцию-обертку.\n\nВ следующем примере функция `library` используется для объявления новой\nбиблиотеки и автоматически при создании библиотеки (т.е. модуля),\nсвязывает вызов метода `init` с `document.ready`.\n\n{% highlight javascript %}\n\nfunction library(module) {\n $(function() {\n if (module.init) {\n module.init();\n }\n });\n return module;\n}\n\nvar myLibrary = library(function() {\n return {\n init: function() {\n /* код модуля */\n }\n };\n}());\n\n{% endhighlight %}\n\n{:class=\"message\"}\n**Ссылки по теме:** \n[Бен Черри — Погружение в паттерн «Модуль»][5] \n[Джон Ханн — Будущее — это модули, а не фреймворки][6] \n[Натан Смит — Ссылки на window и document в модулях (gist)][7] \n\n\n[3]: http://benalman.com/news/2010/11/immediately-invoked-function-expression/\n[4]: http://groups.google.com/group/comp.lang.javascript/msg/9f58bd11bd67d937\n[5]: http://www.adequatelygood.com/2010/3/JavaScript-Module-Pattern-In-Depth\n[6]: http://lanyrd.com/2011/jsconf/sfgdk/\n[7]: https://gist.github.com/274388\n\n"
},
{
"path": "_includes/translation/rus/07_object-literal-notation.md",
"content": "\n\nВ литеральной нотации объект описывается внутри блока фигурных скобок (`{}`), \nкак набор разделенных запятой пар ключ/значение. Ключи объекта могут\nбыть как строками, так и идентификаторами. После имени ставится двоеточие.\nВ объекте не должно стоять запятой после последней пары ключ/значение,\nтак как это может привести к ошибкам.\n\nЛитерал объекта не требует использования оператора `new` для создания экземпляра,\nно он не должен стоять в начале выражения, так как открытая `{` может быть\nвоспринята как начало блока. Ниже вы можете увидеть пример модуля, определенного\nс помощью литеральной нотации объекта. Новые члены объекта могут быть добавлены\nс помощью конструкции `myModule.property = 'someValue';`\n\n{:.message}\nПаттерн «модуль» может быть полезен для многих вещей. Но если вы считаете, что вам\nне нужно делать приватными некоторые методы или свойства, то литерал объекта — \nболее чем подходящий выбор.\n\n{% highlight javascript %}\nvar myModule = {\n myProperty: 'someValue',\n // Литералы объектов могут содержать свойства и методы.\n // ниже в свойстве определен другой объект,\n // для описания конфигурации:\n myConfig: {\n useCaching: true,\n language: 'en'\n },\n // Очень простой метод\n myMethod: function() {\n console.log('I can haz functionality?');\n },\n // вывод значения заданного в конфигурации\n myMethod2: function() {\n console.log('Caching is: ' + ((this.myConfig.useCaching) ? 'enabled' : 'disabled'));\n },\n // переопределение конфигурации\n myMethod3: function(newConfig) {\n if (typeof newConfig == 'object') {\n this.myConfig = newConfig;\n console.log(this.myConfig.language); \n }\n }\n};\n\nmyModule.myMethod(); // 'I can haz functionality'\nmyModule.myMethod2(); // Вывод 'enabled'\nmyModule.myMethod3({language:'fr',useCaching:false}); // 'fr'\n{% endhighlight %}\n\n{:class=\"message\"}\n**Ссылки по теме:** \n[Ребекка Мёрфи — Использование объектов для организации вашего кода][1] \n[Стоян Стефанов — 3 способа определения класса в JavaScript ][2] \n[Бен Алман — Разъяснения по литералам объектов (понятия JSON-объект не существует)][3] \n[Джон Резиг - Простое наследование в JavaScript][4]\n\n[1]: http://blog.rebeccamurphey.com/2009/10/15/using-objects-to-organize-your-code\n[2]: http://www.phpied.com/3-ways-to-define-a-javascript-class/\n[3]: http://benalman.com/news/2010/03/theres-no-such-thing-as-a-json/\n[4]: http://ejohn.org/blog/simple-javascript-inheritance/\n"
},
{
"path": "_includes/translation/rus/08_commonjs-modules.md",
"content": "\n\n\nВозможно, вы что-то слышали о [CommonJS][4] за последние пару лет. CommonJS — это\nдобровольная рабочая группа, которая проектирует, прототипирует и стандартизирует\nразличные JavaScript API. На сегодняшний день они ратифицировали стандарты для\nмодулей и пакетов — CommonJS определяют простой API для написания модулей,\nкоторые могут быть использованы в браузере с помощью тега `\n \n {% include analytics.html %}\n
![\"Fork](\"https://s3.amazonaws.com/github/ribbons/forkme_left_red_aa0000.png\")
![\"Creative](\"http://i.creativecommons.org/l/by/4.0/80x15.png\")
\n \n