Rodrigo Sim

I registered for Google I/O 2024 and earned a badge! Join me! #DevBadges #GoogleIO developers.google.com/profile/badges…

Spending my Saturday playing the game: Where is my available USART PIN? 🤣

Alright team, we can do this! Retweet if you know anyone who is not currently a subscriber of C++ Weekly! @cppweekly" target="_blank" rel="nofollow noopener">youtube.com/@cppweekly

🚨 New Giveaway Alert! We're thrilled to announce our exciting giveaway in partnership with @wildernesslabs! Enter for a chance to win a Limited Carbon Edition Project Lab v3. 👉 How to Enter: 1. Fill out the form ▶️ bit.ly/46g2tfd 2. Share & Follow us

@appwrite I would like to build a bicycle shop App!

🗣️ Comment what you plan to build with the Appwriter 🫶 Like & RT the tweet above ✅ And submit your entry here: apwr.dev/keyboard

⌨️ GIVEAWAY ⌨️ 🎉 To celebrate our 1.4 release, we have designed an exclusive keyboard, the Appwriter keyboard, and 1.4 swag for you to win! How to win 👇

@bcsanches @giovannibassi IBM Clearcase?? Usei por muitos anos ... não tenho saudades.

@giovannibassi Mas eu usei um da IBM, num projeto éramos obrigado a usar, coloca todos esses no bolso. O treco era tudo ou nada, nem lembro o nome. Vc fazia um check-out, depois rodava um diff na mão e via o q mudou, daí listava arquivo por arquivo q queria fazer commit, atraso total de vida

