| Autor |
Mensagem |
|
|
O problema acontece porque os arquivos não estão sendo fechados e os buffers estão ficando na memória, uma forma mais simples de se implementar isso seria assim:
|
 |
|
|
Na minha cidade tem muito isso, mas se não tem aí na sua pode ser uma boa mesmo você fazer sobre isso, já é um produto pra sua futura empresa 
|
|
|
|
angelo.silvestre wrote:olá, faço ciência da computação e devo começar o tcc no próximo semestre, mas estou com dificuldade de achar algum tema.
Gosto principalmente de IA e Grafos.
Qualquer sugestão viável é bem vinda.
Opa Angelo,
Se você gosta de IA e Grafos, uma boa pra você é algoritmos de aprendizado de máquina e inteligência coletiva. Você encontra facilmente material sobre esses assuntos em livros comuns:
* Programming Collective Intelligence
* Collective Intelligence in Action
* Algorithms of the Intelligent Web
E considerando que você gosta de IA, suponho que já conhece o livro do Peter Naur sobre o assunto, se não conhecer fica aí a dica. Algoritmos de aprendizado de máquina estão em voga hoje, com recomendações pra filmes, música, séries de TV e correlatos, você pode fazer o seu TCC em cima de alguma coisa assim.
Boa sorte!
|
|
|
|
Pra quem quiser aprender um pouco mais sobre comparação de objetos em Ruby, vale a leitura:
Ruby Basics ? Equality operators in Ruby
|
|
|
|
Você até pode, mas é uma péssima idéia a não ser que você esteja fazendo isso com web sockets -> http://weblogs.java.net/blog/spericas/archive/2010/09/29/web-sockets-and-html5-glassfish
Se você não puder usar websockets o ideal é de dentro do servlet retornar pro cliente uma resposta e colocar isso pra executar em uma thread em separado, criar um objeto no banco, por exemplo, com o estatus dessa execução e a sua interface web ficaria de tempos em tempos verificando esse status no banco de dados pra saber se terminou ou não.
|
|
|
|
Será que Akka vai finalmente se tornar a killer app de Scala?
Legal que eles pegaram investimento também pra bancar a continuidade do desenvolvimento do ecosistema, parece que Scala tá que tá agora
|
|
|
|
fredferrao wrote:Mas eu acho que ha duas fases no que diz respeito a produtividade, uma coisa é quando se esta no inicio do projeto, ou sequer temos o produto pronto ainda, ou até mesmo temo o produto pronto, mas devido ao grande sucesso temos que fazer mudanças muito rapidas;
Outra coisa é quanto ja temos um sistema maduro, e temos apenas que ir melhorando, neste caso não ha aquela pressao enorme no quesito produtividade, e é nesta situação que eu acho que se encontra o twitter atualmente.
O Twitter tinha vários problemas pra se resolver:
* Base de código em Ruby difícil de se extender
* Alta latência
* Modelo single threaded do Rails
* VM lenta e pouco confiável pra quantidade de acessos que eles tinham (o Twitter foi um dos primeiros grandes clientes do pessoal do Passenger e do Ruby Enterprise Edition)
Na hora de resolver isso, eles não tinham como resolver os problemas do Rails ou do interpretador do Ruby e eles já tinham muito código rodando na JVM com Scala e Java, por que não ir pro lado do Java que seria capaz de fazer o mesmo trabalho? O sistema teria que ser reescrito de qualquer forma, seja em Ruby ou em Java, mas se eles escrevessem o sistema em Ruby continuariam com as desvantagens de estarem executando no MRI, Nada mais correto do que ir além e pular direto pro Java que já ia dar vários avanços de graça.
Quanto a manutenção, acho que entre Java e Ruby não haja uma distância tão grande. Tenho codebases em Ruby e em Java que trabalho diariamente e o maior problema não é a linguagem, mas sim quem escreve o código. É possível escrever código ruim e difícil de manter em qualquer linguagem, a única vantagem do Java nesse caso é que refactorings são mais fáceis.
|
|
|
|
pcassiano wrote:acreditem se quiser, mas tem gente que acha que a decisão do twitter por mudar pra java foi equivocada, que 'nem tudo é performance' etc... vai entender... 
Pra 99% das empresas isso é fato, nem tudo é performance. Pra o 1% que o twitter faz parte a diminuição de custos que isso pode gerar deve bater nos milhões de dólares
O maior problema que temos hoje é que a maior parte das pessoas que está nos 99% acha que está, na verdade, nos 1%.
|
|
|
|
marcosvinicius.rj wrote:Maurício. Interessante... A maioria dos programadores ruby que conheço prefere clojure.
Disse bem, programadores Ruby. Clojure é uma obra de arte, mas é distante demais do Java pra ter algum apelo real pro programador Java comum. Seria ótimo ver pessoas migrando pra Clojure hoje, mas eu não tenho fé que isso vá acontecer tão cedo. Scala é uma linguagem bem mais próxima e as chances de se ver programadores Java realmente usando ela são bem maiores.
Se qualquer uma das duas sair na frente eu já fico feliz, mas se Ceylon ou Groovy terminarem se tornando o padrão eu vou realmente ficar muito desapontado. Vamos ver o que o futuro guarda pras linguagens da JVM.
|
|
|
|
Kenobi wrote:
A VM entretanto é avançadíssima realmente e como o Maurício disse, vai demorar muito até outras chegarem no nível. Contudo, a idéia da VM é se tornar cada vez mais plural e talvez no futuro tenhamos uma outra linguagem, melhor desenhada, fazendo uso dos seus recursos.
Scala é uma forte candidata, isso sem contar com coisas que estão vindo, como The Ceylon Project - http://blog.talawah.net/2011/04/gavin-king-unviels-red-hats-top-secret.html
Eu diria que já temos essa linguagem melhor desenhada e ela é Scala. Hoje Scala já é mais rápida que o Java inclusive pra muitos trabalhos, ela está evoluindo a passos largos e não tem nenhuma grande empresa enterprisey por trás pra congelar a linguagem numa versão específica. Já vi muita gente dizendo, inclusive, que as vezes a linguagem muda até demais.
Agora na versão 2.8 eles resolveram muitos dos pain points mais conhecidos (e reclamados) da linguagem e eu acredito que a partir de agora seja seguro investir na linguagem pra deployments em larga escala. Já temos muitos big players investindo e o ecosistema ao redor da linguagem só faz crescer. Além disso muitos dos frameworks conhecidos funcionam perfeitamente com ela, então você não perde o seu investimento já feito no Java.
Quanto a Ceylon, eu, pessoalmente, não boto fé. A idéia deles parece ser um Groovy 2, essa coisa de "vamos fazer um java mais legal" não vai muito longe não, porque você vai acabar batendo de frente com outros problemas que a linguagem tem e que não foram resolvidos porque fazem parte da cultura do java. Sem contar que eles ainda vão começar o projeto, existem vários detalhes pra serem encarados na hora de se implementar uma nova linguagem pra JVM e não e aprende isso do dia pra noite não.
Recomendo quem tiver interesse em ler mais sobre isso a ir dar uma olhada no blog do Charles Nutter, um dos desenvolvedores do JRuby, onde ele fala muito sobre como é desenvolver uma linguagem pra JVM.
|
|
|
|
Esse era outro problema do Twitter, eles começaram como um Ruby Shop shiita como o pessoal que estava brigando aqui nessa thread era Java Shiita também e acharam que valia a pena inventar os seus próprios componentes em Ruby pra tudo, como o Starling/Workling pra filas de mensageria, que eram basicamente uma atrocidade. Pobres de código, instáveis e pouco testados, quando haviam diversas soluções em Java e em Erlang pra resolver esse problema.
Acho que hoje eles finalmente estão indo no caminho certo, indo onde a boa tecnologia está e não tendo mais "opiniões" sobre o que deve ser usado ou não. Agora se usa o que dá mais certo pro problema em questão.
|
|
|
|
Zaperjava wrote:Ruby ainda tem muito que evoluir ,está mil anos do Java e .Net no mercado corporativo. Pra pagina da padaria do Tio Joao o Ruby realmente eh bem mais agil . Agora pra mercado corporativo......
É mais fácil o site da padaria do Tio Joào, que tem algumas centenas de clientes, cair, do que uma aplicação "corporativa" numa intranet sendo usada por 5 pessoas.
|
|
|
|
|
É importante lembrar também que usar IO assíncrono não significa ser mais rápido, IO assíncrono normalmente é mais lento que IO síncrono, as pessoas procuram IO assíncrono porque elas reduzem a quantidade de threads necessárias pra fazer o mesmo trabalho, já que você não precisa de uma thread lendo e outra escrevendo do socket pra fazer o trabalho e com menos threads você estressa menos o SO e fica mais fácil de aceitar uma quantidade maior de clientes, já que a quantidade de threads que podem existir no SO é finita e cada thread também aumenta o trabalho do scheduler e o consumo de memória com o seu stack.
|
|
|
|
E só pra complementar um pouco mais, estou trabalhando atualmente exatamente em migrar o backend da empresa de Ruby pra Java, porque estamos tendo um aumento muito grande na quantidade de acessos e os processos em Ruby consomem muito tempo implementando mágica que não precisamos já que o trabalho é basicamente fazer parse de XML, JSON, gerar imagens de PDF e extrair texto de PDFs. O problema é simples e as soluções em java tem um ganho de performance absurdo contra qualquer outra linguagem. Com os benchmarks que fizemos aqui, a extração de texto de arquivos PDF demorava 0.1 segundos em Java e 0.25 com um SDK de terceiros em C e precisamos que isso seja o mais rápido possível, se em C fosse mais rápido, com certeza teríamos ficado com a solução em C.
Já na nossa aplicação web, existe zero de interesse de re-escrever ela em Java, ela é toda em Ruby e deve continuar assim por muito tempo ainda já que ela atende muito bem as nossas necessidades atuais. No dia que ela não atender mais, vamos com certeza mudá-la para que ela seja a melhor possível para os nossos clientes.
Acho que todo mundo deveria por na cabeça que o único time que existe é o time do cliente e você está sempre jogando nele, então é o seu trabalho procurar a melhor solução tecnológica pra ele. E pra fazer isso você tem que procurar conhecer novas tecnologias e novas formas de se resolver os problemas. A comunidade Java produziu muita coisa interessante, gerou projetos que todos nós dependemos até hoje, mas será que não existem em outras linguagens outras soluções que podem ser melhores pros nossos problemas.
Torça pro seu time de futebol, mas pegue todas as linguagens de programação, é a melhor forma de levar a sua carreira de TI, tanto do ponto de vista profissional quanto financeiro, pois quanto mais você sabe, mais você vale e mais vão pagar pelo seu passe.
|
|
|
|
Engraçado que a maior parte das pessoas fala e reclama e briga mas não em a menor noção do real problema. O problema do twitter e da maior parte dos sites de porte absurdo (e não grande porte, grande porte é o sitezinho da igreja) é que chega a um momento em que milisegundos fazem diferença do ponto de vista financeiro e também de uso. Pra maior parte dos sites feitos hoje, demorar 800 milisegundos pra trazer um resultado é normal, natural até, quem faz site usando JSF e componentes de terceiros provavelmente está bem pior do que isso porque a maior parte desses arquivos são enviados via filtros e não diretamente como arquivo pelo servidor HTTP e o tempo vai ser tão ruin quanto seria se fosse feito em Ruby, mas ninguém vai se preocupar com isso porque você vai ter lá os seus 5 usuários simultâneos rodando dentro de uma intranet da vida.
O twitter chegou onde chegou porque eles tinham um turnaround altíssimo em Ruby pra adicionar novas funcionalidades e criar coisas novas, coisas que eles não teriam no início em Java e qualquer pessoa que já tenha feito um projeto web em java na vida sabe exatamente isso. A linguagem se prestou perfeitamente pra transformar o site no sucesso que ele é hoje, mas infelizmente o interpretador do Ruby está anos luz atrás da JVM, na verdade TODOS os interpretadores da atualidade comem poeira feio pra JVM a exceção do Mono e do .Net runtime da Microsoft. PHP? Python? Perl? Todos brincadeira de criança quando comparados ao trabalho de engenharia que levou a máquina virtual do Java que nós temos hoje.
Pro twitter cortar esses milisegundos foi não apenas uma diminuição de custos de hardware como também uma melhora do ponto de vista do usuário que vai notar uma diferença grande na busca final.
O problema é da linguagem? Sim e não, o problema é do interpretador primitivo (assim como os do Python, Php e Perl ) e das vantagens que a linguagem oferece e que também e transformam em custos em tempo de execução para o interpretador. Não existe almoço grátis, ter classes abertas, closures, tudo como sendo objetos em Ruby tem um custo alto no tempo de execução. A grande pergunta que as pessoas devem fazer é, será que esse custo se paga pro meu caso? Será que ter todas essas vantagens hoje do ponto de vista da linguagem cobrem as desvantagens da compicação que é pro interpretador lidar com isso?
Teoricamente, deveríamos todos ser partidários da lógica, já que somos todos programadores, mas as pessoas teimam em trbalhar com tecnologia como times de futebol, defendendo um em detrimento do outro, precisamos deixar dessa infantilidade e enxergar os fatos pelos fatos. Me dá pena ver pessoas que criam "ódio" por ferramentas, frmeworks ou linguagens de programação sem nem ao menos tê-los testado, porque essas pessoas simplesmente sinalizam que não serão capazes de continuar no mercado de TI, que é necessariamente sincretista e propenso aos meshes de coisas completamente diferentes.
Vivemos eternamente no problema onde a única ferramenta a mão é o martelo e queremos que tudo o que aparece na nossa frente são pregos.
|
|
|
|
|
|