Gotcha
Error: The provided key element does not match the schema
Fix: for an AWS endpoint, when trying to do an UpdateItem action via api-gateway, you need to set the method to POST instead of PUT, since the AWS endpoint only takes POST calls
Problem: you just created a new instance, and even though you told it to be publicly available, you can’t connect to it using the provided endpoint….
Solution: you need to explicitly add your current ip address to the security group you are using. Their default security group is miss-leading: even though it says it will accept all traffic from everywhere, it doesn’t (sad panda). Once you add a new security group and attach it to the redshift instance, you will be fine fine fine.
Source of the solution: the infamous stackoverflow:
https://stackoverflow.com/questions/19842720/cant-connect-to-redshift-database
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());
});
1) Install node.js https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager
2) Install express framework:
$ sudo npm install -g express@2.5.8
Note: if you get an error message at this point, complaining about some “Karma” package. Run the following
$ npm uninstall -g generator-karma && npm install -g generator-angular
3) Create your application:
$ express my_app
$ cd my_app && npm install
4) Login your heroku (if you haven’t), and start git
$ heroku login
$ git init; git add .; git commit -am “whatever you want to say”
5)
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:<inputtype="text"name="animal"list="animals"/><br/><datalistid="animals"><optionvalue="Moneky"><optionvalue="Donkey"></datalist>
<inputtype="tel"name="phone"required/> /* Handle phones */
<inputtype="email"name="email"/> /* Emails */
<inputplaceholder="enter your 5 digit id number"type="text"name="idNumber"pattern="[0-9]{5}"/> /* You can customize your own patterns */
<inputtype="number"name="quantity"min="1"max="50"value=""/> /* You can validate numbers this way */
<inputtype="date"min="2012-03-12"step="1"max="2012-05-12"name="departingDate"/> /* Produces a calendar pick for you */
<inputtype="range"name="shoeSize"min="0"max="15"step=".5"value="3"/> /* Produces a range scale */
<metervalue="3"min="0"max="10"></meter><br/> /* Displays percentages in a meter kind of graph */
<progressvalue="35"max="100"></progress> /* Display a progress bar */
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.
CRTL J – Brings online help for the text you have your mouse on