Sua empresa está pronta para contratar um estagiário?

Ontem postei no Twitter o seguinte "estagiário não faz empresa, estagiário faz bug ... quer uma empresa forte, contrate bem". Fui exagerado no comentário, generalizei sobre estagiários. Vou falar o que acho sobre o assunto.

Vamos definir um estagiário, provavelmente um jovem estudante sem experiência nenhuma na área que está atuando, a única noção que ele tem é de estudos e pequenas experiências na área. Qualquer coisa diferente disso não é um estagiário. Não quer dizer que ele seja burro, ele é inexperiente e não sabe completamente como aquilo funciona.

 Se você tem uma empresa que está começando pode pensar que é um bom negócio contratar um ou vários estagiários, e que você vai ensinar para eles o que precisam para evoluir e eles tocarão muito bem os projetos de sua empresa. Não duvido que isso possa acontecer, já fui um estagiário e quando comecei a me destacar, eu carregava praticamente um piano nas costas. Quando você vê um estagiário que se destaca pode ter certeza ele é especial e mandará muito bem a vida toda, será um profissional de destaque.

Continuando, se você contratou esses estagiários na realidade pensou em duas coisas (mesmo que não admita): A economia contratar um estagiário em termos financeiros é considerado mais barato para algumas empresas, mas em contrapartida não lembram que eles necessitam de supervisão e dedicação e por isso pedem estagiários “com experiência” (minha opinião o estagiário é inexperiente então essa opção não é válida, pois ele necessita entrar no mercado para adquirir experiência). O segundo ponto é a dedicação para lapidar esse novato e torná-lo um grande profissional na sua empresa e nesse caso, certamente o estagiário contribuirá bastante para o crescimento da sua empresa. Se você for às faculdades certas contratará bons estagiários capazes de se tornar profissionais incríveis em poucos anos.

Mas tem umas coisas que você pode não estar levando em conta, sua empresa funciona com prazos de clientes, ou de investidores, quer dizer, você tem um tempo determinado para fazer o(s) projeto(s) funcionar(em) bem. Com isso o que acontece normalmente é o seguinte, os estagiários estão sendo ensinados enquanto desenvolvem, você imagina que conseguirá colocar a tempo no ar o que foi prometido, por causa da quantidade de pessoas que a equipe tem. No começo funciona, vai sendo entregue o que precisa, você vai ensinando, mas ai percebe que dificuldades começam a surgir, os estagiários não dão conta de uma tarefa e você tem que pegar.

Lembrem, começa atrasando um dia depois mais um e outro, alguém doente, época de provas dos estagiários, etc.. Nem todos os casos são imprevistos, a prova da faculdade vai acontecer o trabalho e eles precisam estudar para passar, alguns vão desistir, outros não, mas ai começa a hora extra, aquela coisa que parece boba e pequena, mas desgasta. Primeiro você pede a ele ficar 1h, depois aumenta 2h, você não tem como pagar a hora extra então promete que eles vão poder tirar uma semana de folga quando isso acabar, ou monta um frigobar com cervejas, ou paga um ou outro almoço, mas você sabe que não vai acabar, sabe que vai entrar em outro projeto e a equipe estará trabalhando no final das contas umas 14hs, faltando a faculdade, dormindo pouco, se entupindo de café e estimulantes para ficar acordado.
Isso é vida? Acredito que seja um aprendizado, mas poderia ser evitando se tivesse contratado pessoas experientes? Não posso dizer, poderia ter falhado mais? Aqueles estagiários eram melhores que se fossem contratados? Como você vai saber.

