zkwentz

1. Be Up Front

Perception Management is Just Preparation

If you know somehting is coming up that will impact how you are perceived. Right or wrong, be up front about it. Don't damn the other party telling yourself they shouldn't feel this way. And don't try to sneak it, finding a way or some in the moment excuse. Instead, be very upfront about it and put a workaround in place. Colleagues in town and you have to leave early? Put a calendar invite with your time letting them know and apologize, and then setup some time with each earlier in the day.

All projects cost the same amount of time, stress, and resources.

You have these three pools to pull from; time, stress, and resources. If you don't have the resources, you're going to pull from one of the other two. Choose how much from each ahead of time, and be upfront about it with yourself, with stakeholders, with the team.

Put the bottom line up front.

Lead with the BLUF

zkwentz

• ✅ Dissecting Git's Guts. Emily Xie
• Pro Git. Scott Chacon and Ben Straub
• Git From the Inside Out. Mary Rose Cook
• Git from the Bottom Up. Josh Wiegley
• Advanced Git: Graphs, Hashes, and Compression, Oh My. Matthew McCullough
• Unpacking Git Packfiles. Aditya Mukerjee
• Visualising Git's Merkle DAG with D3.js. Tyler Cipriani

zkwentz

{
  "BTTPresetName" : "vas3k v2",
  "BTTPresetUUID" : "DA11492E-9150-4295-9076-842A309D928A",
  "BTTPresetContent" : [
    {
      "BTTAppBundleIdentifier" : "BT.G",
      "BTTAppName" : "Global",
      "BTTAppSpecificSettings" : {

      },

zkwentz

module Sentanalyzer

  module Initializer
    def initialize(*args)
      self.sentihash = load_senti_file('./sentanalysis/sentiwords.txt')
      self.sentihash.merge!(load_senti_file('./sentanalysis/sentislang.txt')) 
      super(*args)
    end
  end

zkwentz

import DS from 'ember-data';

export default DS.FixtureAdapter.extend({});

zkwentz

import DS from 'ember-data';

export default DS.FixtureAdapter.extend({});

zkwentz

export { default } from 'ember-data-fixture-adapter';

zkwentz

A Pattern for Promised Properties

Computed properties and promises, historically, just don't mix. In fact, a lot of developers have devoted a lot of time to avoiding the problem altogether. I work with Ember data a lot, and therefore promises and computed properties a lot, and I'd like to share my pattern for dealing with promised in properties. And how that helped me develop a good pattern for dynamically-keyed, computed properties.

Both of these examples that follow are contrived and both could more easily done in a template, but they come together in a good example where we need to filter a model's hasMany children by a belongsTo relationship on those children, and pass those to a select as options. It shows both the need for these techniques, and yet how much of a corner case they are.

zkwentz

`import DS from 'ember-data'`

Post = DS.Model.extend(
  title: DS.attr('string')
  body: DS.attr('string')
  
  comments: DS.hasMany('comment',async:true)
  
  user: DS.belongsTo('user',async:true)
  

zkwentz

Problem

Ember-validations, was built to define the validations outside the model, and if you define them on your model, it will cause server-side errors to no longer work correctly (still unsure why).

Solution

In this example, we pull the validations off the model, and attach them to our error-wrapper component.

The solution outlined here allows gives you three benefits: