| Autor |
Mensagem |
|
|
A maioria reclama do licenciamento mas só votaram SIM por causa da velha máxima "não se morde a mão de quem dá de comer". Afinal, Red Hat, VMWare, IBM e SAP ganham dinheiro com Java, e não são nem loucos de tomar uma sova da Oracle. A Apache e o Google são os únicos que já perderam alguma coisa, e que por isso tiveram culhões para dizer NÃO.
Tecnicamente é uma boa notícia, mas politicamente significa que Java será um nicho apenas do mercado corporativo, sendo insignificante em outras áreas.
|
 |
|
|
chun wrote:Legal , então GPL não é genuinamente livre ? Voce tem noção da BESTEIRA que está falando ?
elias_era wrote:GPL é uma licença genuinamente livre, Apache permite uso de código proprietário, FSF é diferente do pessoal da OpenSource.
Trolls,
façam um favor, coloquem o que eu havia dito num arquivo e faça um "grep" com a expressão GPL, verão que não traz nenhum resultado! Então, como é que vocês podem retrucar algo de que eu não falei?
Não deveria, mas vou explicar. Quando digo: "BSD e Apache são genuinamente livres", não estou dizendo que as outras não são. Assim como, quando eu digo: "Eu gosto de melancia", não quer dizer que eu detesto melão. Sacou? Ou quer que eu desenhe?
|
|
|
|
A impressão que eu tenho é que Javeiro não entende de software livre. Só pode ser!
Java permite um ecossistema livre, como as inúmeras bibliotecas e servidores disponíveis que estamos utilizando. Porém, isso é diferente de ser livre.
Não é livre porque:
 não é possível fazer fork;