Outra coisa que quase ninguém conta é que o estagiário pode querer sair, sabe aquela história de a grama do vizinho sempre é mais verde, ele é novo inexperiente evoluiu durante os 6 meses que trabalhou com você, entregou muita coisa, mas será que ele sobrevive no mercado? Ele ficou realmente experiente nesse tempo? Será que o código dele era bom ou macarrônico? Vocês testavam o código? Acho que não, tinha muita coisa para fazer e tinha que correr por que estava atrasado.
Se o estagiário bom da sua empresa saiu é que algo tinha errado, pensa bem, será que ele gosta de trabalhar por dia 14hs e ganhar uma mixaria como salário? Será que ele tá feliz de como está programando? Ele não tem mais tempo de nada, não vai a Dojos, a encontros de programação, não tem mais vida. Os sonhos dele de viajar parecem cada vez mais distantes, quando ele escuta que alguém trabalha remoto, os olhos até brilham.

Qual é meu ponto com esse texto, estagiário não é escravo e muitas empresas fazem isso na cara de pau e ainda conseguem manipular seus funcionários para que continuem escravizados, alguns conseguem se libertar e quando olham para trás não acreditam no que passaram. Se você quer contratar um, contrate, mas tenha ciência que ele precisa de um plano de evolução, sua empresa precisa saber tratar de uma pessoa assim, por que a formação profissional dele vai ser baseada no que ele aprendeu e se aprendeu errado vai ser complicado para ele mudar algumas coisas, então tenha consciência do que está fazendo e não explore as pessoas. Contrate direito, avalie a necessidade e o tempo, se pode investir na carreira de um estagiário, ótimo! Precisamos de empresas que criem oportunidades para pessoas competentes, se você precisa de uma pessoa experiente, tem prazo e não tem tanto tempo disponível assim, busque no mercado pessoas com esse perfil e não um estagiário, as vezes o barato pode sair caro, pense antes de fazer, senão vai acontecer como milhares de empresas e acabar no primeiro ano.

Meu ambiente de trabalho em 7 itens II

Tô aqui de bobeira, sem sono, vi um post meu antigo "Meu ambiente de trabalho em 7 itens", resolvi então dizer como esse ambiente está hoje em dia.

1 - Ubuntu

Sempre utilizando a versão atual do sistema, hoje fiz o upgrade para Ubuntu 12.04 LTS, estou na época em que alguns usuários reclamaram muito do Unity, só que eu acho muito boa, como tento usar pouco o mouse, ele está me servindo muito bem. Estou querendo fazer uns testes com Arch Linux, mas isso só  em casa.

2 - VIM

Aposentei o uso do GEdit à alguns mêses, estou pegando pesado no aprendizado do VIM, utilizo a receita do Akita, muito boa, atende o que eu preciso ... por enquanto. Estou pensando em dar uma olhada no Emacs.

3 - Chrome

Chrome é foda, não consigo usar muito outros navegadores depois dele.

4 - Consulta

Como trabalho com Ruby, utilizo http://edgeapi.rubyonrails.org/ e http://www.ruby-doc.org/core-1.9.2/index.html, fora a quantidade absurda de livros que tenho para consultar, Stack Overflow sempre ajuda. Não posso esquecer dos senhores Github e o Google, sempre quebrando galhos.

5 - Papel e caneta

Parece antigo, mas funciona muito bem para mim, colocar a ideia no papel me ajuda na conclusão da tarefa melhor e mais rapidamente.

6 - Pomodoro

Sempre que posso utilizo Pomodoro, muito bom para focar e dividir a tarefas, saber quando parar e dar uma relaxada.

7 - Música

Meu Last.fm diz melhor o que gosto de ouvir, para ocorrer a famosa concentração.

Acho que é só, até o próximo post.

Criando uma simples RESTful API usando Rails 3 e JSON

O exemplo de API utilizando JSON que vou fazer aqui é bem simples. Alguns podem se perguntar "Por que ele não faz com XML?", e eu respondo, você está no post errado, a busca certa no Sr. Google é "API XML Rails", ou algo parecido com isso. Criei esse post por que precisei fazer uns testes de criação de API, tanto para o meu trabalho, quanto para a faculdade, então compartilho minha experiência com vocês. As referências que utilizei para fazer o meu exemplo estão abaixo.

