Muito se tem falado sobre a Regulamentação da Profissão de Analista de Sistemas e suas Correlatas, a discussão é grande, e existe muita gente a favor, muita gente contra e algumas em cima do muro.

O que eu vejo é que muito se fala sem ao menos saber do que se trata. Pouca gente percebeu, mas quem leu a lei na íntegra sabe, para ministrar aulas, ou escrever em blogs (Eu sei que é muito, mas podemos interpretar a lei assim) sobre qualquer coisa que seja de domínio de um “Analista de Sistemas” só poderá ser feita por um Analista de Sistemas.

Não somente isso, mas pesquisas e experimentação só poderão ser feitas por Analistas de Sistemas. Ministrar aulas só poderá ser feita por Analistas de Sistemas.

A lei não da direitos as pessoas que são formadas, por exemplo, em Administração, mas com mestrado em Engenharia de Software a ministrar aulas de Engenharia de Software, pois isso só cabe aos formados em Ciências da computação, processamento de dados ou analistas de sistemas.

No twitter, alguns falaram que a maioria é Pessoa Jurídica e como empresa tanto faz a lei. Isso é um engano, a lei é clara, punirá quem estiver trabalhando como Analista de Sistemas e não for registrado no conselho regional de informática (CREI) ou quem facilitará a quem não é registrado e comprovado Analista de Sistemas a exercer a profissão.

Ninguém ainda sabe como ficará profissionais que trabalham em casa para empresas que ficam em outros estados (Como eu já trabalhei no ano passado). “Eu vou ter que me registrar no CREI aqui no Piauí, em São Paulo ou nos dois?! Por quê a sede da empresa é em São Paulo e eu trabalho em casa!”.

E como ficará o trabalho internacional!? Existem pessoas que fazem outsourcing para empresas na America do Norte, Europa e outros lugares do Mundo, como ficarão essas pessoas!?

Ninguém está preocupado com o impacto imediato que esta lei tem, e o pior, ninguém está se preocupando com o impacto dessa lei a daqui 10 anos. Onde o Brasil será mais uma vez uma nação que consumirá apenas a sucata que é criada lá fora, por que essa lei limitará em todos os aspectos o desenvolvimento tecnologico do nosso país.

Mais uma vez o Brasil está nadando contra a maré querendo “inventar” um impedimento do desenvolvimento de conhecimento. Mais uma vez o Brasil afundará com uma medida que não tem lógica. Mais uma vez nosso país está fazendo o contrário do que pensamos e queremos!

Um pouco de história por aqui. Durante o Oxente Rails fomos “contaminados” de coisas boas :D

Agile, Pair Programming, Espírito Open Source e resolvemos que devíamos trazer esse tipo de ambiente aqui para Teresina! Eu e o Cleiton conversamos com todos os piauienses que foram para o Oxente Rails e ficou certo uma data para realizarmos o primeiro Coding Dojo aqui no Piauí.

Foi um evento FODÁSTICO. Não tínhamos nenhuma experiência sobre como fazer o Coding Dojo ou como nos organizar ou qualquer outra coisa. Para um Dojo “Piloto” nós fomos muito bem!

Partimos para o segundo e foi melhor ainda. Não por que foi ótimo e resolvemos o problema, mas por que tivemos nossa primeira experiência ruim! E como nas metodologias Ágeis, nós aprendemos com os erros! O feedback foi essencial no segundo Coding Dojo.

Para o próximo, que vai acontecer nesta semana, considero que será um dos melhores! Vamos fazer um rodízio melhor!

Se você quiser participar do Coding Dojo, entre no nosso grupo e fique ligado no que vai rolar na lista, ela está sendo super importante para a gente melhorar o Coding Dojo a cada edição!

Eu fico feliz em saber que tem gente fora do nosso estado que está gostando do que nós estamos fazendo aqui no Piauí! Eu acredito que nós podemos nos tornar uma potência em computação! Basta nos esforçarmos! :)

Esse foi o tema da desconferência que eu e o Cleiton Francisco meu amigo josu que trabalha comigo no Jus Navigandi apresentamos no OxenteRails.