Agora que o Git venceu e se tornou a principal forma para versionar código fica parecendo que ele sempre esteve aí. Então bora contar um pouco de como chegamos aqui e falar um pouco das "VCS Wars", que começaram no começo dos anos 2000 e só terminaram de vez perto do final da década passada. Vou contar de lembrança e do meu ponto de vista pessoal, então as lembranças adicionais e histórias pessoais de vocês são muito bem vidas pra ajudar a dar cor nessa história toda. O grande sistema de controle de versão corporativo no fim dos anos 90 e começo dos anos 2000 era o Microsoft Visual Source Safe, que a Microsoft não criou, mas comprou. Lembro que lá por 2000 mais ou menos todo mundo usava a melhor e mais nova versão, a 6.0, lançada em 1998 junto com as versões 6.0 de um monte de produtos, como o VB6, o Visual C++ 6.0 e o Visual Studio 6.0 (que ainda não unificava todas as linguagens sob uma única IDE). Quando a primeira versão do .NET foi lançada, em 2002, era esta versão que estava embutida, junto com a primeira versão moderna do Visual Studio, o C# e o VB.NET. Nessa época boa parte da web corporativa era feita com ASP3, mas o versionamento era com frequência feito de outra forma quando trabalhávamos com ASP. Eu nunca trabalhei full time com ASP - meu foco era desktop naquela época - então só lembro de forma esparça, mas lembro que tinha algo no IIS que fazia o versionamento (não sei se o nome era webdev ou algo do tipo) e todo mundo trabalhava no mesmo servidor, ou seja, sua máquina servia para apenas abrir o código que estava num servidor remoto. Se mais de um dev abrisse o mesmo arquivo, um podia sobrescrever o código do outro. Era bem ruim, e acho que nem tinha a ideia de commits. Por isso que o Visual Source Safe (VSS) foi tão importante, ele permitia que várias pessoas trabalhassem juntas sem sobrescrever o código uma da outra. Isso era tão importante, que ele tinha o conceito de checkout exclusivo, algo que hoje sabemos ser odioso, mas que na época era muito popular, principalmente entre gestores que não codavam (esse entidade que com frequência está do lado errado das decisões técnicas). Checkout era o ato de dizer pro servidor que você iria editar um arquivo. Sim, você contava pro servidor, e dava até pra ver na tela quem estava editando qual arquivo. Devolver os arquivos (alterados ou não) era conhecido como "checkin". E o checkout exclusivo era uma modalidade de checkout em que somente uma pessoa podia fazer checkout de um arquivo por vez, ou seja, quando você estava alterando o código mais ninguém podia alterar. Esse era o modo padrão do VSS, e o que a maioria das empresas adotava. O motivo pra isso é que fazer merge era algo muito difícil, as ferramentas não ajudavam, e perdia-se muito tempo com isso, então a maioria das empresas "resolvia" o problema proibindo o checkout compartilhado. Era um inferno, porque direto você ficava impedido enquanto alguém estava alterando um arquivo que você precisava às vezes só incluir duas linhas. Era comum ouvir na sala de dev "Zé, solta o arquivo tal rapidinho pra eu poder alterar!", ou até um "Quem tá com o arquivo tal?". E quando a pessoa fazia um checkout exclusivo e saia de férias, ou era demitida? Tinha que achar algum admin que soubesse desfazer o checkout a força pra que a gente pudesse voltar a alterar o arquivo. Pura diversão! Branches no começo dos anos 2000 eram raros, muitas empresas simplesmente não usavam ou sequer sabiam que existiam. Quem usava branch já estava muito à frente do resto, e o maior problema deles, de novo, eram os merges. Por isso, mesmo quem sabia que existia evitava. Quem usava branches, no final do desenvolvimento, passava por uma fase final chamada de "integração", que era basicamente algumas semanas integrando código, fazendo merge, arquivo a arquivo. Quem fazia isso eram só as empresas com produtos muito grandes. E esquece testes automatizados, nem a ideia era conhecida pela imensa maioria das empresas, então tudo era testado manualmente, o que fazia que a fase de integração ficasse ainda mais comprida. Integração continua era algo virtualmente inexistente. E ainda não falei de uma das maiores capacidades do VSS: a de corromper o código que você guardava nele. O VSS funcionava alterando os arquivos do seu banco de dados diretamente, ele abria os arquivos, escrevia e fechava. Isso não funcionava em um esquema cliente/servidor, não existia um servidor de VSS, era só um compartilhamento de arquivos. Isso era muito simples, e ajudava a colocar no ar rapidamente um versionador de código, você criava um file share num servidor, mandava o VSS guardar os arquivos dele lá, e pronto! Só que as LANs do começo da década de 2000 não era muito estáveis, e as WANs ainda menos. Se, no meio de um checkin, sua conexão falhasse, ele corrompia o banco de dados do VSS. Ou se duas pessoas tentassem escrever ao mesmo tempo. Em resumo, pelo menos uma vez por semana o banco de dados do VSS estava corrompido, e você precisava rodar rotinas de manutenção. Se os deuses do código estivessem com a pá virada, acontecia de você perder o código pra sempre. Um arquivo (ou vários), simplesmente não abriam mais, aí era um desespero, procurando no departamento quem tinha uma cópia da última versão do arquivo... se alguém tivesse a gente corrigia, senão, já era. Por isso, um monte de gente tinha métodos alternativos de backup, zip e coisas do tipo. Eu lembro de uma empresa que perdeu todo o código de uma DLL feita em VB6, app legada, e passou a escrever o código "em volta" dela; ela tinha a DLL compilada, mas não tinha mais o fonte, então quando precisava alterar algo no código ASP ela simplesmente escrevia direto no .asp, em vez de alterar o código VB. Caos! Nessa época, existia em paralelo o CVS, que muita gente usava, mas eu nunca usei. Havia muitas reclamações sobre ele também, mas ele já funcionava num modelo cliente/servidor. Quem tiver história, conte aí, que também devem ser boas. Só fui ouvir mais sobre ele quando pessoal já estava transicionando pro SVN, e reclamava do CVS. Em 2004 surgiu o Subversion (SVN), no modelo cliente/servidor, com a proposta de substituir o CVS. Muita gente brinca que o SVN nasceu errado, porque ele queria ser "um CVS melhor" (parte da zoeira da época). A real é que o SVN era excelente, quando comparado com as alternativas, e muita gente usou feliz, jogando tanto VSS quanto CVS fora. Tinha que usar via terminal/linha de comando, o que assustava muita gente, então surgiu o TortoiseSVN, uma extensão pro Windows que permitia usar o SVN sem precisar do terminal, direto nas janelas do explorador do Windows, e acho que tinha uma app desktop própria, também. Em 2006 a Microsoft lançou o Team Foundation Server (TFS) com o sistema de controle de versão que depois seria conhecido como Team Foundation Version Control (TFVC). O mesmo do time do VSS criou uma ferramenta nova para a sigla hype da época, o SDLC (Software Development Life Cycle). O TFS era uma ferramenta de servidor, que funcionava somente com as IDEs da Microsoft (inicialmente), principalmente o Visual Studio, e foi lançado para funcionar junto com o Visual Studio 2005, e só anos depois passou a funcionar no Linux e com outras IDEs, e via linha de comando. Era uma grande evolução, já que não se perdia mais código, backup era parte do processo, e ainda vinha com várias funcionalidades adicionais, que existem até hoje no seu sucessor, o Azure DevOps, como controle de trabalho etc. Mas era integrado com SharePoint e levava dias pra instalar. O livro de instalação tinha umas 300 páginas, e lembro de ter instalado ele umas duas vezes. Não era divertido. Como usuário, ele era ótimo, e de lá pra cá ele foi evoluindo muito, inclusive adotando Git na metade da década passada. O TFVC oferecia, e oferece até hoje, as mesmas funcionalidades de checkout exclusivo que o VSS, ou seja, este inferno específico continuava. E continuava até recentemente, quando o Git ganhou essa guerra de forma tão arrasadora, e o TFVC é visto raramente. Em 2005 tanto o Git quanto o Mercurial (Hg) foram lançados, mas ninguém falava deles nessa época de forma muito frequente, ao menos no Brasil. Por mais vários anos seguimos usando TFVC e SVN como as melhores opções, mesmo que Hg e Git existissem. Foi a comunidade de Rails que começou a popularizar o Git no Brasil, como aliás fez com um monte de boas ideias (a popularização do padrão MVC pra web veio deles, também, assim como a disseminação dos testes automatizados, o uso massivo do Github e do Heroku). Lembro que lá por 2009 o Git mal funcionava no Windows, e eu só conseguia usar ele direito no Linux. Já o Hg funcionava bem, já que é feito em Python, e o suporte pra Windows veio muito antes do suporte do Git. Eu cheguei a fazer vários projetos com Hg, e sua ergonomia era bem melhor que a do Git no começo, também. Por isso, também, que a comunidade de Python é uma das que mais usa Hg até hoje. O Git trazia diversas novidades, sendo que três acredito que eram as mais importantes: 1. Ele é distribuído, ou seja, não precisa de um servidor central, e você tem uma cópia fiel do repositório na sua máquina, podendo fazer commits locais. 2. Você pode reescrever o histórico (amend, rebase, squash etc). 3. Branches são baratos e merges são fáceis. Os dois primeiros pontos foram revolucionários, mas era o terceiro que ninguém acreditava. O principal motivo pra todo mundo evitar branches era o custo do merge, e a tal fase de integração que mencionei antes. Com Git, pudemos passar a executar de verdade a integração contínua do código. E cada dev tinha, na prática, um branch local na própria máquina. Além disso, na época, os branches no Subversion eram físicos no servidor, criar um branch no servidor podia levar dezenas de minutos. Uma das demos mais legais do Git que a gente fazia na época era mostrando o tempo pra criar um branch, você fazia um `git checkout -b meubranch` e imediatamente o branch estava criado. Ninguém acreditava. O merge rápido e com boas ferramentas também deixava muita gente atônita. É engraçado pensar nisso hoje, mas na época era essa dificuldade gigante, mesmo. Foram-se anos até que a comunidade de devs e o mercado abraçassem de vez o Git, e o Github sem dúvida foi importante nesse processo. O Github se tornou *a casa* do software livre, e foi instrumental na popularização do Git. A Microsoft só passou a suportar o Git no Team Foundation Server (hoje Azure DevOps/Azure DevOps Server) em 2013 (dez anos atrás!), depois de uma baita pressão do mercado. Eu mesmo acabei causando um certo alvoroço ao, já como MVP, sugerir no site oficial de feedback da Microsoft que algum tipo de DVCS passasse a ser suportado no TFS em 2012, e a ideia se tornar a mais votada em poucos dias, enquanto eles já estavam discutindo a ideia de suportar Git no TFS. E no fim deu tudo certo, e hoje até o time do Windows roda Git no Azure DevOps, no que dizem ser o maior repositório Git do mundo, e considero o Azure DevOps a melhor ferramenta de DevOps do mercado neste momento. Nesse processo rolou muita treta, muita gente achava que o Git nunca seria o principal VCS usado no mundo. Eu contribui como pude, divulguei Git de toda forma, e o coloco num patamar diferente do que existia antes. Vejo algumas gerações nos softwares de controle de versão: 1. VCS sem arquitetura cliente/servidor, como o VSS; 2. VCS centralizados com uma arquitetura cliente/servidor; 3. DVCSs, ou sistemas de controle de versão distribuídos. O Git está na terceira geração (junto com o Hg), e por isso está em outro patamar. Não dá pra comparar VSS ou SVN com Git, é até injusto. Tem palestra minha mais de dez anos atrás contando o que era o Git pra quem ainda não conhecia, e algumas mais recentes falando do seu uso avançado. E eu sigo achando que o melhor uso do Git é feito na linha de comando para a maioria das suas funcionalidades (tem muitos posts meus sobre isso, também). Além disso tudo, o Git não só uma ferramenta de controle de versão. Já falei de demonstrei em palestras várias vezes como ele pode ser instrumental em te ajudar na escrita de código, te ajudando a testar ideias, e até a encontrar bugs. Fora seu uso no servidor, por exemplo, fazendo GitOps. E nem vou entrar nas guerras dos sites de compartilhamento de código, quando um monte de empresas tentava dividir a hegemonia do Github, e todas falharam miseravelmente. Fica pra outro post. Olhando em retrospecto, é incrível que hoje a maioria das empresas tem até vergonha de falar que não usa Git, ou pior, que usa SVN, ou TFVC. Ainda bem!