Utilizei JRuby e PostgreSQL para essa aplicação, coloque o banco e ruby que quiser, se não estiver usando JRuby não copie "jruby -S". Crie uma aplicação rails

  jruby -S rails new zapi_blog -d postgresql

Verifique se o seu Gemfile está parecido com esse aqui:

  source 'http://rubygems.org'

  gem 'rails', '3.1.3'

  # Bundle edge Rails instead:
  # gem 'rails',     :git => 'git://github.com/rails/rails.git'

  gem 'activerecord-jdbcpostgresql-adapter'

  gem 'jruby-openssl'
  gem 'json'
  gem 'pg'
  gem 'execjs'
  gem 'therubyrhino'
  gem 'rack-cache', :require => 'rack/cache'

  # Gems used only for assets and not required
  # in production environments by default.
  group :assets do
    gem 'uglifier', '>= 1.0.3'
  end

  gem 'jquery-rails'

Crie um scaffold Post

jruby -s rails g scaffold Post title:string body:text

Crie e rode as migrações criadas no banco. Vamos ao controller para modificar algumas coisas, prefiro ele bem simplificado, mudo de lugar o "respond_to" que o rails gera e coloco de uma forma mais elegante utilizando "respond_with".

  respond_to :html, :json

  # GET /posts
  # GET /posts.json
  def index
    @posts = Post.all

    respond_with @posts
  end

Inicie sua app e entre em "/posts.json" e abra uma outra aba com "/posts", elas contém o mesmo resultado, só que mostram de formas diferentes. O Rails facilita muito a vida de quem quer criar uma app, de uma forma bem simples é possível injetar os posts de fora da aplicação. Utilizando o "curl", pode ser feito um teste bem simples.

 curl -d 'post[title]=Post1&post[body]=Post1' http://localhost:3000/posts.json

 Nesse teste consigo injetar um post utilizando a URL do "/posts.json". Vou criar um script com ruby para criar os posts, o script irá pegar os dados de um banco de dados já criado e populado, através de JSON irá enviar os posts para a aplicação que está rodando no servidor local.

 Criei os diretórios "rest_api/lib", coloquei dois aquivoes "api.rb" e "post.rb".

 rest_api/lib/post.rb

  class Post < ActiveRecord::Base
  end

rest_api/lib/api.rb

  require 'rubygems'
  require 'active_record'
  require 'json'
  require 'net/http'
  require 'uri'

  ActiveRecord::Base.establish_connection(
    :adapter => "postgresql",
    :host => "localhost",
    :username => "oquevoceusar",
    :password => "suasenhaaquiounao",
    :database => "umbancodedadosqualquer"
  )

  require 'post'

  class Api
    host = 'localhost:3000'
    url = 'http://localhost:3000/posts.json'
    uri = URI.parse(url)
    post_ws = '/posts.json'

    posts = Post.all
    posts.each do |p|
      post = {'title' => p.title, 'body' => p.body}.to_json
      req = Net::HTTP::Post.new(post_ws, initheader = {'Content-Type' => 'application/json'})
      req.body = post
      response = Net::HTTP.new(uri.host, uri.port).start {|http| http.request(req)}
      puts "Response #{response.code} #{response.message}: #{response.body}"
    end
  end

É possível também passar parametros de usuário e senha, entre outras coisas de segurança por esse script e fazer a verificação na app, mas isso é um outro post. Não vou explicar em detalhes o que esse script faz, se você está olhando esse post é por que já tem uma noção boa de ruby on rails, então vá tirar suas dúvidas na API do Ruby ou do Rails, o Sr. Google também ajuda.

Referências:
https://www.socialtext.net/open/very_simple_rest_in_ruby_part_3_post_to_create_a_new_workspace
http://gavinmorrice.com/blog/posts/21-building-a-rest-api-in-rails-3
http://squarism.com/2011/04/01/how-to-write-a-ruby-rails-3-rest-api/
http://blog.project-sierra.de/archives/1788

