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.

Being a Healthy Programmer

Health issues. Something we all face as developers but is not really talked about. Being a developer comes with some very specific health concerns that are different than what I’ve experienced in other fields. As I’ve learned to code over the past year, I’ve gotten a lot of advice and learned a lot of best practices. None of this advice, however, has included anything related to health! All of a sudden, I was coding full time and experiencing all these new issues and I had no idea why. We all experience similar physical pains of transitioning into a new industry but it's one of the things I think isn't discussed adequately enough to prevent it from happening. Additionally, a lot of the solutions cost money, which may be something you don't have a lot of if you are going through a career transition, coming out of a bootcamp, or just in the beginning of your job. In speaking to others, I found that most of the stuff I was experiencing are really common among developers. I sent out a request to understand what people experience and what some solutions are and here’s what I got.


Eyes. Obviously looking at a screen that is two feet away from your face all day has got to have some serious long term effect. Additionally, if you don’t have the right prescription then you’re also probably dealing with some sort of eye strain.

Back. Posture and sitting up straight is really important. Long term affects can include needing physical therapy, surgery or just constant pain.

Headaches. I know a few people (including myself) that have been experiencing afternoons headaches. There are LOTS of things that can affect headaches including hydration, food, eye strain, muscle aches, and more.

Hydration. Turns out we all forget to stay hydrated during the day. Between coffee intake (which actually dehydrates you) and getting so focused on work that we forget to make sure we’re drinking, this is a major issue (that can, of course, relate to other things on this list like general draining, back pain, and headaches).

Food. What?! You forgot to eat again? Me too! I can’t even count the number of times I’ve looked up from my computer and realized it’s 2pm and I haven’t had breakfast or lunch yet. Obviously, not a healthy practice.

Sleep. “Just 5 more minute and I’ll be able to solve this issue and close my computer.” I’ve said this to a friend or my husband so many times. We tend to try to power through problems, drink coffee or energy drinks to push that last bit of code to production, or just accomplish a little more by working through the night which is solid, uninterrupted time. This is also related to something someone called “sleep creep” (which I love). Instead of working through the evening, some developers will get up at 4:30am, have some solid morning work time and then have to check out for a bit in the afternoon for a nap or to recharge.

Weight Gain. We sit. A lot. Like all day. There are lots of ways exercising can affect other things on this list, but weight gain and circulation from sitting all day can definitely be harmful and a tough pattern to break out of.

General draining. What we do involves a lot of brain power and a lot of thinking. It is easy to get exhausted and it’s easy to finish the day and just want to get the easiest thing for food and sit on the couch to unwind. This isn’t so much a solution, but a good article that goes into this issue further.

Hands. There’s lots of concern about repetitive strain and carpal tunnel syndrome. This is definitely an issue that, as a newbie I don’t think about much but as someone getting started in a longterm development career, I probably should.

(Thanks to @vicfriedman, @pamtaro, @embryoconcepts, @robyurkowski, @tundal45, @stevenhaddox, @_ZPH, and @peterbroderick for your help and mentioning issues you’ve faced or are concerned about)

So, how do we improve out situation? It’s great to offer solutions like a standing desk, complex raised screen setup, and other such tools but these tools are expensive! Here are some cheap ways we can solve these issues.

“Pretend” standing desk. My first standing desk was literally 3 boxes stacked on top of one another to give me computer a little bit of height.

Pomodoroing. Following the pomorodo work style basically means that you do focused work for a specific amount of time (usually 25 minutes) and then you take a mandatory break for 5 minutes. There are lots of benefits to doing this but I find that it makes me more aware of myself. When I have a forced break, I make myself drink water, use the restroom during the break. I also find that when I break every 25 minutes, I’m way more aware of my posture and actively correcting my slouchiness.

F.lux. This app helps alter your computer screen lighting based on the time of day. I wasn’t so much a believer until I started using it but the gradual deletion of blue light from your screen helps you mind get ready for sleep even if you’re still using your computer.

Posture exercises. This is one a friend passed along to me. I also recently saw an app that focuses on alerting you when you aren’t holding good posture.

Exercise in general. I’m lumping standing versus sitting into this category as well. Exercise is always tricky to make time for but it is definitely an important part of being a developer (I reluctantly type as someone who really hates going to the gym). Put GYM in your calendar.

And finally, there’s the Healthy Programmer book which I haven’t read at all, but I’d bet it’s pretty informative.

