| Autor |
Mensagem |
|
|
Tirando usuários hardcore, como os que frequentam este forum e que acham o máximo ter um telefone que interpreta código de barras por exemplo, a verdade é que a grande fatia de usuários da mais valor ao conteúdo do que as funcionalidades mirabolantes que o aparelho possa vir a ter, e nesse sentido o iphone é muito superior em termos de facilidade de acesso a conteúdo web e aplicações nativas por meio da appstore.
A Nokia tem muito trabalho pela frente!
|
 |
|
|
rylphs wrote:
cmoscoso wrote:Em se tratando de objetos, alterar os parametros de uma funcao é considerado programacao de risco, voce nao esta reduzindo acoplamento, e sim o contrario.
Como assim? Não entendi. 
O metodo algumaCoisa() esta alterando o objeto passado como parametro (x.facaAlgo()).
|
|
|
|
rylphs wrote:
Isso foi só um exemplo mais curto. A questão é o que eu devo fazer quando me deparar com esse tipo de situação. Devo criar o objeto dentro da classe, delegar a criação à quem irá chamar o método, ou talvez isso dependa da situação? Gostaria de saber também sobre o uso de interfaces. Sempre devo criar interfaces? É isso que significa "Programe para uma interface, e não para uma classe"?
Mais uma vez, me desculpem por tantas perguntas, mas ainda tenho muito o que aprender.
Obrigado
O exemplo é curto mas serve pra mostrar uma pratica que é muito comum. E quando se deparar com ela deve refatorar para melhor expressar a intencao do codigo. Em se tratando de objetos, alterar os parametros de uma funcao é considerado programacao de risco, voce nao esta reduzindo acoplamento, e sim o contrario.
Baseado no seu exemplo, sim, delegar a criacao do objeto para quem ira chamar o metodo teria um menor acoplamento.
|
|
|
|
|
O primeiro exemplo dói até na espinha. Chamar um método void num objeto recebido como parâmetro no mínimo é sinal que o design tem que melhorar.
|
|
|
|
leo.luz wrote:Ola a todos!
Infelizmente não pude ir esse ano. Vida de recém casado é dureza. Nesse dia eu tava apertando torneira, instalando prateleiras, etc.. Andei meio fora de sintonia nesses últimos 2 meses. Aos poucos estou voltando a ativa! 
Porém tratei de correr atras para dar uma boa olhada nos slides e ainda peguei o feedback com o pessoal do meu time que esteve por la.
Achei muito interessante essa discussão em relação ao ESB. Mesmo por que o Kenobi (@scaphe) nos ministrou um treinamento no antigo ServiceBus da BEA atual OracleServiceBus no final de 2008. Agora estamos no meio do projeto de implantação, indo para um novo datacenter e o espaço do ESB está reservado.
Sei que estou caindo de pára-quedas na discussão e não pretendo tomar nenhum partido. De qualquer forma acho estranho denegrir a imagem do ESB com a argumentação de que é possível fazer tudo o que ele faz programaticamente. Não que eu duvide dessa afirmação, mas quanto tempo levaria para implementar as funcionalidades desejadas dentro do seu ambiente? Se sua empresa tem uma certa proximidade, facilidade e interesse de negociação com um grande player de mercado, ainda assim estaríamos "errados" em disponibilizar um ESB em nosso modelo arquitetural? Nunca acreditei que ele fosse a bala de prata e que com ele iremos resolver todos os nossos problemas arquiteturais, apenas acredito que ele resolva o que se propõe a fazer.
Agora sinceramente acho ridículo que uma legião passe a crucificar essa solução, por que uma pessoa de renome deu a entender que esse não é o melhor caminho. Como disse, não assisti a palestra, mas me pergunto: será que foi isso mesmo o que Jim Webber quis dizer? " Não usem ESB. Ele é o grande vilão!". Foi realmente essa a moral da história? De fato não tenho certeza se foi isso mesmo, mas o que sei é que visão, coerência e bom senso devem ser os guias de qualquer pessoa quando o assunto é tomada de decisão! 
Abraços!
-LeoLuz-
Uma breve pesquisa neste fórum e na internet pode revelar que antes mesmo da palestra do Jim a discussão envolveu muito mais do que 1 pessoa criticando soluções ESB, ele apenas sintetiza tudo (numa brilhante apresentação por sinal!).
|
|
|
|
francislon wrote:É extremamente natural os moderadores diminuirem suas atividades no fórum. Não esperem que em todo tópico tenha um moderador imediatamente disponivel para responder a dúvida. A função da comunidade é que todos ajudem uns aos outros, não só os moderadores ajudem.
Você ensina uma criança a andar, e depois deixa ela andar por conta própria.
Se estava referindo a meu post, nao falei em ajuda, mas em participacao.
|
|
|
|
Curioso como Ruby sempre é a segunda opcao para o programador Java que resolve procurar alguma coisa diferente. Acontece que Ruby é famoso num nicho em particular que Java domina (servidores) e portanto nao vejo muita diferenca representada nessa escolha (a nao ser pelo fato de ruby estar muito atras do java em termos de tecnologia).
Considerando que ultimamente nao tenho ouvido falar muito na linguagem Ruby supohnho que ainda seja o efeito da onda que nos assolou algum tempo atras e ainda se manifesta em alguns.
|
|
|
|
O problema é que muitos moderadores ja deixaram isso aqui ou participam de uma forma muito timida nas discussoes. Tirando um ou outro que participa mais efetivamente (como o thingol) a impressao é que o forum esta entregue as moscas. O papel de moderador nao pode ser so de bloquear topicos e escrever unit tests pro jforum. IMO, quem nao tempo para entrar nas discussoes com a comunidade deveria passar o bastao para que outros possam exercer o papel de forma mais efetiva.
Nota: Nao quero ser moderador do GUJ.
|
|
|
|
juliocbq wrote:
Agora eu fiquei preocupado. Pra vc, quem cria tecnologia nova? Não confunda Software de Bradesco com tecnologia nova que sai do zero, que ajuda na medicina e na genética, astronomia e viagens espaciais.
O pessoal que trabalha em fábrica de software somente adapta tecnologia.
Se eu estiver errado, é só me provar o contrário.
Poderia esclarecer entao porque defende que seja restringida a atividade desse mercado que apenas "adapta" tecnologia a engenheiros e cientistas de foguete?
Porque esta faltando a quem defende esse tipo de regulacao é justificar de forma convicente seus argumentos em termos de beneficios para os profissionais e o mercado como um todo, em outras palavras, voces precisam pensar fora do umbigo!
Pra falar uma coisa destas, vc deve ter trabalhado somente com CRUD na vida.
Existe um mercado enorme pra esse tipo de aplicacao la fora. Nao seria estranho pra mim se muitos aqui do forum estejam nessa situacao que voce descreveu.
|
|
|
|
Otimo que hoje qualquer pessoa pode fazer uma sistema que vai servir a uma outra, significa que a tecnologia evolui o suficiente para permitir que isso acontecesse. Nao vejo como um retrocesso ou pratica danosa que precisa ser extinguida.
É impressao minha ou os sobrinhos sao geralmente mais produtivos? Gostaria de saber qual linguagem que eles usam...
|
|
|
|
Cmosco que q vc tem contra consultores pre-sales? hehe
Acho que expliquei no posto anterior a forma que alguns trabalham e que deixa a desejar. Acho que o minio que se espera é o vendedor conhecer o produto que esta vendendo, nada contra os consultores pre-vendas, e nem poderia ter, se uma empresa quiser trabalar com outras empresas ela nao pode abrir mao de uma equipe de vendas.
|
|
|
|
Taz wrote:
cmoscoso wrote:
Nunca confie em consultores. Como diria sei la quem: "Quem sabe faz, quem nao sabe ensina, e quem nao sabe ensinar presta consultoria".
Não confunda consultores com consultorias.
Consultores são especialistas contratados para fornecer informações sobre determinada área de conhecimento para empresas. Ou seja, é possível e até recomendável que uma empresa que nunca se aventurou por conceitos como SOA, XP, SCRUM, etc, etc... contrate consultores para fornecer know-how nos primeiros projetos.
Consultorias (body-shops) contratam profissionais a quem chamam de "consultores" com objetivo de alocá-los em suas fábricas e em seus clientes. O único objetivo aqui é o da redução de custos. Quanto menos um profissional se propõe a receber para atender aquela demanda, melhor.
Voce menciona 2 tipos de consultores, aparentemente um bom outro ruim. Portanto meu alerta tem um fundo de verdade!
Nota: Eu nao chamaria contratacao bodyshop como consultores. E acho que as empresas tem essa nocao, tanto é que esse tipo de profissional costuma ser pouco valorizado. As vezes, o termo é utilizado como um titulo pomposo apenas pra seduzir um candidato a vaga que seria de implementacao de uma solucao. (por isso, incompativel com o perfil que seria de um consultor de verdade.)
Mas nao estava me referindo a esse tipo de "consultor". Alias, a frase que citei é injusta sim (alias como toda generalizacao), mas existe ainda um 3o tipo de consultor que voce nao menciona, muito disseminado por ai, que vou chamar de consultor de ferramentas. É aquele que antes de conhecer qual o seu negocio ja tem uma ferramenta pra vender, ou recomendar. Tais ferramentas alem de nao representarem nada em termos de inovacao para o seu negocio (por serem solucoes padronizadas que procuram atender a todos), possivelmente nao resolverao o problema atual. Governanca, IMO, esta mais para um processo agil aplicado ao core business (pessoas e papeis), do que padronizacao de tecnolgia e ferramentas (waterfall). Governanca nao é mais uma das especificacoes SOA.
|
|
|
|
Proteu Alcebidiano wrote:...não programam mais na linguagem java.
+1. So nao tive a coragem de dizer isto aqui. rsrs
|
|
|
|
FredGeek wrote:Galera,
oq vcs recomendam para o usuário q está aprendendo a tecnologia e pensando em tirar certificação?
quais os reflexos q vcs acham q influenciarão positivamente e negativamente a aquisiçao para este perfil de usuário?
tirar este certificado estava nos meus planos desde o ano passado, estava pensando até em fazer pós q enfatize a linguagem Java,
agora já n sei + oq fazer.
obs: Estou acompanhando todas os posts deste tópico e as respostas as perguntas q foram feitas por usuário iniciantes n sanaram a minha dúvida
Voce acha que um potencial cliente seu se importa se voce vai usar java ou nao?
Claro que nao. Portanto se preocupe em criar solucoes, independente da linguagem.
|
|
|
|
carol_programadora wrote:
cmoscoso wrote:
Nao, voce precisa fazer/executar testes funcionais desde o inicio, nao com prototipos mas sim com os requisitos. O ideal seria nao incluir a UI nos testes funcionais. O objetivo é testar as regras de negocio. Num projeto bem arquitetado essas regras de negocio estao agrupadas num lugar, e este lugar nao é a interface do usuario. Quando os testes funcionais passarem significa que o caso de uso foi implementado.
Obrigada pelas respostas, nesse aspecto acima que você disse, então no caso seria realizado após os testes de unidade?
Porque você disse que ao passar por esse teste, então o caso de uso foi implementado, então seguindo uma lógica, após testar as unidades, e ai verificar se as regras estão atendendo?
fiquei confusa em ponto exato realizar 
O que voce entende por "realizar" um teste? Se eu entendi bem e voce quer dizer "executar", entao eu executo os meus de 2 em 2 horas.
Testes funcionais (que sao escritos para/por analista de negocios no inicio) permitem saber quando uma determinada regra de negocio foi implementada. O teste funcional é a especificacao das regras numa forma que seja compreensivel para o seu analista do negocio ao mesmo tempo executavel. Testes de unidade sao testes do desevolvedor num nivel mais baixo, de implementacao.
Dito isso, a ordem em que eles sao "realizados" sao independentes uma vez que cada teste tem propositos diferentes. Na hora que passou o funcional é porque aquele caso de uso esta implementado (pelo menos como fora especificado pelo teste, por isso a importancia de ser escrito pelo analista).
|
|
|
|