Você faz informática?

Quando fui deitar, sempre acabo pensando em algo para escrever, então pensei em umas conversas que ando tendo com amigos e colegas de área, decidi escrever algumas perguntas para reflexão própria e de quem quiser refletir junto. Quem tiver mais algumas mande que coloco no post. Estas perguntas não estão em ordem de importância.

Responda as seguintes perguntas:

Estuda frequentemente fora da faculdade, ou curso?
Participa de listas, fóruns, ou chats de assuntos relacionados a sua área?
Segue pessoas importantes da área no twitter?
Lê artigos, livros, ou posts especializados de pessoas relevantes?
Vai a eventos?
Procura atualizar-se com as novidades constantes que pipocam a todo momento?
Conhece o passado, presente e o possível futuro da informática?
Já está inserido no mercado de trabalho? só vale empregos da sua linha de estudos.

Se a maioria dessas perguntas são respondidas com um "NÃO", você está fazendo isso muito certo ... "só que não". Quando falo isso tenho a certeza ao afirmar que você faz informática por modinha e não por que realmente gosta do assunto, não importa agora a sua área de atuação, se não tem dedicação, você realmente não gosta do assunto. E depois não venha dizer que conhece a área, por que não tem embasamento nenhum para falar de informática.

GRUB error 17

Estava formatando as minhas partições, utilizando o Live CD do Ubuntu 11.04 e o GParted, quando fui reiniciar a máquina me deparei com o chato erro do GRUB error 17, alguns de vocês já devem ter resolvido isso, mas como nunca tinha formatado partições fui atrás do erro, achei este link falando do assunto e consegui adaptar para minha realidade.
O erro acontece quando as partições não estão organizadas e o GRUB precisava ficar na partição do Linux, coisa que não acontecia, então fiz o seguinte:

Antes de começar, TENHA CUIDADO.

Entrei fazendo boot novamente pelo CD, abri o terminal. Virei root.

sudo -i

Listei as partições com:

fdisk -l

A minha saída foi:

Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4dc5fddf
 

Device       Boot   Start         End        Blocks         Id     System
/dev/sda1             1               10           80293+       de    Dell Utility
/dev/sda2   *        11             1926       15383099    7      HPFS/NTFS
/dev/sda3             18184       19457     10233405    db   CP/M / CTOS / ...
/dev/sda4             1926         18183     130590720  5     Extended
/dev/sda5             1926         17566     125628416  83   Linux
/dev/sda6            17566        18183     4960256      82   Linux swap / Solaris

Partition table entries are not in disk order

No meu caso o GRUB precisa estar em /dev/sda5, sabendo disso montei minha partição com:

mount /dev/sad5 /mnt
mount -t proc none /mnt/proc
mount -o bind /dev /mnt/dev

Depois que o GRUB descobriu meus drivers, faço o chroot
 

chroot /mnt /bin/bash

Assim que acabar essa parte, abra o grub:  

grub

Encontre quais os parâmetros que você deve passar no comando root com o find abaixo:

find /boot/grub/stage1

No meu caso a saída foi (hd0,4), passe ele no root:

root (hd0,4)

Por fim rode o setup e feche:

setup (hd0)
quit

Reinicie a máquina e estará pronto. 

Devise x Authlogic

Aviso aos navegantes que essa é a minha opinião, aconteceu comigo e só estou passando minha experiência para outros devels como eu, então não me julguem, posso estar falando alguma merda, mas pelo que conversei com alguns colegas eles tem uma opinião parecida.

Devise é uma ferramenta FODA, mas tem que saber muito bem que tipo de projeto irá utiliza-la. Se for um projeto rápido que você não quer perder tempo nele, vai ser pequeno, é feijão com arroz, utilize o Devise por que já está pronto. Não perca tempo reinventando a roda ela está pronta, utilize.

