Other Great Things I Learned At EmberConf

As a newbie in development, I like to do a post on random things I learned during the conference. These often end up being CS terms, nerd culture related, or other interesting items that didn’t quite fit/make sense in a session post. Here are those from this conference.


Primitives: basic types in javascript like booleans and numbers.

Orthogonal: not a computer term, it just means adjacent.

Grok: means to really really understand something. It’s actually coined from a book about an alien and it’s understanding of humans. Check out the link to the book here.

D3 is a drawing library mostly used for graph’s or charts

Donut charts are pie charts with a hole in the middle

Truthy/falsy: this concept is more or less important based on the language. Basically, when stuff isn’t strictly true or false, javascript tries to help you out and guess which one it’ll be. A quick google search shows that there are lots of better explanations out there on what it is. This one looks pretty comprehensive and interesting: https://gist.github.com/jfarmer/2647362

CLI is a command line interface and it is how you interact with the app on the command line. (A perfect example of things I’ve been doing but didn’t actually know the name for)

This is a great background blog post that a few sessions referred to: http://emberjs.com/blog/2013/12/17/whats-coming-in-ember-in-2014.html


Finally, for other great notes from the conference, check out these links:

https://www.icloud.com/iw/#pages/BAKaAlrUjn9i0hXOyWyBDqAS2MEQFkyKTBaF/EmberConf_2014_Notes

https://github.com/zurt/notes/blob/master/EmberConf-2014.markdown

http://www.justinball.com/2014/03/27/ember-conf-2014-wrap-up/

http://pixelhandler.com/posts/we-are-emberconf-2014

http://hermanradtke.com/2014/03/27/emberconf-2014.html

Final Keynote

And here we are… coming to a close at Emberconf. The final keynote was given by Dave Herman about evolution. He started with a cool little video about putting the source code for the internet online. He used that to talk about evolutions versus revolutions. Revolutions are good but only when there is a need for one, otherwise evolution is great. He talked about some of the current Javascript issues of speed, jit compilation, etc. A revolution might be a new byte code language but an evolution is talking about the current and improving it. He spoke about formalizing patterns, closing the gaps to make things better, building a JS compiler, and studying it to optimize the code.

There is a process to evolve Javascript. He then spoke a bit about echoschript and es6 modules. Adding features that were backwards compatible. All this can lead to 1JS. It leads to focus, consistency and adoption. Consistency meaning orthogonal, composable, etc. and adoption meaning that it is easy to adopt and comes with as few evolutionary issues as possible.

He spoke a bit about “use strict” which fixes some compiler issues (although I’m not completely sure I grasp what and where “use strict” is used for). ES6 modules are strict by default which means a more smooth path. He talked about how features were better than forks and that to pave better paths for the future, we need features that can be adopted into existing code bases. Based on that idea, modules are a better programming model than modes.

He then went a bit into the extensible web manifesto and how that is the process of how we can work together to evolve the platform. Basically, good design is motivated by use cases and work flows. Good design is built from small, orthogonal, and composable primitives. We need to think about the end-to-end system and how it all works and then build those in small pieces. His main point was that developers need to be a part of that process to help iterate, evaluate and create standards. So, in three steps, extensible web works like this:
1. Add missing primitives
2. Enable userland polyfills and compilers
3. Work together (browser vendors and developers)

Snappy Means Happy

Matthew Beale gave us a lot to think about and showed me a bunch of tools I had no idea existed in this talk about performance. He started by giving us some good things to think about… mainly, what does fast mean to you? He showed different speeds and what that would mean in terms of actually viewing an app (ie- animations, etc.). You can use that “fastness” scale to then look at your code and see what piece is taking the longest. Is it the network? The javascript? Or the render? Thinking about each of these and looking at times for each part help you narrow down what tools to use and what part needs to be made snappier.

When you’re ready to dive into performance and have pinpointed what part needs working on, then you can move on to the recommended methodology. This is 1) gather the facts and isolate the problem. 2) analyze and theorize about what’s going on. 3) change a single thing… if you change a bunch of stuff and performance is better then you don’t actually know what made the difference. And 4) confirm the theory. The example Matthew used was loading the ember.js website on your phone.

So, first you need to reproduce the immobile latency reliability… in this case you can use slowyapp, Charles, or network line conditioner. You then create a clean browser (this was also a new concept to me) which means you have no extensions, a private window and therefore nothing interfering with the site you’re working on. Then you measure and analyze in the network inspector. In that inspector you can check out the timings tab which gives you a bunch of information.