🎁 Giving Away 100 System Design + ML System Design Books + Newsletter Deep Dive Content 🎁 To celebrate our upcoming 1-year YouTube channel anniversary, we will be giving away: 🔹 10 signed physical books (vol. 1 + vol. 2 + ML system design; winners get all 3) 🔹 90 1-year subscriptions to the ByteByteGo online course. The course includes content for two system design books (vol. 1 and 2), vol. 3 (coming out in 2023), and an ML system design book. 🔹 10 1-year subscriptions to the ByteByteGo paid newsletter content. 🔹 Shipping is on us. If you live outside the US, you will receive a 1-year subscription to our online course. 𝐇𝐨𝐰 𝐭𝐨 𝐩𝐚𝐫𝐭𝐢𝐜𝐢𝐩𝐚𝐭𝐞: ✅ Follow me on Twitter ✅ Like & Retweet ✅ Subscribe to our free weekly newsletter: bit.ly/42Ex9oZ If you have already signed up, please enter your email again to be eligible. ⏰ The giveaway ends in 72 hours. #systemdesign #coding #giveaway .

10K FOLLOWER GIVEAWAY 🎉🎈🎁 To celebrate 10K followers on Twitter, we're giving away 3x Raspberry Pi Foundation tote bags containing Raspberry Pi branded goodies 😍 Winners will be randomly selected on Friday, 19 May 2023. To enter: Follow us, like & RT this tweet. Good luck!

