Allen's Programming Shed

The diary of a programmer

[pterofaur]

Developer Diary Week 51

Doings:

Ember 1.13 upgrade all day every day

Thoughts:

Feel a lot more confident with the new Ember workflow

I now hate the observers with a passion

I have reassessed how computed properties should work. There really shouldn't be multiple computed properties that recompute on the same property. Otherwise you run into weird race conditions if you have complex interactions.

[pterofaur]

Developer Diary Week 43

Doings:

Rails Girls mentoring

Ember 1.13 migration

Hating generating xlsx

Built a Ember 2.0 ready drag and drop prototype for giggles and edification

Thoughts:

Shout out to my incredible mentees at Rails Girls, the future is in good hands. Teaching is pretty tough. I'm going to work on explaining stuff. "They don't think it be like it is, but it do", thats what I sounded like explaining MVC. I promise I know what I'm talking about.

Ember 2.0 is a pretty cool guy, that doesn't afraid of anything. I'm starting to embrace data down actions up wholeheartedly now that I've used the new action currying. Some weirdness in the component life cycle hooks though.

[pterofaur]

Developer Diary Week 38

Doings:

Didn't do much, just changed my life by getting married

Thoughts:

Thank you to my intelligent wife and beautiful wife Yen for agreeing to marry this clueless but sometimes handsome fellow

I would have never had the guts to become a programmer if it were not for her undying support

Getting married is pretty fun

[pterofaur]

Ember 1.12 to 1.13 Part 1

Introduction:

We are moving to 1.13 for Ember and bring some snacks because its going to be a long ride.

Lifecycle hooks:

Model hook in route - I haven't confirmed this behaviour I will ask on the official repository if this intended but now if you don't explicitly declare the model hook in a route, it returns a params object on hard load of the URL whereas previously you would have a model from a parent route.

Components - I have rewritten the base select component using the examples on the Ember docs with two way binding to provide drop in replacements for {{view "select"}}. The new component React-ish life cycle hooks are pretty cool but some of the use cases are still unknown to me.

One our components, a td in a table that communicates with a graph above and highlights when the mouse is over the data point in the table, rerenders a lot. This is because rerenders are now fired on any attribute change. I thought rerenders would be cheap. But this table seems to be performing badly so we will need to investigate.

I had a discussion with my CTO about the merits of two way data binding. I have come to the conclusion that sometimes its ok. If you have a form that is bound directly to data that seems reasonable and avoids propagating a bunch of unnecessary actions. I do like the new way of passing actions and contexts down into components.

[pterofaur]

Ember Fail of the Day

I go to work and Ember isn't a stranger. I feel like we are seasoned detectives on the beat solving crimes. I've got marital problems and Ember has a gambling habit but we understand each other. But then, somedays I have an out of body experience where Ember surprises me. I think, I really don't know you. I didn't even know you had a brother.

Problem:

I was wrapping the excellent jQuery datatables plugin in an Ember component. For some reason I always assumed that props passed down a component are observable. Wrong.

My assumption was that props passed in to components would not adhere to the normal computed property rules. I have always had this assumption and for some reason it has only bitten me 6 months down the line.

In actual fact props, as we are still in two way binding as default world, are pretty much implemented as Ember.computed.alias("propName"). So the exact same rules apply. If a property is not consumed in the template or by a get it is never computed. This is something I learned in my first couple of weeks with Ember.

This may change later on with Glimmer and cheap rerenders.

Moral of the story, don't believe in magic.

[pterofaur]

Developer Diary Week 34

Doings:

Every day I'm Emberin'

Wedding planning

Signed up for Functional Progamming in Scala and Machine Learning at Coursera

Golang Meetup at Optiver

FinTech Meetup at Vivant

Made my first pull request to a stranger's repo - It was an Ember wrapper for bootstrap date picker, I will count that as open source

Thoughts:

GraphQL is sick, seeya REST, I'm going to explore it and try to get it implemented at work as soon as I can

Really interesting talk about the state of FinTech - I wonder how Tyro got a banking licence

[pterofaur]

EmberTricks[1]: Overwriting data store

Scenario:

I had a form that after submit could be modified on the backend. I needed to handle this and display the newly modified form.

Solution:

The success callback doesn't have any reference to status codes so I handled it in error

this.store.pushPayload is a pretty cool guy and will push a bunch of stuff into the store. A bunch of stuff is necessary. It will only push pluralized models in the payload. ie. users, posts not user, post. If you have any singulars you will have to munge the payload to pluralize the keys and wrap the data in an array.

Render the response as normal with an error status. I used code 409 to indicate a conflict

