anchor.diff:  This is the Angular JS dependency management system in action. Other frameworks have similar (and arguably superior) features. Also, in a larger application, you might use a build time step to bundle all the JavaScript together so it can be loaded efficiently by the browser, but that's almost a matter of taste.
   
   [[using-natural-routes]]
  -== Using "Natural" Routes
  +//== Using "Natural" Routes
  +== "自然な" ルートを使う
   
   The Angular `$routeProvider` by default works with fragment locators in the URL path, e.g. the login page is specified as a route in `hello.js` as "/login" and this translates into "/#/login" in the actual URL (the one you see in the browser window). This is so that the JavaScript in the `index.html`, loaded via the root path "/", stays active on all routes. The fragment naming is a bit unfamiliar to users and it is sometimes more convenient to use "natural" routes, where the URL path is the same as the Angular route declarations, e.g. "/login" for "/login".  You can't do that if you have _only_ static resources, because `index.html` can only be loaded one way, but if you have some active components in the stack (a proxy or some server-side logic) then you can arrange for it to work by loading `index.html` from all the Angular routes.
   
  
positive.code: Angular uses the `<base/>` element to anchor the routes and write the URLs that show up in the browser. You are running in a Spring Boot application so the default setting is to serve from root path "/" (on port 8080). If you need to be able to serve from different root paths with the same application then you will need to render that path into the HTML using a server-side template (many people prefer to stick with static resources for a Single Page Application, so they are stuck with a static root path).
  
  [[extracting-the-authentication-concerns]]
  == Extracting the Authentication Concerns
  
  When you modularized the application above you should have found that the code worked just by splitting it into modules, but there is a small niggle there that we are still using `$rootScope` to share state between the controllers. There's nothing horribly wrong with that for such a small application and it got us a decent prototype to play with quite quickly, so let's not be too sad about it, but now we can take the opportunity to extract all the authentication concerns into a separate module. In Angular terms what you need is a "service", so create a new module ("auth") next to your "home" and "navigation" modules:
  
  
negative.code: You simply need to convert the flag `authenticated` to a function call `authenticated()`, so that the "navigation" controller can reach into the "auth" service and find the value of the flag, now that it is not in `$rootScope`.
  
  [[redirecting-to-the-login-page]]
  //== Redirecting to the Login Page
  == Login ページにリダイレクトする
  
  The way we have implemented our home page up to now it has some content it can display when the user is anauthenticated (it just invites them to log in). Some applications work that way, and some don't. Some provide a different user experience where the user never sees anything apart from the login page until he is authenticated, so let's see how we might convert our application to this pattern.
  
  