Controlling Route Traversals with Flow

This talk was all about routes. Nathan Hammond started by talking about URLs in three different categories… resources, actions, and flows. Resources don’t change the state of an app and are available all the time. We want them to be in our history stack. Finally, they are plural or singular nouns depending on the controller. Actions are things like post or put paths like /login or /recover-password. It receives all the users input at once. It results in the user being presented with flash or a new resource. Finally, it should always contain a verb (see the examples from a few sentences ago). Finally, there are flows. Slows are series of actions across routes. Flows lead to a completed application state.

A state machine allows you to jump into the flow. BUT designing a flow is really hard. You need to make sure you cover every components of the flow. There is a four step process to do this.
Step 1: inventory our routes in the routers
Step 2: list linear paths (ie- login flow traversal path)
Step 3: convert to node graphs
Step 4: identify state change to traverse each path
        Then you do a complete enumeration of the state or if you’re passing in a wait
Step 5: Identify backwards traversals (ie- where does the back button lead to each time you press it).

The CS term for doing this is a directed graph.

The result is a state machine that describes exactly how a user moves through and app. It is the picture that shows ALL of the steps we just outlined.

Looking at this demo, http://alexdiliberto.com/emberconf-2014-demo/#/login, gives us a sense of flows. To “code the flow”, the general strategy is that you start by loading the session state. The you reset the controller (if needed). After, you delegate identification of where you’ll go next. Then you traverse the longest route so you know you visited every node. AND you can use replaceWith instead of transitionTo which Nathan thinks is awesome.

A better strategy is to start with one place that defines flow and load the flow and flow state (explained as where the user is and what state they’re in). Then, you delegate the id of where to go to in the flow. After, you call back into the flow to progress. You start with a definition file with an edge list that dictates a from and a to path with conditions. The conditions are what needs to be checked, like ‘isAuthenticated’. Then you inject the flow logic. beforeModel looks up the current flow and identifies where the user should be and then you set the action. The action will include var Flow. Which sets state on the flow inside your routes so there’s no processing of that information in the route. Or further reading, check out ember-flows which is almost ready: https://github.com/nathanhammond/ember-flows.

UML: not just random letters - Day 2 Session 3

On day 2, I didn’t got to the second session because I was busy having an excellent lunch with the other ladies at the conference thanks to DevChix for organizing and sponsored by Thoughtbot! When I got back, it was time for session three. I wasn’t sure what to attend for session three (day 2 in fact was much higher level, I thought than day one so I was often choosing between sessions where I didn’t really understand any of them so it was a little bit flip of a coin, but the sessions ended up being really interesting). I ended up at The Big Picture with Jim Weirich.

TL;DR: UML can help diagram code which helps programmers see it and organize it with more clarity.

The Big Picture was all about UML which stands for unified modeling language. An initial warning, UML is a visual representation so I’m writing about some of the information but in order to really get the full picture and idea of what Jim discussed, I think it will be necessary to see the diagrams and models alongside the explanatory information.

Moving into the talk, there are three primary ways that you can use UML. You can use it to sketch a process. You can use it as a blueprint and finally you can use it as a programming language. Jim talks about using it primarily as a sketch. The first example he discussed in terms of explaining usefulness was showing dependencies. When you diagram something, you really think through the code and know what your code depends on. This is shown visually via the direction of the arrows. The direction of the arrow is the direction of the dependency. You can also use this diagram to break up certain sections of the code so, at one point, on the example, the controllers were outside of the box (in red) and the application was in the green box (see, this is where seeing the diagram is obviously useful).

One of the primary examples discusses was a sketch of Rake. Rake has few classes, but the classes that do exist contain lots of methods. There is no rules class in rake. There are also no domain specific locations in rake. The application is rake. Within that application, namespaces exist and the scope is constantly changing as you define a task. The file tasks ignore scope. I had never thought about the rake task in this way and broken it apart with this methodology so it was interesting to see the task essentially pulled apart into the different commands and components that comprise it.

There was a brief discussion of object diagrams and how it is important to keep in mind that an object diagram captures how an object looks at that exact time.

He then talked about another use of diagramming when talking about creation. It related to creating a process, but more importantly he used an AR Drone to demonstrate it so pretty much all my focus went to that leaving me with little/no notes on what creating a process actually means and why this methodology is useful for it.

Next we covered dynamic engagement which is a state diagram. In this diagram, you have a start state (represented by a black dot). Then the arrows represent transitions which happen with a trigger that make an action happen which finally switches the state.

Finally, we discussed interactions which are sequence diagrams. My notes for this part are a little shady but sequence diagrams are like object diagrams but with more lines and different lines. The diagrams show sequencing calls and are timing related.

Summarily, I can see where diagraming out code is interesting and useful. After this talk, I also heard others discussing how UML is a waste of time, which I can understand as well. I think in certain scenarios diagramming and utilizing UML could be very helpful and useful but in others, I can understand how it wouldn’t make as much sense.