Se o seu projeto tiver que ter uma personalização maior, por que o cliente pediu algo diferente, usa o Authlogic. Com o Devise poderá ter dor de cabeça dependendo do que o cliente pedir, fora que pode acontecer dele não fazer tudo que você espera, ou ele fazer demais. Considero que o Devise como muitas outras ferramentas foi feita com um propósito e ele foi atingido com sucesso, mas para a sua utilização ele tem que se encaixar no seu modelo de negócio, já que varia de empresa para empresa. Não quer dizer que você esteja fazendo errado, e sim está fazendo da forma que acredita ser a correta.

Estou dizendo isso por que tive dois projetos que erramos na escolha pelo Devise que fazia muito mais do que precisávamos, depois tivemos que retirar e colocar o Authlogic. Hoje temos uma gem feita com o sistema de Engines do Rails 3.10.beta que com uma linha no terminal instala tudo que precisamos e configura, ela é específica para os nossos interesses por isso a utilização do Devise foi descartada por completo, mas não quer dizer para você não possa utilizar. Planejamento é muito importante para não ter dor de cabeça em uma troca mais tarde. Nosso caso trocamos, sendo que tínhamos um projeto em produção então imagine o trabalho que foi, tivemos que mexer em migração, banco de dados, modelo, nossa da calafrio até de lembrar.

Ps.: Demorei pra postar algo por causa da famosa faculdade, já pensei em alguns posts maneiros para fazer.

Até a próxima!!

Quando usar Beta?

Essa é uma perguntinha chata que deve ecoar na cabeça de muito desenvolvedor e gerente de projeto. Eu tenho uma pequena experiência com os dois lados, já desenvolvi com ferramentas estáveis e também com ferramentas betas.

Meu exemplo de ferramenta estável foi de outubro de 2009 até dezembro de 2010, com o Ruby 1.8.7 e o Rails 2.3.5, aonde trabalho. Fizemos coisas bem legais com essas ferramentas, porém no meio do processo vimos a chegada do Rails3, que em caso de atualizar para nova versão iria modificar muita coisa interna e não valeria apena. Fora que as ferramentas que usavamos estavam migrando rapidamente para a nova versão do Rails3 e assim estagnando nossa ferramenta. Basicamente esse é o mal de usar o estável, suas aplicações podem ficar com código defasado muito rápido pelas mudanças constantes das ferramentas que você geralmente utiliza.

Com ferramenta Beta uso desde dezembro de 2010, uso o Ruby estável 1.9.2, mas uso o Beta do Rails o 3.1.0.beta, usava já antes dele virar "--pre". A vantagem disso? Uso funcionalidades que a maioria das pessoas só vai usar em 6 mêses ou mais, modificações realmente necessárias como as Engines que foram colocadas à pouco tempo. Só que existe um preço, se tiver alguma dificuldade para fazer algo, não tem muita documentação existente, vai ter que saber procurar, em listas, foruns, posts que o pessoal do Core Team participa. Outra dificuldade é que outras Gems que seu projeto depende podem não ser compatíveis com o Framework, quer dizer que você vai ter que meter a mão para ajudar a desenvolver. Esses pequenos contratempos fazem que a conclusão do projeto aumente.

E agora? Quando usar Beta? Não sei, depende do propósito, de tempo, equipe, são muitas variáveis para pensar antes de fazer a escolha. O meu pensamento hoje em dia está mais da seguinte forma:
Se for uma ferramenta que me ajude, uso Beta, mais tempo para trabalhar já que provavelmente irá ter muita coisa para fazer. Tendo o cuidado certo não vai ficar ultrapassada.
Se for um site simples, uso estável, sem demora usando gems estáveis que irão me ajudar na conclusão rápida do projeto.
Basicamente o que vai fazer você usar estável ou Beta é o tempo que irá ter que fazer aquela tarefa e que grau de complexidade ele pode vir a ter.
Espero ter ajudado, até a próxima!!!