In the error callback you have access to an object that includes the status code and the response in responseJSON.

When the error is my custom status, I this.store.pushPayload(errorObject.responseJSON)

Now, this is the weird bit. I had the misconception that updating the models will overwrite the most recent changes as the "canonical changes" however this is not the case. Any changes you have made on the front end will still stick around. You actually need to record.rollback() for the model to reflect what you backend has returned.

[pterofaur]

Developer Diary Week 30

Doings:

Trying to integrate Zork into a Slack group that I admin for my GA Web Immersive class

Ember all day

Thoughts:

Had a thought that I should start a Sydney Ember meetup, hey if Adelaide can have one, why not?

[pterofaur]

EmberTricks[0]: Force firing observers and listeners

Scenario:

You have a property or observer that just doesn't want to fire. In my case, we were using a separate controllers with one route to render modals. The modal was for editing some properties of a model with one catch, if I pressed cancel I wanted to rollback only changes for those properties and not the ones outside the modal. ~~model.rollback()~~

Requirements:

I want to listen to when the model changes so that is the approriate hook to observe.

Be able to clear forms on cancel and save

Be able to load current properties

Be able to do partial rollbacks on an unsaved model

Problems:

Listening on model means that it doesn't refire unless the model changes in some way

After pressing cancel and clearing the form it won't refire if you enter with the same model and forms and not pre populated

Binding directly to model properties will refire the the observers and properties but I will lose the ability to partially roll back a model.

Solution:

Create properties and observers that listen to model

Create proxy properties on the controller that hold the value for model

Set the model property to the proxy on save, clear on cancel

Set observers and properties to refire by calling this.propertyDidChange("model") after form is cleared.

[pterofaur]

Developer Diary Week 27

Doings:

Ember all day and night

Learning Go

Wedding planning

Thoughts:

Everyday I have moments where I understand exactly what I'm doing with Ember and then in moments I feel sheer terror and have no idea what's happening anymore. I have a habit of hacking around stuff I don't understand its served me well when I was learning. The mentality and persistence learned is great. But maybe, it's become a crutch I lean on to avoid understanding exactly the heart of what I'm doing. Why are controllers singletons? Should this be a component or just a HTMLbar helper? Should I do this right way or just the first way I can think of?

I made my first big mistake at work today. Had a bug in my code that in the end was pretty simple to fix. Was deployed in the 10 minutes before showing to the client so oops. Going to master these front end acceptance tests because I need them to sleep at night. My greatest weakness is my lacking attention to detail.

[pterofaur]

Your brain on programming

Recently, I have finding it difficult to speak. In general. I cannot form complete narratives that didn't end abruptly as soon as I grow bored of the thought.

Conversations have been hard to have. My mind just wanders and I feel like I have nothing to interesting to offer that isn't a random tangent.

My Symptoms:

lack of concentration

lacking social skills

stuttering

I would like to think I haven't always been like this or it hasn't been bad as it has been recently. Maybe I am predisposed to becoming socially disabled but I do feel like my brain is changing.

The word flow is used to describe the hyper focus that is attained when conditions are right. I wonder whether maintaining this state for long periods makes you act differently while resting. Maybe my brain wants to balance its super focussed state with relaxed drifting. I think I might try some meditation.

[pterofaur]

Ember and Rails and Nested Attributes

Nested attributes are really nice for reducing requests to your API. But EmberData doesn't handle them that well.

Problems and Solutions

Using accepts_nested_attributes_for expects the nested attributes to be under the key {model}_attributes but EmberData ActiveModelSerializer adapter doesn't want to do that so you will have to patch that. A variety of fixes are available on GitHub. Hopefully its pulled into EmberData eventually.

Make sure that you understand how you are serializing and deserializing your nested attributes. It may always be in records or it could be serialize: "records, deserialize: "ids". Look for Ember not recognizing keys in your payload.

When you are creating the nested attributes on the front end you will probably need some kind of proxy object.

You cannot rely solely on computed properties when saving and reloading models with nested properties. You must set _destroy on objects that have been persisted to the backend. However, you can't unload these records from the front end until you save the parent model. EmberData has no idea how to process the model that is returned. The destroyed models are not in the response payload but it assumes that the current ones you have on the client with _destroy tags are new instances. You must unload the orphaned records on your own. Just look for the _destroy: true flag on your child models associated with the parent after the promise resolves.

[pterofaur]

Ember Pitfalls

Things I have learned the hard way about Ember

Gotchas