I’ll be honest, I’m not the best at following all of these. I haven’t found good boxes to make a standing desk, I only successfully pomodoro’ed once in the past 3 weeks, but being more aware of these issues motivates me to make sure I’m establishing best practices for my health. And of course I’m hoping in the near future to be able to purchase the things I need to make my home office and work situation even better (ie- the chair I use is like the worst chair for programming EVER).

Got more issues, suggestions, and cheap alternatives? Leave them in comments below.

Ember- An Intro

I’ve recently started learning Ember. The process of learning ember has been really interesting so far, but one issue I’ve found is a lack of newbie-centric articles since the language is so new. Ember is also my first JavaScript language which is a whole other thing. I have found learning Ember, however, not as difficult as I imagined. Maybe because it feels so rails-esque? As a warning… I hope all of this information is correct, but, as I’m still very new to this, I’m not completely sure.

Ember has similar conventions to rails like the idea of MVC and way to DRY out your code. I’ve found certain things difficult and other things just make sense which is nice. Ember has models and controllers. It has views as well but these views are known as templates. So far, I really like the template piece as compared to views. I find them easy to follow and easy to create. Templates are created using handlebars which as also compatible with mustache.

Here are some components of Ember. Ember is comprised of es6 modules. The modules are a way of DRYing out code. Basically, these es6 modules can be used in other parts of the application so instead of having to just copy and paste code, you can just pull in the es6 module. There are also actions- Actions are events that trigger associated methods in the controller. They are always stored in an actions hash. Computed properties - A computed property mimics the behavior of a property and treats the templates variables as a value but it correlates to a function in your es6 controller. A function – a function can return an array so you can define a property to connect to a specific point in the array which makes it a nice way of filtering an array. For the property: Property (code that connects) to what the function depends on in the controller… which is defined at the top of the page (ie- Ember.ArrayController)

Models: The model is still used as the ORM for the database. The es6 module defines the attributes of the model and what type they are.

There are also routes, which are different from routes.rb. Each of the model pieces also have a routes part. The routes allow us to set different states. Different actions are available to the user based on what state the application is in. Defining those states, also allows us to determine what actions are available to us in the state and then make those actions happen. Separate from this, there is a router which defines the routes (paths) for the app and a routes.rb which define the rails paths.

One issue I’m currently having is determining what is pure ember versus what is a piece of the specific structure I’m using, which is Ember-appkit-rails. The most confusing piece of this are the controllers, models, and other components that are all held in the same directory. So, for example, when I’m working on creating a controller, I have to determine if it’s an es6 controller or a .rb controller… same thing with models.

Controllers. There are two types of controllers… an object controller or an array controller. Object controllers deal with a single object, array controllers deal with multiple objects in a collection.

Templates are the views in Ember. In a template, {{outlet }} tells the template where to render the code.

Finally, getting a little into additional ember pieces (this is the part I feel I still need to learn the most about), Ember-data is a library that lets you retrieve records from the server and hold them in the store, update them in the browser and then save them back to the server.

Here are a bunch more links for learning:
EmberWatch
Awesome intro talk on Ember for Rails devs
Great article on Ember
Ember docs
Ember appkit

More Ember posts to come!

Interesting Reads 3/15 - 3/21

A fairly diverse set of reads this week from agile development, to being a better programmer, to some cooking related things. Lots of good info in these, mostly short, posts and articles.

Enjoy!

Why Agile is failing

A great read on holocracy. One of the highlights for me, "Dysfunction happens any time somebody can't do something because they need permission, or won't do something because they're afraid of some repercussion."

The corruption of agile

"Don't burn yourself out to be a better programmer"

7 years of culinary science

No one knows what they're doing. Favorite quote: "The good news is that this makes you very not dangerous. The bad news is that it also makes you feel dumb and helpless a lot of the time."

Making technical decisions. Really interesting talk by Sarah Mei.

Sandi Metz's most recent talk slides. Can't wait to see the video!

So Many Random Learnings

I love learning and in the past few weeks, I've learned so much!! In lieu of a more organized post on this stuff, here’s a random smattering of what I’ve learned the last few weeks.

Ls –lM lists everything in list form
Git rebase –i sha is what you use in order to squash commits

Git rebase master… I’m still learning the process and exactly how to troubleshoot this but it seems standard in worksflows that require pull requests and it’s pretty interesting to solve merge conflicts.

Debugging (with capybara): insert a save_and_open_page to see what page/path opens

Alfred workflows are amazing. I’m trying to train myself to use my mouse less. My wonderful mentor suggested that instead of going cold turkey on the mouse, I should start by getting good at just a few things. So, I’m starting with Alfred workflows and trying to get better at not using my mouse within my text editor (sublime).

