| Autor |
Mensagem |
|
|
Excelente Elomar, valeu! A grande maioria dos pontos levantados por vc nós decidimos mesmo optar pela simplicidade e a empresa consegue resolver apenas com a descrição da vaga (salário, remoto, requisitos, etc.). Quem quiser põe, quem não quiser não põe.
Buscas avançadas tb resolvemos de forma simples, como o Google faz. Busca textual e pronto. É simplesmente suficiente e resolve quase tudo (o resto é complicado demais para valer a pena e ser realmente importante para alguém) - YAGNI.
Algumas outras tem a ver mesmo com a filosofia do projeto e provavelmente nunca teremos. No ondetrabalhar optamos sempre pelo mais simples (famoso "menos é mais"), mas eu sei que vc já entendeu isso. É questão de foco diferente apenas.
elomarns wrote: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.
Esse já temos. 
|
 |
|
|
Marcio Duran wrote:Ainda estou esperando a implementação para multi-Thread em ArrayList
http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/CopyOnWriteArrayList.html
Desculpa, mas o resto não consegui entender.
|
|
|
|
Marcio Duran wrote:Estamos discutindo o performático em vista de fatores que combinem melhor resultado, não se pode limitar questão de perfomance nessa ótica de uma situação isolada referente ao algoritmo
Tem razão. E já foi dito nesse tópico algumas vezes que a melhor escolha vai depender do uso e necessidade.
Mas nesta discussão específica o ponto foi a afirmação de LinkedList ser "mais performático" para a operação add(elemento). O que claramente não é verdade, como mostrado pelo Paulo.
|
|
|
|
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.
|
|
|
|
Ou seja sergiotaborda está claramente errado.
Pode admitir. Errar é humano, não precisa se envergonhar. O pior é querer ficar insistindo no erro.
Duran, o seu teste insere no começo: lista.add(0, elemento). A discussão é sobre a inserção no fim da lista: lista.add(elemento).
|
|
|
|
Tio And wrote:Agora poderiam criar o ondeestagiar.com
http://ondetrabalhar.com/estagio, resolve não? 
Também estamos trabalhando no ondeestagiar.com e provável que seja algo um pouquinho diferente.
|
|
|
|
E estamos aí para dúvidas e sugestões!
Faço um apelo para quem souber de vagas onde trabalha, por favor comente sobre o OndeTrabalhar.com. Em breve as vagas começarão a aparecer aqui pelo GUJ.
|
|
|
|
|
Qualquer feedback será muito bem vindo!
|
|
|
|
Thiagosc wrote:É por causa de comentários assim que eu não levo Ruby a sério.
Não leve. Faz bem.
|
|
|
|
celso.martins wrote:Você esteve no Falando em Java?
Lá o Kung fez um sistema para gerar números aleatórios usando uma linha (duas porque não coube na tela), mas com 150 comandos nesta linha.
Quando alguém da platéia gritou pedindo para fazer em Java, pois a bagaça não funcionava, ele falou algo assim: Nem morto, em Java eu precisaria de dezenas de linhas.
Eu olhava aquelas duas linhas (uma na verdade) e ficava imaginando: e para debugar uma app com, sei lá, 300 linhas dessas. Vai levar uma eternidade. Prefiro escrever mais linhas, e deixar o código legível, que escrever tudo em uma e ficar meia hora só para entender o que essa linha faz. Esse é o ponto central do meu questionamento.
Desculpem ter chegado atrasado na discussão, mas (ainda em tempo)...
O que eu fiz lá no Falando em Java, foi uma solução rápida para resolver o problema do sorteio. De forma alguma eu acho que o poder e vantagem de Ruby está em permitir fazer esse tipo de coisa. Eu sou um dos que mais critico os "Perl one-liners" que resolvem problemas imensos mas são totalmente ilegiveis.
Eu gosto muito de Ruby (e não acho que seja bala de prata, tem sim os seus problemas), justamente pela expressividade, já muito bem comentada por aqui pelo Dalto (dlt). E expressividade não é fazer o programa em uma linha, na minha opinião tem muito mais a ver com dimiuir o ruído, na hora de resolver o problema. Ruby é uma linguagem MUITO adequada para construção de DSLs internas e para deixar o código próximo do problema que ele resolve.
Outro ponto importante é a diversão. Como o Kenobi já comentou, é uma delícia programar em Ruby. É claro que isso é opinião pessoal, mas que com certeza deve ser levada em conta na hora de escolher uma tecnologia para uma equipe.
ps.: aquela "1-linha" de código que eu fiz em Ruby é legível sim, para quem tem um pouco de fluencia na linguagem. Mas ser legivel para todos não era mesmo o objetivo daquele código. Era só uma solução rápida e simples que _eu_ pude fazer para o problema.
|
|
|
|
Só um adendo, como não vi ninguém postando aqui ainda, o pessoal da Locaweb gravou um vídeo com alguns relatos sobre as palestras:
http://vimeo.com/4894074
|
|
|
|
Eu posso até discordar fortemente de algumas opiniões do Kenobi, mas tenho que tirar o chapéu pro cara por duas coisas:
1) Seria muito mais fácil deixar as convicções de lado e concordar com a opinião de muita gente de peso da comunidade, que acredita na maré "rest sim, esbs pesados não". Mesmo assim o Kenobi mantém a opinião contrária ao que parece ser a tendência. Ponto positivo pela personalidade forte e por não ser maria-vai-com-as-outras.
2) Por isso:
Kenobi wrote:Acredito que o ESB não é necessário à todos cenários, mas daí dizer que ele pode ser simplesmente substituído, acredito que se deve analisar cada caso.
Perfeito. Opinião sensata de qualquer bom arquiteto/desenvolvedor/tomador de decisão e serve para qualquer tecnologia/discussão.
|
|
|
|
Kenobi wrote:Com relação à palestra do Jim Webber, achei que deveria haver uma outra com posição um pouco contrária, pois me preocupa como ele coloca questões sobre níveis de arquitetura SOA por exemplo, protocolo leve quando em cenários enterprise ainda mais com uma cadeia de valor em processos, as exigências são outras.
No começo da palestra o Jim comentou que ele não ia dar nenhuma arquitetura-solução-para-tudo. Ia mostrar algumas vantagens e deixar para quem estivesse vendo decidir quando usar e quando não usar.
Kenobi wrote:Vale lembrar que nenhuma arquitetura é SilverBullet e colocar arquitetura RESTful somente inerente à Hypermedia, pode ser parcialmente verdade, já que muitos modelos nem passam por UI com o usuário.
Perfeito sobre não haver silver bullet, mas até onde o meu limitado conhecimento vai, a web foi a plataforma/arquitetura que conseguiu suportar os mais diversos sistemas, usos e possibilidades de integração. E a web foi feita para ser restful .
Das hypermedias, eu não sei se vc pegou bem o que o Jim queria passar, mas a idéia é que elas vão ser consumidas por outros sistemas mesmo. Não é xhtml para UI, é xhtml/atom para outros sistemas lerem.
Kenobi wrote:Colocar arquitetura por exemplo como ESB somente para localização - transparência, é uma das características. Mas o conceito teve evolução, e fora Orquestração( que você não consegue fazer com REST) e Coreografia de serviços , há ainda outros valores como políticas de SLA e ESB escala sim, depende da arquitetura de domínios ( cluster) que você montar.
Um dos principais "valores" (?) que foi defendido nas duas palestras dele foi que o ESB está "on-the-wire". Ou seja, conseguimos tudo que ele oferece usando simplesmente o que está disponível no protocolo.
Por exemplo, dá sim para fazer orquestração e coreografia com REST. Era justamente o que ele estava mostrando quando falava de hypermidias. Como diz o HATEOAS (hipermedia as the engine of application state), a própria hypermedia diz quais são os próximos passos em um processo/workflow, através dos links.
|
|
|
|
Para quem quiser acompanhar o desenvolvimento do vraptor3, o código está hospedado no github. Uma ótima oportunidade para aprender um pouco de git, não? 
http://github.com/caelum/vraptor
Lembrem-se que ainda há um trabalho enorme de documentação a ser feito!
|
|
|
|
Muito obrigado pelos elogios e críticas de todos. Isso com certeza nos faz cada ano ter eventos melhores!
Em especial, eu e o Sérgio exageramos um pouco mesmo na abertura. Na próxima melhoramos.
Bruno Laturner wrote:Não lembro em qual palestra foi:
+ Citaram o A re-introduction to JavaScript, do Mozilla. Sabe que eu sempre achei o JavaScript um nojo, coisa de fazer efeitinho na web. Depois dessa leitura eu me toquei que dá pra fazer programas com uma linguagem programação, por mais que isso soe estranho.
- Falaram muito brevemente do item acima
Fui eu que disse! Eu adoro JavaScript; valeu a dica! Quem sabe uma palestra sobre coisas legais de JS numa próxima?
Valeu mesmo gente! Saí do evento ontem bem contente.
|
|
|
|