firebase setup

Basic startup command:

npm install -g firebase-tools

firebase login

firebase init (make sure you click the space bar to select an option, otherwise your firebase.json file will be empty)

create an index.html page in that dir

in the firebase console, click on the “add firebase to your web app” button, and put your javascript code into the index.html page

 

 

Recipes: how to listen to DOM insertions

The technique described here (more details in there):

http://davidwalsh.name/detect-node-insertion

It basically involves putting a CSS animation to the elements that will be attached in the future. When they get inserted, they run the animation, and when the animation finish running, it throws an “animationstarts” event.

The last part involves attaching a listener to the parent DOM, so when the CSS animation thrown the event, it is catch and processed there:

parentEl.addEventListener("animationstart", insertListener, false); // standard + firefox

You could also use the ‘DOMNodeInserted’ event, but it will be deprecated:

currentBox.bind(‘DOMNodeInserted’, function(e){
currentBox.find(‘object’).attr(‘width’, currentBox.width()).attr(‘height’, currentBox.height());
});

HTML5: Form fields

New attributes:

autofocus=”autofocus”

required=”required”

oninput="updateMessage(this)" /* You can run custom JS on input */

autocomplete=”on”  // Remembers what the users enter in the field before, and makes it available for autofill. If you want to create your own list of autofill values:

Choose an animal:  <input type="text" name="animal" list="animals" /><br />
  <datalist id="animals">
   <option value="Moneky">
   <option value="Donkey">


  </datalist>
<input type="tel" name="phone" required /> /* Handle phones */
<input type="email" name="email"  /> /* Emails */
<input placeholder="enter your 5 digit id number" type="text"
    name="idNumber" pattern="[0-9]{5}" /> /* You can customize your own patterns */
<input type="number" name="quantity" min="1" max="50" value="" /> /* You can validate numbers this way */
<input type="date"  min="2012-03-12" step="1"
                         max="2012-05-12" name="departingDate" /> /* Produces a calendar pick for you */

<input type="range" name="shoeSize" min="0" max="15" step=".5" 
value="3" /> /* Produces a range scale */
<meter value="3" min="0" max="10"></meter><br /> /* Displays percentages in a meter kind of graph */

<progress value="35" max="100" >
</progress> /* Display a progress bar */
 

Agile: the basics

 

Core values:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negociation

Respond to change over following a plan.

Notice the word “over”, not “instead of”

At its core:

1) Plan and release small iterations.

2) At the end of each iteration cycle, there should be a full set of testing and verification of what was released. Ideally continuous integration and automated testing.

3) Every day progress is measure to see if small iteration goals are to be made.

4) Your product manager should be the coordinator / director / bottleneck. He must be constantly checking progress / resources / trends / grooming the backlog / re-prioritization / leading in the right direction

5) Plan / Do / Check / Act. Imagine a cannon arm, where you have to constantly adjust the angle until you hit the target.

6) Always organize a retrospective at the end of each cycle: it is important to evaluate the work done / take corrective action / adjust.

7) Project division:

Phase 1: Build the simplest system span of neccesary, barebone features first

Phase 2: Corner cases / security / flexibility / other important things on top of bare bone features

Phase 3: Refine UI / bells and whistles, secondary features, nice to haves, etc

8) Release objectives: Quality, Speed to Market, Features (number of), Brand, Reputation. Unfortunately, each one of those areas takes time and sometimes cancel each other out, so you have to balance out which ones you are to pursue first in the time given. Or if you want it all, plan a high amount of time accordingly. Or make a plan B for the ones you won’t meet.

9) Constantly prune and groom your backlog, with the following (changing) dimension in consideration at all times:

– Vision (the grandiose high level idea that will deliver you to the promised land)

– Themes (formalizing the direction towards the vision, you may have more than one theme / path to make it happen)

– Narratives (Describe your theme. high level summary of your product or service, and how it will “get you there”)

– Epics (The narrative, translated to high level features)

– Stories (Breaking down the high level features in small increment tasks and sub-features. Must be doable within one sprint, or broken down further if they don’t fit)

Type of sprints:

Push sprints: points to be burned are pre-planned and preset. They can be checked against a burn chart at the end of the sprint.

Pull sprits: kanban. The back log is maintained to have the highest items that need to be taken care of on top of the list. Developers pull the items from the top as they become available to work on them. Items sit on the following categories: Ready, In Progress, Ready for Verification, Done

Incremental vs Iterative approaches.

– Incremental: you add complete features to the product, one a a time. Riskier because you may get too close to release date with a few key features not even started.

– Iterative: you work mostly in the most important features, but make sure you also build the secondary stories, enough to reduce the risk of an entire section of your product becoming all of a sudden a must-have and you haven’t start it. Or spending a lot of time in a section where at the end won’t be as important as expected at the beginning, in which case, abandoning it won’t be such a loss

 

Other considerations:

– Collective wisdom: at estimation time, the more input you have, the more accurate the estimate is (bell curve, mean indicates the best approximation to the right answer)

– Failure does not mean bad resource / employees, but inability to lead them in the right direction. As long as there is the trust where they are willing to succeed, it should be a matter of coaching them and leading them into that. At the end of the day, who really wants to fail?

– In software development, there will always be a high amount of uncertainty about how long the project will take. Which will be reduced as you work along. Have that into consideration, and plan accordingly

– You don’t have to finish a product through to validate if it will deliver you to your company vision and objectives. Try to validate your vision / themes / epics / features as fast as possible, way ahead of release date. Sometimes you don’t have to build a complete finish product to see nobody will use it. Get early feedback. Put out alphas and betas. Mock features and measure the click-through rates to them. Validate your vision before it is too costly to readjust it or abandon it.