Alfred workflows that I have set up include spotify, dash, and being able to search for any file or folder on my computer. I’ve got the git workflow partially set up.

In Sublime text, one of the most useful things I’ve learned recently is CMD + . will switch back and forth between the test file and file being tested. CMD T allows you to type to open a file. Just to name a few.
Option and highlight lets you highlight the first letter of each line


Git commit (without –m, etc.) will open your text editor so you can do the commit message there, save it, close it and it’ll bring you back to the command line and finish the commit
Git checkout – brings you back to the last branch you were on
Git rebase –i HEAD ~1 rolls back 1 commit (~2 rolls back 2 commits)

From the command line putting touch and then the path with the filename at the end will create that file

When squashing commits (which means making multiple commits into one commit), you always ‘s’ (squash) the second one

Gem railroady produces a UML diagram of your code structure

Kill process… somehow I created a connection with a server and then I created a second connection with a server and then couldn’t get one of those connections to close!
ps aux | grep finds the process so you can see if it’s running (I’ve since used this ps aux | grep ruby and ps aux | grep puma)
Then kill -9 prodID (number all the way to the left) kills it. Alternatively, you can also kill it by doing killall -9 thin (or whatever you’re trying to kill)

Interesting Reads 3/8 - 3/14

First I have to read all the things I bookmarked for the week, then I can make the post of which of those things were interesting. Here's the list for this past week. Not too much actually, but what's here are some pretty short posts that are quite interesting.

Enjoy!


This week, I've been getting up close and personal with pivotal, learning it's tricks and how to better write user stories for the current build. Here's a great piece from a little while ago about some good guiding principles.

Using Pivotal for setting time estimates on chores and bugs... or not

Some interesting info on RailRoady, a cool visualization gem

I've been trying to learn more about all the words mentioned in this article (background jobs, multi-threaded, etc.). Chris mentioned Sucker Punch to me a few weeks ago. I haven't used it yet, but this post gives way more info about it which is nice.

Learning to Code is NOT Easy

In the past few months, the necessity to learn to code has been everywhere. It seems as though everywhere you look, someone is telling you to learn to code and there are very few dissenting opinions. With this push to learn to code has come a proliferation of bootcamps and other “accessible” opportunities to become a developer without necessarily needing a background in computer science.

But the idea of shoehorning people into a career and encouraging them by saying that learning is easy is a dangerous notion that hurts both individuals and the industry as a whole.

Learning to code is not easy, it is however, achievable and there is a big difference between those two words. You can learn the basics and know how to code, but to actually be a good developer takes years of practice and dedication. It is a craft that you need to constantly work on and improve upon. You can see this through the numbers of books and podcasts and meetups and mentorship and tutorials available to those in the field at all levels. Good programmers know that there is always more to learn and always ways to grow. They put in time during work and after work to continue to work to master their craft… and they love it.

Just like anything else, it takes hard work and dedication. You can learn to code in a short period of time, but it definitely doesn’t just happen. Oftentimes, people ask me how I learned so quickly (more often the question goes “Is it really that easy that you just started teaching yourself and were quickly coding and looking for a job?”) My answer is that no, it isn’t easy, but it is doable and in order to achieve what I did, I made as much time as possible. I go to meetups most nights of the week, code every day, and sacrificed other things so that I could make that time for myself. And to be honest, the thing I love most about coding is that it is constantly challenging and that there is always more to learn. For me, it’s not just the cool thing to do right now, and it’s not an easy path to making the big bucks. If you’re not passionate and you don’t do it for fun, you’re going to hate coding as a career.

There is a fine line between false advertising and being afraid you’ll discourage people from joining the industry, but we, collectively, are doing the industry a disservice by advertising that learning to code and becoming a developer is easy.

Here are some great articles I found along the way:
https://www.codefellows.org/blogs/this-is-why-learning-rails-is-hard
http://happybearsoftware.com/how-to-survive-your-first-year-as-a-programmer.html

Final Gem Post- The Action Class

This is a little out of order since it's been a while since my last post on the gem I helped build, but I wanted to get it out there. Feel free to refresh your memory by re-reading these posts 1, 2, and 3. The action class is a small, fairly simple class that is mostly used to just outline all of the attributes in an action item and then also distinguished a few method for specific attributes which are more common or may be requested more often.

The whole class looks like this:

