\n \n
- \n \n
  - \n Change log\n
  \n
- \n I Part I - An AngularJS application\n
  - \n 1. Why? How? What?\n
    - \n 1.1 How this book is built\n
    - \n 1.2 Maturity Models Project\n
    - \n 1.3 Maturity Models source code\n
    - \n 1.4 Start with tests\n
    - \n 1.5 The power of Simple\n
    - \n 1.6 I really like Angular 1.x\n
    - \n 1.7 My Application Security Background\n
    - \n 1.8 Price of this book\n
    \n
  - \n 2. Maturity Models\n
    - \n 2.1 Data repositories\n
    - \n 2.2 Tests - API\n
    - \n 2.3 Tests - QA - Browser\n
    - \n 2.4 Tests - QA - Http\n
    - \n 2.5 Tests - QA - JsDom\n
    - \n 2.6 UI - Server-side\n
    - \n 2.7 Maturity Models - Features\n
    - \n 2.8 App structure\n
    - \n 2.9 Code - QA\n
    - \n 2.10 Code - UI - Angular\n
    - \n 2.11 Code - Web Services - API\n
    - \n 2.12 Tests - QA\n
    - \n 2.13 Tests - UI\n
    - \n 2.14 Adding an Controller\n
    \n
  - \n 3. Case-study: Adding a new API and View\n
    - \n 3.1 Adding Backend Service\n
    \n
  - \n 4. Angular-v1\n
    - \n 4.1 $digest\n
    - \n 4.2 $http\n
    - \n 4.3 $injector\n
    - \n 4.4 $scope and $rootScope\n
    - \n 4.5 $timeout\n
    - \n 4.6 Angular mocks\n
    - \n 4.7 Config\n
    - \n 4.8 Controllers\n
    - \n 4.9 Dependency Injection\n
    - \n 4.10 Directives\n
    - \n 4.11 Module\n
    - \n 4.12 Opinionated Angular\n
    - \n 4.13 Patches\n
    - \n 4.14 REPL from inspector\n
    - \n 4.15 Routes HTML 5 mode\n
    - \n 4.16 Routes\n
    - \n 4.17 Services\n
    - \n 4.18 Should angular 1.x be forked\n
    - \n 4.19 Simple 1 page Angular\n
    - \n 4.20 Template-Urls\n
    - \n 4.21 Testing Angular\n
    - \n 4.22 Two-way Model binding\n
    - \n 4.23 Why Angular 1x\n
    \n
  - \n 5. Technologies used\n
    - \n 5.1 Agile using Kanban WIP\n
    - \n 5.2 Bower\n
    - \n 5.3 CoffeeScript\n
    - \n 5.4 CSS\n
    - \n 5.5 D3\n
    - \n 5.6 Digital Ocean\n
    - \n 5.7 Docker-Hub\n
    - \n 5.8 Docker\n
    - \n 5.9 Electrium\n
    - \n 5.10 Foundation\n
    - \n 5.11 Git - Branches\n
    - \n 5.12 Git - Commits\n
    - \n 5.13 Git - Rebase\n
    - \n 5.14 Git - Submodules\n
    - \n 5.15 Git - Tags\n
    - \n 5.16 GitHub\n
    - \n 5.17 Gulp\n
    - \n 5.18 HTML\n
    - \n 5.19 JIRA\n
    - \n 5.20 JQuery\n
    - \n 5.21 Javascript\n
    - \n 5.22 Node - Express\n
    - \n 5.23 Node - Fluentnode\n
    - \n 5.24 JsDom\n
    - \n 5.25 Karma\n
    - \n 5.26 Mocha\n
    - \n 5.27 Morgan\n
    - \n 5.28 NPM\n
    - \n 5.29 PhantomJS\n
    - \n 5.30 Node modules\n
    - \n 5.31 Node - Supertest\n
    - \n 5.32 Node\n
    - \n 5.33 Open Source\n
    - \n 5.34 Pug\n
    - \n 5.35 WallabyJs\n
    - \n 5.36 WebStorm\n
    - \n 5.37 Docker Cloud\n
    - \n 5.38 Travis\n
    \n
  - \n 6. Development\n
    - \n 6.1 Code Formatting\n
    - \n 6.2 Continuous Deployment\n
    - \n 6.3 Fluent Asserts\n
    - \n 6.4 Issue Creation Strategy\n
    - \n 6.5 Risk Acceptance Strategy\n
    \n
  - \n 7. Testing\n
    - \n 7.1 5000% code coverage\n
    - \n 7.2 All tests pass, all the time\n
    - \n 7.3 App Actions via Chrome Bookmarks\n
    - \n 7.4 Be happy when tests fail\n
    - \n 7.5 Be happy with changes\n
    - \n 7.6 Code without looking at the app\n
    - \n 7.7 Create Test APIs and DSLs\n
    - \n 7.8 Good tests design is critical\n
    - \n 7.9 Minimum TDD requirement\n
    - \n 7.10 No limitations on test stack\n
    - \n 7.11 Perform demos using Automation\n
    - \n 7.12 Print tests for review\n
    - \n 7.13 Real code is simple\n
    - \n 7.14 Real-time Code coverage\n
    - \n 7.15 Real time test execution\n
    - \n 7.16 Run tests on all Commits of all Branches\n
    - \n 7.17 Security vulns are features\n
    - \n 7.18 WebStorm tests setup\n
    - \n 7.19 Write tests for all bugs\n
    - \n 7.20 Controlling dependencies\n
    - \n 7.21 Real world angular bugs\n
    \n
  - \n 8. Security Tests\n
    - \n 8.1 AngularJS Security\n
    - \n 8.2 A1 - Injection\n
    - \n 8.3 T11 - Denial of Service\n
    - \n 8.4 A2 - Broken Authentication\n
    - \n 8.5 A3 - Cross-site-scripting\n
    - \n 8.6 Accepting Risk\n
    - \n 8.7 Answer Security questions with (unit) Tests\n
    - \n 8.8 Attack surface changes breaks tests\n
    - \n 8.9 Create tools to Brute Force app\n
    - \n 8.10 Deadlines create pollution\n
    - \n 8.11 How to pentest this app\n
    - \n 8.12 Http Headers\n
    - \n 8.13 No security by obscurity\n
    - \n 8.14 OWASP Top 10\n
    - \n 8.15 Other vulns that need tests\n
    - \n 8.16 Pattern - Don’t care about security\n
    - \n 8.17 Pattern - Don’t use .html() method\n
    - \n 8.18 Pattern - Don’t use jQuery\n
    - \n 8.19 Pattern - Don’t use strings\n
    - \n 8.20 Pattern - Validate all input\n
    - \n 8.21 Pollution not Technical Debt\n
    - \n 8.22 Vulnerabilities by Design\n
    - \n 8.23 Pattern - Don’t use server-side templates\n
    \n
  - \n 9. GitHub\n
    - \n 9.1 Commits\n
    - \n 9.2 Images Copy and Paste\n
    - \n 9.3 Issues - Labels\n
    - \n 9.4 Issues\n
    - \n 9.5 Offline coding\n
    - \n 9.6 Online editor\n
    - \n 9.7 Pull Requests\n
    - \n 9.8 Pulse and Graphs\n
    - \n 9.9 Releases\n
    - \n 9.10 Todo’s Checklists\n
    - \n 9.11 Version Control\n
    - \n 9.12 WebHooks\n
    - \n 9.13 Wiki\n
    \n
  - \n 10. Future\n
    - \n 10.1 SAST Analysis\n
    \n
  \n
\n
\n Notes\n

Change log

\n\n

Here are the changes made (per version):

\n\n

\nv0.50 (Jun 2016)\n
- Major refactor where the book was split into two Parts\n
  - Part I - new content based on the Open Source project Matrity-Models
  - Part II - previous book content (the one based on my blog posts)
  \n
