D
Deleted member 156771
.
Ultima Edição:
Registre uma conta gratuita hoje para se tornar um membro! Uma vez conectado, você poderá participar neste site adicionando seus próprios tópicos e postagens, além de se conectar com outros membros por meio de sua própria caixa de entrada privada!
JavaScript, pois é um canivete suiço, dá para fazer várias coisas em áreas diversas. Se compensa, bom, como iniciante acho complicado, pois precisaria ter alguma bagagem para ter o que oferecer.
Eu não conheço muito os trabalhos de freelancer, mas já vi alguns do tipo Workana e achei bem ruins, pois paga-se muito pouco.
Normalmente o que funciona em freelancer é consultoria, mas novamente, precisa ter bagagem, ter contatos.
vi
vim é coisa de leite com pera.
Personalizei o vim todo, ficou uma delícia de usar.Eu uso o vi quase todo dia. Só com ele eu entendi a treta entre espaços vs tab.
Tentei usar webstorm por um tempo mas achei o vscode superior.To usando o VS Code e achei bem mais simplificado principalmente para subir um projeto no GitHub
To usando o VS Code e achei bem mais simplificado principalmente para subir um projeto no GitHub
Eu gosto do Sublime Text para fazer uma edição rápida em arquivos XML, YAML, SQL e etc. Ele foi feito em C++ então ele abre instantaneamente, já o VSCode usa Javascript com Electron e demora um pouco mais para abrir e também usa bem mais memória RAM. O VSCode eu só uso nos projetos de front-end.Tentei usar webstorm por um tempo mas achei o vscode superior.
Caramba eu deixei passar essa primeira linha hahaha. Eu dei uma lida por cima só pra ver sobre o que era o tópico. Foi mal!Foi o que eu coloquei na primeira linha do tópico, aquele tópico é o muro das lamentações. Esse aqui vamos focar em notícias, artigos, compartilhar informações e não lamentações. É mais para separar as coisas, senão fica muito tumultuado.
Foi o que eu coloquei na primeira linha do tópico, aquele tópico é o muro das lamentações. Esse aqui vamos focar em notícias, artigos, compartilhar informações e não lamentações. É mais para separar as coisas, senão fica muito tumultuado.
Dependendo da instituição eles dão algumas facilidades, pois muitas das instituições de lá tem parcerias com faculdades brasileiras.Dúvida:
Pós/Especialização/Mestrado via EAD em uma instituição do EUA, alguem sabe algo a respeito e o quanto é burocrático fazer isso morando no Brasil?
Imagino que a longo prazo se for procurar emprego fora do Brasil isso deve ajudar demais e um documento do EUA deve servir pra passar credibilidade em qualquer país.
Dependendo da instituição eles dão algumas facilidades, pois muitas das instituições de lá tem parcerias com faculdades brasileiras.
Varia conforme instituição, mas de algumas que eu vi, era basicamente pagar, fazer o curso e depois eles disponibilizavam o diploma para você imprimir.
Depois do curso não sei, porém durante o curso são bem chatos, no máximo tem os estágios de verão.É então, nem tou falando de uns lugar foda tipo MIT.
Pode ser uma "uniEsquina do EUA", tava até vendo uma interessante do Texas que oferece EAD mas era uns 50 mil reais por ano e... sei lá, Texas tem uma certa fama de não gostar muito de gente de fora do EUA então da um certo receio de algum professor tentar dificultar as coisas só de sacanagem.
Achei legal que várias delas te dão "work permit" por um tempo depois que concluir o curso então da até pra pegar um tempo de experiência em alguma empresa gringa.
Mas não faço ideia de como é a rotina com os estudos desse jeito.
Estudem blockchain e as linguagens para trabalhar com ela e serão felizes!!!O resto já é muito blá-blá, não o leveram a nada!
20 anos do Manifesto Ágil: a rebelião fracassada
O Manifesto Ágil completou 20 anos este ano, e há dois fatos que parecem evidentes:
Como chegamos a esse ponto? Todo mundo diz que faz Agile, mas quase ninguém é Agile.
- Agile, como rótulo, venceu; ninguém quer ser chamado de não Agile.
- O Agile, da forma como é praticado, fica terrivelmente aquém das ideias revolucionárias de seus fundadores.
Donde o Manifesto
Em fevereiro de 2001, um grupo de dezessete especialistas em software se reuniu no The Lodge at Snowbird ski resort nas montanhas Wasatch de Utah. Ao longo de alguns dias de discussão e debate, eles escreveram de forma colaborativa o “Manifesto de Desenvolvimento Ágil de Software”.
* Não sei a história pessoal de cada signatário, mas daqueles que conheço, todos ainda estavam ativamente escrevendo código ou tinham uma longa e recente história disso.
O primeiro ponto a destacar é que eram praticantes. Eles não eram gerentes de projeto, CTOs ou Engenheiros VP. Eles eram desenvolvedores, programadores, cientistas e engenheiros. Eles ainda estavam lançando códigos * e trabalhando com as partes interessadas para resolver problemas. Isso é importante.
O outro ponto é que o Manifesto Ágil não foi criado no vácuo. Muitas dessas pessoas já tinham uma metodologia que criaram e / ou faziam proselitismo. Eu posso estar um pouco fora do tempo, mas acho que todas essas metodologias pré-existiam “A Agile capital”: Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming. Eu sei que Schwaber e Sutherland falaram publicamente sobre Scrum em 1995, e Beck e Jeffries começaram a falar sobre Extreme Programming (XP) em 1996, eu acho.
Todos neste grupo tinham profunda experiência em escrever software e todos estavam em busca de uma alternativa aos processos de desenvolvimento de software pesados e orientados por documentação que governavam o dia. O cerne do manifesto eram quatro declarações de valor:
Estamos descobrindo melhores maneiras de desenvolver
software ao fazê-lo e ao ajudar outros a fazê-lo.
Por meio desse trabalho, chegamos a valorizar:
Indivíduos e interações sobre processos e ferramentas
Software de trabalho sobre documentação abrangente
Colaboração do cliente sobre negociação de contratos
Respondendo à mudança seguindo um plano
Ou seja, embora haja valor nos itens
à direita, valorizamos mais os itens à esquerda.
Uma nova esperança
Do nosso ponto de vista em 2021, é fácil tomar muito da prática moderna de desenvolvimento de software como garantido, mas em 2001, essas ideias eram extremamente radicais.
O que você quer dizer com que vai começar a construir o software antes de reunir todos os requisitos e estimar cada peça de funcionalidade? Isso é insano!
A parte importante que fica esquecida é que o Agile foi aberta e militantemente contra a gestão no início. Por exemplo, Ken Schwaber foi vocal e explícito sobre seu objetivo de se livrar de todos os gerentes de projeto - não apenas tirar as pessoas de seus projetos, erradicar a profissão de nosso setor.
Agilidade e PMI
Scrum Masters quase não tinha autoridade, não tinha votos nas questões. Eles eram líderes-servos, ajudando a proteger e desbloquear a equipe, mas não a administrar a equipe. XP era semelhante. Se bem me lembro, o XP originalmente tinha rastreadores e treinadores, que tinham uma vibração semelhante de facilitação e suporte.
Alistair Cockburn, signatário do manifesto e criador da metodologia Crystal e arquitetura hexagonal, teve uma discussão maravilhosa e perspicaz sobre isso recentemente, incluindo esta ideia (parafraseada):
Sou um Scrum Master certificado, trabalho em equipes Agile há mais de 15 anos e li muitos dos livros populares da área. Nunca vi ninguém enquadrar a ideia de forma tão explícita e sucinta (novamente parafraseando Cockburn):
O império Contra-Ataca
De certa forma, o Agile foi um movimento trabalhista de base. Certamente começou com os praticantes no terreno e foi empurrado para cima na gestão. Como isso funcionou?
Em parte, isso se deve ao crescimento dos desenvolvedores em número e valor para seus negócios, ganhando influência. Mas o maior fator, na minha opinião, é que a abordagem tradicional em cascata simplesmente não estava funcionando. À medida que o software ficava mais complicado, o ritmo dos negócios acelerava e a sofisticação dos usuários aumentava, tentar planejar tudo com antecedência tornou-se impossível. Abraçar o desenvolvimento iterativo era lógico, embora um pouco assustador para os gerentes acostumados a planejar tudo.
Lembro-me de reuniões em meados dos anos 2000 em que você podia dizer que a administração não estava realmente acreditando, mas estava sem ideias.
Que diabos, vamos tentar essa ideia maluca de que os engenheiros vivem falando. Não estamos atingindo os prazos agora. Quanto pior pode ficar?
Então, para sua surpresa, começou a funcionar, meio que aos trancos e barrancos. As equipes se debateriam por um tempo e então lentamente ganhariam suas pernas, descobrindo quais padrões funcionavam para aquela equipe individual, ganhando impulso. Depois de alguns sprints, você começará a ver o verdadeiro poder de priorizar o software funcional, a colaboração, reservar um tempo para inspecionar e adaptar e tudo o mais.
No decorrer de cerca de 5 anos, o Agile deixou de ser uma metodologia da qual você já tinha ouvido falar, mas provavelmente não estava acostumada com algo que todo mundo fazia. Em 2005, eu estava trocando de emprego e me lembro que o fato de saber um pouco sobre Agile e TDD foi um verdadeiro diferencial. Em 2010, presumia-se que as equipes de software modernas estavam fazendo um pouco do Agile. Pelo menos, isso foi verdade para minha bolha no mundo da consultoria; as grandes empresas sempre se movem mais devagar.
Conseguimos! Nós ganhamos! Parabéns a todos!
E esse é o fim da história. Você pode fechar a guia do navegador.
Infelizmente, como muitas revoluções, a história do Agile não se desenrolou como seus fundadores imaginaram.
Acontece que o Agile mal feito muitas vezes parece o caos.
- Acontece que priorizar indivíduos e interações é um conceito difícil de vender. É muito mais fácil vender processos e ferramentas.
- Acontece que software funcional é mais difícil de produzir do que planos irrealistas e resmas de documentação.
- Acontece que colaborar com os clientes requer confiança e vulnerabilidade, nem sempre presentes em um ambiente de negócios.
- Acontece que a reação à mudança geralmente é superada por executivos que desejam se sentir no controle e ainda precisam legitimamente fazer planos de longo prazo para seus negócios.
Isso não significa que os quatro valores estejam errados. Significa apenas que tudo isso requer algum esforço para acertar, alguma coragem para aceitar que o software é inerentemente confuso e caótico às vezes. Você tem que entender e acreditar que se continuar aprendendo e se adaptando e melhorando e enviando, você eventualmente chegará a um lugar muito melhor, um lugar muito mais honesto, realista e produtivo do que você jamais poderia com o Waterfall.
Esses são pontos importantes. Ainda precisamos planejar, documentar e ter rigor no Agile. É uma questão de equilíbrio. No entanto, se sua organização está lutando com uma transformação Agile, afundando no caos, você vai saltar quando alguém lhe oferecer um barco salva-vidas na forma de certificações, processos e ferramentas. Os executivos entendem os processos e ferramentas muito mais do que grocam equipes auto-organizadas.
Retorno doRogue One?
É aqui que minha estrutura de três atos se quebra um pouco, porque, infelizmente, não vejo os rebeldes corajosos voltando com este, pelo menos não sob o rótulo de Agile.
Está lotado de fornecedores de ferramentas, consultores de processos e especialistas que fazem promessas que nunca podem ser cumpridas. É assim que acabamos com SAFe e Scaled Scrum e todos os outros sabores Agile corporativos. Essas estruturas não foram criadas com intenções maliciosas e provavelmente têm algum valor no contexto certo. Mas eu não os chamaria de Agile. Tentar dimensionar uma metodologia que enfoca os indivíduos e as interações inevitavelmente levará a problemas - e corroerá o valor original da metodologia.
É assim que terminamos com esta famosa peça de 2018 de Ron Jeffries, signatário do manifesto e co-criador do XP.
Os desenvolvedores devem abandonar o Agile
É assim que acabamos com a famosa peça de 2014 de Dave Thomas, signatário do manifesto e co-criador da Programação Pragmática.
Agile is Dead (Long Live Agility)
Retro
A parte realmente triste disso para mim é ver os jovens desenvolvedores denegrirem o Agile e pensarem nele como um meio para a administração extrair promessas irrealistas e fazer com que as equipes de desenvolvimento trabalhem por horas loucas. Entendo. O único Agile que eles já conheceram foi um mecanismo de controle imposto a eles, não uma ferramenta de auto-capacitação que eles abraçaram com alegria. Mas espero que o início de algumas discussões sobre a história e a visão original possa nos ajudar a lembrar como as coisas deveriam ser.
A boa notícia em tudo isso é que os princípios do Manifesto Ágil são tão sábios e relevantes hoje quanto eram há 20 anos. E mesmo supostos apóstatas como Jeffries e Thomas ainda pensam assim.
Jeffries, no artigo mencionado acima, diz: “No entanto, os valores e princípios do Manifesto para o Desenvolvimento Ágil de Software ainda oferecem a melhor maneira que conheço para construir software e, com base em minha longa e variada experiência, eu seguiria esses valores e princípios, não importa qual método a organização maior usou. ”
Eu concordo.
Não é moderno ou legal falar sobre Agile agora. Agile é enfadonho. Todo mundo faz Agile, certo? Agora é o momento perfeito para refletir sobre os últimos 20 anos e nos fazer algumas perguntas:
Alguns de nós da Simple Thread que viveram a revolução planejam refletir sobre cada um dos 12 Princípios Ágeis originais nos próximos meses, contextualizar seu significado original e considerar seu valor no ambiente atual de desenvolvimento de software.
- O que deu certo?
- O que deu errado?
- O que queremos fazer de diferente da próxima vez?
Minha esperança é que, estudando os princípios fundamentais, possamos aprender com o passado e, nas palavras de Dave Thomas, possamos manter nossa agilidade mesmo se decidirmos abandonar o “Agile”.
Agile at 20: The Failed Rebellion
Every software team says they do Agile and yet almost nobody is Agile. How did we get to this point? Where do we go from here?www.simplethread.com
Bom, a tradução literal é alavancar e distribuir as postagens do seu site.
O leverage aqui é sobre técnicas para manter as pessoas em um site.
O syndicate aqui é sobre distribuição, para fazer com que seu conteúdo seja republicado por sites e redes de terceiros para obter mais exposição.