Part of that information shows us that if you look at the timeline, you can see the load order of things and how long each element is taking. Here, you end up being able to move a script tag which makes the page’s load time much faster.

Next, we looked at “janky” animation. To solve this issue, you first need to understand browsers, then you measure with the timeline tool (another one of the inspector tabs). You can highlight a specific section to get more information about it. You can look at frames which show how long something takes to get to the screen. Green = paint, yellow = javascript, clear = upload to GPU, compositing. AND THEN, render console has a bunch of additional tools you can use to record and generate the data.

If you’re a little lost on where all these tools are and how to access them, the slides show it all pretty clearly.

Also, at this point in my notes I had written “OMG, so many tools!” which I thought was worth sharing here.

In this case, the solution to the issue is a webkit transform that keeps it on the GPU and then uploads the whole thing to the graphics card. By adding a Z translation to the animation, it forces the GPU to say this is 3D and should be put on the graphics card.

Finally, we talked about ember.js property change notifications. For this methodology, first you need to understand observers and then look at the profiler. Observers are synchronous and fire when a set thing occurs. There are two options .setProperties or Ember.run.once. Then you look at the profiler. The profiler has processing and memory. You run a profile and get back information in form of a flame chart. A flame chart allows you to see the stack that is being run. In the list view you can use the profiler to pinpoint the issue. Here, you refactor to create a buffer instead of pushing items into an array which fires 1 change notification instead of many.

The important thing to remember here is to have a methodology to solve issues, to remember that web performance does not equal ember performance and that there are a heck of a lot of awesome tools you can use to help you out.

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.

Convergent/Divergent

This talk was crazy. It was really academically intense and while I was able to follow the basic ideas, there was a lot of important information and concepts that were ran through really quickly. Fortunately, it seemed like most of the conference participants also thought this talk was also presented really quickly, so I wasn’t alone on this. Also, every time I went to write a note, I feel like I missed the next two points and came back into the conversation on the third, so hopefully those notes don’t seem really disjointed. I will say that Chris seems like a really smart, nice dude so it’s definitely worth connecting with him for more details on this if you want to dive into it more.

There are distributed computing issues and you’re building a distributed system. Basically, if you’re pushing state to the client, it means you’re caching validations which can lead to consistent data issues and more. This is an issue regardless of the database you’re using and this fact means you’re building a distributed system.

Some of the main issues are dropped messages, rendered messages, race conditions, partial failures, and custom merges. There are TCP incast, TCP slow-start, and Nagle’s algorithm… these are cases of latency spikes… I think.

Then he went a little into distributed systems theory and consistency. Consistency is a contract and if developers follow the contract then there will be predictability. There are three kinds of consistency. Strict linearizable which is the total order of all events in a system and for single servers. Then there’s eventual consistency which means you eventually see all the events. It is a weaker form of consistency. Finally, there’s causal consistency which is basically, I observe an update immediately but another person may see the change a little later. When dealing with consistency, it comes down to safety vs. liveness.

You need consensus to deal with consistency. For consensus, you’re basically looking at termination, agreement, and validity. Termination means eventually the info will show. Agreement means it will all have the same value. Validity is that the value will be part of consensus. It comes down to a generals problem which are academic concepts. There’s two generals or the Byzantine generals. There are algorithms used to solve this. Some of those algorithms are paxos, raft, 2pc, and 3pc.

I’m not sure how this lead into vector clocks but then we discussed vector clocks whick allow us to define all possible orderings in a system. There are also dotted version vectors which are things having to do with events and actors.

We then went into CRDTs. CRDTs are conflict free replicated data types. These are data structures that store something. There are two types of CRDTs: state based and operations based. State based CRDTs have monotonicity which means functions where as inputs increase, outputs increase. We care about associativity (which is a binary operation… addition is associative), community (also a binary function, addition is also commutable), and idempotence (also a binary function). All three of those exist in programming.

If that wasn’t quite enough for you, we then spoke about bounded join semilattices… which is another math term, but this one has a decent diagram in the slides so check that out.

So, why is all of this important? Because consensus is hard. We want to avoid coordination so the system can progress and we want a weak consistency and higher availability. The conclusion is that you’re building a distributed system so you need to be thinking about this.

The Unofficial, official Ember Testing Guide

This was one of the sessions I was anxiously awaiting and it did not disappoint. First, a big hand of applause for Eric Berry for giving an excellent talk (his first one!). The slides were excellent and I can’t wait to continue looking into the new ember-qunit.

