| Autor |
Mensagem |
|
|
asaudate wrote:
elomarns wrote:Embore ache que "desenvolvedor de software" expresse melhor o conjunto de atividades que costumamos fazer, não vejo problema nenhum com a palavra "programador". Até porque, a maioria das pessoas sabe o que é um programador, por isso fica mais fácil explicar para terceiros o que fazemos do que usando "desenvolvedor" ou "analista de sistemas" (essa expressão sim me desagrada).
Por fim, vale mencionar que pessoas do calibre do Dennis Ritchie se definem como programador, portanto, estar na mesma categoria que o criador do C e um dos criadores do Unix não pode ser demérito.
E na mesma categoria dos estagiários da empresa, também!
Se você prefere nivelar por baixo, em termos de conhecimento e experiência (não joguem pedras em mim, estagiários), sim. Já eu fico satisfeito com uma expressão que descreve razoavelmente bem o que eu faço, é de fácil compreensão para leigos, e que é suficiente para gente muito mais competente do que eu, citando novamente pessoas como Dennis Ritchie.
|
 |
|
|
Embore ache que "desenvolvedor de software" expresse melhor o conjunto de atividades que costumamos fazer, não vejo problema nenhum com a palavra "programador". Até porque, a maioria das pessoas sabe o que é um programador, por isso fica mais fácil explicar para terceiros o que fazemos do que usando "desenvolvedor" ou "analista de sistemas" (essa expressão sim me desagrada).
Por fim, vale mencionar que pessoas do calibre do Dennis Ritchie se definem como programador, portanto, estar na mesma categoria que o criador do C e um dos criadores do Unix não pode ser demérito.
|
|
|
|
kicolobo wrote:Eu achei simplesmente fantástico. Achei uma maravilha como leitor de ebooks e navegador da Internet, assim como visualizador de fotos e leitor de e-mail.
Há momentos em casa nos quais pego meu notebook e começo a navegar na web sentado em uma poltrona. O negócio parece confortável, mas de fato não é. Você ainda tem o teclado incomodando. Com o iPad, fica muito mais tranquilo, porque é basicamente como você leria uma revista convencional, ou seja, é cômodo!
Pra expor fotos também achei muito bacana. Tente expor fotos para seus amigos usando um notebook/netbook e você vai entender na hora o que estou querendo dizer. Como leitor de ebooks também achei bem interessante: mais viável inclusive que o Kindle pelo fato de ser colorido (penso muito em livros de arte e quadrinhos nestas horas).
E, o que achei também fascinante na apresentação: aquela aplicação de desenho. Cara: é fenomenal! Bem melhor que os tablets wacom com os quais mexi até agora.
Agora, é importante saber o que não é o bicho né? Não é um netbook. 90% das reclamações que escutei foram do tipo: "não é multi-tarefa", "não tem câmera". Claro que não. Este não é o propósito do bicho. Seu propósito, pelo que ficou claro na apresentação é ser um "aparelho de leitura". Pra isto, eu achei simplesmente fantástico.
Claro, é um aparelho de leitura metido a besta né? Possui alguns jogos e aplicativos, mas não acredito que estes venham a ser o MUST do iPad.
aliás, pra quem curte ler no banheiro (meu caso), o bicho cai como uma luva também 
Eu também me empolguei com o iPad como plataforma para leitura, no entanto, ele tem um grande incoveniente para essa função: a bateria. Segundo a Apple, a bateria dele dura 10 horas, o que no mundo real significa 5 horas.
Comparado ao Kindle, essa duração da bateria é muito curta.
|
|
|
|
Eu tenho a edição original desse livro, e me decepcionei um pouco. Em geral, os livros da série Head First, além de possuirem uma didática excelente, são razoavelmente completos, o que não ocorre com o Head First Rails. Ao fim da leitura, você terá uma boa visão geral sobre o Rails, mas não vai realmente saber muito sobre ele.
Por exemplo, no capítulo sobre Ajax, no fim das contas, você só aprenderá 3 helpers (link_to_remote, periodically_call_remote e remote_form_for), sendo que o livro sequer menciona a existência de templates RJS.
Enfim, eu só recomendo o Head First Rails para quem não sabe nada sobre Rails e quer ter uma introdução mais detalhada ao assunto através de um livro realmente agradável de ler. Mas se você já sabe um pouco sobre o Rails e/ou quer realmente aprendê-lo a fundo, ele não é uma boa escolha (ao contrário do Agile Web Development with Rails).
|
|
|
|
entanglement wrote:
biluquinha wrote:Programo em um PC aqui no servico e como vcs lidam em relacao a proteger os arquivos, vcs salva no HD! os codigos fontes? e so qualquer um chegar copiar o codigo fonte e ja era? como vcs lidam com isso?
Ponha um pitbull na porta da empresa para não deixar entrar ninguém desconhecido, e um bom advogado para processar quem roubar os códigos-fontes. 
Na prática o que ocorre é que códigos-fontes costumam ser inúteis sem os programadores que os fizeram, portanto mesmo em empresas grandes não há tanta neura assim contra "roubo de códigos fontes".
Como o Neófito disse, é melhor ter os fontes sempre bem protegidos contra falhas no computador (ou deleções indevidas) em um (ou mais) servidores de controle de versões.
Considero isso um indício de código ruim.
|
|
|
|
marcobiscaro2112 wrote:Como dito, a TENDÊNCIA (não quer dizer que já aconteceu e nem que vai, de fato, acontecer) é que tudo seja feito via browser.
Claro que o 'tudo' não pode ser um 'tudo' de verdade, já que é preciso de um navegador (e consequentemente uma base de SO) para rodar o sistema.
Mas aí entra a questão da centralização de dados. Imagine que você possa trabalhar em qualquer computador, com os seus arquivos, sem precisar ficar levando-os para todo lugar. Ou ainda, se seu PC pegar um vírus, você não perde nenhum arquivo... basta reinstalar a base do sistema e o navegador e lá está tudo do jeito que você deixou.
E como todos sabemos, nem tudo é perfeito... Algumas coisas são difíceis (ou até mesmo impossíveis) de imaginar. Imagine, por exemplo, rodar um jogo hiper pesado direto da Internet... Parece impossível. Por enquanto: quem ia imaginar a Internet como está há alguns anos? Ou mesmo imaginar um notebook há 40 anos, época em que cada computador ocupava o espaço de várias salas?
Veremos...
Alan Kay imaginou algo como um notebook há 41 anos atrás.
|
|
|
|
|
Eu uso o NetBeans, juntamente com code templates que eu criei pra HTML/XHTML e CSS.
|
|
|
|
Você ainda precisa ser proficiente em HTML (ou XHTML) e CSS para fazer um site bonito e acessível (isso também é importante). No entanto, existem alguns frameworks CSS e até templates de sites prontos para serem utilizados, mas obviamente eles são genéricos demais, portanto não espere ter algo memorável usando eles.
Um exemplo de tecnologia feita para melhorar as interfaces gráficas gerada pelo Rails é o Streamlined.
|
|
|
|
Bruno Laturner wrote:
raf4ever wrote:Netbeans.
E,pra mim,essa história de "desenvolvedor ruby não usa IDE" é utopia 
Algumas IDEs acabam mais atrapalhando que ajudando, por exemplo quem vem do Java usando Netbeans, e começa a usar o autocomplete dele, vai ficar mais perdido que sem ele. É totalmente inútil se você não sabe a API.
Outra coisa, desenvolvimento Ruby tem raiz mais forte em Mac OS X e Linux, e boa parte das ferramentas são feitas para rodar em interpretadores de comandos. Acaba que velocidade de desenvolvimento é algumas ordens maior que ficar clicando com mouse. Os desenvolvedores também tem maior costume em fazer seus próprios scripts p/ automatizar tarefas, o que as IDEs não vão ter suporte.
Acho que outra coisa que contribui com o desuso de IDEs é o foco maior em testes automatizados, justamente por não poderem depender de checagens em tempo de compilação, que as IDEs hoje tem. Não precisa ficar com dezenas de janelas abertas verificando tudo, nem precisam depender de ferramentas para refatorar o sistema.
Acho que a maioria dos desenvolvedores que usam o NetBeans para programar com Ruby/Rails só usam mesmo as funcionalidades referentes à edição de código, project explorer, caminhar pelos arquivos e encontrar arquivos do projeto. Ou seja, usam as coisas que um editor como o TextMate tem. Tarefas como executar generators, executar tarefas rake, executar testes e usar o irb ou o console do Rails, em geral são realizadas numa janela de comando.
Bom, pelo menos esse é o meu perfil de uso, por isso adoraria uma versão mais leve do NetBeans, que excluisse praticamente tudo o que eu considero gordura.
|
|
|
|
Juk wrote:
elomarns wrote:
Luiz Aguiar wrote:
Juk wrote:A unica coisa que me faz falta de verdade programando Ruby é um refactoring decente, principalmente "Extract Method" e "Rename". Já tem gente trabalhando nisso e acredito que em pouco tempo teremos uma boa ferramenta de refactoring disponivel.
Teste o RubyMine e chore rs 
O NetBeans também tem essas duas funcionalidades, embora o RubyMine seja mesmo superior quando o assunto é refactoring.
Testei no NetBeans 6.7.1 e o rename não funcionou como esperado (refatorei um model e quase nada além do nome da classe foi alterado, quando eu esperava que refatorasse todo o conteudo relacionado como controllers, migrations, etc) e no menu refactoring não aparece nenhuma opção de Extract Method.
Não testei o RubyMine ainda, irei testar!
O Rename realmente deixa a desejar no NetBeans. Já o Extract Method está disponível como um quickfix, ou seja, ele não aparece no menu, você tem que selecionar o trecho de código que quer extrair para um método, apertar Alt+Enter, e então escolher a opção "Extract Method".
Para maiores informações, dá uma olhada na página de refactoring do Ruby no NetBeans.
|
|
|
|
Luiz Aguiar wrote:
Juk wrote:A unica coisa que me faz falta de verdade programando Ruby é um refactoring decente, principalmente "Extract Method" e "Rename". Já tem gente trabalhando nisso e acredito que em pouco tempo teremos uma boa ferramenta de refactoring disponivel.
Teste o RubyMine e chore rs
O NetBeans também tem essas duas funcionalidades, embora o RubyMine seja mesmo superior quando o assunto é refactoring.
|
|
|
|
Achei curioso o fato da Engine Yard ter contratado a equipe do JRuby, já que no fim do ano passado, devido à crise financeira, eles demitiram parte da equipe do Rubinius. Caso eles já tenham se recuperado dos eventuais problemas financeiros, imagino que faria mais sentido contratar novamente os desenvolvedores demitidos, já que a Engine Yard investe há bastante tempo no Rubinius.
Agora, se não me engano, a Engine Yard vai ter mais gente trabalhando no JRuby do que no Rubinius, já que a equipe do Rubinius só tem 2 desenvolvedores (Evan Phoenix e Brian Ford), enquanto a equipe do JRuby possui 3 (Charles Nutter, Thomas Enebo e Nick Sieger).
Enfim, presumo que, no mínimo, eles queiram diversificar no investimento das implementações do Ruby, não mais favorecendo o Rubinius.
|
|
|
|
Realmente o OndeTrabalhar ficou mesmo bem simples, e isso definitivamente é um ponto positivo. E apesar de eu ser partidário da simplicidade, do YAGNI, do "Start with No" (e do Getting Real como um todo), realmente acabo fugindo um pouco da simplicidade quando penso em um site de vagas para Rails.
Inicialmente também pensei em algo bem básico, apenas algumas poucas informações, como título e descrição das vagas, mas isso acabou soando insatisfatório, embora reconheça que as alternativas apontadas por você resolvem a maioria dos problemas. Enfim, deve ser o meu lado de desenvolvedor falando mais alto, e optando pela opção mais custosa apenas pela jornada.
De qualquer forma, desejo boa sorte para o OndeTrabalhar.
|
|
|
|
|
Algo que eu esqueci de mencionar no post anterior, é que também incluiria a possibilidade do contratante marcar uma vaga como preenchida, já que muitas vezes eu mesmo fico na dúvida se uma vaga um pouco mais antiga já foi preenchida ou não. Usaria essa informação de forma a não listar as vagas já preenchidas na home do site, apenas as últimas 5 vagas que ainda não foram preenchidas.
|
|
|
|
Fabio Kung wrote:
elomarns wrote:Parabéns à Caelum pela idéia e pela ótima implementação. O site tem um layout muito bonito, e URLs realmente óbvias.
Confesso que estava pensando em fazer um site do tipo, só que focado em vagas para Rails. No entando, agora julgo desnecessário, embora fizesse o site ligeiramente diferente, justamente por ter planejado focar em vagas de emprego com uma tecnologia específica.
Muito obrigado Elomar! Só por curiosidade (e querendo melhorar sempre), o que faria de diferente?
elomarns wrote:Seria interessante um post no blog da Caelum detalhando a implementação do site, dizendo coisas como plugins/gems utilizados, ambiente de deploy, entre outras características do projeto.
Com certeza, em breve!
elomarns wrote:Por fim, uma sugestão um pouco mais extrema que eu daria seria disponibilizar o código fonte do site no GitHub, caso vocês não tenham intenções comerciais com ele. Seria uma ótima ferramenta de aprendizado, até mesmo para os cursos de Ruby on Rails na Caelum.
Ótima sugestão. Precisamos pensar direitinho aqui, mas consideraremos com carinho.
Eu entendi a idéia de manter o site simples, e concordo completamente, mas eu incluiria um formulário de cadastro de vagas um pouco mais detalhado, de forma que o candidato à vaga não tenha dúvidas sobre ela. Entre as informações extras que eu colocaria, incluiria um campo para salário (tendo também um check box indicando se ele é negociável), o local do trabalho (local ou remoto), o regime de trabalho (CLT ou PJ) e uma área para incluir conhecimentos relacionados ao Rails que são necessários ou desejáveis para quem pretende preencher a vaga.
Além disso, incluiria também um formulário de cadastro para railers, embora esse cadastro só seria necessário para se candidatar a uma vaga. ou seja, ele seria dispensável para a visualização e busca de vagas. Entre os campos do formulário de cadastro, eu incluiria o link para o perfil no GitHub, e uma área onde os usuários informariam os seus conhecimentos dentro do ecossistema do Rails. Dessa forma, o contratante poderia avaliar de forma mais fácil se os candidatos possuem os requisitos necessários.
Por exemplo, ao cadastrar uma vaga, o contratante, entre outras informações, adicionaria o RSpec, o Haml, o Saas e o Xapit como conhecimentos necessários para preencher a vaga. Ao visualizar os candidatos para essa vaga, ele veria os conhecimentos que eles informaram possuir, e então poderia analisar melhor qual se encaixa melhor à vaga. Opcionalmente, o site poderia ainda indicar a relação requisitos / conhecimentos de cada candidato a uma vaga, indicando a porcentagem dos requisitos da vaga que ele atende.
Por fim, incluiria uma busca avançada também, embora seria a busca simples que apareceria em todas as páginas.
Enfim, seria diferente em alguns aspectos do OndeTrabalhar.com, mas também tentaria manter a simplicidade, embora sei que este site hipotético seria menos direto. Além disso, é óbvio que muito do que eu disse não poderia ser aplicado no OndeTrabalhar.com, devido a sua abrangência.
|
|
|
|
|
|