Contamos a nossa experiência em até colocar no ar uma aplicação livestream usando o Sinatra, a api do twitter, uma tabela no sqlite pra servir de cache e um pen drive como repositório.

Olá, hoje vou contar apenas uma das histórias de desenvolvimento que vivenciei.

Há alguns anos trabalhei em uma empresa de desenvovimento, e lá nós tínhamos papeis bem definidos! X semanas eram de análise, Y semanas de desenvolvimento, Z semanas de design, e assim foi-se.

Durante 8 meses nós desenvolvemos assim, onde o cliente só conhecia o sistema dele uma vez ou outra nesse tempo todo. Nosso prazo já estava estourando e com certeza nós tínhamos cerca de 25% do projeto concluído.

Faltando pouco mais de um mês para finalizar o prazo do projeto, o cliente desesperado queria algo do sistema para poder trabalhar, ele não aguentava mais o sistema atual e a promessa desse novo sistema o fazia querer mais e mais o seu uso.

A equipe então perguntou o que o cliente queria logo de imediato. Paramos todos os códigos que estávamos fazendo e fizemos tudo o que o cliente queria. Foi nesse período que começou o respiro Ágil.

Nessa época de desenvolvimento eu não tinha nenhum conhecimento sobre Ágil, metodologias de desenvolvimento, testes, ou qualquer outro tipo de conhecimento Ágil.

Sentamos com nosso cliente e em duas semanas ele estava com uma parte do sistema pronto e já estava usando em produção! Nessas duas semanas nós trabalhamos com o cliente ali do nosso lado, desenvolvendo e mostrando a cada commit, fizemos isso e conseguimos ter um cliente “satisfeito”, ganhamos um pouco mais de prazo.

Logo após isso eu saí dessa empresa e nunca mais tive contato com ela, até pouco tempo atrás.

Conversando com um dos sócios da empresa, perguntei sobre esse tal projeto, e como eu já sabia e deduzira, o projeto tinha sido finalizado mas não completo, como a maioria dos projetos feitos em Waterfall. Grandes prazos, altos custos e grandes falhas!

Mas para minha surpresa, de todo o sistema, a única parte que ele estava usando foi aquela que fizemos em duas semanas com ele ali do lado! O que para mim foi uma felicidade e como o título desse artigo: Um respiro “Ágil” no meio de um mar waterfall!

Hoje quem desenvolve em Ruby On Rails tem nas mãos as poderosas ferramentas de testes, sejam eles para desenvolvimento orientado a testes ou orientado a comportamentos. E no início nós usávamos fixtures, que são arquivos que contém um amontoado de dados que serão usados em nossos testes.

Junto com a evolução dessas ferramentas nasceram os fixtures replacements. Nasceram para suprir a necessidade de organização e praticidade na utilização de fixtures. Atualmente temos Machinist, Factory Girl, Object Daddy, Dataset, Fixjour e FixtureReplacement. Certamente existem outros, mas esses são os mais famosos e usados.

Hoje vou mostrar como você pode usar o Factory Girl em seus testes/especificações.

Para instalar o Factory Girl:

gem install thoughtbot-factory_girl

Depois você tem que configurar no seu environment o uso da gem:

config.gem :thoughtbot-factory_girl, :lib => :factory_girl, :source => "http://gems.github.com"