Testing looks at assertions. Assertions test the state of your code and QUnit is the default assertion library. In ember tests, there are always two parts, the setup and the teardown (those are callbacks). Now, there are assertions that are already provided (see the slide for those). One thing that Eric noted was that mocha and jasmine are not excluded in ember… you can use either of those for testing as well, but qunit is the happy path (a phrase I’ve come to know and love since working with ember).

Helpers help us guide our app to the state we want to test in our assertions. Looking at the callbacks, the setupForTesting sets up the router, etc. then you call injectTestHelpers which sets up the helpers so then, in your actual test, you write your helpers and then your assertions. Ember.test runs the helpers and qunit runs the assertions. Additionally, there are a bunch of different types of helpers starting with asynchronous helpers, synchronous helpers, and wait helpers. Asynchronous helpers wait for the proceeding helps to finish before they run. These are visit(), fillIn(), click(), and keyEvent(). Synchronous helpers run instantly. An example is find() and finally wait helpers wait for asynchronous helpers to complete before running. An example is andThen().

Then there are custom helpers. Use registerHelper() to create an asynchronous helper. Use registerAsyncHelper() to create a new async helper. A final reminder at the end of this part was that you still have to call injectTestHelpers to make sure you run the helpers regardless of whether they’re custom or not.

So now, the new things that will be in Ember 1.5. There will be new integration helpers. For example, triggerEvent() which takes three arguments: selector, event, and anything additional you need to add. Others are currentRouteName(), currentPath(), and currentURL().

At this point, there was an awesome example of testing search, so if you’ve got search in your app, check it out.

The next part looked at how to test in isolation. So instead of having to test all the pieces all the time, you want to test specific aspects. This is where ember-qunit was introduced. Ember-qunit is a library that lets you perform unit tests without loading the whole container. Ember-qunit was inspired by rspec. You start by setting up the globals is emq.globalize() and then you need to set up the resolver (described as the thing that can find anything… ie- mom). It also provides module helpers. These are moduleFor(), moduleForComponent(), and moduleForModel() . For the example moduleFor(“route:index”), it’s basically saying “hey resolver, I need you to pull this (the route:index in this case) from the container. moduleForModel() is specifically for testing Ember-data. There are super descriptive, awesome slides for each of these module helpers.

The last piece I noted was in controllers. In those tests, you’ll notice a “needs” field. Needs is used to bring in the dependency that the test need to bring in, in order to run… in the case on the slide, the controller for application.

To get going with ember-qunit, you just need to do bower install ember-qunit. It’s in ember-appkit and ember-cli already.

Finally, the last big announcement was that the team is redoing the testing guide on the ember.js site.

Happy Testing!!

Ember Components

The next session was actually entitled “Ember Components” (and wow, writing up these notes, I really am realizing how much components were spoken about but this talk like totally blew my mind). Alex Matchneer started by talking about embracing the controller. The questions he posed to us were what belongs in the router versus the controller? And what’s up with query params?

For those who don’t know, query params is the hash of info and it looks like this /?query=params. So, should query params be in the router or the controller? Putting them in the router makes sense, but it leads to a bunch of issues (outlined in the slides). It was decided that query params would go into the controller, so let’s look at a controller center API. Here, sortby is a property in the controller. queryParams: [‘sortBy’]. Doing this means that there’s no need for custom observation, query params are bound to controller properties, and there are additional add-ins that make it easier and nicer.

But why is this in the controller and not in the router? Well, the controller manages app state and also wraps the model with additional information for the templates. The router is in charge of navigation and is the link between URLs and controller/templates. The router serialized hierarchy into the path and the controllers serialize the app data into the query (this is practically verbatim from the slide).

When looking at router paths, transitionTo (one used often right now) is great but only for complex hierarchical things.

So, will a property be remembered or not? In router-driven controllers, property will live forever, but in an item/other controller, there are shorter lifecycles.

The primitive that is missing is the model dependent state. This is a state, accessible to controllers, tied to a specific model. The store/restore controller properties are scoped to the controller’s model. This can be used for QPs, caching, indexed DBs, local storage. For example, a global cache object gets injected in a controller. The controller decides what bucket that state lives in. And then inside the cache there is a bucket for each bucket key and you are in control over bucket allocation. Ie- it could be in local storage proxy, could be a POJO (Plain old Java object), etc.

Phew. That was a lot to explain. The slides are really excellent for this talk so definitely check them out.