uma implementação não pode usar o TCK usando licenças genuinamente livres, como a BSD ou a Apache
Não estou falando mal da Oracle, isso é uma atitude que começou na Sun e está se estendendo até agora. Se alguém aqui acha que forks e alterações de qualquer pessoa deveria ser proibido, tudo bem! Mas não vem dizer que desse jeito Java é livre, porque não é!
|
|
|
|
Não tem como. A solução é guardar o tamanho numa variável e passá-la junto com o array em todos os momentos.
Assim:
|
|
|
|
lavh wrote:Esses dias tava conversando com o meu chefe sobre começar a deixar de usar Java como linguagem de desenvolvimento, e a resposta dele foi a seguinte
Se Java que é popular, já estamos com vagas a mais de 3 meses abertas e não conseguimos preencher, imagina se a gente passar a usar Scala por exemplo, não vamos encontrar profissionais prontos nunca.
De certa forma eu concordo com ele. Em um mercado aonde falta profissionais como o nosso, você usar algo que não seja mainstream é praticamente assinar um termo de "Terei que treinar todos os profissionais que vierem trabalhar aqui", e isso tem um custo elevado.
É preciso levar esse fato em conta também. Principalmente em áreas como aqui, que um projeto durá em produção 10 anos ou mais. E se vc faz um projeto que vai durar esse tempo em Scala, e neste intervalo Scala é abandonado?
É uma decisão bem delicada essa de abandonar a linguagem Java.
Para nós desenvolvedores, é importante aprender várias linguagens destas que estão surgindo, e tocar nossos projetinhos pessoais com a linguagem que atender melhor e for mais rápida pra aquilo. Mas para as empresas, a decisão fica bem mais difícil.
É a velha visão de curto prazo obfuscando a visão de longo prazo. Às vezes, gostaria de saber de quem não consegue contratar o que foi oferecido para os candidatos e aonde os procurou. Porque, sério, eu recentemente procurei emprego e a maioria dos recrutadores não mostrava nenhum diferencial que pudesse atrair candidatos, nenhum! É tudo a mesma coisa! Como é que eles esperam despertar o interesse de quem já tem quase a mesma coisa num outro emprego?! Bom, divago, voltando ao tópico...
O que você e seu chefe não percebem é que:
a) o pool de programadores Java é grande, mas está cheio de imbecis e alpinistas de carreira, salvando-se poucos; porém, o pool de programadores Scala é pequeno, mas que estão ali por paixão, onde boa parte é muito produtivo.
b) Qualidade triunfa sobre quantidade. A mentalidade taylorista impede de ver que a diferença de produtividade entre o pior e o melhor programador é muito grande, da ordem de 20 vezes mais. Sim, é isso mesmo, programação é uma atividade intelectual, portanto não é limitado pelo cansaço muscular. Posso dizer que é melhor ter uma equipe pequena de sete programadores Scala altamente motivados do que 50 operários que mechem (com "ch", porque não sabem nem português) com Java, mas desmotivados e sem possibilidade de alçar voos.
c) Uma empresa só vai contratar muito menos de 0,1% do pool de programadores. Não precisa que o pool seja grande, apenas que corresponda com a expectativa daqueles que estão neles. Outra, pare de procurar na APInfo, corre atrás e participe das comunidades Scala.
d) Um software não vai durar 10 anos se a política for manter a mesma arquitetura. Ela precisa evoluir, nem que seja pra trocar de linguagens por um tempo. Ou você acha que existe otário dando manutenção em um sistema do jeito que era feito há dez anos trás? (Não precisa responder, eu sei que tem!) Imagine: J2EE 1.3, com Struts 1.2.x, aqueles DTOs intermináveis... Acha que um sistema sobrevive, atendendo plenamente o cliente, continuando do jeito que tá? Se liga! Chegará o momento em que alguma nova tecnologia atenderá melhor os problemas do cliente do que a arquitetura corrente, e os homens do sistema precisam ter coragem para mudar!
|
|
|
|
marcosalex wrote:Já vi um monte de linguagem nova aparecer, pregarem que é o futuro e que os desenvolvedores tem de focar nelas. Daí um monte de gente gasta dinheiro com treinamento, participando de congressos e apresentações e meses depois a linguagem desaparece.
Vamos ser críticos: quanto tempo um bom desenvolvedor demora pra aprender uma linguagem pelo menos ao ponto de ficar produtivo?
Se na sua região o mercado dessas linguagens estiver promissor, beleza. Mas se ainda ficar só na promessa, acho melhor investir em tecnologias que hoje estão em alta e geram dinheiro.
O que não pode é a pessoa ficar extremamente focada em uma só linguagem ou uma só tecnologia, mesmo Java sendo a mais popular. Mas acho que isso é óbvio.
1- Não aparece tanta linguagem nova assim.
2- Qual foi a última linguagem que desapareceu? Eu não conheço nenhuma.
3- Um bom desenvolvedor não demora pra aprender uma nova linguagem. Se demora, não é bom!
4- Inicialmente, um profissional deve buscar sim as tecnologias mais utilizadas hoje. Porém, duvido que demore mais de dois anos pra aprendê-las. Após esse período, o profissional precisa dedicar parte do seu tempo mais no futuro do que no presente. Senão, corre um sério risco de perder o bonde.
|
|
|
|
Usar null não é muito diferente de falar palavrão: é possível evitar, mas você está tão acostumado que o usa do mesmo jeito.
O problema principal é que a maioria dos programadores não entendem de máquinas de estado. Talvez porque morcegaram na aula de Linguagens Formais e Autômatos, ou talvez porque nunca tiveram essa disciplina na faculdade. Por não conhecer, usam null como estado da aplicação. Exemplo: uma classe Pedido possui dataEntrega como atributo que, quando for nulo, significa que o pedido ainda não foi entregue. Ou seja, ao invés de evitar o null, torna-o como parte fundamental para o funcionamento do sistema. E olha que existem outras opções, como criar um enum ou usar o pattern State.
Ponteiro null não tem nada de baixo nível, Assembly não tem referências; é apenas uma maneira pobre de pensar sobre uma linguagem.
Haskell e Scala tem opções quanto ao ponteiro null, é basicamente um container que armazena um valor ou nenhum valor. Mas não é só isso, Haskell tem a notação "do" e Scala tem for-compreensions. Ao colocar uma sequência de instruções dentro de um "do"/for-compreension, se uma delas retornar Nothing, as instruções seguintes param de ser executadas e Nothing é retornado no final. É um jeito mais simples do que verificar com ifs cada retorno de programa.
|
|
|
|
Bruno Laturner wrote:Continuando as afirmações do relatório anterior, eles pedem para que as empresas considerem diminuir a quantidade de código desenvolvido especificamente para Java, em favor de linguagens mais indicadas para o desenvolvimento de suas soluções.
(...)
Por outro lado, eles continuam recomendando a JVM como plataforma, reforçando o uso dela como uma máquina virtual de propósito geral para linguagens como Ruby, Groovy, Scala e Clojure. (retirado do relatório de Janeiro).
É a tendência desde 2007. E é um alerta para os programadores se adaptarem, procurando aprender outras linguagens. Infelizmente, a reação de muitos é trollar no GUJ ao invés de tomar atitude.
Bruno Laturner wrote:Ainda sobre linguagens, eles recomendam a adoção de Ruby, JRuby, C# 4.0, e JavaScript como linguagem de primeiro escalão, e também começarem a tentar Groovy e DSLs.
Principalmente o Ruby, né? A recente versão do Rails 3 é pra mim uma prova de que os railers deixaram de ser babacas e se tornaram adultos; pois o framework agora deixou de ser "opinionated" para ser modularizável e extensível, coisa que qualquer framework ou plataforma grande deve ser.
Bruno Laturner wrote:Plataformas, também desaconselham o GWT, e desenvolvimento de RIAs, além de seu uso em visualizações ricas. (Abril)
RIA sempre foi bullshitagem pra mim. É colocar a aparência estética acima da simplicidade, elegância e usabilidade. Os projetos RIA que eu participei entregavam softwares bonitos mais muito pouco funcionais, e acredito que essa era a norma do mercado.
Bruno Laturner wrote:No campo de SOA, aconselham a evitar o ESB, e os WS-* além do básico.
Na realidade, é o WB-* Basic Profile, né? Sim, isso é um pé-no-saco, porque é muito fácil criar um Web Service que não possui interoperabilidade com outras linguagens.
Kenobi wrote:Outra coisa que ele não menciona é sobre centralização de segurança, por exemplo, que é um grande vilão em projetos com equipes e frameworks heterogêneos.
Eles falam sobre OAuth, serve?
Eu sei lá, eu consigo imaginar centralização de autenticação, com LDAP ou Active Directory. Mas não acho possível, ou mesmo aceitável, usar a mesma solução de segurança para todos os projetos de uma empresa.
|
|
|
|
nel wrote:Aceita uma lista de qualquer tipo de Objeto e retorna um objeto que extenda comparable, sendo que este comparable aceita qualquer Objeto pai de T.
Sim, trata-se de generico, mas me responda, está trabalhando com isto ou foi a título de curiosidade?
P.s: verifique a questão de ? super T, vale a pena.
Abraços.
Err... não. O retorno é void.
A parte <T extends Comparable<? super T>> apenas restringe o tipo genérico que é aceitável.
Quando digo <T extends Comparable>, quero dizer que o parâmetro genético T pode ser de qualquer tipo, deste que implemente a interface Comparable (caso contrário, é erro de compilação).
Camparable também possui um tipo genérico, por isso também é "generificado" na declaração acima. A expressão <? super T> quer dizer: o Comparable pode ser de qualquer tipo T ou qualquer classe pai de T ou qualquer interface que T implemente. É mais fácil de explicar com um exemplo.
Suponha uma classe chamada Animal:
A classe Gato pode ser usado no método sort
porque implementa Comparable, cujo tipo genérico é o mesmo da classe.
A classe Cachorro também pode ser usado
porque implementa Comparable, cujo tipo genérico não é o mesmo da classe, mas é supertipo da classe.
Agora a classe Iguana não pode ser usado
porque, apesar de implementar Comparable, seu tipo genérico não tem relação de supertipo com a classe Iguana.
Espero que tenha sido claro.
|
|
|
|
marcelo.bellissimo wrote:Não tem nada de chute, existem métodos muito bem definidos de se estimar custos e prazos de projetos, utilizando valores que podem ser facilmente mensurados por um bom GP...
Quem estuda metodologias ágeis sabe que o grande ponto fraco é sua falta de capacidade para determinar os riscos do projeto... agora, se você fosse uma empresa grande, com um projeto grande, utilizaria uma metodologia que não te garante os riscos? O bolso dói e não deixa, né?
GP's super power mega hiper formados e certificados, usam esse tipo de metodologia, pois para projetos super power mega hiper complicados e grandes, o risco é super power mega hiper perigoso e grande também, pra se usar outro tipo de metodologia...
Não digo que não há mercado pra esse tipo de metodologia, sempre tem uma ou outra empresa com coragem pra arriscar, mas convenhamos que a grande maioria não compartilha dessa opinião...
Não sei quem disse isso (acho que Mandelbrot) e não lembro se é exatamente desse jeito, mas a frase é assim: "Tem gente que prefere acreditar numa mentira que responda todas as suas dúvidas do que na pura verdade de que não podemos saber de tudo."
O grande problema é que as pessoas encaram a "falta de definição" do Agile como uma fraqueza da metodologia, quando na realidade os projetos é que são inerentemente sem definição. A diferença é que o Waterfall mascara todas as incertezas e todas as desconfianças. Não estou defendendo o Agile, apenas dizendo que Waterfall é errado.
__________________________________________________
Havia um outro ponto da minha conversa que se perdeu. Pelo contexto, o autor original da thread queria saber como praticar, e aí ele pensava em mil processos para fazer a coisa. A minha dica era para parar de usar o processo como desculpa, e começar a praticar escrevendo o software, mesmo que não estivesse correto no ínicio. O meu pressuposto era de que ele estava estudando, e não trabalhando, onde o custo de um erro é zero.
|
|
|
|
É incrível como tem gente que pede a mesma coisa. Eu já escrevi isso antes.
Lendo o meu outro post, você percebe que não precisa de Java ME para instruir o celular a mandar o SMS.
|
|
|
|
Não, não é possível. O JPA assume um a presença de um banco de dados relacional, coisa que o Cassandra não é.
O protocolo diz que, se você quiser fazer conexões remotas, deve vazer isso através do JCA (Java Connector Architecture), que define um meio de conexão da sua aplicação Java com um "sistema externo". Não conheço muito JCA, não poderia te ajudar nessa questão.
Mas também nunca vi um servidor forçar isso, o que implica que você pode abrir conexões ao Cassandra num Servlet ou num EJB, apesar de não "abençoado" pela especificação do Java EE. Qualquer coisa, crie um Singleton pra criar uma conexão ao Cassandra. Ou então, se estiver usando JBoss 6, um Producer do CDI.
|
|
|
|
Cara,
é assim: o pessoal está lhe dando (e você também está propenso a) uma receita Waterfall de fazer as coisas. Porém, uma coisa é certa na nossa área: Waterfall não funciona. Aliás, na nossa área está cheio disso: um monte de coisas que sabe-se que não funciona, mas nada de coisas que certamente funciona.
Você postou no fórum de Java Básico. Então pressuponho que você tem pouca prática com programação. Por isso, te dou um conselho: se você quer fazer um sistema de padaria, faça-o; mesmo não tendo uma ideia de como fazer, faça de qualquer jeito.
O único jeito de aprender é errando, e é nos erros que você vai entender a falta que determinada prática ou metodologia faz. Esquece essa discussão de melhor forma de fazer as coisas. Não existe receita pronta e você só vai entender o que é bom praticando.
|
|
|
|
Marck wrote:Como eu disse, eu entendo que o Objeto possui uma interface, ou seja, a Interface não é um objeto até ela ser implementada! Até por que, para ser objeto, tem que herdar de Object, e Interfaces só podem herdar de outra Interface.
Ou estou errado?
Você confunde implementação com instância. Interface é implementada, mas nunca instanciada; então, uma interface não pode se tornar um objeto, no máximo, posso usá-la como uma referência para um objeto.
Interfaces podem herdar de outra interface, ou pode não herdar de ninguém. Só não podem herdar de classes.
|
|
|
|
Marck wrote:Olá!
Eu entendo que o objeto possui uma interface. Quando esta interface é implementada, ai sim ela É-UM objeto.
Perceba que não faz muito sentido usar os termos "filha" ou "filho". Um Carro É-UM Automovel faz mais sentido do que dizer que Um Carro é Filho de Automovel. O termo "filho" é mais usado em banco de dados onde temos tabelas filhas.
Para ilustrar o que penso, fiz o seguinte teste:
abraço
O teste não faz sentido. Você está testando se uma classe anônima, que implementa Inteface, é instância de Object. Claro que sim. Porém, isso não responde a pergunta do tópico: a de que Interface é filha de Object.
|
|
|
|
|
|