class Action

  attr_reader :attributes

  def initialize(params) 
    @attributes = params
  end

  def title
    @title = attributes['title']
  end

  def description
    @description = attributes['description']
  end

  def reference_name
    @reference_name = attributes['reference_name']
  end

  def action_key
    @action_key = attributes['action_key']
  end
end

The initialize method sets up the class by just creating a hash that is the attributes hash and then the rest of the methods are just pulling out specific pieces from that hash. I’m not sure if by the end of this project, this class will be separate, but to me, it felt like it was doing different stuff than the ActionFetch class so I chose to separate it out.

Interesting Reads 3/1 - 3/7

A day late is better than a week late. Here are the interesting reads (and watches) from this past week.

Currently, I've been working on a bunch of analytics-related queries and tools. I came across this video about measuring which was really useful.

ember, ember, ember!!: http://www.confreaks.com/videos/2597-lonestarruby2013-ember-on-rails-realtalk

I rewatched this amazing Ben Orenstein talk this past week, refactoring from good to great. I had watched it a few months ago and a lot of the concepts went over my head so it's fun to see how much I've been learning!

Related to the questions I have as a professional programmer, some days are good and some days are bad. This was a great article that helped me realize everyone goes through the same roller coaster.

For Fun.

Beefing up those Comp Sci chops

For anyone who's been asked to FizzBuzz

The Maker's Schedule. An old article but still relevant.

New Questions as a Professional Programmer

There are a few steps, I think, in my early days of learning to code progression, where I feel as if leaps were taken. The first is when you start coding. There’s a lot to learn just about the basics at the beginning. The second is when you start tutorials… going though each of the steps, really processing everything and beginning to figure out what to do when you encounter errors and issues. The third happens when you move from tutorials to building your own thing. You’re no longer following directions. You are in charge of scoping out features, thinking about architecture, and solving errors and issues that others may not have encountered exactly. The last (so far) is when you start coding professionally (and getting paid for it). This involves learning new workflows and processes, integrating into a culture, and learning new languages and technologies to name just a few. Through each of these stages, I’ve developed a new set of questions and new things to worry/stress about. I think these questions also change depending on what phase you’re in. Over the last few weeks of coding professionally on a small development team, here are some interesting things I’m thinking worrying about on a regular basis.

1. Learning on the job is tough. The specific project I am working on is mostly written in Ember. It’s been a fascinating language to learn (especially since I previously didn’t have much of a background in javascript at all) and I’m definitely learning much faster since I’m building components and working in the language while learning it. But it is tough to learn amidst deadlines and due dates. How much do you need to know? Am I building things correctly in this new language?

2. How much time should I spend on something? This is a tough question. I want to learn and make sure I’m implementing the best solution but at the same time, how long do I take on something before I either move on, ask for help, or just put the best solution I know in place?

3. What is the normal “getting stuck” level? I feel like I get stuck at least once a day. Whether it’s something confusing on git, or a test that is failing, or some functionality I’m putting in place, every day I spent at least an hour trying to figure out how to move forward. Is this normal? Is it not? How much time do I spend “stuck” before I ping someone?

4. This is related to the question above but… when am I learning and when am I spinning my wheels? There’s nothing I hate more than pinging someone for help only to learn that the solution is super small and silly. I know this happens to everyone, but it makes me feel like I SHOULD have seen the solution and not bothered someone else. But then, there are times where I am reading EVERYTHING out there and googling and researching and breaking a problem into pieces and I wonder, am I spending too much time on this?

5. How much of the process should you follow? There are lots of process “things” in the programming world. Whether it’s test first, write code in the red, green, refactor order, spend time refactoring in general, pair, do code reviews, etc. I love all of these things, but I find myself weighing what process I should follow and how strict I should be with the process, knowing that there are deadlines and things that need to get done. I know it makes sense to do something the long way and then refactor, especially since as a newer developer I’ll learn more that way, but is it always worth taking that time? Sometimes worth it? How long should I spend on writing code vs. refactoring it?

This first position is really fantastic. I feel lucky because in most initial programming positions, developers find themselves doing one type of job or spending months on the ramp up. I was thrown into the deep end a bit from the getgo (which I almost prefer) and I get to do different things every day… rails, ruby, database stuff, javascript, etc. It’s great… wonderful and challenging but also stressful. I look back at the last four weeks and think of the crazy amount of information I have learned. It’s so different than self-teaching and working on projects that I created or things from scratch. And yet, it raises a whole new set of questions in my mind. I imagine that other developers feel the same way… especially in their first position.