Ember for Children

I thought it was nice that this session was included in the first ever Emberconf. With so much information to cover and so many interesting components of the technology, it was nice that the organizers made sure there was a talk that focused on the community and what we can be doing together for underserved communities in technology. Highlighting an achievement like this, really shows that even though we’re cranking out amazing technology, building the community is important and giving back is core to that idea.

DeVaris Brown (who also does ember hot seat) talked about a new initiative he’s launched which takes at risk youth and teaches them about programming and code. He started by talking about the bootcamp idea (something I have mixed feelings about and have written on before) and wanted to provide a bootcamp-type opportunity to high school students that wouldn’t be able to afford something like that. He walked us through the curriculum he used to teach these students, the time he put in, and where the students were today. He worked with Black Girls Code and other organizations to find students. He also spoke honestly about the challenges he faced like reasons students couldn't come to class or the basic typing skills necessary (for which he recommended typing.io).

DeVaris received a standing ovation and got a lot of questions from people on how they can help and get involved. I think it’s great that the community is so interested in providing these opportunities and focusing on these sorts of initiatives. I hope that they can work together and some of the already established organizations to make more things like this happen instead of trying to reinvent a new initiative.

Ember Cli

Next up was a talk on Ember-Cli. Cli means command line interface. From what I understand, Ember-Cli has also had a bit of a sorted past like Ember-data but lots of work is being done to make it much better. This was another talk that primarily talked about the highlights of what’s coming.

Stef Penner presented a few problems and their solutions. The first problem was coupling. The solution here is inversion of control. You have a container (which abstracts coupling) and the resolver (which finds the code for the container to use). The second problem are globals which leads to coupling based on load order. The solution here is es6 modules. Rather than writing this glue code, the app should build that code. This leads to thinking about tooling and shipping to the browser. A third problem mentioned was build stability and the solution is a build pipeline accomplished via new tools like broccoli.

Ember-Cli tries to solve these problems by creating a tested cow path that we’re all working on together. Two highlights are that in ember-cli, you can subscribe to different releases. For example, you can subscribe to beta releases and roll back if necessary. Secondly, cli adds a yeoman-type analytics data as an option. I’m sure there’s much more coming but those are the highlights.

{{x-foo}}

Day two started with a bang with Ryan Florence talking about {{x-foo}}. Speaking more about components, Ryan explained components as tags with a unique style and behavior. They are custom elements with an optional template, with an isolated ember view and the view is the context.

The most important part of this conference was obviously when Ryan pulled out the drone!!!! What’s a good conference without a drone demonstration?! So, in this case, Ryan flew the drone showing these ember components and using Ember. For example, the x-wing was a components and you can checkout the components which outlines all the actions.

Then we moved on to getting the components to talk to the outside world. Two ways were discussed: data binding and actions. Data binding are attributes that components will 2-way bind to. Actions are the actions that the component will outline. For data binding, he used the example of ic-tabs. The use case is to persist to query params. Basically, the controller sets the context of the template so that you can bind to those properties. You can see an example here: http://instructure.github.io/ic-tabs/. Then you can find the query param attribute on the tags. For actions, he discussed ic-menu. These components allows for a solution to the popover edge cases. It outlines on-select=“remove” and same for save and copy. And then those are saved in the controller. You can see an example here: http://instructure.github.io/ic-menu/.

Static tabs and dynamic tabs can both happen via parent and child components. Child components can handle their own state.

Sub-components are identified by events or if you need to manage a more specific class or attribute.

One interesting this that Ryan mentioned was that he is biased towards not having a template connected to a component and in his opinion, if you have a template, then you missed an opportunity for a possible abstraction in your component code.

HTMLBars

And we’ve finally arrived at the last session of the day. As my brain power waned, I was excited to hear about the new things coming in HTMLbars that will make apps faster and better. This session talked about the exciting things to come with Erik Bryn and Kris Selden.

HTMLbars is a templating library on top of handlebars. It understands markup. In htmlbars there is no need for {{bind-attr}}. It will build DOM fragments instead of strings which means no more script tags! These changes will dramatically improve the performance of large lists because htmlbars can rapidly clone DOM fragments.

Binding update order… instead of changing all observers, it’ll update based on the parent. The presenters then showed a flame chart that shows a stack of currently executing code. They also talked about the re-render which is an anti-pattern. Instead of new re-rendering, the content will update itself instead of the entire re-render. It will have smart caching and cloning of the DOM which will enable the re-render to be much faster.

