anchor.diff:  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
  +//== 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.
   
  
positive.code: ____
  
  [[conclusion]]
  == Conclusion
  
  In this section we have seen how to modularize an Angular application (taking as a starting point the application from <<_the_login_page_angular_js_and_spring_security_part_ii,section two>> of the tutorial), how to make it redirect to a login page, and how to use "natural" routes that can be typed or bookmarked easily by users. We took a step back from the last couple of sections in the tutorial, concentrating on the client-side code a bit more, and temporarily ditching the distributed architecture that we were building in Sections III-VI. That doesn't mean that the changes here can't be applied to those other applications (actually it's fairly trivial) - it was just to simplify the server-side code while we were learning how to do things on the client. There _were_ a couple of server-side features that we used or discussed briefly though (for instance the use of a "forward" view in Spring MVC to enable "natural" routes), so we have continued the theme of Angular and Spring working together, and shown that they do so quite well with small tweaks here and there.
  
negative.code: //= Modular AngularJS Application
  = AngularJS アプリケーションのモジュール化
  
  In this section we continue <<_spring_and_angular_js_a_secure_single_page_application,our discussion>> of how to use http://projects.spring.io/spring-security[Spring Security] with http://angularjs.org[Angular JS] in a "single page application". Here we show how to modularize the client-side code, and how to use "nice" URL paths without the fragment notation (e.g. "/#/login") which Angular uses by default, but most users dislike. This is the seventh section of a tutorial, and you can catch up on the basic building blocks of the application or build it from scratch by reading the <<_spring_and_angular_js_a_secure_single_page_application,first section>>, or you can just go straight to the https://github.com/dsyer/spring-security-angular/tree/master/modular[source code in Github]. We will be able to tidy up a lot of loose ends from the JavaScript code of the rest of this series, and at the same time show how it can fit very snugly against a backend server built from Spring Security and Spring Boot.
  
  [[breaking-up-the-application]]
  //== Breaking up the Application
  == アプリケーションの分割
  
  The sample application that we worked with so far in this series was trivial enough that we could get away with a single JavaScript source file for the whole thing. No larger application will ever end up that way, even if it starts out life like this one, so to mimic real life in a sample we are going to break things up. A good starting point would be to take the "single" application from the <<_the_login_page_angular_js_and_spring_security_part_ii,second section>> and have a look at its structure in the source code. Here's a directory listing for the static content (excluding the "application.yml" that belongs on the server):
  
  