Depois de configurado, vamos a criação de suas factories. Por padrão, o Factory Girl carrega automaticamente em seus testes as factories que se encontram em test/factories/*.rb, spec/factories/*.rb ou você pode criar todos os seus factories em um único arquivo e colocar em test/factories.rb ou spec/factories.rb. Você pode criar todos os seus factories em um único arquivo ou separar por model (O que eu acho mais organizado).

Antes de usar o Factory Girl nos seus testes você deve definir como cada model deve funcionar:

1
2
3
4

Factory.define :user do |factory|
  factory.name => "Cairo"
  factory.surname => "Noleto"
end

Você pode ter outras definições, por exemplo:

1
2
3
4
5

Factory.define :admin, :class => User do |factory|
  factory.name => "Administrador"
  factory.surname => "Cairo Noleto"
  factory.admin => true
end

Você pode fazer vários tipos de factories, um para cada situação que você precisar, é mais fácil para fazer a manutenção.

Depois que você define suas factories é hora de realmente brincar com elas ;)

1
2

user = Factory.build(:user)
user_admin = Factory.build(:admin)

Quando você usa build, ele constroi um objeto não salvo.

1
2

user = Factory.create(:user)
user_admin = Factory.create(:admin)

Ao utilizar create, você está criando um objeto salvo.

Você pode criar uma hash com os atributos:

1

admin_attributes = Factory.attributes_for(:admin)

Você pode definir associações:

1
2
3
4

Factory.define :picture do |factory|
  factory.name "Random name"
  factory.association :user, :factory => :user
end

Basicamente o Factory Girl é isso, dessa forma você já pode abandonar as fixtures. Existe mais opções de uso do Factory Girl que você pode olhar a documentação oficial.

Hoje começou as palestras do Erecompi 2009. Esse ano contou com a presença da figura carimbada na comunidade Rails no Brasil do Fábio Akita.

Ele falou sobre o ecossistema Rails e deu uma introdução geral sobre Rails, Ruby, Agile e mais um monte de coisa.

Falou sobre os valores da comunidade, das escolhas e sobre o trilho Ruby On Rails no mundo. Falou da história, tocou no blog de 15 minutos e mostrou um monte de código clonado do github.

Foi legal ver que boa parte das pessoas já sabem o que é Agile (ou estão mentindo ;) e ver que muita gente já conhece Ruby On Rails, apesar de não usar. E ver que há ainda pessoas que não gostam do Agile e temem ver licitações com esse tipo de contrato.

Também contou com um case de sucesso do Grupo Credishop na utilização de (j)Ruby On Rails e nos desafios de colocar a coisa para funcionar em um Oracle 7 sem muita experiência e em um tempo onde praticamente não existia jRuby.

Foi bastante legal ouvir as experiências e os desafios dessas pessoas e poder trocar idéias com elas.

E agora que venha a Rails Summit em Outubro.

Sumi! Nas últimas semanas realmente sumi, por uma boa razão!

Para quem me segue no twitter sabe que vou ser pai, que vou me casar e que comprei um MacBook.

Minha vida está tomando um rumo totalmente novo e isso está me distânciando um pouco do meu blog. Claro que não esqueço totalmente, todos os dias eu acesso e vejo se está tudo ok.

Bom, agora que tenho um MacBook, meu GitHub já tem alguns TextMate Bundles e comecei a “mecher” no OS X :)

Para quem acompanha o mundo Ruby On Rails soube que no dia 16 foi lançado o Passenger com suporte total para Nginx (Lê-se Engine X). Assim temos mais uma rápida opção de deployment para Ruby On Rails.

Para instalar, primeiro instala a gem do Passenger

sudo gem install passenger

O Passenger gera o instalador fácil para Nginx e para o Apache, no nosso caso só digitarmos

sudo passenger-install-nginx-module

Nessa parte eu estava obtendo um erro e não estava instalando o Nginx e aqui nessa thread os Phusion Guys resolveram o problema. Então eu fiz um clone do projeto e rodei um rake package para gerar a gem com a modificação e fiz a instalação da gem e tudo foi resolvido.

Após isso é só configurar o Nginx, que por padrão é instalado em /opt/nginx. Para fazer o deploy é simples, adicione o seguinte código em /opt/nginx/conf/nginx.conf (altere a pasta conforme onde você instalou o Nginx)

1
2
3
4
5
6

server {
   listen 80;
   server_name localhost;
   root /var/www/aplicacao
   passenger_enabled on;
}

Para completar, eu fiz um script onde posso iniciar, parar ou reiniciar o servidor

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

#! /bin/sh

### BEGIN INIT INFO
# Provides:          nginx
# Required-Start:    $all
# Required-Stop:     $all
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: starts the nginx web server
# Description:       starts nginx using start-stop-daemon
### END INIT INFO

#Alter to nginx path
NGINXPATH=/opt/nginx

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=$NGINXPATH/sbin/nginx
NAME=nginx
DESC=nginx

test -x $DAEMON || exit 0

# Include nginx defaults if available
if [ -f /etc/default/nginx ] ; then
        . /etc/default/nginx
fi
 
set -e

case "$1" in
  start)
        echo -n "Starting $DESC: "
        start-stop-daemon --start --quiet --pidfile $NGINXPATH/logs/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS
        echo "$NAME."
        ;;
  stop)
        echo -n "Stopping $DESC: "
        start-stop-daemon --stop --quiet --pidfile $NGINXPATH/logs/$NAME.pid --exec $DAEMON
        echo "$NAME."
        ;;

  restart|force-reload)
        echo -n "Restarting $DESC: "
        start-stop-daemon --stop --quiet --pidfile $NGINXPATH/logs/$NAME.pid --exec $DAEMON
        sleep 1
        start-stop-daemon --start --quiet --pidfile $NGINXPATH/logs/$NAME.pid --exec $DAEMON -- $DAEMON_OPTS
        echo "$NAME."
        ;;
  reload)
      echo -n "Reloading $DESC configuration: "
      start-stop-daemon --stop --signal HUP --quiet --pidfile $NGINXPATH/logs/$NAME.pid --exec $DAEMON
      echo "$NAME."
      ;;
  *)
        N=/etc/init.d/$NAME
        echo "Usage: $N {start|stop|restart|reload|force-reload}" >&2
        exit 1
        ;;
esac
 
exit 0

Você pode colocar a inicialização automaticamente no servidor

sudo update-rc.d nginx defaults

Depois é só inicializar o servidor e pronto.

Para instalar o Apache CouchDB no Ubuntu/Debian-likes use

sudo apt-get install couchdb

Mas a versão que ele instala (pelo menos no Ubuntu 8.10) é uma versão um pouco mais antiga, então resolvi instalar via source

1
2
3

wget [http://linorg.usp.br/apache/couchdb/0.9.0/apache-couchdb-0.9.0.tar.gz](http://linorg.usp.br/apache/couchdb/0.9.0/apache-couchdb-0.9.0.tar.gz)
tar zxvf apache-couchdb-0.9.0.tar.gz
cd apache-couchdb-0.9.0

Antes de instalar, você deve instalar as dependências

sudo apt-get install build-essential erlang libicu38 libicu-dev libmozjs-dev libcurl4-openssl-dev

Após isso a coisa fica fácil :)

1
2
3

./configure
make
sudo make install

Ainda não está finalizado, você deve adicionar um usuário para iniciar o couchdb

sudo adduser --system --home /usr/local/var/lib/couchdb --no-create-home --shell /bin/bash --group --gecos "CouchDB Administrator" couchdb

Você deve dar permissões a algumas pastas

1
2
3
4

sudo chown -R couchdb /usr/local/etc/couchdb
sudo chown -R couchdb /usr/local/var/lib/couchdb
sudo chown -R couchdb /usr/local/var/log/couchdb
sudo chown -R couchdb /usr/local/var/run/

Pronto, agora está instalado, você pode inicializar o Apache CouchDB com

sudo -i -u couchdb couchdb -b

“Apache CouchDB has started, time to relax” ;) assim você inicia o CouchDB manualmente, se você quiser deixar ele iniciando automaticamente, você pode fazer

1
2

sudo ln -s /usr/local/etc/init.d/couchdb /etc/init.d/
sudo update-rc.d couchdb defaults

Agora você pode digitar sudo /etc/init.d/couchdb {start|stop|restart|force-reload|status} e facilmente você inicializará ou finalizará o Apache CouchDB, para você ver seu Apache CouchDB funcionando, clique aqui.

Foi lançado hoje a primeira versão dos Guias dos Rails em português.

Um detalhe importante, é que essa é a primeira versão, por quê esses guias sempre vão sofrer alterações:

• Evoluções do Rails
• Maturação das idéias
• Mudança de rumos no guia

Você pode conferir todos os guias aqui.