Looking at just the DOM, there will be more of an ability to use willInsertElement because you’ll have the element that you ant to insert. And you’ll have more animation ability. For example, you’ll be able to set an animation off the screen because it’s coming up (you want to use the animation soon) and you can move it onto the screen in css transitions. There is custom rendering which then interacts with the DOM and will be secure by default.

It’ll also be easier to step through the render path to show more of the template to the DOM path which will clear up some of the “magic” that ember usually does automatically. I’m not exactly sure what this means IRL but I’m looking forward to finding out. HTMLbars will also bake in support for server-side rendering and looking at this, they’ve focused on the SEO use case.

Last but not least, they’re predicting a 2-3x performance improvement based on these changes.

There isn’t a lot out there right now about HTMLbars but it looks like it’s coming soon and once it arrives, I’m sure there will be lots written about it.

Modeling the app store and more

This session was a really cool session that showcased what ember can do and something that was build with ember as opposed to diving into a specific tool or component of the framework. Presented by Jeremy Mack, the talk was about how he used tapas with ember and built a search engine without a server. Jeremy looked at the app store and was annoyed with the silly popup links and the lack of good functionality in the app store.

The first issue he discussed was that there are lots of different data types in the app store. The core model is the iTunes item and an iTunes item has data like price, artwork, name, etc. Everything else inherits from iTunes item.

Jeremy then talked about mixins, which let you encapsulate functionality and reuse them. Mixins are kind of like components (I think) but components focus on the template and what you see whereas mixins focus on properties that can be added to other classes. The app mixin that was created are comprised of things that ALL apps have. These are aspects like screenshots, version, developer, and more. Then there is a genre mixin, and other mixin types. The app uses different mixins depending on if the iTunes item is a song, app, movie, or other option.

Then there is an adapter. The adapter is code that talks to a specific endpoint. In addition, there are then serializers. The serializers turn the adapter stuff into the format that you want it in.

Going back to talking about the iTunes item… it has classifies, polymorphism and sideloading. Classifiers are different properties that we know about. There’s a top charts serializer which uses the ID to transform the top charts data into the correct format. Then there are also relationships which map the parent-child relationships using ember data. It also maps the other data (ie- bringing into the app view information from youtube, rotten tomatoes, etc.). There is a fetcher which is defined in the controller. It takes care of pagination (custom built in this app), uses the identity map to de-duplicate, looks at required params, max results, etc.

Finally, in the templates for the app, there were lots of partials utilized, which is interesting. And as a sidenote, he uses fastclick to optimize the touch response.

Finally, here’s the app! It’s amazing so check it ou: fnd.io

Ember Components transclude my directives

This talk was given by John K. Paul and I have to say, I learned A LOT during it. As I mentioned, components were mentioned a lot during this conference but this session gave me some interesting understanding of additional terms and a little bit of Angular.

In Angular, directives make custom widgets. They decorate existing HTML with additional functionality… essentially a piece of HTML and a piece of javascript. In directives, you can also restrict based on specific parts. For example, restrict E means restrict based on an element, restrict C means restrict based on a class.

Transclusion is the inclusion of one thing into something else. Directives are used for making a DSL in your HTML but in order to do that, there are lots of knobs and levers and you need to understand lots of stuff to make that happen. For example, you put transclude: true in a directive definition which takes whatever is inside the element and moves it into the html where “ng-transclude” is written.

Ember’s got something similar to directives and those are components… except that components are much cooler and much easier to understand and create. An ember component is a custom component that you can use in many different places. The more general form of this are web components which are discussed in the extensible web manifesto (more on that in a later post) but it is basically rolling your own reusable widget. Ember components let us do something like this now and allows us to encapsulate HTML, CSS, and JS. It lets us package together a structure and behavior.