Controllers are singletons. Oh my god controllers are singletons. I don't care if you have a new model. That controller is the same controller. Kept forgetting since I came from Rails and treated controllers like Backbone views. If you have weird behaviour of some data from another model being present, it means you didn't write your code reactively enough. eg. More computed properties based on the changing model or you haven't torn down some properties. This will probably be solved when routeable components arrive.

Model hook doesn't fire after the route has been loaded if you transitionTo or link-to the route with a model. If you do either of the above with an ID it will refire. Use afterModel if you want to get something all the time.

All model and afterModel hooks fire before any setupControllers fire. ie. Child routes model and afterModel fire before parent route setupControllers. Do not rely on doing this.controllerFor in an afterModel or model hook it might not be there when you expect it to be. Another thing that will go away hopefully.

Do not setup empty objects or arrays on the controller. Controllers are singletons remember. Setting someArray: Ember.A() will mean even when you have a new model. There won't be an empty array. It will still be populated with the same junk. If you want to intialize an empty array or object everytime the route is visited set it up in an .on("init")

Sometimes you can't always rely on computed properties. This applies especially if it needs to be done in order. I will make a separate post about what made me realise this.

To send actions from components inside components you need to create a chain of actions up through the components.

Thats all that come to mind right now. You have to remember that Ember is changing everyday. The code we wrote 6 months ago looks nothing like the code we write now. I can't wait for the new routeable components and rendering engine!

[pterofaur]

Developer Diary Week 25

Doings:

Made a fool of myself at SydJS by announcing a job, in other news Kinesis is looking for junior to medium sized front end JS developers

Ember all day and night

Thoughts:

I have been feeling a bit of disquiet lately with my code. Something like, is this code really going last more than 5 seconds before someone needs to rewrite it? I feel like I'm wandering off the beaten track and I don't have the confidence to say that there were good reasons I came out here.

Solutions:

In my previous post I was mulling over the benefits of implementing the ability to make incredible queries such as: include=xmodel+ymodel. I still maintain that is the way to go. I have come to a interim solution where I have multiple serializers for index summary returns without children and full recursive serialization. The system is simple against parent models that I hit on the afterModel hook in Ember. Its not perfect and requires more metaprogramming and thought but it is more performant than the alternative of being strictly RESTful.

[pterofaur]

Developer Diary Week 23

Doings:

Ember - all day all night

Building a Rails API

Thoughts:

I think Ember's biggest advantage is Ember CLI. It manages all that minutiae that you really don't want to think about eg. folder structure, dependencies, live reload. Less cognitive over head is awesome.

Reactive programming is the way to go for front end programming. I will never go back. By reactive I mean something like numberOfWidgets = widgets.length. But! Instead of that being numberOfWidgets being equal to the value at that point in time. numberOfWidgets is bound to the value of widgets.length and anytime that widgets are added or removed numberOfWidgets will be recalculated and functions it participates in will be recomputed. You can imagine how useful this is for managing state and asynchronicity on the front end.

What is boggling me at the moment is how to design a nice backend API. When you arent using a websocket it doesnt make much sense to get each model and association one at a time. Maybe even if you are, you will be smashing your DB pretty hard. This post has inspired me to make my APIs more flexible and push the mess of what to serialize to the front end by making very specific queries. I have no idea how to implement this yet.

[pterofaur]

Developer Diary Week 20

Doings:

Moving house

Ember.js

Go - finishing tutorials

Exercism - Check it out for feedback on your code

Thoughts:

I love exercisms tiny little consumable puzzlers. The feedback system is also super cool. It is very interesting to compare your work with others and see how others approach problems.

My Ember knowledge is still WIP. Ember CLI is wicked cool with its Rails-ish convention over configuration paradigm. No more _this=this! Thinking about building elements that are reactive and declarative has been somewhat of a epiphany. I still need to think hard about my implementations of observers and computed properties before reaching for the jQuery event hammer.

I excited about building some UI elements!

[pterofaur]

2014 Retrospective

Doings of 2014:

Left the job I had for 6 years that I hated, with the encouragement of my dream girl

Moved cities

Got a job in my former dream career

Left that job because it wasn't me

Had heaps of fun and committed to my passion for programming by doing the Web Development Immersive at General Assembly

Proposed to said dream girl

Became a professional developer

Thoughts:

Everything's turning up pterofaur.

Hopefully 2015 is just as good.

Yen, who is reading this right now, over my shoulder, I can't thank you enough for sticking with this lost soul. Every time I doubted myself, you supported me. You believed in me when I didn't. There aren't enough song lyrics to express how much you mean to me.

Future Doings:

Follow through on the things I say I will do, give it at least 5 mins

Put the lid on all kinds of stuff

Be a better developer