These are the migration to start with.
The first one activate the extension HSTORE and adds an hstore column 'metadata' on the covers table
class AddMetadataToCovers < ActiveRecord::Migration
def change
execute 'CREATE EXTENSION hstore'
add_column :covers, :metadata, :hstore
| --colour | |
| -I app |
| class ImageAsset < ActiveRecord::Base | |
| include Flex::ModelIndexer | |
| flex.sync self | |
| #... | |
| after_find :fetch_extra_data_from_elasticsearch | |
| def fetch_extra_data_from_elasticsearch | |
| self.searchable ||= Flex.get(id: id, type: self.class.name.underscore)['_source'] |
This simple script will take a picture of a whiteboard and use parts of the ImageMagick library with sane defaults to clean it up tremendously.
The script is here:
#!/bin/bash
convert "$1" -morphology Convolve DoG:15,100,0 -negate -normalize -blur 0x1 -channel RBG -level 60%,91%,0.1 "$2"
| # Original Rails controller and action | |
| class EmployeesController < ApplicationController | |
| def create | |
| @employee = Employee.new(employee_params) | |
| if @employee.save | |
| redirect_to @employee, notice: "Employee #{@employee.name} created" | |
| else | |
| render :new | |
| end |
(from https://it.groups.yahoo.com/neo/groups/extremeprogramming-it/conversations/topics/11233)
Sono d'accordissimo che la competenza tecnica è fondamentale. Ma non è tutto; lo sviluppo software è un esercizio sociale e non è per niente scontato che mettere delle persone insieme produca la collaborazione desiderata. Anche se le persone sono bravissime tecnicamente. C'è dell'altro. Ci sono delle competenze specifiche che hanno a che fare con la collaborazione; ci sono delle skill che hanno a che fare con capire come interagire con le persone e capire come aiutare le persone a fare il prossimo passo. Bisogna studiarle. [...]
Quindi che cos'è un coach agile? Ci sono aziende che vogliono migliorare e si rendono conto di non riuscire a fare il passo completamente da soli. Il coach agile interviene lì. Qualche volta quello che faccio è consigliare una tecnica di programmazione, qualche volta spiego come funziona il planning game, qualche volta conduco una retrospettiva, qualche volta ascolt
Paolo Perrotta:
Eppure XP "funziona", nel senso che migliora il modo di lavorare delle persone. E Scrum "funziona", nel senso che convince il manager intontito dalle puttanate che ha studiato (o più probabilmente da quelle che non ha studiato) a cambiare approccio, costruire team di persone invece che accozzaglie di risorse allocate al 25%, mettere insieme un backlog anziché arrancare dietro al già accaduto, focalizzarsi sul timebox anziché sul timesheet, eccetera. Se vi sembra poco, siete stati più fortunati di me.
Andrea Tomasini:
Scrum è stato uno dei primi approcci "Lightweight" documentati, è come tutti gli altri che hanno seguito sotto l'ombrello Agile aveva ed ha ancora oggi l'obiettivo principale di installare una "nuova" cultura del lavoro basata su rispetto, collaborazione, auto organizzazione e focus. In un contesto di cambio culturale, seguire alcune pratiche è un modo per realizzare quei pattern comportamentali che producono la cultura che si vuole raggiungere. Non è però l'unico modo
Just connect to your Jenkins instance, localize the junit tests report folder (e.g. /data/jenkins/jobs/Jeronimo/workspace/Repository/target/surefire-reports) and then issue this shell command:
grep -h "<testcase" `find . -iname "TEST-*.xml"` | sed 's/<testcase name="\(.*\)" classname="\(.*\)" time="\(.*\)".*/\3\t\2.\1/' | sort -rn | head
These notes are taken while reading "Liftoff: Launching Agile Teams & Projects".
When projects start, a liftoff generates the momentum team need to overcome the inertia presented by lack of common purpose, unclear communication channels, undefined working relationships, and other areas of ambiguity.
A liftoff also provides the positive force that moves a project toward its destination's successful delivery.
A great proportion of the issues teams wrestle with can be traced back to a lack of clarity and alignment from early days of the project: miscommunications, unexamined assumptions, and misperceptions create an environment in which people make decisions and take actions that unintentionally work at cross-purposes and undermine overall progress.
Chartering in agile projects has the same general goal, but a different level of detail and set of assumptions. The goal of a Charter is still to describe the project at a high level, gain agreement into the W5+ (What, Why, Who, When, Where and How) attributes of the project and give authority to proceed. However, since agile methods are often used on projects with uncertainty around requirements / technology, and high rates of change, there is typically less certainty around scope.
In general agile charters have less detail, are shorter documents, and focus more on how the project will be run than what exactly will be built. This is because when aiming at a static target (unchanging requirements / technology) it is appropriate to plan, plan some more and then execute. In the dynamic and moving target environment of an agile project lots and lots of planning may not be appropriate if elements of the project are likely to change. So, when aiming at a moving target, we need to allow for mid flight