Austin Story

Ruby, Rails and Javascript Blog

What are the alternatives?

By Leave a Comment

I have reflected a lot recently on how difficult it can be to deliver agilely estimated stories on time.  Estimating is hard because you really can’t know how long something takes to do until you do it.  But it is also easy after you starting a story to get off track into a cycle where a story is either underestimated or over delivered.  So that looks like this.

Dev says I think this will take a day

Dev starts and works for a day, then keeps going

Dev delivers on day 2, story goes through QA and is finally delivered on day 3

Most of the time, the scope creep is discovered only after the story is completely finished as the manager is crunching velocity.  The dev feels bad that he was 3 times slower than expected on the story and the manager wonders why their teams velocity is so low.

I think there can be a different perception on estimates.  You can’t estimate the task, but you can estimate your perception of the task, and when your perception is off, it is a good opportunity to discuss the new perception with the other people on your team.  In the scenario above, on day two the dev’s perception of the task was off and he needs to re-estimate the task with at least one other team member.  This is a positive check and gives the opportunity to meet and ask the vital question “What are the alternatives to your current approach?”.  At a minimum, your perception of the task has changed and you can discuss if your current approach is ok or if there are different ways to go at the problem.

Simple and effective. I think this could have several benefits with the main being the dev will focus on the problem instead of their current solution and evaluating the course they are going on relative to the overall big picture.  It also has the positive check from someone else on the team to lend input.  I’m not sure how this will pan out but plan on giving it a go and then will report back here after some time.

Quickly Understand Webpack Style Loaders

By Leave a Comment

This is a summary of an exceptional video I watched on youtube related to webpack 2 style loaders.  All concepts here are still relevant in the most recent webpack version (4)

Definitions
CSS-loader – Takes your css files and adds them to your bundle
SASS-loader – takes sass/css files and adds them to your bundle.
Style-loader – Takes a stylesheet that has been added to your bundle and converts it into a style tag. I.e. load your css to style tags.

To use any of these loaders just add them to your rules like this.

rules: {
  test: RegExp, use: [applied, in, reverse],
  test: /\.scss$/, use: ['style-loader', 'css-loader', 'sass-loader']
}

But this inlines each of your styles as it’s own individual file into the header. What if you wanted to just include a single file?

Enter the extract-text-webpack-plugin

It wraps all the files and then combines them into a single file. You add this to the plugins area

plugins: [
  new ExtractTextPlugin({
    filename: "new-stylesheet-name.css",
    disabled: isDev,
    allChunks: true
  })
]

and then update the scss rule to use the plugin

rules: {
  test: /\.scss$/,
  use: ExtractTextPlugin({
    fallbackLoader: 'style-loader',
    loader: ['css-loader', 'sass-loader'],
    publicPath: '/dist'
  })
}

How does VueJS 2 Server Side Rendering Work

By Leave a Comment

VueJS comes with a lot of SSR built in. Sometimes SSR can seem a little mystical but at its heart it is really these things

a. Compile and render your component and it’s children
b. Generating your styles and initializing store if you use vuex
c. Assembling all of that
d. Taking care of sourcemap stuff
e. Responding in the way the client expects

This code lives in vue/src/server and the function that coordinates all of this lives in `create-bundle-renderer.js`. It exports a function called createBundleRendererCreator that does the following things.

NOTE: bundle is a generic term for a specification for mapping file names to js and source maps

1. Creates a String or Stream renderer based on what is specified
2. Load the bundle (it can be a file reference, string or object generated by VueSSRRendererf)
3. Create an function that can use that bundle to create a component given a context
4. return an object that can use the renderer from 1 to render a String or Stream

With this in place vue-server-renderer is able to use this to generate and serve your components.

a. render.js => utility functions for generating and cache a component
b. vue-ssr-html-stream.js HTMLStream => Takes care of assembling vuex, head and css
-> pulls template from index.html and reassemble
-> Creates __INITIAL_STATE__ in _flush method
-> Adds css form vue-stle-loader
-> adds head data from server-renderer
c. create-renderer.js

VueJS will follow this algorithm when attempting client side hydration

1. It will always attempt to hydrate when the root node has data-server-rendered attribute.
2. In dev mode, if it failed to hydrate there will be a warning. If nothing happens, it worked.
3. In prod mode, it assumes the markup is correct.