.NET,C#, CLR,CLI,Boas práticas,Arquitetura,Agile
Carreira
Obrigado ASKSoftware!
097 dias
Olá pessoal, após um longo tempo sem postar estou de volta com algumas novidades, algumas novidades profissionais que vou compartilhar aqui no blog e outras pessoais, quem me acompanha no facebook já deve ter reparado 
. A principal novidade é que após 1 ano e 8 meses eu deixei de trabalhar na asksoftware e voltei a trabalhar com o pessoal da Harpia Ventures, sendo mais específico com o pessoal do place to ask. Quem me acompanha sabe que em 2009 eu trabalhei na harpia ventures com o pessoal do Evenka.
Falando do tempo em que fiquei no asksoftware certamente não vou conseguir descrever tudo que aprendi lá. Desde as pessoas incríveis que tive a chance de conhecer até todas as tecnologias que aprendi. Muito do meu aprendizado pode ser visto aqui no blog, entre as tecnologias que usamos nos diversos projetos estão: ASP.NET MVC (1,2 e 3), Entity Framework 4, TFS. Hg,XML, XSL além de praticar um monte de coisas que acredito como TDD, agilidade e build contínuo.
Eu só tenho a agradecer pela oportunidade e pela confiança que a equipe depositou em mim, espero em breve ter a oportunidade de participar de outros projetos com a galera.
Falando do futuro aqui na Harpia ventures vou continuar com um trabalho semelhante com o exercido da Harpia Ventures, com exceção do tipo de software que estamos construindo que é uma aplicação social pra internet e não um software corporativo intranet. Os primeiros conhecimentos que vou ter que adquirir/praticar aqui são otimização/escalabilidade e segurança, então já sabem que vem post no blog sobre isso ai, vou começar com o livro Ultra-Fast ASP.NET, indicação da galera aqui. Por enquanto é isso pessoal, até,
DevDay #BH Sucesso Total
1176 dias
Olá pessoal, no ultimo sábado(27-08) tive a honra de participar do #devday. Eu já tinha confirmado minha ida ao evento um mês antes, no entanto surgiu a oportunidade de participar fornecendo uma lightning action. Quero agradecer ao pessoal de BH que foi super. receptivo e bem legal, um prazer rever amigos e conhecer pessoalmente muitos outros.Eu e RodrigoVidal gostamos tanto que até perdemos o voo, o evento foi excelente.
Conteúdo
A agenda já prometia um grande evento, tivemos de tudo! destaco as lightning actions que foram bem dinâmicas e legais. gostei bastante da apresentação sobre NoSql apresentada pelo gibran, gostei bastante também da talk sobre qualidade de codificação apresentada pelo Glauber. Entre as palestras teve tudo que gostaria de ouvir, a primeira que destaco foi a apresentação sobre a importância do front-end e as novidades do rails 3.1, eu gosto de Rails e já esperava uma apresentação bem focada no framework e no mundo Ruby, no entanto fui surpreendido por uma excelente palestra totalmente focada em desenvolvimento de front-end web. O Daniel Lopes mostrou como olhar de maneira profissional o front-end e de quebra deixou vários assuntos pendentes de estudo. Ainda tivemos as palestras sobre falhas de segurança e a palestra chocante do Rodrigo Vidal sobre programação funcional. O Rodrigo vidal explodiu a cabeça do pessoal, falando bem sobre programação funcional. A apresentação envolveu matemática, compiladores,linguagens e tudo mais que programadores gostam de ouvir, sensacional. Ainda tivemos o Giovanni bassi falando sobre CoffeeScript, mostrou bem como está fácil usar a tecnologia com o ambiente de desenvolvimento .NET, nota 10.
Minha Lightining action
Eu falei rapidinho como está sendo o processo de mudança e adoção de melhorias no dia-a-dia da asksoftware, foi uma apresentação rápida e bem pragmática. aqui estão meus slides
Happy Hour e comunidade
O happy hour foi sensacional, rolou até tarde no assacabrasa. O pessoal discutiu muito sobre tudo e pouco sobre software, é legal ver a comunidade ainda mais próxima e conversando sobre muitas coisas além de desenvolvimento.. quem foi ao devday e não foi no hh perdeu metade do evento 
Para saber mais
Você pode saber mais sobre o evento buscando a hashtag #devday que por sinal foi TT em Belo Horizonte, você ainda pode acompanhar o blog do Douglas Aguiar
Eu confio no suporte, o suporte confia em Dev?
0226 dias
by higor.cesar
in Carreira
Olá pessoal, estava pensando em colocar agile no titulo desse post pois afinal de contas parece que quase tudo que é legal hoje com relação a equipes e comportamento profissional é relacionado á agilidade certo? Eu não concordo com isso, então vamos falar sobre o assunto(confiança) independente sobre o que a equipe acredita ou pratica.
O assunto voltou à tona(já falei muito sobre esse assunto com o sidney filho) e durante um #HH com o pessoal da ASKSoftware conversando com um profissional do suporte, ele me falava como acreditava no software que estamos desenvolvendo e ainda como acreditava que a equipe está fazendo um bom trabalho e que fica feliz em trabalhar na empresa e com a equipe que trabalha. Isso já era o suficiente para me fazer pensar, afinal de contas não tenho a mesma certeza que a equipe de desenvolvimento acredita no software que está sendo criado quanto o profissional do suporte em questão.
A conversa continuou e ele ainda me disse que quando presta suporte que envolve possíveis problemas ele sempre parte do princípio que as outras equipes, implantação e desenvolvimento, fizeram um ótimo trabalho e da melhor maneira possível. Ficar sabendo disso me deixou muito feliz em saber da confiança depositada por esse profissional no que estava sendo feito por todas as outras equipes. Imediatamente após o sentimento de felicidade e satisfação teve início um momento de reflexão, eu faço o meu trabalho da melhor maneira para só assim ser merecedor da confiança de outras pessoas?
Enquanto eu refletia sobre o merecimento da confiança de outros colegas de trabalho, comecei a pensar se todos os membros da minha equipe também fazem por onde, para só fazermos parte de uma equipe merecedora de confiança. Durante a semana em que rolou esse HH o pessoal de desenvolvimento discutiu bastante sobre transparência entre os membros da equipe. Como já falei aqui em posts anteriores estamos adotando práticas ágeis e acredito que já passamos por boa parte da curva de aprendizado, o ponto é que agora acreditamos que devemos evoluir para um ponto onde as pessoas precisam ser transparentes e confiarem que cada pessoa faz o seu melhor.
Essa semana vou falar sobre a conversa que rolou no HH com o “cara” do suporte e propor uma reflexão sobre o assunto. É isso pessoal, espero que o post sirva de reflexão para as pessoas que ainda acreditam que podem fazer a diferença.
Percepção da geração de valor
0260 dias
Olá pessoal, o assunto do post será a percepção pelas partes envolvidas em projetos de software sobre a geração de valor. O post será baseado na experiência que estou tendo durante a adoção de agile na equipe em que trabalho, logo muita baboseira ou concepções não corretas de acordo com as literaturas podem surgir.
Desenvolvedor Herói
O IgorMusardo fez a tradução e falou um pouco sobre o assunto aqui, no post ele a tentativa de alguns desenvolvedores de salvar o projeto/Sprint/release com atos heroicos, quer exemplos?
- Nos últimos dias de um Sprint mal sucedido o desenvolvedor começa a trabalhar 3 horas a mais por dia na tentativa de salvar o Sprint.
- Após um dia inteiro corrigindo bugs e revendo implementações em javascript o desenvolvedor não vai embora enquanto não corrigir o ultimo bug no I.E 6
- Após uma review desastrosa o desenvolvedor decide virar a noite resolvendo bugs
Ahh isso que você está falando é dedicação/perseverança/paixão! Fique calmo, também não sou o desenvolvedor experiente em lidar com a vontade de ver as coisas funcionando e ver o Sprint falhando de maneira absurda. Desde que iniciei com desenvolvimento até os dias atuais encarei as tarefas de tal maneira, afinal de contas missão dada é missão cumprida. No início da carreira não existia hora extra suficiente, trabalhava o quanto fosse preciso por mais que as vezes estivesse tão cansado que até era “destrutivo”.
Horas extras não sustentáveis a longo prazo
Todos estão cansados de saber, afinal de contas já leram isso no programador pragmático e na metade das bibliografias sobre agilidade. O complicado é na hora que o bicho pega conseguir encaras os fatos com frieza e respeitar os limites
Porque você não vai salvar o projeto?
Quanto maior o projeto menor será o efeito de suas noite sem sono e fins de semana de programação. Quando um projeto precisa de 20 horas/desenvolvedor semanais a mais para ser entregue no prazo é sinal que existe um problema, Se é necessário um herói para fechar todos os Sprint isso certamente é um problema.Você realmente acredita que consegue salvar um projeto de 6 meses com uma dezena de pessoas envolvidas somente com suas 10 horas extras semanais? Você pode até tentar..
E dai que você é um herói? ninguém sabe disso
Pode até ser possível que com dedicação e força de vontade você consiga salvar um Sprint ou até um release. Digamos que você trabalhou durante o final de semana refartando uns códigos e tornou o desenvolvimento do Sprint mais fácil, a questão é: quem se importa? vejamos um exemplo:
O desenvolvedor A refatorou um código tenso na segunda pela noite e acabou trabalhando até as 23 horas, no próximo dia o desenvolvedor está cansado pela manha e se atrasou para o daily scrum. Os desenvolvedor B e C não olham o servidor de código fonte e nem fazem ideia de um commit as 23 horas, sendo assim logo consideram que o desenvolvedor A está “desmotivado’. A percepção de valor gerada pelo desenvolvedor A é zero, nem seus amigos de trabalho reconhecem o valor e quem dirá seu gestor ou ainda o Cliente.
Eu sou herói por vocação, gosto de programar e resolver problemas
Esse ponto é defendido por alguns desenvolvedores, eu até já defendi essa ideia trocando um tuites com o igormusardo e já foi fruto de discussões também com o Juan lopes. São dois pontos diferentes, são eles:
- Vicio em resolver problemas
solução: Frequentar dojos, resolver problemas como treino em programação, participar de competições - Gosto muito de programação
solução: Desenvolver novos projetos, dedicar tempo ao estudo e aprimoramento, abrir seu próprio negócio.
Reflexão:Estou mesmo gerando valor?
Todos os pontos aqui abordados são voltados a reflexão sobre o valor gerado por atos heroicos durante o desenvolvimento. Existem diversos outros pontos que não foram tocados como por exemplo família e dinheiro. É importante que um ritmo sustentável seja mantido, afinal de contas do que adianta só apagar incêndios e não atacar o problema de uma maneira adequada que propicie a todos os envolvidos a percepção adequada de valor.
O Background do desenvolvedor .NET
4296 dias
Olá pessoal, esse é um dos post que estou devendo a muito tempo e já vou dizendo aqui que se você defende .NET e C# de maneira xiita e acha que PHP não serve pra nada é melhor parar de ler agora mesmo.
Antes de entrar no assunto principal do post preciso fazer uma introdução que envolve falar um pouco sobre a minha carreira e como entendo programação. Eu tenho 21 anos e comecei a programar aos 15 anos, tenho pouco tempo de experiência mas já consegui aprender algumas coisas legais. Eu iniciei em programação usando Delphi, logo no início achava tudo muito legal, afinal de contas sentia uma tal liberdade pois conseguia obter um resultado de diversas maneiras. Após uns 2 anos de Delphi me envolvi bastante com Java,PHP e ASP, nesse tempo estava aprendendo orientação a objetos e boas práticas de desenvolvimento. Logo após esse período que durou mais ou menos um ano comecei a trabalhar com .NET, inicialmente com VB.NET e depois foquei no C#.
Evolução, larguei o PHP e MySQL
Durante esse tempo programei usando plataformas Linux e Windows, editores ricos(VS) e simples (notepad ++) , eu como comecei do Linux com GEdit até chegar no windows + visual studio. Durante os primeiros anos e cada mudança de tecnologia eu pensava
“Meu deus, como eu consegui usar essa tecnologia ruim por tanto tempo? ahh agora eu evolui nunca mais usarei a tecnologia x!”
Assim que comecei a frequentar algumas comunidades .NET e conhecer desenvolvedores C# vi que muitas pessoas também pensavam como eu e investiam bastante tempo falando mal de uma ou outra linguagem ou até mesmo um editor.
Que chato! sempre visual studio + C#
Depois de algum tempo desenvolvendo em .NET comecei a sentir falta de usar Linux e outras tecnologias, linguagens e editores. Então voltei a desenvolver algumas coisas em Java e comecei a aprender um pouco sobre outras langs como Ruby, então estava parcialmente em contato com outras tecnologia. Comecei a frequentar grupos de outras linguagens e descobri que grande parte das pessoas lá não ficavam reclamando da sintaxe de atribuição de uma linguagem.
Durante a minha carreira tive a chance de conhecer excelentes profissionais e encontrei alguns “gurus” que me ensinaram que saber uma linguagem é legal, mas existe um conhecimento valioso que vai além de saber sintaxe. Desde que aprendi isso gostei a ideia e entre os últimos 20 livros técnicos que li acho que uns 2 ou 3 eram sobre linguagens, todo o resto é sobre aquelas letrinhas que todos nós sabemos ser importantes.
Se você usar a linguagem X e editor Y você será infeliz e amaldiçoado!
Escuto em muitas rodas de desenvolvimento primariamente .NET que se você usa PHP e MySql é impossível desenvolver bem ou ainda se você não usar o Visual Studio com resharper você não será produtivo. Até entendo esse pensamento quando parte de um inicialmente, mas as vezes encontro pessoas mais experientes pensando assim e amaldiçoando todas as outras possíveis soluções.
Sou mais que um desenvolvedor, sou um desenvolvedor .NET
Considerando que todos os programadores gostam de verdade de programação, e isso envolve ficar horas fuçando código ou ainda participar de competições ou perder finais de semana dentro de uma sala discutindo código é no mínimo estranho ver desenvolvedores que se denominam desenvolvedores .NET e C# e que não estudam outras linguagens.
Saber programar não envolve apenas conhecer sintaxe
Todos as pessoas que frequentam esse blog sabem do valor de coisas como Refatoração, testes unitários, orientação a objetos e princípios como DRY, e nenhuma dessas coisas é pertinente de uma plataforma ou linguagem, então como é possível desenvolver bem em C# e não conseguir entregar um software em VB.NET ? seu conhecimento de programação é muito mais amplo que sintaxe de uma linguagem e ainda mais acredite sua linguagem vai acabar ou se tornar obsoleta em breve
Ok, mas que .NET é melhor que Java é!
Pergunto sinceramente, qual o mérito de comparar linguagens de maneira depreciativa? Não é melhor acreditar que existe uma combinação de fatores onde pode ser viável usar a determinada tecnologia? você também não fica de saco cheio de usar a mesma linguagem 8/10 horas dia por um ano?
Conclusão
Acredito que se uma pessoa gosta mesmo de programação a linguagem não deve ser o mais importante, todos temos uma linguagem preferida mas não precisamos programar e defender apenas uma linguagem. Seguir a dica do programador pragmático de aprender ao menos uma linguagem por ano vai fazer com que você aprenda mais “programação” e ainda permite que você não fique entediado de escrever sempre o mesmo CRUD em C#. O framework .NET é muito rico, permite o uso de linguagens como Boo, IronPython e IronRuby. É isso pessoal, vamos largar o xiitíssimo e cair dentro do código, eu por exemplo ando muito tentado em começar a postar sobre outras coisas além do mundo .NET no blog, estou tentando evoluir também, vamos juntos!
Links
http://boo.codehaus.org/
http://dojorio.wordpress.com/sobre/
http://pragprog.com/the-pragmatic-programmer
Review:Rework
3311 dias
Olá pessoal, uma das minhas ultimas leituras foi o livro Rework. Antes de começar a falar sobre o conteúdo do livro posso adiantar que se você gosta de Agile pode parar de ler e ir correndo comprar o livro, eu garanto que você vai gostar.
Agilidade aplicada em negócios
Provavelmente em algum momento você já pensou em iniciar um negócio, se buscou ajuda de outras pessoas provavelmente eles falaram que você precisa de um plano de negócio, uma ideia bem definida, uma análise do mercado e dezenas de outros documentos. Os comentários na contra-capa do livro já defendem que você não precisa de nada disso para começar, na verdade você precisa apenas começar! você pode começar com apenas uma hora por dia e não precisa de nenhum documento ou consultoria em negócios.
Planning is guessing
Neste capitulo a dica é encarar planejamento como suposição. Quando você cria um plano de negócios você pode estar planejando todos os passos do seu negócio por mais de um ano. O plano de negócio envolve muitos aspectos que estão fora do controle ou até da zona de influencia do empreendedor, então você não deveria se aborrecer se as coisas não saírem como o planejado. Isso é absolutamente normal.
Responder a mudanças mais que seguir um plano
Be a starter
Aqui os autores dizem que o termo empreendedor deve ser abandonado, o termo empreendedor carrega muita bagagem. Quando pensamos em empreendedores pensamos em pessoas experientes em negociações e que sabem como planejar um novo negócio. A sugestão é que você se denomine um “iniciador”, afinal de contas você só precisa iniciar.
You don,t create a culture
Esse capitulo aborda a “definição” da cultura da nova startup, geralmente a cultura é baseada na missão, visão e valores. Essa cultura é artificial, a cultura real é fruto do comportamento e práticas do dia a dia
Culture is the by-product of consistent behavior
Start at the epicenter
Quando um novo negócio é iniciado existem coisas que você quer fazer, coisas que você pode fazer e ainda coisas que você precisa fazer. O fato é que você precisa começar pelo necessário. E como identificar o que é necessário? pergunte-se:
Se eu remover essa funcionalidade, o produto que estou vendendo ainda vai existir?
Esse capitulo é seguido por um capitulo de titulo ignore the details early on juntos esses capítulos lembram também o princípio YAGNI
Long list do’nt get done
O capitulo começa perguntando quando foi a ultima vez que você terminou todos os itens de uma lista grande de coisas a fazer.Grandes listas intimidam e na maioria dos casos você não precisa concluir todos os itens,então começe a fazer listas menores.
Conclusão:
Rework é o livro ideal pra quem está pensando em iniciar um negócio e gosta tanto dos princípios ágeis que gostaria de aplicar agile além do desenvolvimento de software.Eu tive uma experiência boa durante um curso de scrum que realizei pouco depois de ler o livro, tive a chance de ligar diversos princípios agile ao conteúdo obtido do livro.É isso pessoal, espero que esse pequeno post motive-os a ler o livro e que seja uma boa experiência.
Carreira: Como foi meu último ano de trabalho
0371 dias
by higor.cesar
in Carreira
Faz aproximadamente um ano que fui convidado a trabalhar na Landesigners como desenvolvedor .NET sênior. Na entrevista me interessei muito pela proposta de influenciar as decisões de arquitetura dos projetos. Meu trabalho diário envolveria seleção de tecnologias, definição de arquitetura(código) dos projetos e implementação das soluções.
Primeiros meses de trabalho
O primeiro mês de trabalho foi bem legal, selecionar as tecnologias pro projeto foi fácil, sendo um sistema online corporativo usamos grande parte das tecnologias mainstream do mundo Dot Net. O complicado foi evangelizar a equipe com uma arquitetura razoável de separação de responsabilidades em camadas. A equipe já tinha desenvolvido em .NET mas sem muita experiência em boas práticas e etc., o resultado é que ficou um clima de descrença e demorou um pouco até que todos estivessem desenvolvendo fluentemente com a nova arquitetura. Hoje a equipe não só compreende a arquitetura atual como também se preocupa em organizar e evoluir o projeto.
Muitos projetos em dois meses
Durante o ano passado participei de projetos de diferentes tipos como Windows Service, Web Services, Código de integração com terceiros e bibliotecas utilitárias. Alguns desses projetos envolvem processamento multi-thread que nos levou a criar um padrão de desenvolvimento, tivemos a chance de fazer tunning e chegamos ao final com uma arquitetura e código razoável e cliente satisfeito com o produto. Já nesta etapa a equipe estava confiante nas soluções e valorizando a comunicação e o trabalho em equipe. Nesta etapa trabalhamos em mais de um projeto, aconteceu que parte do código ficou proprietário, então tínhamos esse problema para resolver.
Construção do relacionamento na equipe
Após a ultima etapa que durou mais ou menos dois meses a equipe já tinha um bom relacionamento, então começamos a discutir mais as soluções possíveis assim como começar a parear e tivemos como resultado o nivelamento de conhecimento nos vários projetos da empresa
Análise dos seis meses iniciais de trabalho
Após esse tempo tínhamos clientes satisfeitos e um projeto de código razoável mas ainda muito trabalho pela frente. Teve início uma série de discussões sobre metodologias ágeis e praticas relacionadas como teste unitário e automatização de build
Hoje e amanha
Atualmente estamos desenvolvendo soluções mais elegantes e a preocupação com o código da equipe me agrada bastante. Temos teste em alguns projetos e iniciamos um trabalho mais próximo dos princípios ágeis e até agora estamos evoluindo na minha visão.Já temos consciência do débito técnico e sabemos que temos que pagar esse débito aos poucos. Estou trabalhando para que em breve a equipe tenha plena ciência dos princípios ágeis assim como um senso de responsabilidade e satisfação em desenvolver software.
Conclusão
Hoje vejo arquitetura como um papel dentro da equipe de desenvolvimento, na verdade acho que o ideal é que toda a equipe possua conhecimentos necessários para discutir e especificar boas soluções. Hoje ainda estou no inicio da minha carreira e estou completamente satisfeito com a experiência que adquiri durante os últimos anos. Sem dúvida ainda não participei de “Equipes perfeitas” ou “Projetos perfeitos” acho que participar de equipes e ser capaz de contribuir para a evolução dos membros e dar soluções razoáveis com recursos limitados são experiências vivenciadas por bons desenvolvedores de software.
Relacionamento transparente na equipe ágil
3384 dias
A interação entre indivíduos é um dos mais importantes valores da cultura ágil. Hoje vejo que muitas empresas com seu scrum-but interpretam parcialmente esse valor. As equipes se reúnem toda manha, definem o rumo em conjunto e “valorizam” os indivíduos.
Qual o problema? os relacionamentos são transparentes?
Exemplo: um desenvolvedor não acredita que o time chegou na melhor arquitetura para um novo projeto, o que ele faz? cede com medo de não ser aceito? ou ainda tenta defender seu ponto de vista mesmo que não seja compreendido ou não compreenda a solução selecionada pela equipe?
Enquanto ele não compreender e valorizar a solução como a mais adequada para o problema ele pode continuar com seu pequeno pensamento divergente
Alguns podem pensar que não existe motivo para desmotivação pois é só uma pequena decisão do projeto. O problema é que isso pode acarretar em novas pequenas frustrações, como assim? basta ver a teoria das janelas partidas.
-
"Considere-se um edifício com algumas janelas quebradas. Se as janelas não são reparadas, a tendência é para que vândalos partam mais janelas. Eventualmente, poderão entrar no edifício, e se este estiver desocupado, tornam-se ocupas ou incendeiam o edifício.
Ou considere-se um passeio. Algum lixo acumula-se. Depois, mais lixo acumula. Eventualmente, as pessoas começam a deixar sacos de lixo."
No contexto do relacionamento entre indivíduos uma primeira falha de compreensão pode acarretar em um ambiente propício para novas falhas até um momento em que a transparência e confiança se perdem.
O que podemos fazer?
Nos últimos anos tive algumas experiências que me ensinaram que não só de tecnologia se faz um desenvolvedor. Todos sabem que habilidades sociais tem seu valor, no entanto em equipes ágeis essas habilidades são mais importantes ainda.
É isso pessoal, estou longe de falar com autoridade sobre o assunto mas acho que vale por ser a visão de um desenvolvedor. O propósito do post é propor uma reflexão.
E quando Linguagem é ubíqua mas é Legada?
2399 dias
Contexto do problema
Olá pessoal, como o texto sugere o assunto será a linguagem ubíqua de um projeto de migração de sistema. Atualmente participo de um projeto de migração de um sistema de workflow desenvolvido em VB 6 e coisas da época, Assim que cheguei a equipe teve o início de mudança de paradigmas. As mudanças ocorreram no processo de desenvolvimento, terminologias e tecnologias. O modelo antigo usava notação Húngara e as pessoas se comunicavam usando expressões do tipo: O método A espera os parâmetros idPart e tpSt. O que isso quer dizer? depende do método! A utilização de siglas fazia com que termos tivessem mais de um significado, em determinado contexto o significado era esse:
idPart = Id do participante
tpSt = Status
Todas as equipes envolvidas com o produto falavam a mesma língua mesmo que essa língua fosse dúbia as veze, O fato é que existia e ainda existe uma linguagem ubíqua.
Solução do analista/Arquiteto
Eu desempenho o papel de arquiteto nesse projeto(sei que muitos discordam quanto a consideração de arquitetura sendo um papel) e logo que começamos a desenvolver usamos novos padrões de nomenclatura, e isso significa:
- Eliminação da notação húngara
- Adoção do inglês como padrão
- Diminuição da quantidade de siglas
Estamos desenvolvendo a nova versão do produto que inclui muitos produtos “acessórios” e tudo está ocorrendo razoavelmente bem, os clientes estão satisfeitos mas de fato poderia ser melhor(assunto para outro post), a equipe está razoavelmente acostumada com a tradução entre termos e tudo mais..O problema?
Hoje vejo que fui responsável por destruir parte da linguagem ubíqua!
Hoje vejo que a comunicação seria excelente sem traduções e etc., quando cheguei no projeto não tive a maturidade para ver que já existia uma linguagem e que todos estavam satisfeitos com ela. Fico feliz em hoje conseguir ver que fiz uma escolha precipitada.
É isso pessoal, gostaria de ouvir de outros desenvolvedores que passaram por esse embate entre uma linguagem ubíqua “Fora dos novos padrões” e uma nova linguagem que não é compartilhada pela equipe. Tem experiências? conta ai..
Reunião DotNetArchitectsRJ (15-01-2010)
1408 dias
Olá pessoal, sabado dia 15/01/2010 vai rolar no Infnet mais uma reunião do DotNetArchitectsRJ, iniciando as 09:00 hrs. Essa será a primeira reunião da comunidade em 2010 e todos nós estamos motivados em tornar este ano melhor que o que passou.
Pauta
Não temos uma pauta definitiva! no ultimo encontro rolou um coding dojo até a hora do almoço e durante o almoço definimos alguns assuntos para debater e simplesmente tudou rolou na maior sintonia.Você pode conferir o que rolou no ultimo encontro aqui no meu post
Participe
Você pode participar levando problemas pro dojo, sugestões de palestras ou dúvidas o negócio é participar.
Infra estrutura
O evento vai rolar no Infnet e só posso dizer que a estrutura lá arrasa! Tem tudo para ficar bem legal, máquinas poderosas,projetores, internet de alta velocidade.. é só chegar
Informações