Estou juntando todas as ISOs do Kurumin para disponibilizar como arquivo histórico. Quem tiver alguma podemos combinar por DM adicionar, tá faltando algumas... (dá RT para dar uma força)

Pessoal, estão abertas as inscrições para a turma 10 do meu curso online e ao vivo de Clean Code e Clean Architecture! app.branas.io/clean-code-e-c…

Pow só 33 seguidores pra 5k. Podiamos fechar o ano com 5k nao? Dá um RT e segue ae pra ajudar! Resumo do que faço: Hackeio e explodo coisas, também rodo Doom onde não é pra rodar.. E (tento) ajudar quem tem problemas com baixo nível ou quer entender como as coisas funcionam

Lenovo's committing to further transformative form factor innovation by revealing rollable smartphone & PC proof of concepts. #LenovoTechWorld #WeAreLenovo

Tune in to #LenovoTechWorld on Oct. 18 to see our latest innovations, hear from industry leaders & watch people change the world with our tech. What time? Glad you asked: 🕘 9:00 AM PDT 🕚 11:00 AM CDT 🕛 12:00 PM EDT 🕐 1:00 PM BRT lnv.gy/3D1tYO4 | #WeAreLenovo

Join Lenovo, October 18th, at #LenovoTechWorld where Lenovo & industry leaders explore how our technical innovations will empower our changing world for the better. REGISTER NOW: lnv.gy/3g9Zu3i | #WeAreLenovo

Tecnologia mais inteligente já está capacitando nosso mundo em mudança. Junte-se a nós no dia 18 de outubro para revelar nossas últimas inovações, ouvir líderes do setor e mostrar como nossa tecnologia está capacitando as pessoas a mudar o mundo para melhor. #LenovoTechWorld

Welcome to the Android fam, Motorola edge 30 Ultra, edge 30 Fusion and Edge 30 Neo! #hellomoto #FindYourEdge

Less than 24 hours to go before the #OSSummit Latin America Virtual Experience begins! Catch five different talks by our teammates from @Mesonbuild system applications to #remoteworking team connections.

Texting a friend with a different phone than you should be no problem… Right? @Apple? #GetTheMessage

@AndroidDev Android 1.5 with Motorola DEXT at 2009. Next was Android 2.0 with Motorola Droid at same year.

When did you first start on Android? Reply below to let us know! ⬇️