gem install rails
rails new my_app -T
# Variation on Hashrocket's script for managing the git process | |
# as documented here: http://reinh.com/blog/2008/08/27/hack-and-and-ship.html | |
# Create shell scripts out of each of these, put them in your path (~/bin for example) | |
# chmod 755 them and use like this: | |
# | |
# This version of hack is totally different than Hackrockets. I feel that hack implies | |
# that you are getting started, not finishing up. sink is Hashrockets hack. | |
# | |
# $ hack branch_name | |
# Test and Implement until done |
require 'eventmachine' | |
require 'evma_httpserver' | |
class MyHttpServer < EM::Connection | |
include EM::HttpServer | |
def post_init | |
super | |
no_environment_strings | |
end |
A test is not an unit test if: | |
* it talks to the database | |
* it communicates across the network | |
* it touches the file system | |
* it can’t run at the same time as any of your other unit tests | |
* you have to do special things to your environment (such as editing config files) to run it | |
Tests that do these things aren’t bad. Often they are worth writing, and they can be written in a unit test harness. However, it is important to keep them separate from true unit tests so that we can run the unit tests quickly whenever we make changes. | |
-- | |
by Michael Feathers |
#!/bin/sh | |
set -e | |
# Example init script, this can be used with nginx, too, | |
# since nginx and unicorn accept the same signals | |
# Feel free to change any of the following variables for your app: | |
TIMEOUT=${TIMEOUT-60} | |
APP_ROOT=/path/to/your/app/current | |
PID=$APP_ROOT/tmp/pids/unicorn.pid | |
ENVIRONMENT=production |
## Prepare ################################################################### | |
# Remove RVM | |
rvm implode | |
# Ensure your homebrew is working properly and up to date | |
brew doctor | |
brew update | |
## Install ################################################################### |
<exec failifexecutionfails="true" failonerror="true" | |
executable="${postgres.dir}/bin/pg_dump" | |
output="backup-ouput.txt"> | |
<env key="PGPASSWORD" value="${postgres.password}" /> | |
<arg value="-U" /> | |
<arg value="${postgres.user}" /> | |
<arg value="-h" /> | |
<arg value="${postgres.host}" /> | |
<arg value="-Fc" /> | |
<arg value="--blobs" /> |
# THANKS EVERYONE FOR YOUR BELOVED BENCHMARKS. | |
# THIS PATCH IS NOW IN RAILS: | |
# | |
# https://github.com/rails/rails/commit/885a599303585b796da7a0a1c3ccd0bc5c642134 | |
# Please add the following lines after Bundler.require | |
# and before "class Application < Rails::Application" | |
# in your config/application.rb | |
# | |
# Notice this is just an experiment, don't leave those |
This installs a patched ruby 1.9.3-p327 with various performance improvements and a backported COW-friendly GC, all courtesy of funny-falcon.
You will also need a C Compiler. If you're on Linux, you probably already have one or know how to install one. On OS X, you should install XCode, and brew install autoconf
using homebrew.
Vou iniciar este post com uma breve visão do que EU entendo sobre os principais XDD para em seguida discutir o motivo pelo qual não os acho relevante. Gostaria também de ressaltar que posso SIM ter uma visão limitada ou equivocada destes XDD’s, porém não vamos minimizar esta discussão com argumentos simplórios como “falta de conhecimento”, “falta de prática” ou coisas do gênero... pois o que será discutido aqui é um pouco mais conceitual e filosófico do que as técnicas/processos em si.
Com isso dito, vamos lá:
Esta técnica (ou processo) que visa obter uma maior qualidade na arquitetura/código, pois guindo o desenvolvimento por testes além de se ter um resultado mais assertivo, você também obtém uma arquitetura desacoplada. Geralmente se aplica este processo (NovoTeste->Falha->Implantação->Sucesso->NovoTeste...) em pequenos ciclos.