An example John K. Paul used was ember tabs, which are also ember components. They’re reusable. More examples are x-tabs and x-pane. The best thing about components is that you can take this functionality that is encapsulated in this component and just copy and paste it into your code, change very few things and have it good to go in the app you’re working on. The last slide talked about ember component lists that Eric Berry (http://coderberry.me/) and John K. Paul (https://gist.github.com/johnkpaul/6796944) have been putting together and urged other people to add to it as they create components. I, for one, think a collective list like this would be amazing and I’m very excited to use components more and experiment with how to use them to make us more productive and make our app better!

Animations and Transitions

Can you believe that at this point we were only like half way through the first day?! I’m amazed at how much was covered so quickly.

The next talk was about animations and transitions. I have to admit, after the last couple of talks where I hadn’t yet had much hands-on experience with those tools, I was really excited for this one. The project I’ve been working on has had some animation and transition difficulties so I was interested in hearing why these transitions were potentially so complex and get some good ideas for moving forward.

The talk was give by Edward Faulkner. The talk “slides” are basically an awesome demo that you can continue to use as you experiment with different transition and animation types.

Ember animations fall into 2 categories of simple and complex. Simple animations are those that occur in the same route.

Sample: {{animate-changes of=how }}: this separates how I’m animating versus what I’m animating and then the actual animation happens in the css.

There are also components that have a toggle animated class which can have current and next specified.

<div>
  <div class="next">{{next value}}</div>
  <div class="current">{{current value}}</div>
</div>


In an ember component, you can also have a bound property. You can use bound properties to show what is happening (in the case of the demo- the font size is a bound property). You can track the state and bind it.

You can also have an animated if helper. Here, you can have a computed property in the controller that is related to the animated helper and in the template, you can dictate how to represent these situations.

The more complex animations are those that go between routes. These are much more difficult and there is no drop-in library that solves this. You need to figure out how to coordinate the transition and animation between the views, templates, controllers and routes. Referring to the slid e showing the parent to child transition, we're looking at a nested route. The parent route stays rendered and the parent controller has a computed property looking for the details controller, which can flip the class and trigger the css transition. This is a mouthful but it makes sense. Going back is a much more complicated story. One way to solve this is to enact willTransition. The example for this is in the presentation slides. I highly recommend checking it out because I don’t have notes from this part which means I was too fascinated by what was going on to write down the steps.

The last part of the talk discussed modals. A modal has a state and URL that is not tied to the route. But modals can be used with query params to bypass the router and go directly to the controller meaning that rendering the modal has its own css rules. BUT be careful because you need to animate the modal away as well which is more difficult. Just clicking on “back” or “ok” doesn’t animate it away, it just takes it away. At the end, a few mobile specific concerns were mentioned as well.

Broccoli

Moving right along, the next talk was from Jo Liss about Broccoli. Broccoli is a js build tool. The goal of broccoli is to have an architecture that allows faster build reloads. The session was broken up into three parts. First, how to write a broccoli build definition. Second, sketch out the broccoli api. Third, how broccoli integrates.

Broccoli definitions are in the brocfile.js. the broccoli plugin has support for lots of other things as well including coffeescript. When you run the build in broccoli, it outputs a new tree and then to export you just call merge trees which pulls the css and js files into one tree.

The broccoli api is a simple one. Broccoli only knows trees which can be represented by a string in the directory or an object. This object has two functions, the read function and the cleanup function. The read function returns a directory (or a tree). The tree will be called and read repeatedly to build and then at the end, cleanup will be called. The api is tiny and the goal is to keep it small and more over things into helper packages. One example of a helper package is broccoli-transform. Another is broccoli- filter which works with a 1:1 relationships. This package implements the 1:1 relationship of input to output files. It also has cache so you don’t have to recompile everything all the time.

Finally, there was a discussion on integration. Broccoli is a small library and there is a need for broccoli to provide a good api so that it can be integrated into more tools. Broccoli does integrate with the back end as well.

I’ve got a lot to read about broccoli in order to fully understand it but I felt like this session gave me a good overview and some interesting places to dive in a little further. Since, I’ve got a better understanding that broccoli is like a rake task in ruby or the asset pipeline in rails. Broccoli is important because as your application grows, the amount of time it takes to reload a build grows. If you want to easily edit files and then reload the browser, you don’t want to have to rebuild everything in order to see the changes. I haven’t used grunt (a task-runner tool) before but there seems to be a lot of information about how when editing files, there are lots of complications and dependencies that can quickly build up and make just reloading the files you’ve changed a poor solution. But with broccoli, it tracks the files you are changing and these dependencies and rebuilds only the ones that need rebuilding so your build time is faster. I think sections 4 and 5 of this link do an excellent job providing a little more background and detail on this.

Next step for me, I think, is to dive into this post a little further: http://ampersate.com/getting-started-with-broccoli-and-emberjs

Ember Data

Moving right along was a session on ember data with Igor Terzic. This session was a little tough for me to follow so I’ll do the best I can on the write up notes. Ember data is also something that is discussed a lot and that I understand but haven’t really had a chance to dive into as much as I’d like to so far. I think this affected my ability to follow the talk because the talk was partially on what’s new in ember data, partially on what’s coming soon, and partially on where it’s been in the past. I know it’s been an arduous journey for ember data to get to where it is today so I think if I knew a bit more about the ember data history, the talk would have been even better for me.

The speaker was super entertaining and his slides were interesting but the talk definitely jumped around a bit making comprehensible notes and distilling themes and key ideas a little challenging. So here goes…

Ember data is a framework to solve problems. It is a data persistence framework. All problems can be categorized into a quadrant. The axis are unique vs. common and easy vs. hard. Easier problems can be easily fixed which means they’re locked down less. The core principle of Ember Data here is that changes to the data api should not affect the app code.

All adapter and serializer code was rewritten in the past few months. And in the future, the idea is to continue to tighten up the api.

The speaker went through a few different core problems and whether they were easy, medium, or hard. First up was data transformation. Data transformation is an easy problem. It is easy but unique. The second problem is asynchronicity which is related to promised which have gotten better. Asynchronicity is a medium problem because it is hard but common. Now in ember, there is a complete asynchronous promise-based solution and in the future, there will be an even more tight api related to promises. Relationships can be synchronous or asynchronous. Additionally, in the future there will be an easy way to implement lazy arrays and all relationships will be promisified in the future. Ember data returns promise proxy mixin.

Next, we come to the caching problem. Caching is a hard and common problem. In this case, Igor discussed an identity map as a way to access records based on a type ID. The main improvement in ember data around this is a standardized data retrieval process which will lead to greater productivity.

Finally, locality is discussed. Locality is a hard and unique problem. This is basically explained as data coming in all the time from lots of different places. Basically, locality = craziness. Locality depends on your api data transfers, how the data is coming you're your application, etc. Adding relationships of things makes this issues even more complex. Ember data tries to change the relationship syncing problem. Now there is also more focus on the problems at hand.

More information here: http://emberjs.com/blog/2014/03/18/the-road-to-ember-data-1-0.html

Contributing to Ember

The next session was on Contributing to Ember. This is going to be a pretty short write up because a lot of the talk just went of the technical structure of how to contribute.

The three types of contributions are primarily fixing/cleaning up the docs, reporting and/or fixing bus, and submitting new features.

First step is to pick the right repo. If you’re looking at the docs, there is a guides repo and a main repo. For each of the types of contributions, there is a naming convention that goes along with the commit and you want to make sure to use the right prefix for what you’re committing. Because I’m mostly interesting in looking at the docs, I took the most notes around there. There are three kinds of commit prefixes [DOC], [DOC beta], and [DOC release]. For bug fixes, when submitting something you want to make sure to add a test that shows regression. If you can show a test, then you definitely need to show instructions and do a jsbin with specific information. The main point emphasized here was to make it as easy as possible for others to see the bug you are talking about… especially if you are submitting a bug report but not necessarily fixing the bug.

Another important emphasis was on security. Mainly, DO NOT report security issues on github. For those, email the security team privately.

For submitting features, all features are behind feature flags. In features, you want to look at the JSON to see if the feature is enabled or not. There are specific feature commit message instructions with specific message types and you want to make sure to hide changed behind flags.

Finally, they talked about the release cycle, which was interesting. There are basically three channels and six-week cycles. The three channels are beta, canary, and release. Beta is branched from canary and includes bug fixes, doc updates, and goes on a weekly release cycle. Canary is everything, new features, bug fixes, etc. Release is also branched from beta and it’s doc updates, major regressions, and security fixes.

I have to admit, I was a little intimidated at the end of this talk. I really want to contribute to open source, especially to something like the ember docs where I feel I could maybe help pinpoint confusing points or rephrase to make things more understandable, but walking through this process made me pretty nervous about screwing up the prefix or process.

Using Ember to Make the Seemingly Impossible Easy

This session was titled “Using Ember to Make the Seemingly Impossible Easy" with Andre Malan and Heyjin Kim. The talk touched on four different pieces of ember.

The first was migrations. Migrations can be a really difficult issues especially when trying to transfer data from a SQL database to a new database. The speakers told a story about having this problem and trying to solve it. Ultimately, they were able to solve it using ember data. Basically, they did an entire migration based on ember data provided data in both apps which provided them with the mechanism to pull the data out and push it into a different place.

The second aspect they spoke about were visualizations. This is basically helping people understand the story behind the data. In order to do this effectively, they used an ember component (something that was frequently discussed throughout the conference). Basically, in an ember component, they encapsulated D3 code. They did this by defining a components, adding the D3 code into it which allowed them to draw a donut chart. I’d never heard of D3 code before but the main point was that by wrapping this code into an ember component, a developer can change/utilize the ember component to make the changes they need to instead of having to dive into the D3 code.

The third thing they spoke of was infinite scrolling. This was an interesting issue because it involves loading these items into the browser so that they’re essentially ready to go when someone continues scrolling. The speakers specifically spoke about a scrolling list of video events and that for the view to happen, the post view has to go through the vine controller to make the switch to video. Instead, you can swap the DOM from heavy weight to light weight objects and that by constantly clearing out the DOM and repopulating it with new information.

The final thought was on two apps in one. The problem Andre and Heyjin encountered was that they had an app that was entirely behind an authentication wall, but there was one page that they wanted to make a public URL but couldn't because you had to log in to see anything on the site. The solution ended up being a non-authenticated rails app with a new router. Basically, they spun up a new app with a small sprinkle of ember in the controller. If you do this and think about quickly developing different applications then you can send different types of people (ie- consumers, managers, administrators, etc.) to completely different applications leading to different JS structures and views based on what kind of a user the person is.

Opening Keynote

The opening keynote was done by Tom Dale and Yehudah Katz. It started with some thoughts on inclusivity which was really nice to see. I also think the way they frame inclusivity both for the conference and for the Ember community at large was really impressive. It wasn’t just a standard read of the code of conduct and it wasn’t presented in a lecture format. It was presented in a way that the emotion of exclusivity and inclusivity were really felt by the participants on a deeper level.

This idea of inclusivity continued throughout the talk. Tom and Yehudah spoke about the Ember core team and encouraged people to get involved. They made a point to stress that the core team is not just about being a developer, there is also space on the core team for event planners, community builders, and others who will be core to building ember in different capacities. They talked about contributing to the docs and, as a newbie, was encouraged by the fact that they stressed a need for newer developers to be contributing as well to ensure that the docs and pieces of ember were accessible and understandable to everyone.

They also spoke about productivity. A core reason for people using ember is to be more productive every day. They showed this through the idea of outlining flows. When you think about a flow on an app, even simple features can have a complex flow and many screens. They then highlighted different ember apps that showed ember from different flow ideas and representations, making the point that one of Ember’s strengths lies in it’s ability to allow developers to create and link new screens very easily. Some of the apps highlighted were Vine, Bustle, and Travis.

It was an excellent opening session that really set a good tone for the rest of the conference.

EmberConf 2014 - Setting the Scene

Last week, I went to EmberConf 2014. This conference was the first official Ember conference and it was fantastic. For those of you who don’t know what ember is, it is a JavaScript framework that I’ve been working with for the past two months. The conference was in Portland and it was a single-track, 2-day long, wonderful experience. Because I took copious notes, I figured I would do that same thing I did for RubyConf this past year and write up a post for each session. Some of these will be longer, some will be shorter, and if you know Ember, PLEASE, feel free to add comments and additional thoughts. I also want to get these up pretty quickly, so there will likely be a few posted at a time.

I’ll be honest, I was nervous going to this conference. I’ve only been to a few tech conferences so far and at most of them DC Rug and Arlington Ruby are represented pretty heavily so I generally never feel like I’m stepping into the unknown without a solid group of people to fall back on if I’m feeling lost. I’m also used to going into a conference as a “known newbie” either because it’s a smaller local conference and most people know my level of experience or, like at RubyConf, because I was an opportunity scholar. Emberconf was different. I knew a couple of people going in but they were much looser connections and again, there were few of them AND I was just one of the crowd.

My fears and nervousness were quickly quelled at the conference though. The general atmosphere was kind and excited and everyone wanted to meet one another. I also had some great people like Gustin, Chris, and Ashish offer some awesome twitter introductions which really helped as well! There were a total of 430 people there, which is a pretty manageable number. This was also the first single track conference that I had been to and I really enjoyed it. I did wish there was an opportunity to switch up the table you were sitting at during the day but for the most part, it was great. You sat at a table, really got to know everyone there. There were a good number of breaks and because everyone was hearing the same sessions, there was a lot to talk about.

The sessions were 30 minutes long, which I felt was a pretty good length for most of them, although didn’t always allow for enough Q&A time. Again, though, the benefit of a small, single track conference is that the speakers are all accessible to ask more questions to during the breaks. So, the scene is set… now onto the sessions.