- removed leanpub-book-site as submodule
- added TravisCI build workflow (with files pushed to https://github.com/DinisCruz-Dev/Book_Practical_AngularJS_Build)
\n
\nv0.40 (Jan 2016)\n
- Added new local editor ui (from o2platform/leanpub-book-site repo) which provides
- a local site (using express) to preview content
- generation of Leanpub manuscript folder\nfrom a better formatted folder structure
- Fixed tons of content formatting issues and broken images
- Fixed issues:\n
  - Fix images in “AngularJS code editor using UI-Bootstrap and CodeMirror”
  \n
- This version doesn’t add or remove content (the main focus was on the refactoring and fixing of bad images)
\n
\nv0.30 (Aug 2014)\n
- Re-wrote the Introduction
- Added ‘AngularJS Books’ chapter (to Introduction)
\n
\nv0.20 (29 March 2014)\n
- updated Readme.md file to point to existing articles.
- renamed all content files to *.md (which make sense since they are Markdown files, and they look much better at GitHub) and gave them a name that is related to its current chapter
- new files: C0-Introduction/Table_of_contents.md
- created a GitHub-only ‘table of contents’ which links to all available chapters. Each chapter intro page also has the links for its child articles. Added some navigation links to the end of each article (to allow easy navigation when browsing the content in GitHub)
\n
\nv0.13 (16th March 2014)\n
- added new cover to eBook version
- lots of formatting changes to most chapters/posts (specialy on current source code samples)
- added leanpub attributes for: frontmatter, mainmatter, backmatter
- major rename of markdown file names to help to quickly see which file belongs to what chapter (see github repo)
\n
\nv0.12 (11th March 2014)\n
- fixed spellings
- fixed nested list in this change log (needs 4 spaces on line start)
- fixed use of sections in ‘Appendix Posts Details’
- created github repository for this book: https://github.com/DinisCruz/Book_Practical_AngularJS
\n
\nv0.11 (11th March 2014)\n
- Create the following main section: “Using AngularJS”, “KarmaJS”, “Firebase”, “Misc Tricks”, “IDEs”, “Troubleshooting”, “Appendices”
- Changed the order of the chapters (using the new sections created, instead of the original import structure (by month))
- Book configuration change to add page break for every section (i.e. blog post)
- Added this change log
- Created Git repo on local dropbox sync folder
- Added Appendix “Post’s Details”
\n
\nv0.10 (10th March 2014)\n
- First release of book with raw import from blogger posts (no formatting or editing done)
\n

\n\n\n

\nI Part I - An AngularJS application

\n\n

explain story of this Part I

\n\n

\n1. Why? How? What?

\n\n

explain the why, how and what of Part I

\n\n

\n1.1 How this book is built

\n\n

Content at github
Built using travis

\n\n

\n1.1.1 How to report an issue

\n\n

show GitHub flow to submit issues

\n\n

\n1.1.2 How to fix an problem

\n\n

for example a typo

\n\n

\n1.2 Maturity Models Project

\n\n

This is the project that I created when asked to do a full BSIMM mapping for a large UK Organization

\n\n

Having done a number of these mappings before …prob is scalability … which is why I needed to build a tool

\n\n

add links to BSIMM docs and mappings
add pics of using it

\n\n

\n1.3 Maturity Models source code

\n\n

add links to the multiple repos
instructions on how to run it locally\n
- or on Docker
\n

\n\n

\n1.4 Start with tests

\n\n

Key requirement for development
I don’t really like how in most books Testing is a 2nd (or 3rd) class citizen
My objective on this book is to always show test test first
I found that when you read a test first (i.e. before the code), you build a mental model of what the ‘real’ code should be doing (and it helps in understanding it)
There is a full section on Testing and the techniques I use
Every developer tests their code, the only question is if they are ephemeral ¹ (i.e don’t last) and repeatable
Tests are documentation and should be a source of truth for how the app works
Print tests on paper and review them

\n\n

\n1.4.1 Managers need to write tests

Since they have the technical ability to do so (and it is a waste of their skills if they only ‘manage’)

\n\n

\n1.4.2 Abusing the (unit) Test concept

\n\n

For me the ‘unit’ is whatever being tests

\n\n

My definition is if it can be executed with {link to Unit Test Frameworks at Wikipedia}, then is an Unit Test.

\n\n

I’ve started to use “(unit) Test” has a way to refer to Unit Tests (as a way to indicate that the ‘unit’ is different)

\n\n

\n1.5 The power of Simple

\n\n

Code needs to be simple
nothing to add, nothing to remove
refactoring until removing loses context and adds complexity
Simple doesn’t mean lack of ‘things’\n
- Microsoft made this mistake all the time
- One button apps can be really complex, and multiple-buttons app can be really simple
- the key is the Design of the experience (from coding, to testing, to usage)
\n

\n\n

\n1.6 I really like Angular 1.x

\n\n

not the most popular statement at the moment (June 2016)
Angular 1.5.6 is really mature and has all the key components I need
Alternatives bring more complexity (and yes power, but I’m not felling the need for that power)

\n\n

$\"\"$ ²

\n\n

\n1.7 My Application Security Background

\n\n

Although I have been a developer since the ZXSpectrum days (and Amiga, x86, x286, x486,….) my 10 year focus on AppSec makes me look at code differently

\n\n\n

\n\n\n

\n1.8 Price of this book

\n\n

This book has 6586 people who went through the checkout process at Leanpub, of those 6k users, only 149 of them paid for the book.

\n\n

This was possible because I allowed the price of the book to be zero. Since the book was (and still isn’t) complete, I was not comfortable demanding that the book had to be paid. Note that the first version of the book was mainly made of content from my own blog. I was not able to update it regularly, which means that the book is still not ‘officially’ done/released.

\n\n

I also like the idea that knowledge should be shared, and if there is somebody out that wan’t the info but is not able to afford it, that person should have access to i.

\n\n

Another way of looking at this, is that I have been able to start publishing a book on a topic I am interested in, find potential readers, and get paid (a bit) while the book is being created (which btw, is more than most self-publishing authors)

\n\n

The reality is that this experiment allowed me to really understand how to write and publish books (namely gaining the confidence to do it)

\n\n

An interesting angle, is that it is better to have 6k potential buyers (that have shown interest in the book), than 500 buyers (who will not buy the book again). As it stands I have a direct connection to the readers who are interested in AngularJS and like what I’m trying to do with this book.

\n\n

For reference, as of 17 June 2016, this book had 6586 readers, with 149 paid readers and $638.75 royalty (note that Leanpub only takes about 20% of the price paid)

\n\n\n

\n\n\n

\n1.8.1 Adding paid version which included Printed book

\n\n

I really like printed books (they are a better technology to read books), so I recently added an experiment to also sell them on the Leanpub website.

\n\n\n

\n\n\n

At the moment I will send the book directly to the buyer, which will need revising if there are too many buyers (this would be a nice problem to have)

\n\n

\n1.8.2 Moving to only paid version

\n\n

The new release of the book will include a website will all the content (in an better design/format then the website provided by Leanpub). All content is available for free at GitHub and I’m also exploring the idea to publish the released pdf into GitHub as releases.

\n\n

When this is in place, I’m thinking (for this book) to move away from the minimum zero price range, and maybe set it to $10, $20 or even $30 (nice thing of Leanpub is that I can experiment with it)

\n\n

\n1.8.3 Not much feedback from readers

\n\n

One area that I would like to see more is feedback from readers. I do try to make it easier to provide such feedback (comments on Leanpub website, GitHub issues, direct email), but so far it has not worked very well.

\n\n

\n2. Maturity Models

\n\n

This is the application that is being used on this Part I

\n\n

\n2.1 Data repositories

\n\n

explain how they work
why there were created
option to support confidential data (not pushed into main public Maturity-Models repo)

\n\n

\n2.1.1 Current structure of Data repositories

\n\n

BSIMM-Graphs-Data
Maturity-Models-AppSec
Other
special folder

\n\n

\n2.2 Tests - API

\n\n

These are the apis used by the tests (i.e. this is an Test API). The idea is to wrap way the app is accessed from the tests, so that they (the tests) don’t need to worry about how to execute the request (i.e. they just handle the answer)

\n\n

At the moment there are 2 ways to access the application

\n\n

\nHttp - Using direct http requests (the bare-to-the-metal approach). This approach is good for speed. Works really well for API calls and pages that don’t need ‘angular state’ (for example testing page components)
\nJsDom - Using node’s jsdom which creates a simulated DOM that is actually able to invoke Angular’s digest. This has the advantage that we have all the power of Node’s apis when analyzing the Angular objects. Good for tests that need to have an Angular Digest working
\nBrowser - Using Chrome (i.e. Electron, where the full site is accessed and invoked. This has the advantage that we are testing the real app with all dependencies enabled. Good for looking down the user experience and confirming that latest changes (or refactoring) has not modified the user experience

\n\n

\n2.3 Tests - QA - Browser

\n\n

\n2.3.1 Browser-API.coffee

This is the API that allows access Chrome

\n\n

\n2.4 Tests - QA - Http

\n\n

\n2.4.1 Http_API.coffee

\n\n

This is the API that allows access via direct http requests, and has the following methods: GET, $GET, GET_Json, server_Url

\n\n

 1 cheerio    = require 'cheerio'\n 2 Travis_API = require './Travis-API'\n 3 \n 4 class Http_API\n 5 \n 6   constructor: ->\n 7     @.travis_API = new Travis_API()\n 8 \n 9   GET: (path, callback)=>\n10     full_Url = @.travis_API.server_Url() + path\n11     full_Url.GET callback\n12 \n13   $GET: (path, callback)=>\n14     @.GET path, (data)=>\n15       callback cheerio.load data\n16 \n17   GET_Json: (path, callback)=>\n18     full_Url = @.travis_API.server_Url() + path\n19     full_Url.json_GET callback\n20 \n21   server_Url: ()=>\n22     @.travis_API.server_Url()\n23 \n24 module.exports = Http_API\n

\n\n\n\n

\n2.5 Tests - QA - JsDom

\n\n

\n2.5.1 JsDom_API.coffee

\n\n

This is the API that allows access via JsDom, and has the following methods: $app, $http, $scope, open, server_Url, wait_No_Http_Requests

\n\n

 1 Travis_API  = require './Travis-API'\n 2 jsdom       = require('jsdom')\n 3 \n 4 class JsDom_API\n 5 \n 6   constructor: ->\n 7     @.travis_API = new Travis_API()\n 8     @.$          = null\n 9     @.document   = null\n10     @.window     = null\n11     @.http       = null\n12     @.on_Created = null\n13     @.on_Load    = null\n14 \n15   $app: ()=>\n16     element = @.window.document.querySelector('.ng-scope')\n17     @.window.angular.element(element)\n18 \n19   $http: ()=>\n20     @.$app().injector().get('$http')\n21 \n22   $scope: ()=>\n23     @.$app().scope()\n24 \n25   open: (path, callback)=>\n26     if typeof(path) is 'function'\n27       callback = path\n28       path     = ''\n29     if not path.starts_With('/')\n30       path = '/' + path\n31 \n32     url = @.server_Url() + path\n33     config =\n34       url: url\n35       features :\n36         FetchExternalResources  : [\"script\"]\n37         ProcessExternalResources: [\"script\"]\n38         SkipExternalResources   : true\n39       created: ()=> @.on_Created?()\n40       onload : ()=> @.on_Load?()\n41       done   : (err, window)=>\n42         throw err if err\n43         @.window = window\n44         @.$      = window.$\n45         callback @.$, @.window\n46 \n47     jsdom.env config\n48 \n49   server_Url: ->\n50     @.travis_API.server_Url()\n51 \n52   wait_No_Http_Requests: (next)=>\n53     if @.$http().pendingRequests.length > 0\n54       5.wait =>\n55         @.wait_No_Http_Requests(next)\n56     else\n57       next()\n58 \n59 module.exports = JsDom_API\n

\n\n\n\n

\n2.6 UI - Server-side

\n\n

explain how initially there was a ‘pug based’ server-side rendering of HTML

\n\n

\n2.7 Maturity Models - Features

\n\n

Here are the current feature set of the application

\n\n

Home page

\n\n\n

\n\n\n

Projects

\n\n\n

\n\n\n

Teams

\n\n\n

\n\n\n

Team A - View

\n\n\n

\n\n\n

Team A - Edit

\n\n\n

\n\n\n

Team A - Raw

\n\n\n

\n\n\n

All Data

\n\n\n

\n\n\n\n

\n\n\n

API

\n\n\n

\n\n\n

API - /file/get/team-A

\n\n\n

\n\n\n

API - /file/get/team-A?pretty

\n\n\n

\n\n\n

API - routes/list-raw

\n\n\n

\n\n\n

API - routes/list

\n\n\n

\n\n\n

\n2.8 App structure

\n\n

This is the current App structure

\n\n

API

\n\n\n

\n\n\n

\n\n\n

Data

\n\n\n

\n\n\n

\n\n\n

\n2.9 Code - QA

\n\n

This is the site with the QA tests.

\n\n

These are tests designed to be executed on a live version of the site , either at localhost (while dev), or pre-prod (current using DigitalOcean)

\n\n

Browser automation is done using Electrium

\n\n

\n\n\n

\n\n\n

/src

\n\n\n

\n\n\n

/test

\n\n\n

\n\n\n

/test-performance

\n\n\n

\n\n\n

.travis.yml

\n\n

Need to add display so that the browser automation works ok

\n\n

1 language: node_js\n2 \n3 node_js:\n4   - \"5\"\n5 \n6 before_script:\n7   - \"export DISPLAY=:99.0\"\n8   - \"sh -e /etc/init.d/xvfb start\"\n9 #  - sleep 3\n

\n\n\n\n

package.json

\n\n

 1 {\n 2   \"name\": \"bsimm-graphs-qa\",\n 3   \"version\": \"0.0.1\",\n 4   \"description\": \"\",\n 5   \"main\": \"index.js\",\n 6   \"scripts\": {\n 7     \"test\": \"mocha --compilers coffee:coffee-script/register -- recursive test\"\n 8   },\n 9   \"author\": \"Dinis Cruz\",\n10   \"license\": \"ISC\",\n11   \"dependencies\": {\n12     \"cheerio\": \"^0.20.0\",\n13     \"electrium\": \"0.0.7\",\n14     \"fluentnode\": \"^0.6.1\",\n15     \"mocha\": \"^2.5.2\"\n16   },\n17   \"devDependencies\": {\n18     \"async\": \"^1.5.2\",\n19     \"jsdom\": \"^9.2.1\"\n20   }\n21 }\n

\n\n\n\n

wallaby.js

\n\n

This is the only wallaby file that I don’t execute all tests at the same time (with browser/network automation it is very easy to create long running and performance intensive tests)

\n\n

 1 module.exports = function ( ) {\n 2     return {\n 3         files: [\n 4             { pattern: 'src/**/*.coffee'}\n 5         ],\n 6 \n 7         tests: [\n 8             //'test/**/*.coffee'\n 9             'test/jsdom/**/*.coffee'\n10             //'test/http/**/*.coffee'\n11         ],\n12 \n13         testFramework: 'mocha',\n14 \n15         env: {\n16             type: 'node'\n17         },\n18         workers: {\n19             recycle: true\n20         }\n21     };\n22 };\n

\n\n\n\n

\n2.10 Code - UI - Angular

\n\n

This is the submodule probject that contains the AngularJS based UI

\n\n

There are no server side generate pages

\n\n

\n\n\n

\n\n\n

/src

\n\n\n

\n\n\n

/test

\n\n\n

\n\n\n

/views

\n\n\n

\n\n\n

.travis.yml

\n\n

 1 language: node_js\n 2 \n 3 node_js:\n 4   - \"5\"\n 5 \n 6 before_script:\n 7 \n 8   - npm install -g bower\n 9   - bower install\n10   - npm install -g gulp\n11   - gulp\n12   - ls -la\n

\n\n\n\n

bower.json

\n\n

 1 {\n 2   \"name\": \"maturity-models-ui\",\n 3   \"description\": \"Maturity Models UI\",\n 4   \"main\": \"index.js\",\n 5   \"authors\": [\n 6     \"Dinis Cruz\"\n 7   ],\n 8   \"license\": \"ISC\",\n 9   \"homepage\": \"https://github.com/DinisCruz/Maturity-Models-UI\",\n10   \"moduleType\": [],\n11   \"dependencies\": {\n12     \"d3\": \"~3.5.16\",\n13     \"radar-chart-d3\": \"~1.2.1\",\n14     \"foundation\": \"^5.5.3\",\n15     \"angular\": \"^1.5.6\",\n16     \"angular-mocks\": \"^1.5.6\",\n17     \"chai\": \"^3.5.0\",\n18     \"angular-route\": \"^1.5.6\"\n19   }\n20 }\n

\n\n\n\n

gulpfile.coffee

\n\n

 1 gulp          = require 'gulp'\n 2 coffee        = require 'gulp-coffee'\n 3 concat        = require 'gulp-concat'\n 4 pug           = require 'gulp-pug'\n 5 plumber       = require 'gulp-plumber'\n 6 templateCache = require('gulp-angular-templatecache');\n 7 \n 8 \n 9 source_Files  = './src/**/*.coffee'\n10 pug_Files     = './views/**/*.pug'\n11 css_Files     = './views/css/**/*.css'\n12 \n13 html_Folder   = './.dist/html'\n14 js_Folder     = './.dist/js'\n15 css_Folder    = './.dist/css'\n16 \n17 gulp.task 'compile-pug', ()->\n18   gulp.src pug_Files\n19       .pipe plumber()\n20       .pipe pug()\n21       .pipe gulp.dest html_Folder\n22 \n23 gulp.task 'compile-coffee', ()->\n24   gulp.src(source_Files)\n25       .pipe plumber()\n26       .pipe coffee {bare: true}\n27       .pipe concat js_Folder + '/angular-src.js'\n28       .pipe gulp.dest '.'\n29 \n30 gulp.task 'templateCache', ['compile-pug'], ()->\n31   gulp.src html_Folder + '/**/*.html'\n32       .pipe templateCache( module: 'MM_Graph' )\n33       .pipe gulp.dest js_Folder\n34 \n35 gulp.task 'concat-css', ()->\n36   gulp.src(css_Files)\n37       .pipe concat css_Folder + '/app.css'\n38       .pipe gulp.dest '.'\n39 \n40 gulp.task 'watch', ['compile-coffee', 'compile-pug', 'templateCache', 'concat-css'], ()->\n41   gulp.watch source_Files, ['compile-coffee']\n42   gulp.watch pug_Files   , ['compile-pug', 'templateCache']\n43   gulp.watch css_Files   , ['concat-css']\n44 \n45 gulp.task 'default', ['compile-coffee','compile-pug', 'templateCache', 'concat-css'], ()->\n

\n\n\n\n

karma.config.js

\n\n

 1 module.exports = function(config) {\n 2     config.set({\n 3         basePath: '',\n 4         frameworks: ['mocha'],\n 5 \n 6         files: [\n 7             'bower_components/angular/angular.js',\n 8             'bower_components/angular-route/angular-route.js',\n 9             'bower_components/angular-mocks/angular-mocks.js',\n10             'bower_components/jquery/dist/jquery.min.js',\n11             'node_modules/chai/chai.js',\n12 \n13             '.dist/js/angular-src.js',\n14             '.dist/js/templates.js',\n15 \n16             'test/**/*.coffee'\n17         ],\n18         exclude       : [ ],\n19         preprocessors : {\n20             'test/**/*.coffee': ['coffee'],\n21         },\n22         reporters     : ['progress'],\n23         port          : 9876,\n24         colors        : true,\n25         logLevel      : config.LOG_INFO,\n26         autoWatch     : true,\n27         browsers      : ['PhantomJS'],\n28         singleRun     : true\n29     })\n30 };\n

\n\n\n\n

package.json

\n\n

 1 {\n 2   \"name\": \"maturity-models-ui\",\n 3   \"version\": \"0.0.1\",\n 4   \"description\": \"AngularJs UI for Node application to help managing Maturity Models\",\n 5   \"main\": \"index.js\",\n 6   \"directories\": {\n 7     \"test\": \"test\"\n 8   },\n 9   \"scripts\": {\n10     \"test\": \"node_modules/.bin/karma start karma.conf.js\"\n11   },\n12   \"repository\": {\n13     \"type\": \"git\",\n14     \"url\": \"git+https://github.com/DinisCruz/Maturity-Models-UI.git\"\n15   },\n16   \"author\": \"DinisCruz\",\n17   \"license\": \"ISC\",\n18   \"bugs\": {\n19     \"url\": \"https://github.com/DinisCruz/Maturity-Models-UI/issues\"\n20   },\n21   \"homepage\": \"https://github.com/DinisCruz/Maturity-Models-UI#readme\",\n22   \"devDependencies\": {\n23     \"chai\": \"^3.5.0\",\n24     \"coffee-script\": \"^1.10.0\",\n25     \"gulp\": \"^3.9.1\",\n26     \"gulp-angular-templatecache\": \"^1.8.0\",\n27     \"gulp-coffee\": \"^2.3.2\",\n28     \"gulp-plumber\": \"^1.1.0\",\n29     \"gulp-pug\": \"^3.0.3\",\n30     \"karma\": \"^0.13.22\",\n31     \"karma-coffee-preprocessor\": \"^1.0.0\",\n32     \"karma-mocha\": \"^1.0.1\",\n33     \"karma-phantomjs-launcher\": \"^1.0.0\",\n34     \"mocha\": \"^2.5.3\",\n35     \"phantomjs\": \"^2.1.7\",\n36     \"phantomjs-prebuilt\": \"^2.1.7\",\n37     \"supertest\": \"^1.2.0\"\n38   }\n39 }\n

\n\n\n\n

wallaby.coffee

\n\n

 1 module.exports = (wallaby)->\n 2   #console.log wallaby\n 3 \n 4   just_Load = (file)->\n 5     return { pattern: file, instrument: false, load: true, ignore: false }\n 6   config =\n 7     files : [\n 8       just_Load 'bower_components/angular/angular.js'\n 9       just_Load 'bower_components/angular-route/angular-route.js'\n10       just_Load 'bower_components/angular-mocks/angular-mocks.js'\n11 \n12       just_Load 'bower_components/jquery/dist/jquery.min.js'\n13 \n14       # weird bug where chai will load from node_modules but not from bower_components\n15       #{pattern: 'bower_components/chai/chai.js', instrument: true},\n16       just_Load  'node_modules/chai/chai.js'\n17 \n18       './src/**/*.coffee'\n19       './.dist/js/templates.js'\n20 \n21     ]\n22     tests : [\n23       './test/**/*.coffee'\n24     ]\n25 \n26     bootstrap:  ()->\n27       window.expect = chai.expect;\n28 \n29   testFramework: 'mocha'\n30 \n31   return config\n

\n\n\n\n

wallaby.js

\n\n

1 require('coffee-script/register')\n2 \n3 module.exports = require('./wallaby.angular.coffee')\n

\n\n\n\n

\n2.11 Code - Web Services - API

\n\n

This is the node app which provides the web services consumed by the AngularJS front end (I’m not going to into much detail about this app, since this is a book about AngularJS not Node :) )

\n\n

\n\n\n

\n\n\n

/data

\n\n\n

\n\n\n

/src

\n\n\n

\n\n\n

/test

\n\n\n

\n\n\n

.travis.yml

\n\n

 1 sudo: required\n 2 services:\n 3   - docker\n 4 \n 5 language: node_js\n 6 \n 7 node_js:\n 8   - \"5\"\n 9 \n10 git:\n11     submodules: false\n12 \n13 env:\n14   global:\n15     - secure: \"UnkjM...slVDl+NOBo=\"\n16     - secure: \"F2TFY...71tNyPFyEQ=\"\n17     - secure: \"eWiQ3...12PYxYF0FY=\"\n18 \n19 \n20 before_install:\n21     - cat .gitmodules\n22     - sed -i 's/git@github.com:/https:\\/\\/github.com\\//' .gitmodules\n23     - cat .gitmodules\n24     - git submodule update --init --recursive\n25 \n26 before_script:\n27 \n28   - cd ui\n29   - npm install\n30   - npm install -g bower\n31   - npm install -g gulp\n32   - bower install\n33   - gulp\n34   - cd ..\n35 \n36 \n37 script:\n38   - echo \">>>>> Running core tests<<<<<\"\n39   - npm test\n40   - echo \">>>>> Running UI tests<<<<<\"\n41   - cd ui\n42   - npm test\n43   - cd ..\n44 \n45 \n46 after_success:\n47 \n48   - echo \">>>>> Updating Dev fork <<<<<\"\n49   - git remote add upstream https://DinisCruz-Dev:$git_pwd@github.com/DinisCruz-Dev/Maturity-Models.git\n50   - git push -f upstream\n51 \n52   - echo \">>>>> Building DOCKER IMAGE and pushing it go Docker Hub <<<<<\"\n53   - echo 'building docker image'\n54   - docker images\n55   - docker build -t diniscruz/maturity-models .\n56   - docker images\n57   - docker login -e $DOCKER_EMAIL -u $DOCKER_USER -p $DOCKER_PASS\n58   - docker push diniscruz/maturity-models\n59 \n60   - echo \">>>>> Cloning Maturity-Models-QA, adding extra commit and pushing it to Maturity-Models-Dev for  <<<<<\"\n61   - cd ..\n62   - git clone https://github.com/DinisCruz/Maturity-Models-QA.git\n63   - cd Maturity-Models-QA\n64   - git remote add upstream https://DinisCruz-Dev:$git_pwd@github.com/DinisCruz-Dev/Maturity-Models-QA.git\n65 \n66   - git config --global user.email \"bot@travis.com\"\n67   - git config --global user.name \"Travis Bot\"\n68 \n69   - git log -n5 --pretty=oneline > travis-git-log.txt\n70   - git add .\n71   - git commit -m \"Comming files for $(git rev-parse HEAD)\"\n72   - git push -f upstream master\n

\n\n\n\n

Dockerfile

\n\n

 1 FROM    node\n 2 \n 3 RUN \tgit clone https://github.com/DinisCruz/Maturity-Models.git\n 4 WORKDIR Maturity-Models\n 5 RUN     sed -i 's/git@github.com:/https:\\/\\/<user>:<token>@github.com\\//' .gitmodules\n 6 RUN     git submodule init\n 7 RUN     git submodule update\n 8 RUN     git pull origin master\n 9 RUN     npm install --quiet\n10 \n11 WORKDIR ui\n12 RUN     npm install --quiet\n13 RUN     npm install --quiet -g bower\n14 RUN     npm install --quiet -g gulp\n15 RUN     bower --allow-root install\n16 RUN     gulp\n17 WORKDIR ..\n18 \n19 RUN     pwd\n20 RUN     mkdir logs              # node app was failing to create this folder\n21 RUN     ls -la\n22 \n23 CMD     npm start\n24 \n25 \n26 # travis builds image and deploys to docker hub at: diniscruz/maturity-models\n27 # build manually using: docker build -t diniscruz/maturity-models .\n

\n\n\n\n

package.json

\n\n

 1 {\n 2   \"name\": \"maturity-models\",\n 3   \"version\": \"0.0.1\",\n 4   \"description\": \"Maturity Models\",\n 5   \"main\": \"server.js\",\n 6   \"scripts\": {\n 7     \"test\": \"node ./node_modules/mocha/bin/mocha --compilers coffee:coffee-script/register --recursive -R list\",\n 8     \"start\": \"node server.js \"\n 9   },\n10   \"repository\": {\n11     \"type\": \"git\",\n12     \"url\": \"git+https://github.com/DinisCruz/Maturity-Models.git\"\n13   },\n14   \"author\": \"Dinis Cruz\",\n15   \"license\": \"ISC\",\n16   \"bugs\": {\n17     \"url\": \"https://github.com/DinisCruz/Maturity-Models/issues\"\n18   },\n19   \"homepage\": \"https://github.com/DinisCruz/Maturity-Models#readme\",\n20   \"engines\": {\n21     \"node\": \"5.3.0\"\n22   },\n23   \"dependencies\": {\n24     \"async\": \"^1.5.2\",\n25     \"body-parser\": \"^1.15.1\",\n26     \"cheerio\": \"^0.20.0\",\n27     \"coffee-script\": \"^1.10.0\",\n28     \"d3\": \"^3.5.16\",\n29     \"express\": \"^4.13.4\",\n30     \"express-load\": \"^1.1.15\",\n31     \"file-stream-rotator\": \"0.0.6\",\n32     \"fluentnode\": \"*\",\n33     \"mocha\": \"^2.4.5\",\n34     \"morgan\": \"^1.7.0\",\n35     \"pug\": \"2.0.0-beta2\",\n36     \"serve-index\": \"^1.7.3\"\n37   },\n38   \"devDependencies\": {\n39     \"supertest\": \"^1.2.0\"\n40   }\n41 }\n

\n\n\n\n

wallaby.js

\n\n

 1 module.exports = function () {\n 2     return {\n 3         files: [\n 4             'src/**/*.coffee',\n 5             'views/**/*.pug',\n 6             { pattern: 'data/**/*'              , instrument: false, load: false, ignore: false },\n 7         ],\n 8 \n 9         tests: [\n10             'test/**/*.coffee'\n11         ],\n12 \n13         env: {\n14             type: 'node'\n15         }\n16     };\n17 };\n

\n\n\n\n

\n2.12 Tests - QA

\n\n

The QA tests are split into two areas test and test-performance

\n\n\n

\n\n\n

At the moment the main difference is that the test-performance contains:\n - tests that take long to run\n - tests that test the QA test APIs (Http-API, JsDom-API and Browser_API)

\n\n

The idea is that the test should run quickly (i.e. sub second) which excludes any test that is stable but takes longer. This also makes the test tests wallabyjs friendly (i.e. I can run those tests and get real-time feedback).

\n\n

Here is the test execution (in 552ms):

\n\n\n

\n\n\n

Here is the test-performance execution (in 7s 33ms):

\n\n\n

\n\n\n

\n2.13 Tests - UI

\n\n

These are the UI tests which execute using Karma

\n\n\n

\n\n\n

\n2.14 Adding an Controller

\n\n

Once we have the Data-Project we need to expose it via an Controller (called API-Project)

\n\n

Here is the test

\n\n

 1 Api_Project = require '../../src/controllers/Api-Project'\n 2 \n 3 describe 'controllers | Api-Project', ->\n 4   api_Project = null\n 5 \n 6   before ->\n 7     using new Api_Project(), ->\n 8       api_Project = @\n 9 \n10   it 'constructor', ->\n11     using api_Project, ->\n12       @.constructor.name.assert_Is 'Api_Project'      \n13       @.data_Project.constructor.name.assert_Is 'Data_Project'\n14       @.router.assert_Is_Function()\n15 \n16   it 'add_Routes', ()->\n17     using new Api_Project(), ->\n18       @.add_Routes()\n19       @.router.stack.assert_Size_Is 1\n20 \n21   it 'list', ()->\n22     res =\n23       json: (data)->\n24         data.assert_Contains ['demo', 'appsec']\n25 \n26     using new Api_Project(), ->\n27       @.list(null, res)\n

\n\n\n\n

Here is the code

\n\n

 1 Data_Project  = require '../backend/Data-Project'\n 2 express       = require 'express'\n 3 \n 4 class Api_Project\n 5   constructor: (options)->\n 6     @.options      = options || {}\n 7     @.router       = express.Router()\n 8     @.data_Project = new Data_Project()\n 9 \n10   add_Routes: ()=>\n11     @.router.get '/project/list'     , @.list\n12     @\n13 \n14   list: (req,res)=>\n15     res.json @.data_Project.projects_Keys()\n16 \n17 module.exports = Api_Project\n

\n\n\n\n

\n3. Case-study: Adding a new API and View

\n\n

This is the story of an new feature that was added without browser being opened once:

\n\n\n

\n\n\n

Although the brief looks simple (add a way to list projects and expose it on an api and view) there were a lot of moving parts.

\n\n

In total there were 7x code and 9x test files created/modified:

\n\n

\nMaturity-Models\n
- src/backend/Data-Project.coffee
- src/controllers/Api-Project.coffee
- src/server/Server.coffee
- test/controllers/Api-Project.test.coffee
- test/server/Server.test.coffee
- test/supertest/Api-Project.super.test.coffee
\n
\nMaturity-Models-UI\n
- src/angular/Routes.coffee
- src/controllers/Projects-Controller.coffee
- src/services/MM_Graph_API.coffee
- views/pages/projects.page.pug
- test/angular/Routes.test.coffee
- test/controllers/Projects-Controller.test.coffee
- test/services/MM_Graph_API.test.coffee
- test/views/projects.page.test.coffee
\n
\nMaturity-Models-UI \n
- test/http/views/projects.page.http.coffee
- test/jsdom/views/projects.page.jsdom.coffee
\n

\n\n

\n3.1 Adding Backend Service

\n\n

First step is to add a backend service (called Data-Project) which will provide data about the current projects (in this case metadata about the project and its files).

\n\n

Here is the test

\n\n

 1 Data_Project = require '../../src/backend/Data-Project'\n 2 \n 3 describe 'backend | Data-Project', ->\n 4   data_Project = null\n 5 \n 6   beforeEach ->\n 7     data_Project = new Data_Project()\n 8 \n 9   it 'constructor',->\n10     using data_Project, ->\n11       @.constructor.name.assert_Is 'Data_Project'\n12       @.data_Path.assert_Contains 'data'\n13                  .assert_Folder_Exists()\n14 \n15   it 'project_Files', ->\n16     using data_Project, ->\n17       assert_Is_Null @.project_Files('aa')\n18       console.log @.project_Files()\n19 \n20   it 'projects', ->\n21     using data_Project, ->\n22       @.projects()._keys().assert_Contains('demo', 'appsec')\n23 \n24   it 'projects_Keys', ->\n25     using data_Project, ->\n26       @.projects_Keys().assert_Contains('demo', 'appsec')      \n

\n\n\n\n

Here is the code

\n\n

 1 class Data_Project\n 2   constructor: ()->\n 3     @.data_Path       = __dirname.path_Combine('../../data')\n 4     @.config_File     = \"maturity-model.json\"\n 5     @.default_Project = 'demo'\n 6 \n 7   project_Files: (project_Key)=>\n 8     key = project_Key ||  @.default_Project           # todo: refactor to make it clear\n 9     return using (@.projects()[key]),->\n10       project_Path = @.path\n11       if @.path\n12         values = []\n13         for file in project_Path.files_Recursive()\n14           if file.file_Extension() in ['.json', '.coffee']\n15             if file.not_Contains 'maturity-model'\n16               values.push file\n17         return values\n18       return null\n19 \n20   # returns a list of current projects (which are defined by a folder containing an maturity-model.json )\n21   projects: ()=>\n22     projects = {}\n23     for folder in @.data_Path.folders_Recursive()\n24       config_File = folder.path_Combine @.config_File\n25       if config_File.file_Exists()\n26         data = config_File.load_Json()\n27         if data and data.key\n28           projects[data.key] =\n29             path: folder\n30             data: data    \n31     projects\n32 \n33   projects_Keys: ()=>            \n34     @.projects()._keys()\n35 \n36 \n37 module.exports = Data_Project\n

\n\n\n\n

Here is what the development UI looks like (with wallaby confirming 100% code coverage)

\n\n\n

\n\n\n

\n4. Angular-v1

\n\n

\n4.1 $digest

\n\n

explain how it works

\n\n

\n4.2 $http

\n\n

used to make network/ajax requests
works differently in tests (requests will not be made)\n
- this is a great thing, and will push us into a great development environment
\n

\n\n

get

\n\n

1 file_List: (callback)=>\n2   url = \"/api/v1/file/list\"\n3   @.$http.get url\n4          .success callback\n

\n\n\n\n

post

\n\n

1 file_Save: (target,data, callback)=>\n2   url = \"/api/v1/file/save/#{target}?pretty\"\n3   @.$http.post(url, data)\n4          .success (data)->\n5             callback data\n

\n\n\n\n

\n4.3 $injector

\n\n

used to get depenencies injection references

\n\n

\n4.4 $scope and $rootScope

\n\n

used to hold data
show how to access it from Chrome inspector

\n\n

\n4.5 $timeout

\n\n

used to trigger code execution after the $digest loop has ended

\n\n

\n4.6 Angular mocks

\n\n

\n4.7 Config

\n\n

\n4.8 Controllers

\n\n

\n4.9 Dependency Injection

\n\n

explain how it works
Services and Testing use this a lot
add inject($...)-> code samples

\n\n

\n4.10 Directives

\n\n

\n4.11 Module

\n\n

explain what it is
how it is wire up
option to bootstrap it manually
all tests have it set up

\n\n

\n4.12 Opinionated Angular

\n\n

list cases where Angular forces a particular direction

\n\n

\n4.12.1 Http doesn’t work in tests

\n\n

\n4.13 Patches

\n\n

add get_Keys method to $templateUrls$\n(experiment with prototype method adding)

\n\n

\n4.14 REPL from inspector

\n\n

Every now and then there is the need to access the angular objects directly
List multiple ways to do that

\n\n

\n4.15 Routes HTML 5 mode

\n\n

why I preferred the use of multiple single-pages
better linking
better isolation
no ‘routes magic’ (which can be harder to debug)

\n\n

\n4.16 Routes

\n\n

Why I choose the simpler ng-route (vs the more mature and complex….)

\n\n

\n4.17 Services

\n\n

\n4.18 Should angular 1.x be forked

\n\n

time to move away from Google?
show the true power of open source
this should happen anyway since there are too many apps that use Angular 1.x that will not be migrated (specially since the migration path is not smooth)

\n\n

\n4.19 Simple 1 page Angular

\n\n

I like the fact that I’m able to create a 1 page working version of Angular that has all the components require to make angular work
nice path to evolve from the 1 page app, into more professional and mature app

\n\n

\n4.20 Template-Urls

\n\n

\n4.21 Testing Angular

\n\n

make references to the Testing section (later in the book)

\n\n

\n4.22 Two-way Model binding

\n\n

great to learn
use for debugging
{{…}} is a great syntax

\n\n

\n4.23 Why Angular 1x

\n\n

When I started this project I had the opportunity to review the current alternatives (as of 2016) to Angular 1.x

\n\n

\n4.23.1 Angular 2.0

\n\n

looked to complex

\n\n

\n4.23.2 React

\n\n

I like the virtual DOM and some of the JS constructs,but it didn’t seem to have the same components that I really like in Angular (directives, services, testing)

\n\n

\n5. Technologies used

\n\n

This section contains all the different technologies that I used in the development of the Maturity-Models project

\n\n

In alphabetical order

\n\n

[ ] Agile-using-Kandan-WIP
[ ] Bower\n
[ ] CoffeeScript\n
[ ] Css\n
[ ] D3\n
[ ] Digital Ocean\n
[ ] Docker\n
- [ ] Docker Hub\n
- [ ] Docker Cloud\n
\n
[ ] Electrium\n
[ ] Foundation\n
[ ] Git\n
- [ ] Git Branches\n
- [ ] Git Commits\n
- [ ] Git SourceTree\n
- [ ] Git Submodules\n
- [X] Git Tags\n
- [ ] Git Rebase\n
\n
[ ] GitHub\n
[ ] Gulp\n
[ ] Html\n
[ ] Javascript\n
[ ] Jira\n
[ ] JQuery\n
[ ] Node\n
- [ ] Node Express \n
- [ ] Node Fluentnode\n
- [ ] Node JsDom\n
- [ ] Node Karma\n
- [ ] Node Mocha\n
- [ ] Node Morgan\n
- [ ] Node Npm\n
- [ ] Node PhantomJS\n
- [ ] Node modules\n
- [ ] Node Supertest
\n
[ ] Open Source\n
[ ] Pug\n
[ ] Travis\n
[ ] WallabyJs\n
[ ] WebStorm\n

\n\n

idea: it would be quite interesting to do an infograph with these technologies and how they relate to each other\n - client vs server\n - development vs build

\n\n

\n5.1 Agile using Kanban WIP

\n\n

WIP = Work In Progress\n
- means focus is ensuring no bottle necks between development, testing, qa and deploy
- means that qa and deploy issues are solved asap (not at the end when they are massive)
- keep the size of the problem to be solved as small as possible
\n

\n\n

\n5.2 Bower

\n\n

\n5.3 CoffeeScript

\n\n

add why I like CoffeeScript
like to site and demos
put explanation of how I teach CoffeeScript (i.e. making Javascript simpler and simpler until there is nothing else to take out)
CoffeeScript patters http://coffeescript-cookbook.github.io/chapters/design_patterns/\n
- (add screentshot)
\n
clases https://colinmackay.scot/2012/03/17/classes-static-properties-and-inheritance-in-coffeescript/

\n\n

\n5.4 CSS

\n\n

no LESS or SASS (for now)

\n\n

\n5.5 D3

\n\n

used to create the radar diagrams
interesting issue at the moment to load the D3 dependencies (which need to be set in the main JS, {link GH issue})

\n\n

\n5.6 Digital Ocean

\n\n

show example of creating droplet
show integration with Docker-cloud
ssh into instance\n
- see docker deployments in Actions
- debug deployment problem
\n

\n\n

\n5.7 Docker-Hub

\n\n

\n5.8 Docker

\n\n

\n5.8.1 useful docker commands

\n\n

\n5.8.2 Docker vs VMs

\n\n

analogy of git vs svn

\n\n

\n5.9 Electrium

\n\n

where it is used
how it works
based on Electrium (node and V8 with the same event loop)
based on Spectron
not very stable at the moment

\n\n

\n5.10 Foundation

\n\n

used for CSS styles
12 grid view
buttons, labels, form inputs, tables

\n\n

\n5.11 Git - Branches

\n\n

explain how they are used on normal development and on ‘experiments’

\n\n

\n5.12 Git - Commits

\n\n

Using git commits has a constant backup
Use staging to create better commits

\n\n

\n5.13 Git - Rebase

\n\n

very powerful to create clean merges and Pull Requests
take a while to understand it (but it will make total sense when you get it)
needs to be done carefully and will require multiple experiments to get it right
make sure you have all changes committed and pushed before doing any rebase experiments\n
- I usually prefer to start with a clean clone of the repo and do the rebase there (into another branch which is used for the Pull Request)
\n

\n\n

\n5.14 Git - Submodules

\n\n

Using git submodules to separate repos\n
- isolate dependencies
- promote separation of concerns
- clean commits
\n

\n\n

\n5.15 Git - Tags

\n\n

Used to mark releases and versions.

\n\n

For example I used them in the Maturity-Models project to mark the version of the code-base that was used in the example.

\n\n

Here is what tags looks like in SourceTree (with also a branch called v0.1)

\n\n\n

\n\n\n

Since we have 4 main repos each need to have a tag (so that we can easily find the specific commit) Maturity-Models

\n\n\n

which we can browse in Github

\n\n\n

Note the ui @ c715df6 ref (above), which points to this commit (also marked with v0.1 tag)

\n\n\n

Which is also easily viewed in GitHub (note the url)

\n\n\n

Here is the BSIMM-Graphs-Data repo v0.1 tag

\n\n\n

And the Maturity-Models-QA repo v0.1 tag

\n\n\n

For other practical examples of using git tags see:\n* Adding Tags to TeamMentor Master repository\n* Syncing all releases to the same commit and Tag (for TeamMentor v3.4)

\n\n

\n5.16 GitHub

\n\n

This is such an important part of the workflow, which has its own section\n
- link to it
\n

\n\n

\n5.17 Gulp

\n\n

how it works
current Gulp tasks
gulp watch

\n\n

\n5.18 HTML

\n\n

best part is that I don’t use it
all HTML is generated by Pug
HTML generation is one of the most dangerous things that can be done
the main security responsibility that views have is to safely create HTML, and the best way to do it securely is to code in an environment where that happens by default (and one really has to work hard to create HTML insecurely)

\n\n

\n5.19 JIRA

\n\n

Used for RIKS management workflow
JIRA issues linked to GitHub using ‘links’

\n\n

\n5.20 JQuery

\n\n

the key of jQuery is NOT to use it (on the client)
Once we are coding in Angular, JQuery is not really needed, and its use is usually an indication of using angular wrong
on the testing side, that is a different, where there are a number of tests (for example JsDom based) that use it to check HTML elements

\n\n

\n5.21 Javascript

\n\n

used on both client (Angular) and server (Node) codebase
Compiled into it from CoffeeScript (using Gulp)
Could do the same for mocha but not needed
The client side Javascript is all concatenated into one file via GULP (note that lack of doing this is usually a sign of lack of CI (since this is quite easy to do, when one has an CI))

\n\n

\n5.22 Node - Express

\n\n

The web server used
list and explain the modules used
show code ‘Server’

\n\n

\n5.23 Node - Fluentnode

\n\n

what it is trying to do
show examples

\n\n

\n5.24 JsDom

\n\n

Used for QA tests, really powerful since it exposes the angular objects to Node (with all the power of node’s APIs)

\n\n

\n5.25 Karma

\n\n

used to test AngularJS code
created by Angular team, knows Angular well
compatible with Tests that are coded with Wallaby
both config files are very similar ({add screenshot showing them side-by-side})
uses PhanthomJS to run the tests

\n\n

\n5.26 Mocha

\n\n

\n5.27 Morgan

\n\n

for logging

\n\n

\n5.28 NPM

\n\n

Node Package Manager

\n\n

\n5.29 PhantomJS

\n\n

used by Karma

\n\n

\n5.30 Node modules

\n\n

node dependency management
folders inside node_modules
mention the crazy amount of dependencies that are installed\n
- show the diff between what is defined in package.json and what exists inside node_modules
\n

\n\n

\n5.31 Node - Supertest

\n\n

\n5.32 Node

\n\n

Javascript on the server side running on V8 engine
One user thread with one event loop (lots of threads on the background)\n
- very easy to create tons of parallel requests
\n

\n\n

\n5.33 Open Source

\n\n

\n5.34 Pug

\n\n

Pug ³ is an …
Great example of synergy between Development and Security
there should no XSS on this side (but we need proof of it)

\n\n

\n5.35 WallabyJs

\n\n

the key for TDD
real time (affected) test and code coverage in IDE
all types of tests are able to be coded using it

\n\n

\n5.36 WebStorm

\n\n

show my IDE setup
features used

\n\n

\n5.37 Docker Cloud

\n\n

Nodes

\n\n\n

\n\n\n

Repositories

\n\n\n

\n\n\n

Containers

\n\n\n

\n\n\n\n

\n\n\n\n

\n\n\n

This is really powerful, the ability to easily ssh into the deployed docker container

\n\n\n

\n\n\n

Services

\n\n\n

\n\n\n\n

\n\n\n\n

\n\n\n\n

\n\n\n

\n5.38 Travis

\n\n

used as part of CD (Continuous deto:
run tests
create docker image
push docker image to Docker Hub
push commit to forks (in one case with an extra commit)

\n\n

\n5.38.1 Travis badges

\n\n

nice way to keep an eye on the status of the builds

\n\n

\n5.38.2 travis reacting to an GitHub commit

\n\n\n

\n\n\n\n

\n\n\n\n

\n\n\n\n

\n\n\n

\n6. Development

\n\n

\n6.1 Code Formatting

\n\n

explain my current logic
show examples
for example https://twitter.com/DinisCruz/status/743063496754094080

\n\n

\n6.2 Continuous Deployment

\n\n

explain how it works
the multiple parts of it
add diagram

\n\n

\n6.3 Fluent Asserts

\n\n

from Fluentnode
tests tell a story of its development
makes tests easy to read

\n\n

\n6.4 Issue Creation Strategy

\n\n

explain the rule to create issues
in my view, the smaller the better
strategies to visualize them
add human analysis (i.e. metadata on how to read certain things)
for example the concept of closing issues that are risk accepted

\n\n

\n6.5 Risk Acceptance Strategy

\n\n

abusing the term ‘risk’
different types of ‘risks’:
- Security
- Bugs
- Hack
\n

\n\n

\n7. Testing

\n\n

\n7.1 5000% code coverage

\n\n

it is not about 100% code coverage
it is about using code coverage has a tool

\n\n

\n7.2 All tests pass, all the time

\n\n

no broken tests since they promote more broken tests
all tests passing is used to move from one CD stage into the next

\n\n

All test passing does not indicated that the app has no bugs or issues that need to resolved. It just means that the latest changes have not modified the behavior of the application (at the least the parts that were had not tests changed)

\n\n

\n7.2.1 Code changes without tests are random changes

\n\n

\n7.2.2 Alarm bells should ring on code changes that don’t break tests

\n\n

opportunity to understand blind spot and add test coverage for it

\n\n

\n7.3 App Actions via Chrome Bookmarks

\n\n

keys to help development and testing\n
- not that the devs should be using the browser, but when they do, they should not be clicking on things (like login, fill form, go to page X)
\n
The evolution of this is to create a custom browser extension that allows for more complex workflows (show example of REPL I created)

\n\n

\n7.4 Be happy when tests fail

\n\n

as long they are the tests you where expecting to fail, if not you have a problem

\n\n

\n7.5 Be happy with changes

\n\n

see changes as your competitive advantages
embrace changes, don’t view them as a bad thing

\n\n

\n7.6 Code without looking at the app

\n\n

Be able to code for long periods of time without actually opening the app (website or API) and looking at it

\n\n

switching context is very expensive

\n\n

\n7.7 Create Test APIs and DSLs

\n\n

which of course have to be tested

\n\n

\n7.8 Good tests design is critical

\n\n

tests are not 2nd class citizens
care and focus must exist on how they are created, maintained and designed

\n\n

\n7.9 Minimum TDD requirement

\n\n

without it, in my book, one will struggle to do TDD
TDD should be easy
High code coverage should be easy

\n\n

“My TDD environment for AngularJS”

\n\n\n

\n7.10 No limitations on test stack

\n\n

it is ok (and natural) to lock down the dev stack of an app (since the cost of upgrade can be high, with no significant benefit)
it is NOT ok to to limit the technologies and techniques that can be used for testing. Of course that the technologies used have to be solid, maintainable and scaleable; but one shouldn’t be locked by the tech stack of the main app
tests will not run on production
ok to have all sorts of technologies (specially if they can execute inside docker)
for example using .NET to test an Java app, Node to test an .NET app, Python to run QA tests via Selenium

\n\n

\n7.11 Perform demos using Automation

\n\n

great way to test drive Testing APIs and DSLs

\n\n

\n7.12 Print tests for review

\n\n

remarkable way to review code

\n\n

\n7.13 Real code is simple

\n\n

easy to read and maintain
it is OK(ish) to introduce some black magic and hacks on tests (as long as they are stable, easy to understand and maintain)

\n\n

\n7.14 Real-time Code coverage

\n\n

A requirement for TDD
WallabyJs does this perfectly
WebStorm workflow works, but it not very good (to many brain distractions and too slow)

\n\n

\n7.15 Real time test execution

\n\n

A requirement for TDD
WallabyJs does this perfectly
WebStorm with auto-execute (in seconds) is a decent compromise

\n\n

\n7.16 Run tests on all Commits of all Branches

\n\n

no broken tests

\n\n

\n7.17 Security vulns are features

\n\n

which also needs tests

\n\n

\n7.18 WebStorm tests setup

\n\n

How to run the multiple type of tests in WebStorm

\n\n

\n7.19 Write tests for all bugs

\n\n

great way to measure quality of test infrastructure
example the path of writing tests at all layers (from web interface to DB)
then do the reverse and build a reverse-tree with all affected code paths

\n\n

\n7.20 Controlling dependencies

\n\n

using testing

\n\n

Example of detection of jQuery update (which happened a couple days before that screenshot)

\n\n\n

\n\n\n

\n7.21 Real world angular bugs

\n\n

Upwork missing module

\n\n

this is the kind of bug that would had been picked up with TDD (where all code is tested and multiple levels)

\n\n

$\"\"$ \n⁴

\n\n

\n8. Security Tests

\n\n

\n8.1 AngularJS Security

\n\n

“Angular is pretty safe already, but if not used correctly with secure best practices, will still lead to insecure software” ⁵

\n\n

AngularJS as a client side framework, does not suffer from the same type of vulnerabilities that we usually see on web apps. By design, all assets are already on the client (i.e. the AngularJS app) and the attacker has full control over its execution environment (i.e. the browser).

\n\n

In fact if you see too many Authorization decisions on the Angular code, then that is usually an indication that the server side is not enforcing those roles. A key concept is that Client side validation, authentication and authorization are ‘usability features’, not ‘security features’

\n\n

The main security issue that needs to handled at the AngularJS layer is XSS (Cross-Site-Scripting), which is created by the insecure creation of HTML.

\n\n

AngularJS provides a lot of protections by default (specially when compared with other client side frameworks), but that doesn’t mean that it it not possible to create XSS (i.e. Javascript execution). For example I’ve seen plenty of XSS created by direct DOM manipulation (usually in directives or jQuery-like coding).

\n\n

Here are the patterns I like to following when coding AngularJS Apps:

\n\n

For me the key for AppSec is Assurance and that can only be done when we are able to Answer Security questions with (unit) Tests

\n\n

Here is what AngularJS says about Security:

\n\n\n

\n8.1.1 Online resources

\n\n

\nPresentations
\n
- \nAn Abusive Relationship with AngularJS, Dec 12 2015 , Mario Heiderich,
- \nng-owasp: OWASP Top 10 for AngularJS Applications, Jun 2015, Kevin Hakanson
- \nSecuring your AngularJS Application, Mar 2016, Philippe De Ryck
- \nAngularJS Security: defend your Single Page Application, Oct 2015, Carlo Bonamico
- \nSecure AngularJS, Dec 13, Asaf David, @asafdav
- \nJSMVCOMFG - To sternly look at JavaScript MVC and Templating Frameworks, Dec 2013, Mario Heiderich
\n
\nVideos\n
- \nSecurity with Angular JS, May 13, David Mosher
- \nAn Abusive Relationship with AngularJS, Mario Heiderich, btconfDUS 2016
\n
\nSecurity Research\n
- \nmustache-security - AngularJS.wiki which had this response\n
\n
\nArticles (note that these are done for ‘usability’)\n
\n

\n\n

\n8.2 A1 - Injection

\n\n

explain what it is, and how it can be created in the app
{this and the ‘Patterns’ section is kinda an ‘Security Coding Standards’ for the Maturity-Models app
Add example of the RCE vulns that existed in the app (and still exist)
A1 - Injection

\n\n

\n8.3 T11 - Denial of Service

\n\n

Point to T2 accepted risk issues

\n\n

\n8.4 A2 - Broken Authentication

\n\n

Point to T2 accepted risk issues
A2 - Broken Authentication

\n\n

\n8.5 A3 - Cross-site-scripting

\n\n

should not be possible
need assurance
how it can be proven that doesn’t exists\n
- things to do: add test that confirms that Pug’s raw html is not used (see if it possible to remove this feature from Pug (open issue asking for it))
\n
A3 - Cross-site-scripting

\n\n

\n8.5.1 AngularJS directives, the source of XSS vulns

\n\n

it is in directives where I’ve seen XSS vulns in Angular Apps

\n\n

\n8.5.2 Other ways to create XSS in Angular

\n\n

see http://blog.portswigger.net/2016/01/xss-without-html-client-side-template.html research

\n\n

\n8.6 Accepting Risk

\n\n

\n8.7 Answer Security questions with (unit) Tests

\n\n

(unit) Test must be used to answer security questions:\n
- for example how do you know if a particular endpoint or API is not vulnerable to XSS (you need proof)
- how does the angular code handle the data that is received from the server\n
  - what happens if the server is the once attacking the client AngularJS app
  - we need to know which server side provided data is not safely handled by the client-side code (ideally the answer is none, since the AngularJS app is able to safely handle all of it)
  \n
\n

\n\n

\n8.8 Attack surface changes breaks tests

\n\n

See https://twitter.com/DinisCruz/status/745582490186833921 and https://twitter.com/DinisCruz/status/745604432751136768?replies_view=true&cursor=ADCW1FXsWAo for pics of this in action

\n\n

\n8.9 Create tools to Brute Force app

\n\n

example of O2 Platform tool to push the app hard and to visualise it

\n\n

\n8.10 Deadlines create pollution

\n\n

End of Sprints, Delivery Deadlines or ‘where are we at’ presentations, can be a massive source of hacks and lost of focus, where compromises are made in the code, so that XYZ feature can be shown.

\n\n

There are numerous places where this has already happened in the Maturity-Models app, and (ideally) all have been captured in Quality issues (so that they can be addressed at a later stage).

\n\n

This is a good example of the ‘pollution’ created during development

\n\n

Yes, progress needs to exist and it is important to show the business owners what is going on, but, if too many compromises are made ‘just for the demo’, this can be a false economy (i.e. more expensive in the medium/long term)

\n\n

The good news is that High levels of code coverage allow the gaps created to be identified

\n\n

\n8.10.1 Â how long will it take to clean up the mess

\n\n

google exec for allowing research projects

\n\n

\n8.11 How to pentest this app

\n\n

find blind spots
don’t play game of security by obscurity

\n\n

\n8.12 Http Headers

\n\n

example of testing security of existing HTTP headers (the ones that exist and the ones missing)

\n\n

\n8.13 No security by obscurity

\n\n

not playing that game
all code is available on GitHub
all security issues are mapped

\n\n

\n8.14 OWASP Top 10

\n\n

link to owasp.org page
explain what it is
every app needs to have an OWASP Top 10 that explains how to create them (an Top 10 vuln)

\n\n

\n8.15 Other vulns that need tests

\n\n

put list here (with link to Respective GitHub issue)

\n\n

\n8.16 Pattern - Don’t care about security

\n\n

the best model is one is able to code without carrying about security\n
- i.e. it is very hard if not impossible to create an security issue without breaking a test
\n

\n\n

\n8.17 Pattern - Don’t use .html() method

\n\n

The .html() is really evil and problematic
it should not be used since it implies that DOM objects are being created in an insecure way
when data needs to be put inside an element .text() needs to be used.
attributes have to be set using attribute’s setters

\n\n

\n8.18 Pattern - Don’t use jQuery

\n\n

on code not on tests
jquery promotes hacking the DOM which is always a bad thing
logic is that if we can’t do something with Angular apis and need jquery, something is wrong with approach taken
there should be very little (if not not none) direct DOM manipulation

\n\n

\n8.19 Pattern - Don’t use strings

\n\n

strings are really dangerous beasts
no need for 4Gbs of unicode variables
use classes and strongly typed objects
this is one area where there is still some work to do (and refactoring)

\n\n

\n8.20 Pattern - Validate all input

\n\n

show techniques and examples
show vuln that exists (and existed) in Maturity-Models projects
Regexs are a great way to do this (but one has to be careful not to create DoS situations)

\n\n

\n8.21 Pollution not Technical Debt

\n\n

pollution is a much better analogy

\n\n

\n8.22 Vulnerabilities by Design

\n\n

list the current security issues that the app has (either by design or as features)

\n\n

\n8.23 Pattern - Don’t use server-side templates

\n\n

Don’t mix server side and client side templates … Most HTML encoders and frameworks leave {{}} alone\n⁶

\n\n

there should be a clean ‘air-gapped’ separation between client side code (Angular based) and service side code (NodeJS REST based)
all data transfers between client and server is done via AJAX calls (using AngularJS services)
all content loaded from server is static (AngularJS templateUrl, javascript, css, images)
there should be no server-side templates, dynamic generated content or (even worse) dynamic creation of javascript blocks (with data injected into it using string concats/transclusion)\n
- this actually existed in the first versions of the Maturity Models project, where there were a number of html pages that were dynamically generated from jade templates (see images below)
- part of the move to angular was to avoid the inevitable complexity and security issues of handling user data (in this case the BSIMM mappings)
\n

\n\n\n

\n\n\n\n

\n\n\n

this separation of concerns dramatically simplifies the testing of both client and server code
One of the security issues that this move prevents is the {{ }} injection that can occur in AngularJS code generated on the server side\n
- the injection blind-spot is caused by the fact that the chars { } | ( ) [ ] = , . are not usually escaped, but are very useful when writing Javascript exploits (see jsfuck for an example of how crazy Javacript can be).
- add reference to research on this topic that exists on the AngularJs-security.md page
\n

\n\n

\n9. GitHub

\n\n

it is such an important part of the workflow that it deserves a separate section

\n\n

\n9.1 Commits

\n\n

GitHub Commits

\n\n

\n9.2 Images Copy and Paste

\n\n

for example the workflow that I have when adding images to this book
see http://blog.diniscruz.com/2012/04/solution-to-copy-and-paste-images-into.html

\n\n

\n9.3 Issues - Labels

\n\n

\n9.4 Issues

\n\n

\n9.5 Offline coding

\n\n

how git and github support it

\n\n

\n9.6 Online editor

\n\n

to edit code and documentation
all changes will trigger a build and deployment

\n\n

\n9.7 Pull Requests

\n\n

PRs for short

\n\n

\n9.8 Pulse and Graphs

\n\n

show examples of what they look like

\n\n

\n9.9 Releases

\n\n

\n9.10 Todo’s Checklists

\n\n

small thing that can make a big difference

\n\n

\n9.11 Version Control

\n\n

What git is all about
everything is on version control (all source files, diagrams, images, etc..)

\n\n

\n9.12 WebHooks

\n\n

how the travis magic works

\n\n

\n9.13 Wiki

\n\n

\n10. Future

\n\n

\n10.1 SAST Analysis

\n\n

Maybe using Codiscope
Current state of SAST engines and code analysis tools\n
- some good for quality
- not many for security
\n

\n\n

Notes

1↩

\n\n

2image from http://www.bennadel.com/blog/2439-my-experience-with-angularjs—the-super-heroic-javascript-mvw-framework.htm↩

\n\n

3formerly known as Jade {add link to site}↩

\n\n

4https://twitter.com/DinisCruz/status/740995756719497216)↩

\n\n

5Katy Anton, on email↩

\n\n

6Erlend Oftedal, @webtonull, https://twitter.com/webtonull/status/745007874385055744↩

\n\n\n

\n\n

\n\n","tocStructure",[578,579,580,581,582,583,584,585,586,587,588,589,590,591,592,593,594,595,596,597,598,599,600,601,602,603,604,605,606,607,608,609,610,611,612,613,614,615,616,617,618,619,620,621,622,623,624,625,626,627,628,629,630,631,632,633,634,635,636,637,638,639,640,641,642,643,644,645,646,647,648,649,650,651,652,653,654,655,656,657,658,659,660,661,662,663,664,665,666,667,668,669,670,671,672,673,674,675,676,677,678,679,680,681,682,683,684,685,686,687,688,689,690,691,692,693,694,695,696,697,698,699,700,701,702,703,704,705,706,707,708,709,710,711,712,713,714,715,716,717,718,719,720,721,722,723,724,725,726,727,728,729,730,731,732,733,734,735,736,737],{"_77":71,"_40":68,"_69":-5,"_72":73,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":78,"_40":79,"_69":-5,"_72":80,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":84,"_40":85,"_69":-5,"_72":86,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":92,"_69":-5,"_72":93,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":95,"_69":-5,"_72":96,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":98,"_69":-5,"_72":99,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":101,"_69":-5,"_72":102,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":104,"_69":-5,"_72":105,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":107,"_69":-5,"_72":108,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":110,"_69":-5,"_72":111,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":113,"_69":-5,"_72":114,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":84,"_40":116,"_69":-5,"_72":117,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":119,"_69":-5,"_72":120,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":122,"_69":-5,"_72":123,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":125,"_69":-5,"_72":126,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":128,"_69":-5,"_72":129,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":131,"_69":-5,"_72":132,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":134,"_69":-5,"_72":135,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":137,"_69":-5,"_72":138,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":140,"_69":-5,"_72":141,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":143,"_69":-5,"_72":144,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":146,"_69":-5,"_72":147,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":149,"_69":-5,"_72":150,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":152,"_69":-5,"_72":153,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":155,"_69":-5,"_72":156,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":158,"_69":-5,"_72":159,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":84,"_40":161,"_69":-5,"_72":162,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":164,"_69":-5,"_72":165,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":84,"_40":167,"_69":-5,"_72":168,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":170,"_69":-5,"_72":171,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":173,"_69":-5,"_72":174,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":176,"_69":-5,"_72":177,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":179,"_69":-5,"_72":180,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":182,"_69":-5,"_72":183,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":185,"_69":-5,"_72":186,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":188,"_69":-5,"_72":189,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":191,"_69":-5,"_72":192,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":194,"_69":-5,"_72":195,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":197,"_69":-5,"_72":198,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":200,"_69":-5,"_72":201,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":203,"_69":-5,"_72":204,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":206,"_69":-5,"_72":207,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":209,"_69":-5,"_72":210,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":212,"_69":-5,"_72":213,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":215,"_69":-5,"_72":216,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":218,"_69":-5,"_72":219,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":221,"_69":-5,"_72":222,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":224,"_69":-5,"_72":225,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":227,"_69":-5,"_72":228,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":230,"_69":-5,"_72":231,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":233,"_69":-5,"_72":234,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":236,"_69":-5,"_72":237,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":84,"_40":239,"_69":-5,"_72":240,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":242,"_69":-5,"_72":243,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":245,"_69":-5,"_72":246,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":248,"_69":-5,"_72":249,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":251,"_69":-5,"_72":252,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":254,"_69":-5,"_72":255,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":257,"_69":-5,"_72":258,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":260,"_69":-5,"_72":261,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":263,"_69":-5,"_72":264,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":266,"_69":-5,"_72":267,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":269,"_69":-5,"_72":270,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":272,"_69":-5,"_72":273,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":275,"_69":-5,"_72":276,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":278,"_69":-5,"_72":279,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":281,"_69":-5,"_72":282,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":284,"_69":-5,"_72":285,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":287,"_69":-5,"_72":288,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":290,"_69":-5,"_72":291,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":293,"_69":-5,"_72":294,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":296,"_69":-5,"_72":297,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":299,"_69":-5,"_72":300,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":302,"_69":-5,"_72":303,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":305,"_69":-5,"_72":306,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":308,"_69":-5,"_72":309,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":311,"_69":-5,"_72":312,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":314,"_69":-5,"_72":315,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":317,"_69":-5,"_72":318,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":320,"_69":-5,"_72":321,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":323,"_69":-5,"_72":324,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":326,"_69":-5,"_72":327,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":329,"_69":-5,"_72":330,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":332,"_69":-5,"_72":333,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":335,"_69":-5,"_72":336,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":338,"_69":-5,"_72":339,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":341,"_69":-5,"_72":342,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":344,"_69":-5,"_72":345,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":347,"_69":-5,"_72":348,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":350,"_69":-5,"_72":351,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":353,"_69":-5,"_72":354,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":84,"_40":356,"_69":-5,"_72":357,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":359,"_69":-5,"_72":360,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":362,"_69":-5,"_72":363,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":365,"_69":-5,"_72":366,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":368,"_69":-5,"_72":369,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":371,"_69":-5,"_72":372,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":84,"_40":374,"_69":-5,"_72":375,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":377,"_69":-5,"_72":378,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":380,"_69":-5,"_72":381,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":383,"_69":-5,"_72":384,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":386,"_69":-5,"_72":387,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":389,"_69":-5,"_72":390,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":392,"_69":-5,"_72":393,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":395,"_69":-5,"_72":396,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":398,"_69":-5,"_72":399,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":401,"_69":-5,"_72":402,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":404,"_69":-5,"_72":405,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":407,"_69":-5,"_72":408,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":410,"_69":-5,"_72":411,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":413,"_69":-5,"_72":414,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":416,"_69":-5,"_72":417,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":419,"_69":-5,"_72":420,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":422,"_69":-5,"_72":423,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":425,"_69":-5,"_72":426,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":428,"_69":-5,"_72":429,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":431,"_69":-5,"_72":432,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":434,"_69":-5,"_72":435,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":437,"_69":-5,"_72":438,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":84,"_40":440,"_69":-5,"_72":441,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":443,"_69":-5,"_72":444,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":446,"_69":-5,"_72":447,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":449,"_69":-5,"_72":450,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":452,"_69":-5,"_72":453,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":455,"_69":-5,"_72":456,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":458,"_69":-5,"_72":459,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":461,"_69":-5,"_72":462,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":464,"_69":-5,"_72":465,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":467,"_69":-5,"_72":468,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":470,"_69":-5,"_72":471,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":473,"_69":-5,"_72":474,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":476,"_69":-5,"_72":477,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":479,"_69":-5,"_72":480,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":482,"_69":-5,"_72":483,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":485,"_69":-5,"_72":486,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":488,"_69":-5,"_72":489,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":491,"_69":-5,"_72":492,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":494,"_69":-5,"_72":495,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":497,"_69":-5,"_72":498,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":500,"_69":-5,"_72":501,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":503,"_69":-5,"_72":504,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":506,"_69":-5,"_72":507,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":509,"_69":-5,"_72":510,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":84,"_40":512,"_69":-5,"_72":513,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":515,"_69":-5,"_72":516,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":518,"_69":-5,"_72":519,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":521,"_69":-5,"_72":522,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":524,"_69":-5,"_72":525,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":527,"_69":-5,"_72":528,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":530,"_69":-5,"_72":531,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":533,"_69":-5,"_72":534,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":536,"_69":-5,"_72":537,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":539,"_69":-5,"_72":540,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":542,"_69":-5,"_72":543,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":545,"_69":-5,"_72":546,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":548,"_69":-5,"_72":549,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":551,"_69":-5,"_72":552,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":84,"_40":554,"_69":-5,"_72":555,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":91,"_40":557,"_69":-5,"_72":558,"_70":71,"_87":-5,"_88":-5,"_89":-5},{"_77":71,"_40":560,"_69":-5,"_72":561,"_70":71,"_87":-5,"_88":-5,"_89":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]

Table of Contents

Change log

\nI Part I - An AngularJS application

\n1. Why? How? What?

\n1.1 How this book is built

\n1.1.1 How to report an issue

\n1.1.2 How to fix an problem

\n1.2 Maturity Models Project

\n1.3 Maturity Models source code

\n1.4 Start with tests

\n1.4.1 Managers need to write tests

\n1.4.2 Abusing the (unit) Test concept

\n1.5 The power of Simple

\n1.6 I really like Angular 1.x

\n1.7 My Application Security Background

\n1.8 Price of this book

\n1.8.1 Adding paid version which included Printed book

\n1.8.2 Moving to only paid version

\n1.8.3 Not much feedback from readers

\n2. Maturity Models

\n2.1 Data repositories

\n2.1.1 Current structure of Data repositories

\n2.2 Tests - API

\n2.3 Tests - QA - Browser

\n2.3.1 Browser-API.coffee

\n2.4 Tests - QA - Http

\n2.4.1 Http_API.coffee

\n2.5 Tests - QA - JsDom

\n2.5.1 JsDom_API.coffee

\n2.6 UI - Server-side

\n2.7 Maturity Models - Features

\n2.8 App structure

\n2.9 Code - QA

\n2.10 Code - UI - Angular

\n2.11 Code - Web Services - API

\n2.12 Tests - QA

\n2.13 Tests - UI

\n2.14 Adding an Controller

\n3. Case-study: Adding a new API and View

\n3.1 Adding Backend Service

\n4. Angular-v1

\n4.1 $digest

\n4.2 $http

\n4.3 $injector

\n4.4 $scope and $rootScope

\n4.5 $timeout

\n4.6 Angular mocks

\n4.7 Config

\n4.8 Controllers

\n4.9 Dependency Injection

\n4.10 Directives

\n4.11 Module

\n4.12 Opinionated Angular

\n4.12.1 Http doesn’t work in tests

\n4.13 Patches

\n4.14 REPL from inspector

\n4.15 Routes HTML 5 mode

\n4.16 Routes

\n4.17 Services

\n4.18 Should angular 1.x be forked

\n4.19 Simple 1 page Angular

\n4.20 Template-Urls

\n4.21 Testing Angular

\n4.22 Two-way Model binding

\n4.23 Why Angular 1x

\n4.23.1 Angular 2.0

\n4.23.2 React

\n5. Technologies used

\n5.1 Agile using Kanban WIP

\n5.2 Bower

\n5.3 CoffeeScript

\n5.4 CSS

\n5.5 D3

\n5.6 Digital Ocean

\n5.7 Docker-Hub

\n5.8 Docker

\n5.8.1 useful docker commands

\n5.8.2 Docker vs VMs

\n5.9 Electrium

\n5.10 Foundation