Podcasts about Monorepo

Malcolm Matalka, founder of Terrateam, joins host Giovanni Asproni to talk about the reasoning behind choosing a not-so-widespread language (OCaml) and (almost) totally avoiding frameworks for the development of Terrateam. While discussing the reasons for choosing this specific programming language and the advantages and disadvantages of using external frameworks, they also consider a range of related topics, including static vs. dynamic typing, the use of monorepos, and the advantages of choosing a single language that can be used both for web front ends and server back ends. The episode ends with lessons learned that can be applied to other contexts and projects. Brought to you by IEEE Computer Society and IEEE Software magazine.

في حلقة النهارده هنتكلم عن موضوع مهم في تطوير الويب، وهو الـ "Monorepo". ببساطة، المونوريپو هو مكان واحد بنحط فيه مشاريع كتير بتاعتنا، بدل ما كل مشروع يبقى له Repository خاص بيه. يعني بدل ما يبقى عندك كذا "بيت" للمشاريع، كلهم بيبقوا في "بيت العيلة".طيب، ليه نعمل كده؟ فيه فوايد كتير. أول حاجة، الكود بيتشارك بسهولة بين المشاريع المختلفة. لو عندك Component كويس، تقدر تستخدمه في أكتر من مشروع من غير ما تكرره. تاني حاجة، إدارة الـ Dependencies بتبقى أسهل بكتير، ومشاكلها أقل. كمان، التغييرات اللي بنعملها في الكود بتبقى متناسقة بين كل المشاريع، وده بيقلل المشاكل. ده غير إن الشغل بيبقى أسرع، والتيم بيقدر يشتغل مع بعض بشكل أحسن.لكن، زي أي حاجة، المونوريپو له تحدياته. مهم برضو نختار الأدوات المناسبة، زي Nx أو Turborepo أو pnpm workspaces، كل أداة ليها مميزاتها.في الحلقة دي، هنشرح كل ده بالتفصيل، وهنعرف إمتى نستخدم المونوريپو وإمتى لأ!لينكات مفيدة:NxTurborepopnpm workspacesLerna

Tobi Lütke is the founder and CEO of Shopify, a $130 billion business that powers over 10% of all U.S. e-commerce. Starting as a snowboard shop in 2004, Shopify has become the leading commerce platform by consistently approaching problems differently. Tobi remains deeply technical, frequently coding alongside his team, and is known for his unique approach to leadership, product development, and company building. In our conversation, we discuss:• Why complexity kills entrepreneurship• How to develop and leverage your unique talent stack• How specifically Tobi approaches thinking from first principles• The importance of focusing on unquantifiable qualities like joy and delight• Why Tobi works backward from a 100-year vision• Why metrics should support decisions, not make them• The power of following your curiosity• What Tobi believes it takes to be a great product leader• Much more—Brought to you by:• Sinch—Build messaging, email, and calling into your product• Liveblocks—Ready-made collaborative features to drop into your product• Loom—The easiest screen recorder you'll ever use—Find the transcript at: https://www.lennysnewsletter.com/p/tobi-lutkes-leadership-playbook—Where to find Tobi Lütke:• X: https://x.com/tobi• LinkedIn: https://www.linkedin.com/in/tobiaslutke/• Website: https://tobi.lutke.com/—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• X: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—In this episode, we cover:(00:00) Welcome and introduction(04:17) The Tobi tornado(07:10) Maximizing human potential(11:05) Education and personal growth(16:47) Operating without KPIs(25:00) First-principles thinking(40:04) Remote work(45:59) Why Tobi never stopped coding(54:46) Embracing disagreement(01:01:27) The 100-year vision(01:09:29) Balancing tactics and positioning(01:17:15) Encouraging entrepreneurship(01:19:34) The power of good UX(01:28:42) The talent stack and unique opportunities(01:34:30) The role of passion in product development(01:36:39) Final thoughts and farewell—Referenced:• How Shopify builds a high-intensity culture | Farhan Thawar (VP and Head of Eng): https://www.lennysnewsletter.com/p/how-shopify-builds-a-high-intensity-culture-farhan-thawar• Breaking the rules of growth: Why Shopify bans KPIs, optimizes for churn, prioritizes intuition, and builds toward a 100-year vision | Archie Abrams (VP Product, Head of Growth at Shopify): https://www.lennysnewsletter.com/p/shopifys-growth-archie-abrams• The ultimate guide to performance marketing | Timothy Davis (Shopify): https://www.lennysnewsletter.com/p/performance-marketing-timothy-davis• Brandon Chu on building product at Shopify, how writing changed the trajectory of his career, the habits that make you a great PM, pros and cons of being a platform PM, how Shopify got through Covid: https://www.lennysnewsletter.com/p/brandon-chu-on-what-its-like-to-build• IRC: https://en.wikipedia.org/wiki/IRC• Goodhart's law: https://en.wikipedia.org/wiki/Goodhart%27s_law• Glen Coates on LinkedIn: https://www.linkedin.com/in/glcoates/• How Shopify builds product: https://www.lennysnewsletter.com/p/how-shopify-builds-product• The Last Dance on Netflix: https://www.netflix.com/title/80203144• Autoregressive Models for Natural Language Processing: https://medium.com/@zaiinn440/autoregressive-models-for-natural-language-processing-b95e5f933e1f• Archimedean property: https://en.wikipedia.org/wiki/Archimedean_property• Tabula rasa: https://en.wikipedia.org/wiki/Tabula_rasa• Daniel Weinand on LinkedIn: https://www.linkedin.com/in/danielweinand/• World of Warcraft: https://worldofwarcraft.blizzard.com• Harley Finkelstein on LinkedIn: https://www.linkedin.com/in/harleyf/• Monorepo: https://en.wikipedia.org/wiki/Monorepo• The Sarbanes Oxley Act: https://sarbanes-oxley-act.com/• Shopify builds Shopify Balance with Stripe to give small businesses an easier way to manage money: https://stripe.com/customers/shopify• Stanford marshmallow experiment: https://en.wikipedia.org/wiki/Stanford_marshmallow_experiment• Brian Armstrong on LinkedIn: https://www.linkedin.com/in/barmstrong/• We are the Web: https://link.wired.com/public/32945405—Recommended books:• Finite and Infinite Games: https://www.amazon.com/Finite-Infinite-Games-James-Carse/dp/1476731713• The Infinite Game: https://www.amazon.com/Infinite-Game-Simon-Sinek/dp/073521350X/—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com.—Lenny may be an investor in the companies discussed. Get full access to Lenny's Newsletter at www.lennysnewsletter.com/subscribe

Dans cet épisode de « Dans la Tech », on décrypte le vaste débat qui anime développeurs et équipes DevOps : faut-il opter pour un monorepo ou un multirepo ? Accompagnés de Mathieu et Maxence, on partage nos retours d'expérience, nos anecdotes et nos galères respectives sur la mise en place et la maintenance de ces différentes approches. Au programme : • Les avantages du monorepo : meilleure cohérence, mutualisation des ressources et tooling, mise à jour forcée de tous les services… • Les inconvénients du monorepo : CI/CD plus complexe, lourdeur à l'échelle, discipline exigeante… • Les bénéfices (mais aussi les limites) du multirepo : autonomie des équipes, séparation claire par service, mais difficulté de standardisation… • Des exemples concrets avec Terraform, Node, Go et la gestion des dépendances. • Comment l'organisation interne et la culture d'entreprise influencent le choix monorepo vs multirepo. Que vous soyez développeur, DevOps ou simplement passionné par l'architecture logicielle, cet épisode vous aidera à mieux comprendre les implications et les bonnes pratiques autour du monorepo et du multirepo. Music by Daniel Hourtoulle from Pixabay

Coding with AI changes everything. It changes how we design, test, and improve our software projects. Today, I'm talking to generative AI expert James Phoenix.He's written the book on prompt engineering and shares his hard-earned AI insights freely on the show — including a crash course in developing effectively with the Cursor IDE.Are developers just AI wranglers now? Technical managers? Will we ever code again?You'll find out today.This episode is sponsored by Paddle.com — if you're looking for a payment platform that works for you so you can focus on what matters, check them out.The blog post: https://thebootstrappedfounder.com/james-phoenix-mastering-code-ai-for-the-modern-developer/The podcast episode: https://tbf.fm/episodes/356-james-phoenix-mastering-code-ai-for-the-modern-developerCheck out Podscan to get alerts when you're mentioned on podcasts: https://podscan.fmSend me a voicemail on Podline: https://podline.fm/arvidYou'll find my weekly article on my blog: https://thebootstrappedfounder.comPodcast: https://thebootstrappedfounder.com/podcastNewsletter: https://thebootstrappedfounder.com/newsletterMy book Zero to Sold: https://zerotosold.com/My book The Embedded Entrepreneur: https://embeddedentrepreneur.com/My course Find Your Following: https://findyourfollowing.comHere are a few tools I use. Using my affiliate links will support my work at no additional cost to you.- Notion (which I use to organize, write, coordinate, and archive my podcast + newsletter): https://affiliate.notion.so/465mv1536drx- Riverside.fm (that's what I recorded this episode with): https://riverside.fm/?via=arvid- TweetHunter (for speedy scheduling and writing Tweets): http://tweethunter.io/?via=arvid- HypeFury (for massive Twitter analytics and scheduling): https://hypefury.com/?via=arvid60- AudioPen (for taking voice notes and getting amazing summaries): https://audiopen.ai/?aff=PXErZ- Descript (for word-based video editing, subtitles, and clips): https://www.descript.com/?lmref=3cf39Q- ConvertKit (for email lists, newsletters, even finding sponsors): https://convertkit.com?lmref=bN9CZw

Nx just released version 19.7, join us as we catch up on the latest and greatest of Nx with Isaac Mann and Mike Hartington. We will cover what's new in Nx and learn more about the Nx Experts program. We will get the inside scoop to Monorepo World in Mountain View coming up on October 7th.Learn More about our guests: X: @mannisaac, @mhartingtonhttps://monorepo.world/https://nx.dev/Follow us onX: The Angular Plus Show The Angular Plus Show is a part of ng-conf. ng-conf is a multi-day Angular conference focused on delivering the highest quality training in the Angular JavaScript framework. Developers from across the globe converge on Salt Lake City, UT every year to attend talks and workshops by the Angular team and community experts.Join: http://www.ng-conf.org/Attend: https://ti.to/ng-confFollow: https://twitter.com/ngconf             https://www.linkedin.com/company/ng-conf             https://bsky.app/profile/ng-conf.bsky.social             https://www.facebook.com/ngconfofficialRead: https://medium.com/ngconf Watch: https://www.youtube.com/@ngconfonline Edited by Patrick Hayes https://www.spoonfulofmedia.com/ Stock media provided by JUQBOXMUSIC/ Pond5

Topics covered in this episode: Python is easy now Trying out free-threaded Python on macOS Module itertools overview uptime-kuma Extras Joke Watch on YouTube About the show Sponsored by ScoutAPM: pythonbytes.fm/scout Connect with the hosts Michael: @mkennedy@fosstodon.org Brian: @brianokken@fosstodon.org Show: @pythonbytes@fosstodon.org Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesdays at 10am PT. Older video versions available there too. Finally, if you want an artisanal, hand-crafted digest of every week of the show notes in email form? Add your name and email to our friends of the show list, we'll never share it. Brian #1: Python is easy now or Postmodern Python or Beyond Hypermodern Chris Ardene Mostly a cool review of using rye for setup linting typing testing documentation CI/CD Also a nice discussion of how to deal with a Monorepo for Python projects Michael #2: Trying out free-threaded Python on macOS via pycoders How to install free threaded Python the easy way Testing the CPU bound work speed ups for FT Python Brian #3: Module itertools overview Rodrigo 20 tools that every Python developer should be aware of. In 5 categories Reshaping Filtering Combinatorial Infinite Iterators that complement other tools Things I forgot about chain pairwise zip_longest tee Michael #4: uptime-kuma A fancy self-hosted monitoring tool Features Monitoring uptime for HTTP(s) / TCP / HTTP(s) Keyword / HTTP(s) Json Query / Ping / DNS Record / Push / Steam Game Server / Docker Containers Fancy, Reactive, Fast UI/UX Notifications via Telegram, Discord, Gotify, Slack, Pushover, Email (SMTP), and 90+ notification services, click here for the full list 20-second intervals Multi Languages Multiple status pages Map status pages to specific domains Ping chart Certificate info Proxy support 2FA support Extras Brian: Still working on a new pytest course. Hoping to get it released soon-ish. Michael: Open source Switzerland spyoungtech/FreeSimpleGUI — actively maintained fork of the last release of PySimpleGUI Joke: Java vs. JavaScript

Tworzenie oprogramowania nie sprowadza się jedynie do backendu, natomiast tematyka architektury front-endu do tej pory była w zasadzie zupełnie nieobecna w Better Software Design. Do tej pory, ponieważ dzisiejszy odcinek otwiera nowy rozdział w podkaście i tego rodzaju zagadnienia będą się co jakiś czas pojawiać. A rozmowy na takie właśnie tematy prowadzić będzie najlepszy znami mi architekt front-endu, Tomasz Ducin.Tak, tak, nie jest to przejęzyczenie. Przy dzisiejszym poziomie złożoności technik i narzędzi, po prostu nie można znać się na wszystkim. Dlatego mam dużą satysfakcję z tego, że Tomek będzie gościł w Better Software Design w nowej roli, dostarczając wiedzę z najwyższej front-endowej półki. Pozostaje zacząć nowy etap z przysłowioego "wysokiego C" i bardzo interesującym tematem.Gościem specjalnym dzisiejszego odcinka jest Bartosz Cytrowski, Senior Software Engineer w Atlassianie. Jeśli chcesz się dowiedzieć, jak wygląda architektura makro front-endu w Atlassianie i Jira Cloud, czy jak pracuje się w tak ogromnym i popularnym ekosystemie, to ten odcinek jest właśnie dla Ciebie!W tym odcinku usłyszysz między innymi o:czym jest monorepo, jego zaletach i wadach, a także o tym jak pracuje się z nim w Atlassianie,narzędziach wykorzystywanych do rozwoju systemu o takiej skali jak Jira Cloud,sposobie pracy w systemie, w którym pojawia się ponad 1000 pull-requestów dziennie,kontrolowaniu zależności pomiędzy modułami,stosowaniu feature flags i bezpiecznym wprowadzaniu zmian dotykających wielu zespołów,testowaniu zmian, dog-foodingu i bezpiecznym wdrażaniu nowych wersji.Zapraszam!

Continuous Integration: Ein muss für jedes Software-ProjektDie kontinuierliche Integration, wie z.B. das Herunterladen von Dependencies, das Kompilieren der Applikation sowie das Ausführen von Unit- oder Integrationstests, ist ein “alter Hut” für viele Software Engineers. Doch die wenigsten wissen, was eigentlich wirklich dahintersteckt. Denn es ist viel mehr als “nur” ein paar Tests auszuführen.Woher kommt der Begriff Continuous Integration (CI)? Was sind die Kern-Prinzipien von CI? Wie sieht eine gute CI-Pipeline eigentlich aus? Inwieweit hat sich das Konzept von CI sowie die Tools in den letzten 17 Jahren entwickelt? Was bedeuten die Buzzwords Dev-Pipeline-Parity, Shift-left, CI-Theatre, Dev Done und Done Done eigentlich? Welchen Business-Value liefert CI und warum sollte auch das Management dafür sorgen, dass der Build immer Grün ist? Und wie sieht CI eigentlich außerhalb von Web, Cloud und Mobile aus? Zum Beispiel in Industrien wie Automotive und IoT?All diese Fragen werden von unserem Gast, Michael Lihs, Infrastructure Consultant bei Thoughtworks, beantwortet.Bonus: Deine Strava-Aktivität sagt viel über dein Leben aus.**** Diese Episode wird gesponsert von www.aboutyou.deABOUT YOU gehört zu den größten Online-Fashion Shops in Europa und ist immer auf der Suche nach Tech-Talenten - wie zum Beispiel einem (Lead) DevOps/DataOps Engineer Google Cloud Platform oder einem Lead Platform Engineer. Alle Stellen findest auch unter https://corporate.aboutyou.de/en/our-jobs ****Das schnelle Feedback zur Episode:

We all know about Flask and Django. And of course FastAPI made a huge splash when it came on the scene a few years ago. But new web frameworks are being creating all the time. And they have these earlier frameworks to borrow from as well. On this episode we dive into a new framework gaining a lot of traction called Litestar. Will it be the foundation of your next project? Join me as I get to know Litestar with its maintainers: Jacob Coffee, Janek Nouvertné, and Cody Fincher. Links from the show Guests Jacob Coffee Jacob on Github: github.com Jacob on Twitter: @_scriptr Jacob on Mastodon: @Monorepo Cody Fincher Cody on LinkedIn: linkedin.com Cody on GitHub: github.com Email: cody.fincher@gmail.com Janek Nouvertné Janek on GitHub: github.com Email: j.a.nouvertne@posteo.de Litestar: litestar.dev Litestar Documentation: litestar.dev Litestar on Twitter: @LitestarAPI Litestar on Mastodon: @litestar Litestar Blog: blog.litestar.dev Discord: discord.gg Reddit r/Litestar: eddit.com Litestar on PyPI: pypi.org Benchmarks: docs.litestar.dev v2.0 Release: github.com gunicorn: gunicorn.org msgspec: github.com httpx-sse: github.com duckdb: duckdb.org rich-click: github.com blacksheep server: neoteroi.dev Watch this episode on YouTube: youtube.com Episode transcripts: talkpython.fm --- Stay in touch with us --- Subscribe to us on YouTube: youtube.com Follow Talk Python on Mastodon: talkpython Follow Michael on Mastodon: mkennedy Sponsors Sentry Error Monitoring, Code TALKPYTHON Talk Python Training

inStreamly to narzędzie, które pomaga streamerom przekształcić swoją pasję w zysk oraz wspiera marki w dotarciu do nowych odbiorców. W naszej rozmowie z Damianem, współzałożycielem i CTO tego startupu, przyjrzymy się technicznym aspektom działania tego narzędzia oraz dowiemy się, jak wygląda praktyka czterodniowego tygodnia pracy.

2023年2月に開催された企画「UIT新春Tech blog 2023」の記事について、記事の執筆者である@spring-rainingと@naoto.ikunoが話しました。

In this episode of Syntax, Wes and Scott look through the results of the State of JS survey for 2022. Show Notes State of JS 2022 00:26 Welcome 01:24 Thoughts on the survey in general 04:24 Country of origin 05:53 Salaries 08:14 Higher education 08:58 JavaScript features 15:41 Browser APIs 21:15 Library Usage 26:11 Interest in frontend frameworks 28:40 Framework usage 31:41 Rendering frameworks 34:57 Build tools usage over time 39:37 Monorepo tools Moon 46:41 Backend frameworks Civet 47:42 JavaScript run times 51:01 TypeScript JavaScript balance 52:17 JavaScript flavors 57:03 Resources Fireship Dev Shameless Plugs Scott: LevelUp Tutorials Wes: Wes Bos Tutorials Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Monorepos are contrary to how many of us have been taught to use source control. To start a project or app, the first thing we do is create a git repo for it. This leads to many focused and small repositories. A quick check of my GitHub account shows there are 179 non-fork repositories. That's a lot but I think many of us work that way. But it's not like this with monorepos. There you create one (or a couple) repositories for your entire company. This might have 100s or 1,000s of employees working on multiple projects within the single repo. Famously, Google, Meta, Microsoft, and Airbnb all employ very large monorepos with varying strategies of coordination. On this episode, we have David Vujic here to give us his perspective on monorepos as well as highlight an architectural pattern and set of tools for accomplishing this in Python. Links from the show David on Twitter: @davidvujic David on Mastodon: @davidvujic@mastodon.nu Monorepo definition: wikipedia.org git-sizer tool for large repos: github.com git partial clones: docs.gitlab.com git sparse checkout: git-scm.com Polylith architecture: polylith.gitbook.io Article: A simple & scalable Python project structure: davidvujic.blogspot.com The last Python Architecture you will ever need?: davidvujic.blogspot.com python-polylith plugin for poetry: github.com Watch this episode on YouTube: youtube.com Episode transcripts: talkpython.fm --- Stay in touch with us --- Subscribe to us on YouTube: youtube.com Follow Talk Python on Mastodon: talkpython Follow Michael on Mastodon: mkennedy Sponsors Microsoft Founders Hub 2023 Brilliant 2023 Talk Python Training

Juri joins James and Amy to discuss Monorepos and the benefits of using them on your projects as well as his work at Nrwl.SponsorsRapidAPIRapidAPI, the world's largest API hub, is used by over three million developers to find, test, and connect to thousands of APIs — all with a single API key and dashboard.Find the APIs that you need for your project, embed the API into your app, and track usage of all your APIs through a single dashboard. If you create an API, use RapidAPI to make it available to over three million developers already using the RapidAPI Hub.StoryblockStoryblok is the first headless CMS that offers a unique combination of visual editing tools and highly customizable content blocks for marketers on top of a modern headless architecture that gives developers the flexibility to build fast and reliable digital platforms. Show Notes00:00 Introduction01:24 What is a Monorepo?09:37 How to Manage with Yarn or NX?11:57 Where does the cash live?13:11 Setting up a Workspace15:18 Linking Repos20:35 MPM Links22:22 Sponsor: RapidAPI23:21 Managing PRs with Large Teams27:55 What does Nrwl do?30:29 Juri's Communities34:26 Lerna for MPM Libraries36:02 Sponsor: Storyblock36:47 Juri's Career and Management Roles41:37 Picks and Plugs

Kiedyś tworzyło się monolity, które składały się z wielu projektów. Potem nastąpiła era mikroserwisów, gdzie każdy, posiadał własne repozytorium. A co obecnie jest w modzie?Czy powinniśmy sięgnąć po monorepo, czy jednak po polyrepo? Które podejście bardziej pasuje dla zespołów rozproszonych, pracujących w różnych strefach czasowych?Czy można pracować w strukturze hybrydowej?Jak wyłapać granicę, po przekroczeniu, której warto migrować z jednego podejścia do drugiego?Jak pewnie się spodziewacie, na te pytania odpowiedź brzmi: to zależy. Natomiast naszym celem jest przedstawienie Wam od czego

Back from a short hiatus, Pascal is joined by Jon to talk about the infrastructure that allows commit to sync between Meta's monorepo and GitHub. While ShipIt has been around for a while, allowing commits from the internal repository to sync out to GitHub, Diff Train is its younger brother to allow the inverse. This makes it possible for open-source-first projects like PyTorch to develop on GitHub and bring changes back into the monorepo without sacrificing security and reliability. Got feedback? Send it to us on Twitter (https://twitter.com/metatechpod), Instagram (https://instagram.com/metatechpod) and don't forget to follow our host @passy (https://twitter.com/passy). Fancy working with us? Check out https://www.metacareers.com/. Links: https://github.com/facebook/pyre-check https://github.com/facebookincubator/cinder https://github.com/facebook/hhvm https://github.com/facebook/fbshipit Timestamps: Intro 0:06 Intro Jon 1:49 Open-sourcing an internal project 7:26 Open Source Team @ Meta 10:22 Third-party dependencies 12:07 ShipIt 13:48 Diff Train 29:01 Most excited about 41:07 The GIL 42:29 Outro 44:22

Allen Wyma talks with Eric Arellano (they/them) and Stu Hood (he/him), maintainers of Pants, a build system made for monorepos. Contributing to Rustacean Station Rustacean Station is a community project; get in touch with us if you'd like to suggest an idea for an episode or offer your services as a host or audio editor! Twitter: @rustaceanfm Discord: Rustacean Station Github: @rustacean-station Email: hello@rustacean-station.org Timestamps [@00:10] - Pants' Introduction [@01:26] - Different languages used in building Pants [@03:25] - Pants versions [@06:00] - Pants' history and why it started [@11:09] - What is a Monorepo and why you would want to use it [@13:48] - Polyrepo vs Monorepo [@19:04] - What makes Pants unique [@21:03] - Why Pants needed to rewrite some parts from Python to Rust and other languages [@22:31] - Why Pants chose Rust [@25:46] - Pants 1 vs Pants 2 [@27:12] - Challenges integrating Python and Rust [@29:03] - How Eric and Stu figured out which parts should be written in Python and which should be in Rust [@32:27] - Future plans and what's next for Pants? [@36:15] - Shoutouts and parting thoughts Credits Intro Theme: Aerocity Audio Editing: Plangora Hosting Infrastructure: Jon Gjengset Show Notes: Plangora Hosts: Allen Wyma

主にOSSプロジェクトで活用されているmonorepoバージョニングツール「Changesets」を社内プロジェクトに導入した話について、@potato4dが@spring-rainingに聞いてみました。

Fredrik snackar med Niclas Edenvin, Erik Hedberg, och Adam Sernheim om artikeln " A development process startup founders should use to ship features weirdly fast", en kort artikel med ganska starka åsikter om hur utveckling bör bedrivas i små företag. Vi diskuterar punkterna i … någon sorts ordning och har åsikter om det mesta. Många saker är bra, några förvånar oss, och några känns till och med konstiga. Det blir featureflaggor, monorepon, tester, och mycket mer. Avsnittet sponsras av 46elks som bygger ett enkelt API för SMS och telefoni. Registrera dig på 46elks.se/kodsnack så får du en överraskning och utökade möjligheter att experimentera med deras tjänst. Skicka notiser per SMS, ring upp folk, ordna telefonväxlar, och mycket mer. Hur mycket kod krävs för att skicka ett meddelande? Här är ett Curl-exempel: curl https://api.46elks.com/a1/sms -u API_USERNAME:API_PASSWORD -d to=+46766861004 -d message="Hej kodsnacklyssnare! Testa att skicka ditt första SMS med Curl." -d from=Kodsnack API-dokumentationen hittar du på 46elks.se/docs. Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @oferlund, och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik. Länkar Kodsnack fyller tio - kom och fira med oss! Indio studios Spelsylt #7 Niclas Erik - och tidigare avsnitt med Erik Adam - och tidigare avsnitt A development process startup founders should use to ship features weirdly fast Feature branches Vercel Render Heroku Next.js Monorepon Observerbarhet Git-flow 46elks - veckans sponsor 46elks.se/kodsnack - registrera dig här för att få 200 kronor i krediter Curl Gamasutra - numera tydligen Game developer Postman Featureflaggor A/B-tester Growthflags Unleash - featureflaggor Optimizely Togglz - featureflaggor för Java och Spring Martin Fowler Martin Fowlers artikel om featureflaggor Integrationstester Selenium Loki - visuella regressionstester Titlar Silverkulor hela vägen Det ställer bara till problem, branches Hålla main releasebar En branch som ligger och ruttnar Monorepo mot multirepo Pipelinen som ställer krav Fail fast and furious Demos på uppstuds En stor backlog för hela tåget Ett stort regelverk kring en switch Ja på alla frågorna

Ignace's Website - https://nyamsprod.comIgnace's GitHub - https://github.com/nyamsprodIgnace's Twitter - https://twitter.com/nyamsprodBakame GitHub - https://github.com/bakame-phpSponsor Ignace - https://github.com/sponsors/nyamsprodLeague CSV GitHub - https://github.com/thephpleague/csvLeague CSV - https://csv.thephpleague.com/League URI GitHub - https://github.com/thephpleague/uriLeague URI -  https://uri.thephpleague.com/League Period GitHub - https://github.com/thephpleague/periodLeague Period - https://period.thephpleague.com/Domain Parser GitHub - https://github.com/jeremykendall/php-domain-parserThe PHP League - https://thephpleague.com/Frank de Jonge - https://twitter.com/frankdejongeStorage, with Frank de Jonge - https://laravelpodcast.com/episodes/storage-with-frank-de-jongeJonathan Reinink - https://github.com/reininkEloquent and the Query Builder, with Jonathan Reinink - https://laravelpodcast.com/episodes/eloquent-with-jonathan-reininkBarry vd. Heuvel - https://github.com/barryvdhLaravel Debugbar, with Barry vd. Heuvel - https://laravelpodcast.com/episodes/laravel-debugbar-with-barry-vd-heuvelPHP Manual for fgetcsv - https://www.php.net/manual/en/function.fgetcsv.phpComposer - https://getcomposer.org/PSR-4: Autoloader - https://www.php-fig.org/psr/psr-4/The SplObjectStorage class - https://www.php.net/manual/en/class.splobjectstorage.phpStreams - https://www.php.net/manual/en/book.stream.phpSymfony - https://symfony.com/PHP Releases - https://phpreleases.com/Doctrine - https://www.doctrine-project.org/Doctrine Collections - https://www.doctrine-project.org/projects/doctrine-collections/en/1.6/index.htmlLazy Collections - https://laravel.com/docs/9.x/collections#lazy-collectionsHelpers & Collections, with Jacob Baker-Kretzmar - https://laravelpodcast.com/episodes/helpers-collections-with-jacob-baker-kretzmarSushi - https://github.com/calebporzio/sushiEloquent - https://laravel.com/docs/9.x/eloquentPSR-7: HTTP message interfaces - https://www.php-fig.org/psr/psr-7/WhatWG - https://whatwg.org/parse_url - https://www.php.net/manual/en/function.parse-url.phpCarbon GitHub - https://github.com/briannesbitt/CarbonChronos GitHub - https://github.com/cakephp/chronosJeremy Kendall - https://github.com/jeremykendallPHP Domain Parser - https://github.com/jeremykendall/php-domain-parserCaneco - https://twitter.com/caneco

  Episode 248 Colum is a Senior Software Engineer at Narwhal Technologies. He enjoys speaking about #nx, #angular, #monorepos, #javascript, and #typescript. He's joining us from Northern Ireland.   Links https://columferry.co.uk/ https://github.com/Coly010 https://twitter.com/FerryColum https://colum-ferry.medium.com/ https://www.linkedin.com/in/colum-ferry-3a36a9169/   Resources https://nx.dev/ https://nrwl.io/ https://lerna.js.org/ https://micro-frontends.org/ https://webpack.js.org/concepts/module-federation/ https://blog.nrwl.io/lerna-is-dead-long-live-lerna-61259f97dbd9   "Tempting Time" by Animals As Leaders used with permissions - All Rights Reserved × Subscribe now! Never miss a post, subscribe to The 6 Figure Developer Podcast! Are you interested in being a guest on The 6 Figure Developer Podcast? Click here to check availability!  

We talk to Juri Strumpflohner, Director of Engineering and Dev Experience at Nrwl, about Nx, the future of Nx in 2022, and the importance of monorepos. Links https://nx.dev/ https://twitter.com/nrwl_io https://twitter.com/nxdevtools https://twitter.com/juristr https://www.youtube.com/c/JuriStrumpflohner Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form, (https://podrocket.logrocket.com/get-podrocket-stickers) and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Juri Strumpflohner.

This week we're joined by Daniel Stockman the former maintainer of Lerna.In this episode we talk about he became the sole maintainer of the project, how he dealt with burnout, and thet future of Lerna.

In this episode, we talk to the creator of Turborepo and Vercel Team Lead, Jared Palmer, about why he created Turborepo, the current state of monorepos, how to move from Lerna, and more! Links https://twitter.com/jaredpalmer https://twitter.com/turborepo https://twitter.com/vercel https://turborepo.org https://vercel.com Follow us. Get free stickers. Follow us on Apple Podcasts, fill out this form (https://bit.ly/3wOynRm), and we'll send you free PodRocket stickers! What does LogRocket do? LogRocket combines frontend monitoring, product analytics, and session replay to help software teams deliver the ideal product experience. Try LogRocket for free today. (https://logrocket.com/signup/?pdr) Special Guest: Jared Palmer.

What's up everyone, this is Dariusz Kalbarczyk co-founder of NG Poland, JS Poland, AngularMaster.dev & WorkshopFest.dev. Welcome back to the Angular Master Podcast. Today, together with Manfred Steyer, who is an excellent Speaker, Trainer, Consultant and Author with focus on Angular. We will talk about Micro Frontends and Standalone Components You are doing quite a lot with Micro Frontends. However, there is the rumor that micro frontends are bad for UX and bundle sizes. Why's that? Well said. But if we decide to do so. How to deal with these problems? I have to ask this question. Does it really make sense to use Module Federation in Monorepo? Continuing the tone of the previous question. Are there technical reasons for introducing Module Federation? It is very interesting what you said. Let us go one step further. What are misconceptions you see in the area of Micro Frontends? How does the mental model behind the standalone components work? How to improve your architecture without NgModules? How to prepare for a NgModule-less world and how to migrate existing projects? How to use Standalone Components with existing code and Angular libs What are your wishes for the future of Micro Frontends? --- Send in a voice message: https://podcasters.spotify.com/pod/show/angular-master/message

Please consider supporting Anna Filina's Ukrainian relatives https://afilina.com/donate/ua-supplies Other ways to support the people of Ukraine https://supportukrainenow.org Changelog - This is another pre recorded show as I am traveling over the next few days. - On Mondays Twitch stream we covered lessons 6, 7 and 8 of the PHP login course. I am planning to finish lessons 9 and 10 next Sunday. - On Tuesdays YouTube live stream we started putting up the scaffolding for the PHP registration course.This was quite a fun and productive live stream as I was looking after both dogs whilst planning the PHP architecture. I've decided to do everything in OOP so we are building a mini PHP framework which handles database interactions. I've been playing with a Monorepo What is a Monorepo A single code repository for all projects Users of the repository have access to all the code A single place to commit, merge and track code changes In todays show I will explain why I've stared using a Monorepo and my predictions on the experiment. My web development courses ➡️ Learn How to build a JavaScript Tip Calculator ➡️ Learn JavaScript arrays ➡️ Learn PHP arrays ➡️ Learn Python ✉️ Get my weekly newsletter ⏰ My current live coding schedule (Times are BST) Thursdays 20:00 = Live Podcast YouTube Sundays 14:30 - Live coding on Twitch

Join us this week with Juri Strumpflohner, the head of DX and Europe Engineering at [Nrwl](https://nrwl.io/).Nrwl maintains [NX](https://nx.dev) a next generation build system with first class monorepo support and powerful integrations.Join us as we dive deep into the feature set and learn all about how the make builds lightning fast.

Nu händer det grejer. Vi var nere i Barcelona för några veckor sedan på konferens och tog då tillfället i akt och spelade in vår första livepodd inför publik. Spännande, kul, nervöst och wow så roligt. Här var det som vanligt Andreas och Mattias som var med men även en ny röst. Oscar tog plats i poddstolen och diskuterade med oss kring Microfrontends samt Monorepo och våra erfarenheter kring fenomen. Vi ber om ursäkt i förväg att då och då kan det vara lite dåligt ljud men detta var första gången vi körde live så tills nästa gång blir det bättre. Ha en fin helg! Hosted on Acast. See acast.com/privacy for more information.

In this episode of The Angular Plus Show, we talk with Nrwl CEO Jeff Cross about code organization, monorepos, multi-repos, and how build tools like NX, Lerna, and TurboRepo are shaping the future of app development.

第 7 期：依赖与模块 录制时间： 2021-08-29 嘉宾：盛傲飞 主持：杨文，欧长坤 本期摘要：这是 Go 夜聊的第七期节目，我们和 goproxy.cn 的作者在 Go 1.17 发布时聊了聊在 Go 语言中的依赖管理、模块等相关的机制。Go 语言中的 Modules 走到今天这一步经历了哪些波折？看似在其他语言里早已攻克的代码依赖管理，在 Go 语言的情景下，又有哪些不为人知的努力？ 时间线 00:00 开场白 01:06 接触 Go 语言的契机 02:57 Beego 等一系列 Web 框架的对比 04:37 自己动手写 Web 框架 06:33 Go Modules 之前的依赖管理 16:12 Monorepo 代码管理的优劣 22:24 “臭名昭著” 的 GOPATH 和 vendor 28:36 dep 的风波 37:46 “独裁式” 管理风格下的需求工程 43:52 进入 Go Module 时代 46:47 Go Modules 的基本原理 52:40 godoc 和 pkg.go.dev 54:57 从 golang.org 合并到 go.dev 域名 66:22 Go Modules 的最小版本选择算法 MVS 70:27 环境变量 GOPRIVATE 72:25 模块的懒加载 77:36 模块别名机制 82:10 GOPATH 的废除与 Go 1 兼容性保证 84:43 Go Workspace 工作区 86:17 构建 goproxy.cn 的经历 89:57 搭建代理的难点及其与镜像站的区别 96:42 七牛云接管 goproxy.cn 的运营 相关链接 谢大 astaxie 写的 Beego 知名 Web 框架 Gin 曾经的知名 Web 框架 Martini 知名 Web 框架 Echo 傲飞 aofei 写的 Web 框架 air 标准库 net/http 曾经的依赖管理工具 goven gopkg.in yaml 包 无闻编写的 ini 解析包 曾经的依赖管理工具 gopm 曾经的依赖管理工具 govendor 曾经的依赖管理工具 dep Russ Cox 关于 vgo 依赖管理的演讲 Go Modules 的前身 vgo Go Modules 规范 Russ Cox 和 Rob Pike 开发的 licensecheck 模块功能目前的主要开发者 Bryan C. Mills 傲飞开发的 Go 模块代理站 goproxy.cn 李保坤开发的 Go 模块代理站 goproxy.io 曾经的文包文档站 godoc.org 的源码 Go 语言的多模块工作区 Workspace 的提案 模块别名功能的相关讨论 尾声推荐：jellyfin.org 嘉宾推荐：The Art of Multiprocessor Programming (2nd Edition) 嘉宾推荐：golang.design/go2generics

In this second part episode of Syntax, Wes and Scott continue talking about the 2021 State of JavaScript survey: mobile and desktop libraries, testing, monorepo, runtimes, flavors of JavaScript, and more! Sentry - Sponsor If you want to know what's happening with your code, track errors and monitor performance with Sentry. Sentry's Application Monitoring platform helps developers see performance issues, fix errors faster, and optimize their code health. Cut your time on error resolution from hours to minutes. It works with any language and integrates with dozens of other services. Syntax listeners new to Sentry can get two months for free by visiting Sentry.io and using the coupon code TASTYTREAT during sign up. Sanity - Sponsor Sanity.io is a real-time headless CMS with a fully customizable Content Studio built in React. Get a Sanity powered site up and running in minutes at sanity.io/create. Get an awesome supercharged free developer plan on sanity.io/syntax. Freshbooks - Sponsor Get a 30 day free trial of Freshbooks at freshbooks.com/syntax Show Notes 00:10 Welcome 01:20 Scott's new sound panels 03:32 Instacart 2021 State of JS Survey Tauri 07:46 Mobile and Desktop libraries 13:50 Testing Vitest Playwright Cypress 19:48 Sponsor: Sentry 21:26 Monorepo tooling 27:00 Sponsor: Sanity.io 28:18 JavaScript Runtimes 30:51 JavaScript Flavors 32:32 Non JavaScript Languages 39:38 Utilities Syntax 401: Monorepo pnpm Turborepo 40:19 Resources Syntax.fm 403: JavaScript in 2022 - New, Coming and Proposed Features 43:18 Opinions 47:21 Features missing from JavaScript 49:30 Awards 52:58 Sponsor: Freshbooks 53:38 SIIIIICK ××× PIIIICKS 56:41 Shameless Plugs ××× SIIIIICK ××× PIIIICKS ××× Scott: StoryPal Wes: Heartbeat Hot Sauce Matty Matheson on Hot Ones Gordon Ramsay on Hot Ones Shameless Plugs Scott: LevelUp Tutorials Wes: Wes Bos Tutorials Tweet us your tasty treats Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

Nx is here to make your life easier. In this episode, Paige and TJ talk with Jack Hsu, a developer whose Nrwl and Nx expertise is blowing us away with how streamlined things can be. “It's nice for everyone to see what's going on, not just the core developers.” - Jack Hsu In This Episode 1) What beginners NEED to know to get started with Nx this year 2) Why you'll LOVE using a Monorepo in 2022 to maintain your sanity 3) The BIG 2022 trends around Next.js, Nx, and Nrwl you ought to know Sponsors Top End Devs (https://topenddevs.com/) Raygun | Click here to get started on your free 14-day trial (https://raygun.com/?utm_medium=podcast&utm_source=reactroundup&utm_campaign=devchat&utm_content=homepage) Coaching | Top End Devs (https://topenddevs.com/coaching) Links Painlessly Build and Deploy Next.js Apps With Nx | by Jack Hsu | Nrwl (https://blog.nrwl.io/painlessly-build-and-deploy-next-js-apps-with-nx-225e2721da78) Jack Hsu (https://medium.com/@jay_soo) Github: Jack Hsu ( aysoo ) (https://github.com/jaysoo) Picks Jack- IdeaVim Paige- Watch Snowpiercer | Netflix Official Site (https://www.netflix.com/in/title/80177458) TJ- YouTube TV (https://tv.youtube.com/welcome/?utm_servlet=prod) Special Guest: Jack Hsu.

Dziś dyskutujemy o tym, które rozwiązanie architektoniczne, monorepo czy polyrepo, lepiej sprawdza się w projektach. Czy też może – do jakiego rodzaju projektu pasuje które z nich?

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Ruby 3.1.1 Released Ruby 3.1 adds error highlighting gem Introducing Propshaft Delayed Job vs. Sidekiq: Which Is Better? Jmespath.rb - a Ruby implementation of JMESPath AnyCasts, Ep. 2: Of users and direct messaging (pt. 1) How to add Search in Rails using Meilisearch Web The State of JS 2021 Results 4 Ways to Handle Async Operations in Javascript Future Javascript: Records and Tuples RTK Query Best Practices Track down the JavaScript code responsible for polluting the global scope The second argument in JSON.stringify() Monorepo.tools - everything you need to know about monorepos, and the tools to build them Minze - dead-simple framework for shareable web components SwiftLaTeX - a WYSIWYG Browser-based LaTeX Editor RWpod Cafe 29 (05.03.2022) Сбор и голосование за темы новостей

In this Hasty Treat, Scott and Wes talk about PNPM and monorepos! Freshbooks - Sponsor Get a 30 day free trial of Freshbooks at freshbooks.com/syntax and put SYNTAX in the “How did you hear about us?” section. LogRocket - Sponsor LogRocket lets you replay what users do on your site, helping you reproduce bugs and fix issues faster. It's an exception tracker, a session re-player and a performance monitor. Get 14 days free at logrocket.com/syntax. Show Notes 4:40 - What is pnpm? https://pnpm.io/ Performant npm https://www.youtube.com/watch?v=hiTmX2dW84E Find and remove node modules find . -name "node_modules" -type d -prune -exec rm -rf '{}' + 08:30 - Why monorepo? Internal packages all in one place Forks and custom packages easier Commands that control everything at once 10:33 - Workspaces Not exclusive to pnpm Yarn, npm, pnpm all have them now Different syntax packages: - "packages/**" 12:48 - How it works in practice All commands run through root Use in host, hook up my monorepo to render run commands Filter and recursive "install:all": "pnpm recursive install", "clean": "pnpm recursive exec -- rm -rf node_modules; rm shrinkwrap.yaml; rm -rf node_modules", "ui:dev": "pnpm recursive run dev --filter @leveluptuts/ui", 16:35 - Using submodules https://paigeniedringhaus.substack.com/p/march-2021-git-submodules Why submodules? Public and private Links https://www.npmjs.com/package/npx https://yarnpkg.com/ Tweet us your tasty treats! Scott's Instagram LevelUpTutorials Instagram Wes' Instagram Wes' Twitter Wes' Facebook Scott's Twitter Make sure to include @SyntaxFM in your tweets

In a version control system, a Monorepo is a version control management strategy in which all your code is contained in one potentially large but complete repository.  The monorepo is in stark contrast to an alternative approach in which software teams independently manage microservices or deliver software as libraries to be imported in other projects.  The post Git Scales for Monorepos with Derrick Stolee appeared first on Software Engineering Daily.

In a version control system, a Monorepo is a version control management strategy in which all your code is contained in one potentially large but complete repository.  The monorepo is in stark contrast to an alternative approach in which software teams independently manage microservices or deliver software as libraries to be imported in other projects.  The post Git Scales for Monorepos with Derrick Stolee appeared first on Software Engineering Daily.

In a version control system, a Monorepo is a version control management strategy in which all your code is contained in one potentially large but complete repository.  The monorepo is in stark contrast to an alternative approach in which software teams independently manage microservices or deliver software as libraries to be imported in other projects.  The post Git Scales for Monorepos with Derrick Stolee appeared first on Software Engineering Daily.

In a version control system, a Monorepo is a version control management strategy in which all your code is contained in one potentially large but complete repository.  The monorepo is in stark contrast to an alternative approach in which software teams independently manage microservices or deliver software as libraries to be imported in other projects. 

Episode 7 of the Console DevTools Podcast, a devtools discussion with David Mytton (Co-founder, Console) and Jean Yang (CEO, Akita Software).Tools discussed:Sourcegraph - code search engine.Hoppscotch - test UI for API requests.Find more interesting tools and beta releases for developers at https://console.devOther things mentioned:Github.Dropbox.Monorepo.PageRank.Github Copilot.Postman.Console EP2 - GitHub CopilotConsole EP6 - Philosophy of open sourceLet us know what you think on Twitter:https://twitter.com/jeanqasaurhttps://twitter.com/davidmyttonhttps://twitter.com/consoledotdevOr by email: hello@console.devWe are always on the lookout for interesting tools to feature in the newsletter, so please say hello if you're working on something new or have recently used a tool you think we'd like.We only include things that would be of interest to experienced developers and do not accept payment for product inclusion. Read our selection criteria.Recorded: 2021-08-10.

In this episode, Gerhard talks to his Skyhook Adventure friends: Alan Cooney, Saul Cullen & Wycliffe Maina. They are the ones that introduced Gerhard to the world of serverless in the context of Amazon Web Services. Gerhard shared his experience with remote work, how to ship software with confidence and consistency, and what to look for in infrastructure as code. At the heart of Skyhook Adventure are adventure trips, and 2020 was not a good one for this business. As you can already tell, code and infrastructure was not the biggest challenge for this team. Having said that, serverless, microservices, a monorepo and the event-based architecture played a big part in successfully navigating the challenges. This is a story about what happens when a good team allows itself to be guided by solid experience and keeps doing the right thing, long-term. It's fun, real, and it applies to many.

In this episode, Gerhard talks to his Skyhook Adventure friends: Alan Cooney, Saul Cullen & Wycliffe Maina. They are the ones that introduced Gerhard to the world of serverless in the context of Amazon Web Services. Gerhard shared his experience with remote work, how to ship software with confidence and consistency, and what to look for in infrastructure as code. At the heart of Skyhook Adventure are adventure trips, and 2020 was not a good one for this business. As you can already tell, code and infrastructure was not the biggest challenge for this team. Having said that, serverless, microservices, a monorepo and the event-based architecture played a big part in successfully navigating the challenges. This is a story about what happens when a good team allows itself to be guided by solid experience and keeps doing the right thing, long-term. It's fun, real, and it applies to many.

François est connu pour son franc-parler ! C'est un expert sur beaucoup de sujets autour du Build. On peut parler avec lui de SRE, de DevOps, de Basel, de makefile, de Gradle. Son parcours est intéressant ! Il a fait des choix de carrière très précis, pour faire en sorte que son expertise soit la plus valorisée en particulier financièrement.

Accelerate Nx lernayarn workspaces bazelrush

This episode of Semaphore Uncut features Jonathan Creamer, Senior Software Engineer at Microsoft. We hear his monorepo experiences and about his work in the field of 'DivOps' - the term he coined to describe the engineering of front-end tooling.Key takeaways:DivOps is DevOps for the front-endMonorepo's power is having all dependencies at your fingertipsMake and test sweeping changes across the whole monorepo in secondsEmbrace monorepo early to keep options openMonorepo tooling enables micro-frontend architecturesWorkspaces and Webpack module federation are ones to watch in futureAbout Semaphore UncutIn each episode of Semaphore Uncut, we invite software industry professionals to discuss the impact they are making and what excites them about the emerging technologies.

Welcome! This is the very first episode of the devtools.fm podcast

In this episode, Donn talks with Glenn Leifheit from Microsoft about a concept known as "Secure Development Lifecycle". Glenn is a Senior Security Program Manager at Microsoft.Glenn explains to you what the secure development lifecycle is, how it works and how you can implement something like this in your company. He also shares the top tips you can implement in order to get the quickest benefit of the Secure Development LifecycleLinks from the showApplication Inspector:  GitHubDevSkim:  GitHubAttack Surface Analyzer:  GitHubOSS Gadget:  GitHubRecursive Extractor:  GitHubMicrosoft SDL: Microsoft Security Development LifecycleCodeQL: CodeQL for research | GitHub Security LabOWASP:  OWASP Foundation | Open Source Foundation for Application SecurityOWASP Top 10: OWASP Top Ten Web Application Security Risks | OWASPOWASP Web Security Testing Guide: OWASP Web Security Testing GuidePython basic code analysis:  Pylint - code analysis for Python | www.pylint.orgTypeScript basic code analysis: GitHub - typescript-eslint/typescript-eslint: Monorepo for all the tooling which enables ESLint to support TypeScriptFind Glenn online hereGlenn's LinkedInGlenn's TwitterDonn's Free E-Book on FreelancingFree E-Book on Freelancing RatesContact@fragmentedcast or our Youtube channel@donnfelker and donnfelker (on Instagram)Freelancing for Mobile Developers (Donn's YouTube)kaushikgopal (on YouTube) or blog.kaush.co or @kaushikgopalDisclaimer: Many of the links we share to products are affiliate links. They help support the production of Fragmented. Thank you for your support.

In this episode of Semaphore Uncut, I talk to Benjy Weinberger, co-founder of Toolchain. We discuss the open-source build tool, 'Pants', and hear Benjy's views on the monorepo strategy for managing your codebase.Key takeaways:Pants: a fast, scalable build systemExplicit modelling of dependencies is key to Pants performanceMonorepo gives visibility and ownership of the effects of your changesMonorepo helps avoid dependency hellHow Pants works: a concrete exampleTools to make adopting Pants easyHow to contribute to Pants V2About Semaphore UncutIn each episode of Semaphore Uncut, we invite software industry professionals to discuss the impact they are making and what excites them about the emerging technologies.

We talked about our transition to a monorepo back in episode 305. This move has all sorts of advantages for us, like the simplicity of having a single repo to pull and be up to date with and linting/formatting code in a consistent way across the entire code base of CodePen. This time we’ll get […]

KONUKGürkan Oluç - https://twitter.com/grknKONUŞULANLAR- Yazılımcı pozisyonları- Twitter'da SRE neler yapar?- SRE DB bilgisi ve kod yazma yetenekleri- Kullanılan programlama dilleri- Organizasyon yapısı ve çalışma şekilleri- Ruby on Rails'i bırakma ve Scala'ya geçiş- Frontend teknolojileri- Yazılım takımları- Twitter'in mimari yapısı- Yazılım testleri ve code review sureçleri- Monorepo'yu yönetmek- Pandemi dönemi ve uzaktan çalışma- Yurtdışında yaşamak ve Twitter'da çalışmak- Büyük firmalar ile iş görüşmeleri yapmak-----Üretim Bandı'nın Slack grubu olduğunu biliyor muydunuz? 900'e yakın ürün yöneticisi, girişimci, yazılımcı, tasarımcının bir arada bulunduğu aktif ürün topluluğuna siz de katılın:>>> uretimbandi.com/slackİki haftada bir yayınladığımız, ürün geliştirmeyle alakalı bültenimizi de aşağıdaki linkten takip edebilirsiniz:>>> uretimbandi.com/bulten

Alex and Chris talk about the glory that is having all of CodePen’s code base in a single repository. This was a slow journey of a couple of years. The biggest step was what jokingly named “CodePen in Stereo” which involved consolidating everything Node-based on CodePen (mostly a bunch of lambdas) into a single repo, […]

Can a monorepo be beneficial for development teams? Find out the answers to this and other questions as we interview Narwhal cofounder, Victor Savkin! The post Episode 56: Don't Fear the Monorepo appeared first on TalkScript.FM.

In a software project writing code is just one step of the overall lifecycle. There are many repetitive steps such as linting, running tests, and packaging that need to be run for each project that you maintain. In order to reduce the overhead of these repeat tasks, and to simplify the process of integrating code across multiple systems the use of monorepos has been growing in popularity. The Pants build tool is purpose built for addressing all of the drudgery and for working with monorepos of all sizes. In this episode core maintainers Eric Arellano and Stu Hood explain how the Pants project works, the benefits of automatic dependency inference, and how you can start using it in your own projects today. They also share useful tips for how to organize your projects, and how the plugin oriented architecture adds flexibility for you to customize Pants to your specific needs.

Monorepo, polyrepo. Quando si parla di tecniche per la gestione della codebase spesso ci si trova nel bel mezzo di una guerra. Ho voluto raccontarla smorzando un pochino i toni basandomi sulla storia dei tre porcellini...Disclaimer: Questo episodio è da intendersi sperimentale, quindi non va preso troppo sul serio... Ricordati di iscriverti al gruppo telegram:https://t.me/gitbar## Links- https://twitter.com/mattklein123/status/1080524011438653441- https://link.medium.com/01E2ObyIV9- https://yarnpkg.com/lang/en/docs/workspaces/- https://github.com/Quramy/lerna-yarn-workspaces-example- https://docs.bazel.build/versions/master/bazel-and-javascript.html- https://link.medium.com/rLXl0tj8V9- https://github.com/zenclabs/bazel-javascript- https://github.com/joelparkerhenderson/monorepo_vs_polyrepo## Contatti@brainrepo su twitter o via mail a info@gitbar.it.## CreditiLe sigle sono state prodotte da MondoComputazionaleLe musiche da Blan Kytt - RSPN e Broke For Free - Something Elated

Nishiura Kazukiさん（@daisy1754）をゲストに迎え、ペイメントテクノロジーや急成長したスタートアップでの開発の話などを伺いました。前編となる今回は、Google Pay、ベイエリアでのスタートアップの探し方、急拡大した企業の成長痛、ペイメントサービス、モノリポ移行について話しました。 ゲストのNishiura Kazukiさん: https://twitter.com/daisy1754 2つのGoogle Payと2つのGoogle Walletの話: https://note.com/daisy1754/n/nc0c9f885d9ed AngelList(スタートアップの採用) https://angel.co *AListはcloseした模様 https://www.bolt.com Bolt https://www2.fast.co/ Fast.co(Boltの競合) Migrating to a Monorepo: https://www.bolt.com/blog/migrating-to-monorepo/ roopakv/swissknife: https://circleci.com/orbs/registry/orb/roopakv/swissknife BFG Repo-cleaner: https://rtyley.github.io/bfg-repo-cleaner/ Your co-hosts: Tomoaki Imai, Chomp CTO — 外食体験を記録、シェアできるソーシャルアプリChompを開発してます https://chomp.app/ https://twitter.com/tomoaki_imai Yusuke Kawanabe, Software Engineer https://twitter.com/ykawanabe

Welcome to episode four of the Cloudify Tech Talk podcast where we drill down in all things repo (Monorepo). This session features Cloudify CTO Nati Shalom, Cloudify Head of R&D Alex Molev and special guest Dor Atias - VP Engineering at Cycode. For any supporting materials, visit cloudify.co/podcast. 

Neste episódio vamos falar sobre uma forma "nova" de lidar com versionamento de código, a ideia de colocar todo código fonte em apenas UM repositório. Será que é uma boa ideia? Como isso funciona? Feed do podcast: www.lambda3.com.br/feed/podcast Feed do podcast somente com episódios técnicos: www.lambda3.com.br/feed/podcast-tecnico Feed do podcast somente com episódios não técnicos: www.lambda3.com.br/feed/podcast-nao-tecnico Lambda3 · #206 - Monorepo Pauta: O que é? Pra que serve? Não é monolito Diferenças de Angular Workspace Vantagens: Setup de ambiente local (clone único) Dependências compartilhadas Gestão de dependências Todos usando a última versão Alterações mais seguras (respostas mais rápidas ao quebrar) Encoraja colaboração entre times PR entre múltiplos apps/libs Desvantagens: Repos muito grande Necessidade de ferramental e ferramentas para lidar com tamanho Links Citados: Nx Bazel Por que o Google armazena bilhões de linhas de código em um único repositório Awesome Monorepo Lerna Equívocos sobre Monorepos Participantes: Giovanni Bassi - @giovannibassi Lucas Teles - @lucasteles42 William Grasel - @willgmbr Américo Neto - @americoneto1 Edição: Compasso Coolab Créditos das músicas usadas neste programa: Music by Kevin MacLeod (incompetech.com) licensed under Creative Commons: By Attribution 3.0 - creativecommons.org/licenses/by/3.0

The Angular Show panelists (Aaron Frost, Brian Love, Alisa Nicoll, and Shai Reznik) chat with the co-founders of Narwhal Jeff Cross and Victor Savkin about Nx and Nx Cloud. But first, we check in with Jeff, who you may not know, has and cuddles with pigs, and Victor, who is a new father.Nx Cloud is a way for you to enable distributed computation cache such that you, your team, and your Continuous Integration (CI) can share build artifacts. Practically speaking, this results in saving you and your organization time when building and testing your application.You might be wondering, what exactly is computation cache? Victor breaks this down for us and shares how Nx tackles this, and further, how we can use Nx cloud to distribute the computation cache across a team, including CI.To get started, you'll need to be using Nx, which not only tackles computation cache, but is a tool for implementing a monorepo strategy. Then, set up Nx Cloud with an access token in your config for distributing the cache.

Why Google Stores Billions of lines of code in a single repository - this is a brief summary of a research paper published by google.

Czwarty odcinek dev.js - JavaScript Podcast poświęcony tematyce monorepo, którego gościem jest Paweł Kalinowski. Podcast poprowadził lider dev.js - Paweł Niewęgłowski. Sponsorem odcinka jest firma SoftServe (www.softserveinc.com).

Alex Okrushko talks about maintaining NgRx in a large monorepo, just like he does at Google. Other discussions include push based services, some RxJS, and advanced typing in TypeScript.

Da wir aus unterschiedlichen Gründen angefangen haben, uns auch ein bisschen mit Javascript-Frontends auseinanderzusetzen, sprechen wir heute mal ganz allgemein über dieses Thema. Und wie man dann von da aus mit - üblicherweise in Python implementierten - Backends spricht. Shownotes Unsere E-Mail für Fragen, Anregungen & Kommentare: hallo@python-podcast.de Lost & Found PyData Deep Dive Meta-Podcast Audio Hard/Software Headsets von Beyerdynamic: DT 297 DT 797 Superlux HMC 660 X und wie man es verwendet HMC 660 X über Klinke anschliessen Audiointerface, das nativ 12v Phantomspeisung kann: Zoom H6 Ultraschall REAPER Studio Link / Beta Zencastr Videokonferenzsoftware Zoom Microsoft Teams Selbsthosting möglich: Jitsi BigBlueButton Pythoncamp Google Meet Whereby FaceTime News aus der Szene A Language Creators' Conversation: Guido van Rossum, James Gosling, Larry Wall & Anders Hejlsberg Django 1.11 EOL Pytest troubles Pyenv windows Javascript Frontends Vielleicht der Ort, um eine Lerngruppe zu organisieren: Vue-JS-Cologne vue react angular jQuery History API REST / GraphQL Relay / Apollo / axios ASGI Single page application redux DRF serializer Monorepo Jacob Kaplan-Moss - Assets in Django without losing your hair - PyCon 2019 WhiteNoise django-storages webpack Parcel FastAPI / Starlette Öffentliches Tag auf konektom

This episode is the quickest of the quackest.  Hear about smashing lego trucks from a young Haupenthal, get a pretty high-level overview of an awesome library called Graphql-Codgen and how I use it in a monorepo with Typescript projects, and get a silly opinion on the Yarn 2 meltdowns. Graphql Codgen: https://github.com/dotansimha/graphql-code-generator Yarn 2: https://dev.to/arcanis/introducing-yarn-2-4eh1 Great article on Yarn 2 vs 1 vs NPM from the folks at Infinite Red: https://shift.infinite.red/yarn-1-vs-yarn-2-vs-npm-a69ccf0229cd Great video on Yarn 2 from Ben Awad: https://youtu.be/bPae4Z8BFt8 Cowboy by The Rumble Strips: https://youtu.be/wmIVu622zRM

Ein wahrer Parforce Ritt an Folge. Wir wandern von Holgers Vortrag, über Scala 3, über starke Typisierung im Frontend irgendwie zu Monorepos und Microfrontends. Ohne das vorher geplant zu haben. Was kann schon schief gehen. Wenigstens reicht es noch für den Heise-Kommentar der Woche. Viel Spaß!

In this episode of Elixir Mix the panel discusses monorepos. They start by defining monorepos and sharing examples of what this looks like. The panelists share the pros and cons of working in a monorepo. They discuss the different projects they worked on using a monorepo and what their experience was like.    Monorepos allow for rapid development.  Any developer can pull it down and work on it. They work better for teams who are new with a new project and they are still trying to figure out where everything goes. In situations like these, quality is not a large concern but once quality is a priority monorepos make less sense.    On the other hand, monorepos make it easier for developers to forget that these applications are distinct. It also makes it easy for developers to ignore older versions of applications. The panel considers if monorepos are worth these downsides. The panel considers how monorepos work with Live View. They also discuss using an umbrella project similarly to monorepos.  Panelists Mark Ericksen Eric Oestrich Josh Adams Michael Ries Sponsors Sentry– use the code “devchat” for two months free on Sentry’s small plan CacheFly Links https://en.wikipedia.org/wiki/Monorepo  https://jenkins-x.io/  https://www.facebook.com/Elixir-Mix  https://twitter.com/elixir_mix Picks Mark Ericksen: https://thinkingelixir.com/vs-code-broken-for-elixir/  Real-Time In-Camera VFX for Next-Gen Filmmaking | Project Spotlight | Unreal Engine  Eric Oestrich: grapevine  Josh Adams: https://github.com/mijailr/askimet_ex  Michael Ries: https://empex.co/la.html

In this episode of Elixir Mix the panel discusses monorepos. They start by defining monorepos and sharing examples of what this looks like. The panelists share the pros and cons of working in a monorepo. They discuss the different projects they worked on using a monorepo and what their experience was like.    Monorepos allow for rapid development.  Any developer can pull it down and work on it. They work better for teams who are new with a new project and they are still trying to figure out where everything goes. In situations like these, quality is not a large concern but once quality is a priority monorepos make less sense.    On the other hand, monorepos make it easier for developers to forget that these applications are distinct. It also makes it easy for developers to ignore older versions of applications. The panel considers if monorepos are worth these downsides. The panel considers how monorepos work with Live View. They also discuss using an umbrella project similarly to monorepos.  Panelists Mark Ericksen Eric Oestrich Josh Adams Michael Ries Sponsors Sentry– use the code “devchat” for two months free on Sentry’s small plan CacheFly Links https://en.wikipedia.org/wiki/Monorepo  https://jenkins-x.io/  https://www.facebook.com/Elixir-Mix  https://twitter.com/elixir_mix Picks Mark Ericksen: https://thinkingelixir.com/vs-code-broken-for-elixir/  Real-Time In-Camera VFX for Next-Gen Filmmaking | Project Spotlight | Unreal Engine  Eric Oestrich: grapevine  Josh Adams: https://github.com/mijailr/askimet_ex  Michael Ries: https://empex.co/la.html

On this week's episode, Steph catches us up on her ever-growing collection of mechanical keyboards, Chris talks about his recent purchase of an apple watch, and they follow up a previous discussion around case-sensitivity (or insensitivity) in URLs and email addresses. They round out the discussion with a chat about writing blog posts and some postgres fun, and finally discuss the merits and drawbacks of monorepos.This episode of The Bike Shed is sponsored by Honeybadger.MechanicalKeyboards.comFrozen LLama Ducky KeyboardApple WatchWithings WatchPostgres Citext (Case-Insensitive text field type)Chris's blog post on Sharing Query Logic Within ActiveRecord ModelsMatt Sumner's Post on DeadlinesOn Writing by Stephen KingThe War of ArtMonorepos: Please don't!Monorepo: please do!Lerna - toll for monorepo management in javascriptIf you're enjoying The Bike Shed, we'd love it if you could give it a rating or review on iTunes. Thanks!

Jeffrey Cross and Victor Savkin are the cofounders of NRWL. They used to work together at Google on the Angular team and started NRWL so that people could use Angular 2 well. Victor talks about NRWL’s tool NX, which came from the desire to help people develop like the tech giants. Companies like Google and Facebook develop in the same repository so that people can collaborate. NX is an open source tool for this collaborative development, known as a monorepo.  Monorepo style development is a way to develop applications such that you develop multiple projects in the same repository and you use tooling to orchestrate development. The tooling connects everything, makes the experience coherent, and ultimately makes the monorepo style work. The benefits of monorepo development are that the tool chain enables you to interact with different projects in the same fashion, collaboration is more effective, and multiple apps can be refactored at once.  The panel discusses what situations are appropriate for a monorepo and which are not. Victor believes that any company with more than one large product would benefit from a monorepo, but it would not benefit a company that wants to keep their teams distinct from one another. The hosts express some concerns about implementation, such as scaling and creating the infrastructure. Victor assures them that a monorepo is inherently scalable, and most tools will work for years and years. As for the infrastructure, companies like NRWL specialize in helping companies set up monorepos, and NX provides many of the necessary tools for a monorepo. A monorepo can be tailor-made to fit any size of company, and can even be created for already established projects.  If you wanted to start your own monorepo, you can start by taking a project or handful of projects and moving them to the same place. As you develop, pull pieces of your applications out and put them into packages. Victor cautions that monorepos tend towards a single version policy, so you’ll want to get on the same version as your third party dependencies before you move your next application in. You can move things in and temporarily have different versions, but plan to make them the same version eventually. Victor talks about how the CI in a monorepo setup looks different, because you run tests against everything that might be broken by that change, not just the project its in. So, when you change something in your code, you need to consider what other pieces of code need to be taken into account. A monorepo does make dependencies more explicit, and when you have good tooling it’s easier to see the effect the changes you make have. This is where NX excels. One of the big advantages of NX is that it allows you to partition your application into packages with a well defined API, and prevents the project from becoming one giant node. You can then interact with those packages, and see what happens when you change something. You have a lot more clarity of how your app is partitioned and what the restraints are. NX allows you to share stuff between the front and backend.  The show concludes with the conversation turning to Jeffrey and Victor’s consulting work. They talk about some of the interesting features that are happening outside of React that we are missing out on. Victor is very impressed with tooling in the Angular community. He talks about a tool called Console for NX. They end by talking about the schematic powered migrations in Angular.  Panelists Leslie Cohn-Wein Dave Ceddia Lucas Reis With special guest: Jeffrey Cross and Victor Savkin Sponsors Sustain Our Software Sentry use the code “devchat” for 2 months free on Sentry’s small plan My JavaScript Story Links NRWL Angular NX Building Fullstack React Applications in Monorepo Angular CLI Follow DevChatTV on Facebook and Twitter Picks Lucas Reis: Dear Startup Cryptocurrencies video by 1Blue1Brown Dave Ceddia: Help, I’ve Fallen (into code) and I Can’t Get Up! Code maps frontend Victor Savkin: Ember Mug Heal the Internet Jeffrey Cross:  lululemon Commission pant Leslie Cohn-Wein Why I’m No Longer Talking to White People Everylayout.dev

Jeffrey Cross and Victor Savkin are the cofounders of NRWL. They used to work together at Google on the Angular team and started NRWL so that people could use Angular 2 well. Victor talks about NRWL’s tool NX, which came from the desire to help people develop like the tech giants. Companies like Google and Facebook develop in the same repository so that people can collaborate. NX is an open source tool for this collaborative development, known as a monorepo.  Monorepo style development is a way to develop applications such that you develop multiple projects in the same repository and you use tooling to orchestrate development. The tooling connects everything, makes the experience coherent, and ultimately makes the monorepo style work. The benefits of monorepo development are that the tool chain enables you to interact with different projects in the same fashion, collaboration is more effective, and multiple apps can be refactored at once.  The panel discusses what situations are appropriate for a monorepo and which are not. Victor believes that any company with more than one large product would benefit from a monorepo, but it would not benefit a company that wants to keep their teams distinct from one another. The hosts express some concerns about implementation, such as scaling and creating the infrastructure. Victor assures them that a monorepo is inherently scalable, and most tools will work for years and years. As for the infrastructure, companies like NRWL specialize in helping companies set up monorepos, and NX provides many of the necessary tools for a monorepo. A monorepo can be tailor-made to fit any size of company, and can even be created for already established projects.  If you wanted to start your own monorepo, you can start by taking a project or handful of projects and moving them to the same place. As you develop, pull pieces of your applications out and put them into packages. Victor cautions that monorepos tend towards a single version policy, so you’ll want to get on the same version as your third party dependencies before you move your next application in. You can move things in and temporarily have different versions, but plan to make them the same version eventually. Victor talks about how the CI in a monorepo setup looks different, because you run tests against everything that might be broken by that change, not just the project its in. So, when you change something in your code, you need to consider what other pieces of code need to be taken into account. A monorepo does make dependencies more explicit, and when you have good tooling it’s easier to see the effect the changes you make have. This is where NX excels. One of the big advantages of NX is that it allows you to partition your application into packages with a well defined API, and prevents the project from becoming one giant node. You can then interact with those packages, and see what happens when you change something. You have a lot more clarity of how your app is partitioned and what the restraints are. NX allows you to share stuff between the front and backend.  The show concludes with the conversation turning to Jeffrey and Victor’s consulting work. They talk about some of the interesting features that are happening outside of React that we are missing out on. Victor is very impressed with tooling in the Angular community. He talks about a tool called Console for NX. They end by talking about the schematic powered migrations in Angular.  Panelists Leslie Cohn-Wein Dave Ceddia Lucas Reis With special guest: Jeffrey Cross and Victor Savkin Sponsors Sustain Our Software Sentry use the code “devchat” for 2 months free on Sentry’s small plan My JavaScript Story Links NRWL Angular NX Building Fullstack React Applications in Monorepo Angular CLI Follow DevChatTV on Facebook and Twitter Picks Lucas Reis: Dear Startup Cryptocurrencies video by 1Blue1Brown Dave Ceddia: Help, I’ve Fallen (into code) and I Can’t Get Up! Code maps frontend Victor Savkin: Ember Mug Heal the Internet Jeffrey Cross:  lululemon Commission pant Leslie Cohn-Wein Why I’m No Longer Talking to White People Everylayout.dev

Episode Summary   Victor Savkin, former angular team member and now cofounder of Narwhal Technologies Inc or Nrwl, returns to Adventures in Angular to teach the panel about monorepos. Victor starts by explaining what monorepos are and why you might need one. Monorepo style development is when multiple projects developed in the same repository and the tools used to manage code between those apps.    There are many benefits to using monorepos as Victor explains to the panel, such as sharing code between apps. Monorepos help you see what's going on in reality as well as helps you take control of the structure of your code. It also allows for more interesting deployment strategies. Victor talks briefly about his time at Google, working on the toolchain and using a large monorepo.   After the panel asks about the costs of using a monorepo strategy, Victor explains that there are many perceived costs that are actually false or easily overcome. The first perceived cost he tells the panel about is how people get confused and believe that apps have to be deployed together when they really have to be developed in the same repository. The second is the fear of misplaced ownership, that some other developer will come along and ruin their code. Victor explains that ownership can be configured and controlled so that no one you don’t trust can touch your code.    The next myth developers believe about monorepos is that it doesn’t scale and especially when it comes to performance. Victor explains that when the app is set up correctly and testing used correctly this isn’t a problem. The final perceived cost is that Git will break. Victor debunks this by explaining that you would have to be doing extremely well in order for Git to be a bottleneck and even then there are ways around that problem.    Victor explains the one real cost and that is you have to change the way you code. The panel discusses a few different coding styles. Victor recommends getting used to single version policy and trunk-based development. He defines trunk-based development, explaining how it works and why it is better for monorepos than long-range branch development.    Victor sees two types of groups who want to get started in monorepos and he explains what they most commonly do wrong. The first is greenfield projects who jump right in without thinking about it and eventually crash. The second is teams with a giant app and through a monorepo in hoping it will help them structure their app. He explains there is a right way to start using monorepos in both situations.   Asking the important question is how to get started. Agreeing upon the structure, naming, ownership, are you going to build the frontend and backend in the same repo, and the answers to a bunch of other questions will affect your work the most, even more than the tooling you use. Some of these answers will be specific to your company where others will be universal, like naming and ownership.    With other tools for monorepo out there, the panel asks Victor why Nrwl decided to build their own tool. Victor explains that the current tools on the market do not do it all. Lerna only does one thing great and Bazel is very selective on who can run it. Nrwl is hoping to marry Bazel to Nx, so they can allow everyone to use Bazel. They want Nx to support all tools and even Windows.    The panel wonders if Nx is perfect. Victor explains that it nearly there. Nx is pluggable and easy to use. It is easy to learn. Victor explains that they really care about developer experience at Nrwl. Nx is free and opensource so everyone can give monorepos a try.    Resources for learning about monorepos are discussed. Victor invites everyone to watch the ten-minute getting started video on the Nx website. He also lets the listeners know about a new book coming out mid-September and it will be more organizational based than the last. The panel wants to know what comes with Nx. Victor explains that Nx gives you modern tools by setting up Cypress, Jest and other tools for you.   Because Nrwl is a consulting firm, the panel hopes that Victor will have an update on the trends. Victor shares his view that trends don’t really tell you anything about the true status of a framework. How many downloads a framework has doesn’t show the longevity of that framework. Frameworks being used to make large scale apps that will be around for years is how you can tell the longevity of a framework. From that perspective, Victor feels that Angular is doing really well.    To end the episode, Shai Reznik recalls how passionate Victor was about NgRx a few years ago. He asks Victor if he still feels the same way as before. Victor explains that NgRx is pretty well most of the time, has great docs, is well maintained, and he would still recommend it. Panelists Jennifer Wadella Brian Love Shai Reznik Alyssa Nicoll Guest Victor Savkin Sponsors   Sentry use the code “devchat” for 2 months free on Sentry small plan Angular Bootcamp My JavaScript Story Cachefly Links https://twitter.com/victorsavkin?lang=en Nrwl Nx — An open source toolkit for enterprise Angular applications. Effective React Development with Nx https://connect.nrwl.io/app/books https://nx.dev/angular/getting-started/what-is-nx MAS 040: Victor Savkin 042 AiA Dependency Injection and Change Detection with Victor Savkin 123 AiA Upgrading from Angular 1 to Angular 2 with Victor Savkin https://nrwl.io/ https://nx.dev/ Momentum  https://www.facebook.com/adventuresinangular https://twitter.com/angularpodcast Picks Brain Love: https://trunkbaseddevelopment.com/ https://www.oreilly.com/library/view/why-angular-for/9781492030294/  Alyssa Nicoll: Caffeine Content Warning! Jennnifer Wadella: The Fall Season NGD Conf Laptop Safety at Conferences Victor Savkin: The Boys Use Less Social Media Freedom App Shai Reznik: https://bit.dev/  True Detective  

Episode Summary   Victor Savkin, former angular team member and now cofounder of Narwhal Technologies Inc or Nrwl, returns to Adventures in Angular to teach the panel about monorepos. Victor starts by explaining what monorepos are and why you might need one. Monorepo style development is when multiple projects developed in the same repository and the tools used to manage code between those apps.    There are many benefits to using monorepos as Victor explains to the panel, such as sharing code between apps. Monorepos help you see what's going on in reality as well as helps you take control of the structure of your code. It also allows for more interesting deployment strategies. Victor talks briefly about his time at Google, working on the toolchain and using a large monorepo.   After the panel asks about the costs of using a monorepo strategy, Victor explains that there are many perceived costs that are actually false or easily overcome. The first perceived cost he tells the panel about is how people get confused and believe that apps have to be deployed together when they really have to be developed in the same repository. The second is the fear of misplaced ownership, that some other developer will come along and ruin their code. Victor explains that ownership can be configured and controlled so that no one you don’t trust can touch your code.    The next myth developers believe about monorepos is that it doesn’t scale and especially when it comes to performance. Victor explains that when the app is set up correctly and testing used correctly this isn’t a problem. The final perceived cost is that Git will break. Victor debunks this by explaining that you would have to be doing extremely well in order for Git to be a bottleneck and even then there are ways around that problem.    Victor explains the one real cost and that is you have to change the way you code. The panel discusses a few different coding styles. Victor recommends getting used to single version policy and trunk-based development. He defines trunk-based development, explaining how it works and why it is better for monorepos than long-range branch development.    Victor sees two types of groups who want to get started in monorepos and he explains what they most commonly do wrong. The first is greenfield projects who jump right in without thinking about it and eventually crash. The second is teams with a giant app and through a monorepo in hoping it will help them structure their app. He explains there is a right way to start using monorepos in both situations.   Asking the important question is how to get started. Agreeing upon the structure, naming, ownership, are you going to build the frontend and backend in the same repo, and the answers to a bunch of other questions will affect your work the most, even more than the tooling you use. Some of these answers will be specific to your company where others will be universal, like naming and ownership.    With other tools for monorepo out there, the panel asks Victor why Nrwl decided to build their own tool. Victor explains that the current tools on the market do not do it all. Lerna only does one thing great and Bazel is very selective on who can run it. Nrwl is hoping to marry Bazel to Nx, so they can allow everyone to use Bazel. They want Nx to support all tools and even Windows.    The panel wonders if Nx is perfect. Victor explains that it nearly there. Nx is pluggable and easy to use. It is easy to learn. Victor explains that they really care about developer experience at Nrwl. Nx is free and opensource so everyone can give monorepos a try.    Resources for learning about monorepos are discussed. Victor invites everyone to watch the ten-minute getting started video on the Nx website. He also lets the listeners know about a new book coming out mid-September and it will be more organizational based than the last. The panel wants to know what comes with Nx. Victor explains that Nx gives you modern tools by setting up Cypress, Jest and other tools for you.   Because Nrwl is a consulting firm, the panel hopes that Victor will have an update on the trends. Victor shares his view that trends don’t really tell you anything about the true status of a framework. How many downloads a framework has doesn’t show the longevity of that framework. Frameworks being used to make large scale apps that will be around for years is how you can tell the longevity of a framework. From that perspective, Victor feels that Angular is doing really well.    To end the episode, Shai Reznik recalls how passionate Victor was about NgRx a few years ago. He asks Victor if he still feels the same way as before. Victor explains that NgRx is pretty well most of the time, has great docs, is well maintained, and he would still recommend it. Panelists Jennifer Wadella Brian Love Shai Reznik Alyssa Nicoll Guest Victor Savkin Sponsors   Sentry use the code “devchat” for 2 months free on Sentry small plan Angular Bootcamp My JavaScript Story Cachefly Links https://twitter.com/victorsavkin?lang=en Nrwl Nx — An open source toolkit for enterprise Angular applications. Effective React Development with Nx https://connect.nrwl.io/app/books https://nx.dev/angular/getting-started/what-is-nx MAS 040: Victor Savkin 042 AiA Dependency Injection and Change Detection with Victor Savkin 123 AiA Upgrading from Angular 1 to Angular 2 with Victor Savkin https://nrwl.io/ https://nx.dev/ Momentum  https://www.facebook.com/adventuresinangular https://twitter.com/angularpodcast Picks Brain Love: https://trunkbaseddevelopment.com/ https://www.oreilly.com/library/view/why-angular-for/9781492030294/  Alyssa Nicoll: Caffeine Content Warning! Jennnifer Wadella: The Fall Season NGD Conf Laptop Safety at Conferences Victor Savkin: The Boys Use Less Social Media Freedom App Shai Reznik: https://bit.dev/  True Detective  

Episode Summary   Victor Savkin, former angular team member and now cofounder of Narwhal Technologies Inc or Nrwl, returns to Adventures in Angular to teach the panel about monorepos. Victor starts by explaining what monorepos are and why you might need one. Monorepo style development is when multiple projects developed in the same repository and the tools used to manage code between those apps.    There are many benefits to using monorepos as Victor explains to the panel, such as sharing code between apps. Monorepos help you see what's going on in reality as well as helps you take control of the structure of your code. It also allows for more interesting deployment strategies. Victor talks briefly about his time at Google, working on the toolchain and using a large monorepo.   After the panel asks about the costs of using a monorepo strategy, Victor explains that there are many perceived costs that are actually false or easily overcome. The first perceived cost he tells the panel about is how people get confused and believe that apps have to be deployed together when they really have to be developed in the same repository. The second is the fear of misplaced ownership, that some other developer will come along and ruin their code. Victor explains that ownership can be configured and controlled so that no one you don’t trust can touch your code.    The next myth developers believe about monorepos is that it doesn’t scale and especially when it comes to performance. Victor explains that when the app is set up correctly and testing used correctly this isn’t a problem. The final perceived cost is that Git will break. Victor debunks this by explaining that you would have to be doing extremely well in order for Git to be a bottleneck and even then there are ways around that problem.    Victor explains the one real cost and that is you have to change the way you code. The panel discusses a few different coding styles. Victor recommends getting used to single version policy and trunk-based development. He defines trunk-based development, explaining how it works and why it is better for monorepos than long-range branch development.    Victor sees two types of groups who want to get started in monorepos and he explains what they most commonly do wrong. The first is greenfield projects who jump right in without thinking about it and eventually crash. The second is teams with a giant app and through a monorepo in hoping it will help them structure their app. He explains there is a right way to start using monorepos in both situations.   Asking the important question is how to get started. Agreeing upon the structure, naming, ownership, are you going to build the frontend and backend in the same repo, and the answers to a bunch of other questions will affect your work the most, even more than the tooling you use. Some of these answers will be specific to your company where others will be universal, like naming and ownership.    With other tools for monorepo out there, the panel asks Victor why Nrwl decided to build their own tool. Victor explains that the current tools on the market do not do it all. Lerna only does one thing great and Bazel is very selective on who can run it. Nrwl is hoping to marry Bazel to Nx, so they can allow everyone to use Bazel. They want Nx to support all tools and even Windows.    The panel wonders if Nx is perfect. Victor explains that it nearly there. Nx is pluggable and easy to use. It is easy to learn. Victor explains that they really care about developer experience at Nrwl. Nx is free and opensource so everyone can give monorepos a try.    Resources for learning about monorepos are discussed. Victor invites everyone to watch the ten-minute getting started video on the Nx website. He also lets the listeners know about a new book coming out mid-September and it will be more organizational based than the last. The panel wants to know what comes with Nx. Victor explains that Nx gives you modern tools by setting up Cypress, Jest and other tools for you.   Because Nrwl is a consulting firm, the panel hopes that Victor will have an update on the trends. Victor shares his view that trends don’t really tell you anything about the true status of a framework. How many downloads a framework has doesn’t show the longevity of that framework. Frameworks being used to make large scale apps that will be around for years is how you can tell the longevity of a framework. From that perspective, Victor feels that Angular is doing really well.    To end the episode, Shai Reznik recalls how passionate Victor was about NgRx a few years ago. He asks Victor if he still feels the same way as before. Victor explains that NgRx is pretty well most of the time, has great docs, is well maintained, and he would still recommend it. Panelists Jennifer Wadella Brian Love Shai Reznik Alyssa Nicoll Guest Victor Savkin Sponsors   Sentry use the code “devchat” for 2 months free on Sentry small plan Angular Bootcamp My JavaScript Story Cachefly Links https://twitter.com/victorsavkin?lang=en Nrwl Nx — An open source toolkit for enterprise Angular applications. Effective React Development with Nx https://connect.nrwl.io/app/books https://nx.dev/angular/getting-started/what-is-nx MAS 040: Victor Savkin 042 AiA Dependency Injection and Change Detection with Victor Savkin 123 AiA Upgrading from Angular 1 to Angular 2 with Victor Savkin https://nrwl.io/ https://nx.dev/ Momentum  https://www.facebook.com/adventuresinangular https://twitter.com/angularpodcast Picks Brain Love: https://trunkbaseddevelopment.com/ https://www.oreilly.com/library/view/why-angular-for/9781492030294/  Alyssa Nicoll: Caffeine Content Warning! Jennnifer Wadella: The Fall Season NGD Conf Laptop Safety at Conferences Victor Savkin: The Boys Use Less Social Media Freedom App Shai Reznik: https://bit.dev/  True Detective  

Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan CacheFly Host: Charles Max Wood Joined By Special Guest: Anatoliy Zaslavskiy Episode Summary Anatoliy Zaslavskiy has been interested in computers since he was 7 years old, and began his programming career in high school, doing web development in PHP for the online community for his favorite show  Avatar: The Last Airbender. Anatoliy currently works for Hover as a Frontend developer transforming home photos into 3D models to help visualize what the final project will look like. Anatoliy shares his journey as a developer with bipolar disorder and tells us how he restructured his career with his employer so he can focus on projects that he enjoys working on. This way he performs at his best and both him and Hover can benefit from his talents. Anatoliy and Charles stress the importance for companies to talk to their developers to understand their nature as both parties benefit from open and honest dialogue. Links JavaScript Jabber 358: Pickle.js, Tooling, and Developer Happiness with Anatoliy Zaslavskiy Anatoliy's Website Anatoliy's Facebook Anatoliy's LinkedIn https://www.facebook.com/javascriptjabber https://twitter.com/JSJabber https://www.facebook.com/DevChattv Picks Anatoliy Zaslavskiy: XState - JavaScript State Machines and Statecharts Nozbe/WatermelonDB: High-performance reactive database Monorepo Charles Max Wood: https://www.twitch.tv/ OBS: Open Broadcaster Software

Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan CacheFly Host: Charles Max Wood Joined By Special Guest: Anatoliy Zaslavskiy Episode Summary Anatoliy Zaslavskiy has been interested in computers since he was 7 years old, and began his programming career in high school, doing web development in PHP for the online community for his favorite show  Avatar: The Last Airbender. Anatoliy currently works for Hover as a Frontend developer transforming home photos into 3D models to help visualize what the final project will look like. Anatoliy shares his journey as a developer with bipolar disorder and tells us how he restructured his career with his employer so he can focus on projects that he enjoys working on. This way he performs at his best and both him and Hover can benefit from his talents. Anatoliy and Charles stress the importance for companies to talk to their developers to understand their nature as both parties benefit from open and honest dialogue. Links JavaScript Jabber 358: Pickle.js, Tooling, and Developer Happiness with Anatoliy Zaslavskiy Anatoliy's Website Anatoliy's Facebook Anatoliy's LinkedIn https://www.facebook.com/javascriptjabber https://twitter.com/JSJabber https://www.facebook.com/DevChattv Picks Anatoliy Zaslavskiy: XState - JavaScript State Machines and Statecharts Nozbe/WatermelonDB: High-performance reactive database Monorepo Charles Max Wood: https://www.twitch.tv/ OBS: Open Broadcaster Software

Sponsors Sentry use the code “devchat” for 2 months free on Sentry small plan CacheFly Host: Charles Max Wood Joined By Special Guest: Anatoliy Zaslavskiy Episode Summary Anatoliy Zaslavskiy has been interested in computers since he was 7 years old, and began his programming career in high school, doing web development in PHP for the online community for his favorite show  Avatar: The Last Airbender. Anatoliy currently works for Hover as a Frontend developer transforming home photos into 3D models to help visualize what the final project will look like. Anatoliy shares his journey as a developer with bipolar disorder and tells us how he restructured his career with his employer so he can focus on projects that he enjoys working on. This way he performs at his best and both him and Hover can benefit from his talents. Anatoliy and Charles stress the importance for companies to talk to their developers to understand their nature as both parties benefit from open and honest dialogue. Links JavaScript Jabber 358: Pickle.js, Tooling, and Developer Happiness with Anatoliy Zaslavskiy Anatoliy's Website Anatoliy's Facebook Anatoliy's LinkedIn https://www.facebook.com/javascriptjabber https://twitter.com/JSJabber https://www.facebook.com/DevChattv Picks Anatoliy Zaslavskiy: XState - JavaScript State Machines and Statecharts Nozbe/WatermelonDB: High-performance reactive database Monorepo Charles Max Wood: https://www.twitch.tv/ OBS: Open Broadcaster Software

Adam and Jerod talk with two members of Segment’s engineering team: Co-founder and CTO, Calvin French-Owen, as well as Software Engineer, Alex Noonan, about their journey from monorepo to microservices back to monorepo. 100s of problem children to 1 superstar child.

Adam and Jerod talk with two members of Segment’s engineering team: Co-founder and CTO, Calvin French-Owen, as well as Software Engineer, Alex Noonan, about their journey from monorepo to microservices back to monorepo. 100s of problem children to 1 superstar child.

Panel: Charles Max Wood Nader Dabit Lucas Reis Special Guests: Luis Vieira In this episode, the React Round Up panelists talk to Luis Vieira about his “Building large scale react applications in a monorepo”. Luis works in Portugal at a company called FarFetch as a front-end architect where he works mostly on JavaScript and infrastructure. They talk about the rationale behind his article, shared components, and what Lerna is and what is does. They also touch on Semantic Versioning, the difference between monolithic application and a monorepo, and more! In particular, we dive pretty deep on: Luis intro Front-end architect at FarFetch Works with JavaScript Rationale behind his article Dividing a project in multiple packages Sharing components between multiple applications Editing shared components Working in a monorepo Simplifies managing between different projects Requires more tooling What is Lerna? If you put multiple packages in one repo, how do you deal with things like the Git history getting mixed up? Versioning How does Semantic Versioning interplay with monorepos? What if you’re not using Semantic Versioning? Using the conventional commit How is the state of CI tooling regarded? He is currently more focused on React What he is experimenting with currently Building monolithic apps Monolithic aps VS monorepo Bazel Nrwl Nx And much, much more! Links: “Building large scale react applications in a monorepo” FarFetch JavaScript Lerna Semantic Versioning React Bazel Nrwl Nx Luis’s Medium @luisvieira_gmr Luis’s Newsletter Sponsors Kendo UI Digital Ocean Get a Coder Job Picks: Charles Take some time off Take a step back to reevaluate Nader Free workshop with Tyler McGinnis to come soon. Keep an eye out at Nader’s Twitter or Tyler’s Newsletter React Native EU Lucas Sketch.systems Luis Vue CLI

Panel: Charles Max Wood Nader Dabit Lucas Reis Special Guests: Luis Vieira In this episode, the React Round Up panelists talk to Luis Vieira about his “Building large scale react applications in a monorepo”. Luis works in Portugal at a company called FarFetch as a front-end architect where he works mostly on JavaScript and infrastructure. They talk about the rationale behind his article, shared components, and what Lerna is and what is does. They also touch on Semantic Versioning, the difference between monolithic application and a monorepo, and more! In particular, we dive pretty deep on: Luis intro Front-end architect at FarFetch Works with JavaScript Rationale behind his article Dividing a project in multiple packages Sharing components between multiple applications Editing shared components Working in a monorepo Simplifies managing between different projects Requires more tooling What is Lerna? If you put multiple packages in one repo, how do you deal with things like the Git history getting mixed up? Versioning How does Semantic Versioning interplay with monorepos? What if you’re not using Semantic Versioning? Using the conventional commit How is the state of CI tooling regarded? He is currently more focused on React What he is experimenting with currently Building monolithic apps Monolithic aps VS monorepo Bazel Nrwl Nx And much, much more! Links: “Building large scale react applications in a monorepo” FarFetch JavaScript Lerna Semantic Versioning React Bazel Nrwl Nx Luis’s Medium @luisvieira_gmr Luis’s Newsletter Sponsors Kendo UI Digital Ocean Get a Coder Job Picks: Charles Take some time off Take a step back to reevaluate Nader Free workshop with Tyler McGinnis to come soon. Keep an eye out at Nader’s Twitter or Tyler’s Newsletter React Native EU Lucas Sketch.systems Luis Vue CLI

AiA 152: Multirepo vs Monorepo with Jeff Whelpley and Kushal Dave On today's episode of Adventures in Angular, we have panelists Ward Bell, Joe Eames and Charles Max Wood. We have special guests, Jeff Whelpley and Kushal Dave. The discussion ranges from the organization of code bases to the benefits of using Monorepo vs Multirepo. Tune in! [00:01:45] – Introduction to Jeff Whelpley and Kushal Dave Kushal is CTO at Scroll, a start-up. Before that, he was at Foursquare, Chartbeat, Google, and IBM. He has worked in a lot of monorepo code base. Although he actually has experience working on a lot of Multirepo situations. Jeff is the CTO of a small startup in Boston called GetHuman that helps people with customer service problems. He has been on Adventures in Angular a couple of times before. He has also been in a couple of other podcasts before, as well as in the open-source community. [00:03:20] – Introduction to the issue Typically, when you’re working in just one or two people team, you don’t really have that many issues centered on dev process, coordinating changes between each other, and trying to figure out the best optimal way to organize your code. Most of the time, you understand the entire code base because you’re working with everything. It gets to be a much different problem once you get to have a larger team. In essence, everything is starting slow down because of different overhead related to the process that was needed in order to make sure got quality changes. You basically have to spend a lot of time and thought around your developer process, how you structure your code, how you physically setup, and organize your entire code base. [00:06:20] – How to organize your code bases? When Kushal worked at Google, everything is in a single giant repository. There are one or two exceptions for client code and some infrastructure things. It allowed people to feel that they could change any of the code and it made it easy to keep everybody in sync with the state of the code. There is some sort of workflow and process things that you have to change in order to get that right. Probably, the biggest one is trying to keep the repo from working in long running branches because things start to diverge. That was the model of Foursquare too. [00:08:15] – How do you run all of the CI across everything? The answer changes to different sizes. At Scroll and for most of the time that Kushal was at Foursquare, it was efficient to run all the builds on every commit. If you just have one mega build that just runs continuously, that’s good enough up until 30 or 40 developers. Once you hit that size, there’s a variety of build tools out there that you can use and understand the structure of your code base. Once you’ve used one of these build tools, declaratively indicate which artifacts depends on which libraries, and what the full dependency thing is, you can build only the relevant CI’s. You can decide whether this change only touches this binary or this test. Chuck also like the approach of having everything in master. If it was experimental, it would still go into master and their CI would effectively run the different builds with the different feature flags. If what you did broke something that somebody else was working on in a process, you could just adjust it midstream. [00:16:00] – Gatekeeper process The gatekeeper process protects the whole code base but at the same time, it’s in the layer of bureaucracy. We’ve been reviewing every piece of code before it’s allowed to land in master. Everybody on our team commits multiple times a day to master. All the changes, as much as possible are really small, especially the feature flag check. In that world, there is this bureaucracy. Hopefully, it’s not holding you up too much. The flipside of that is when you’ll feel really confident that you didn’t break anybody who depends on you and you’re going to have to revisit this change a month from now. For the past 9 months or so, Jeff tried a bunch of different configurations. He tried monorepo and other configurations from the other end of the spectrum - many small packages. As he was interviewing people with their different setups, they’ve all encountered the same types of problems. Regardless if you’re using monorepo or not, as long as you’re trying to keep your changes small and specific, and implemented quickly, it can alleviate any other pains. [00:22:10] – Guard rails The guard rails are just the reviewers. For us, every change that’s getting reviewed means that in some extent, there’s a human check on that. I’m not sure if you can but I certainly know that Reviewable and Fabricate both offer sort of wide range of configuration options. I can imagine the world in which you can programmatically keep people from landing changes that didn’t have that level. In Github, there are guard rails. That actually helps the reviewers. It’s reassuring to have some technology that this person is associated with this set of boundaries. If you want to step outside of the boundaries, they’re going to have to get some other person who understands the code that’s outside of the line to join in approving that. If their organization is big, this is something that they might have to think about. Jeff advises to really be careful about what you’re doing. Is this a change where you are just bumping version numbers or is this something that you have to change a business logic? [00:28:15] – Allowing different people to upgrade dependencies The only way Kushal has ever seen it done is a brutal all-nighter by somebody who has to sit there and get everything working. But one of the things that Google does is they develop a lot of patterns about how to refactor code to make things easier. One solution that Jeff sees is the complete opposite of the spectrum from monorepo. Dr. Gleb Bahmutov is a huge fan of open-source smaller repos - a lot of the mentality of keeping things small, separate and distinct. He’s decided that he’s going to stick in the many repo universe and just create tooling to solve some of these problems. For versioning, he runs this server that detects that a new version has been published. It will automatically try to update it and run all the tests. But according to Kushal, if you have different repos, you can move differently in terms of dependencies but if you’re now out of sync, you may suddenly have incompatible dependencies across what you’re doing. It’s a question of when you want to deal with the problem. Chuck talks about the ways you can get out of sync. With the multirepo, you can get out of sync not just on the dependencies and the build process, but also on the API’s. If you have a module that you’re working on over here and whatever are consuming it on the other side as a driver may not be updated yet so it doesn’t talk properly. Jeff also noticed that with Angular DI, if you aren’t actually using the same version, you run into issues because it has to be the exact same thing at every level or else the injection token is different. [00:36:50] – Develop within Monorepo or develop in a separate repo Chuck thinks that it depends. If there are a lot of dependencies and shortcuts that he can take by relying on the monorepo, he will do it on the monorepo like if it auto loads the correct libraries automatically. And then, they don’t have to do a whole lot of setup. If it’s small, independent, and it’s going to move quickly, then, a separate repo may be the right answer. Kushal adds that there are a lot of benefits in doing it in the monorepo. With feature flags, you have the benefit of reviewing it. It also allows you and others to keep up with everyone in terms of breaking API changes, other than having some brutal merge. Jeff will do it in a separate repo. If this an experimental thing, it disturbs people less. It alleviates the notifications that go on. That is why Kushal’s team also built a lot of custom Slack cooks in order to get some notifications tailored to the parts that they only care about. [00:44:50] – How do you work it out so that things aren’t so tightly coupled? There are no circular dependencies between your packages even transitively. As your monorepo grows you may eventually have some tooling that requires that for your build system. Can this layer have this type of functionality? Or does it need to be moved into a new package? It also means it improves your architecture. Kushal’s team is working on Java. This object that users and organizations create can know about each other’s’ objects but the users can never depend back into organizations or vice versa. You can think of the layered model of networking. We have the pure data model objects are not allowed to know anything about the service layer that interacts with the database. The database can know about those model objects. The web tier can obviously know about both the model objects and the service tier because it utilizes both of those. [00:47:30] – How are those relationships defined? They are defined in build files. If you look at Pants or Blaze or Buck, all those build systems have explicit dependency configurations so you can sort of keeping any of those invariants from being broken.  But Kushal’s team just have a Wiki page that lists out the rules. They also have a test that looks for any cycles in any package dependencies. Jeff’s team created a CLI tool that walks down all subdirectories from where they’re running it. It finds all the package JSON in all your subdirectories and it creates the dependency graphs. They haven’t fully moved to a monorepo but they did start to consolidate. They have a couple of larger repos. This tool will see the dependency graph for all the NPM modules and also see the dependencies between the repos based off of the NPM module dependencies. [00:50:20] – Multimonorepo It’s not perfect to have one larger repo that has basically all of the none-deployable codes. Jeff and his team have a separate set of repos for the actual deployable code. They haven’t made the jump to where Kushal is advocating – using build tools. [00:50:20] – To open-source When you want an open-source portion of what you’re doing but not the entire company’s code base, Jeff thinks that there’s really no way out of having a separate repo for that. Google has this giant internal repo because not everything in it is open-source. Angular is open-source. That’s at least one driver that Angular is in the public Github repo and Google use so much of Angular. And some companies want the sort of open collaboration and free support and upgrades from the community. Other companies see that they’re giving away some kind of competitive advantage that they’re not willing to give up. [00:55:40] – Monorepo is better in all cases Jeff recognizes that there’s a number of organizations that have successfully implemented it but there isn’t an easy way for someone to do it. It’s not common knowledge and does not have a well-known set of tooling and best practices. There’s still a lot to go to get to the point where it’s a no-brainer and everybody knows how to do this the right way. Ward doesn’t know how to do a monorepo but according to him, if he is in an organization or starting an organization, he would go figure out how to do it and would want his organization to have a monorepo. Chuck tends to lean to monorepo but doesn't always do it either. Another caveat is even if he starts with the monorepo, that doesn’t mean that’s where he’s going to end. The answer is if you put them all in separate repos and it turns out that you need benefits of having them all in the same place, you can move them all in one repo. It may not be easy depending on how big and complicated you make your mono or the way you tie together your disparate repos. Kushal is all in. The only time that he wouldn’t do it is if he’s building disparate open-source projects and wanted them to play the open-source ecosystem. The net benefit is that everyone is moving together rapidly because monorepo is optimized for speed. But Kushal wishes that the tooling is better and that many people move to this model. Joe is also open to monorepo in a larger organization. He thinks that the separate repos keep things but monorepo can solve a lot of problems. [01:01:55] – Places to go Jeff has a bunch of articles for people who are pro-monorepo and are advocating for that. He has yet to find one that sets forth like a good mental model or decision framework. This is what Jeff hopes to create in the next couple of weeks before the conference. Picks Ward Bell Hiking Fishing Southern Sierras Chuck Max Wood Book: Profit First by Mike Michalowicz Ketogenic Diet Air-conditioning Joe Eames Book: Everybody Lies: Big Data, New Data, and What the Internet Can Tell Us About Who We Really Are by Seth Stephens-Davidowitz Rent a scooter to ride around Rome Jeff Whelpley Survey: Monorepo vs Multirepo Twitter: @jeffwhelpley Medium: @jeffwhelpey Kushal Dave Technical Design Reviews Book: The Orphan Master’s Son Twitter: @krave Medium: Workflow

AiA 152: Multirepo vs Monorepo with Jeff Whelpley and Kushal Dave On today's episode of Adventures in Angular, we have panelists Ward Bell, Joe Eames and Charles Max Wood. We have special guests, Jeff Whelpley and Kushal Dave. The discussion ranges from the organization of code bases to the benefits of using Monorepo vs Multirepo. Tune in! [00:01:45] – Introduction to Jeff Whelpley and Kushal Dave Kushal is CTO at Scroll, a start-up. Before that, he was at Foursquare, Chartbeat, Google, and IBM. He has worked in a lot of monorepo code base. Although he actually has experience working on a lot of Multirepo situations. Jeff is the CTO of a small startup in Boston called GetHuman that helps people with customer service problems. He has been on Adventures in Angular a couple of times before. He has also been in a couple of other podcasts before, as well as in the open-source community. [00:03:20] – Introduction to the issue Typically, when you’re working in just one or two people team, you don’t really have that many issues centered on dev process, coordinating changes between each other, and trying to figure out the best optimal way to organize your code. Most of the time, you understand the entire code base because you’re working with everything. It gets to be a much different problem once you get to have a larger team. In essence, everything is starting slow down because of different overhead related to the process that was needed in order to make sure got quality changes. You basically have to spend a lot of time and thought around your developer process, how you structure your code, how you physically setup, and organize your entire code base. [00:06:20] – How to organize your code bases? When Kushal worked at Google, everything is in a single giant repository. There are one or two exceptions for client code and some infrastructure things. It allowed people to feel that they could change any of the code and it made it easy to keep everybody in sync with the state of the code. There is some sort of workflow and process things that you have to change in order to get that right. Probably, the biggest one is trying to keep the repo from working in long running branches because things start to diverge. That was the model of Foursquare too. [00:08:15] – How do you run all of the CI across everything? The answer changes to different sizes. At Scroll and for most of the time that Kushal was at Foursquare, it was efficient to run all the builds on every commit. If you just have one mega build that just runs continuously, that’s good enough up until 30 or 40 developers. Once you hit that size, there’s a variety of build tools out there that you can use and understand the structure of your code base. Once you’ve used one of these build tools, declaratively indicate which artifacts depends on which libraries, and what the full dependency thing is, you can build only the relevant CI’s. You can decide whether this change only touches this binary or this test. Chuck also like the approach of having everything in master. If it was experimental, it would still go into master and their CI would effectively run the different builds with the different feature flags. If what you did broke something that somebody else was working on in a process, you could just adjust it midstream. [00:16:00] – Gatekeeper process The gatekeeper process protects the whole code base but at the same time, it’s in the layer of bureaucracy. We’ve been reviewing every piece of code before it’s allowed to land in master. Everybody on our team commits multiple times a day to master. All the changes, as much as possible are really small, especially the feature flag check. In that world, there is this bureaucracy. Hopefully, it’s not holding you up too much. The flipside of that is when you’ll feel really confident that you didn’t break anybody who depends on you and you’re going to have to revisit this change a month from now. For the past 9 months or so, Jeff tried a bunch of different configurations. He tried monorepo and other configurations from the other end of the spectrum - many small packages. As he was interviewing people with their different setups, they’ve all encountered the same types of problems. Regardless if you’re using monorepo or not, as long as you’re trying to keep your changes small and specific, and implemented quickly, it can alleviate any other pains. [00:22:10] – Guard rails The guard rails are just the reviewers. For us, every change that’s getting reviewed means that in some extent, there’s a human check on that. I’m not sure if you can but I certainly know that Reviewable and Fabricate both offer sort of wide range of configuration options. I can imagine the world in which you can programmatically keep people from landing changes that didn’t have that level. In Github, there are guard rails. That actually helps the reviewers. It’s reassuring to have some technology that this person is associated with this set of boundaries. If you want to step outside of the boundaries, they’re going to have to get some other person who understands the code that’s outside of the line to join in approving that. If their organization is big, this is something that they might have to think about. Jeff advises to really be careful about what you’re doing. Is this a change where you are just bumping version numbers or is this something that you have to change a business logic? [00:28:15] – Allowing different people to upgrade dependencies The only way Kushal has ever seen it done is a brutal all-nighter by somebody who has to sit there and get everything working. But one of the things that Google does is they develop a lot of patterns about how to refactor code to make things easier. One solution that Jeff sees is the complete opposite of the spectrum from monorepo. Dr. Gleb Bahmutov is a huge fan of open-source smaller repos - a lot of the mentality of keeping things small, separate and distinct. He’s decided that he’s going to stick in the many repo universe and just create tooling to solve some of these problems. For versioning, he runs this server that detects that a new version has been published. It will automatically try to update it and run all the tests. But according to Kushal, if you have different repos, you can move differently in terms of dependencies but if you’re now out of sync, you may suddenly have incompatible dependencies across what you’re doing. It’s a question of when you want to deal with the problem. Chuck talks about the ways you can get out of sync. With the multirepo, you can get out of sync not just on the dependencies and the build process, but also on the API’s. If you have a module that you’re working on over here and whatever are consuming it on the other side as a driver may not be updated yet so it doesn’t talk properly. Jeff also noticed that with Angular DI, if you aren’t actually using the same version, you run into issues because it has to be the exact same thing at every level or else the injection token is different. [00:36:50] – Develop within Monorepo or develop in a separate repo Chuck thinks that it depends. If there are a lot of dependencies and shortcuts that he can take by relying on the monorepo, he will do it on the monorepo like if it auto loads the correct libraries automatically. And then, they don’t have to do a whole lot of setup. If it’s small, independent, and it’s going to move quickly, then, a separate repo may be the right answer. Kushal adds that there are a lot of benefits in doing it in the monorepo. With feature flags, you have the benefit of reviewing it. It also allows you and others to keep up with everyone in terms of breaking API changes, other than having some brutal merge. Jeff will do it in a separate repo. If this an experimental thing, it disturbs people less. It alleviates the notifications that go on. That is why Kushal’s team also built a lot of custom Slack cooks in order to get some notifications tailored to the parts that they only care about. [00:44:50] – How do you work it out so that things aren’t so tightly coupled? There are no circular dependencies between your packages even transitively. As your monorepo grows you may eventually have some tooling that requires that for your build system. Can this layer have this type of functionality? Or does it need to be moved into a new package? It also means it improves your architecture. Kushal’s team is working on Java. This object that users and organizations create can know about each other’s’ objects but the users can never depend back into organizations or vice versa. You can think of the layered model of networking. We have the pure data model objects are not allowed to know anything about the service layer that interacts with the database. The database can know about those model objects. The web tier can obviously know about both the model objects and the service tier because it utilizes both of those. [00:47:30] – How are those relationships defined? They are defined in build files. If you look at Pants or Blaze or Buck, all those build systems have explicit dependency configurations so you can sort of keeping any of those invariants from being broken.  But Kushal’s team just have a Wiki page that lists out the rules. They also have a test that looks for any cycles in any package dependencies. Jeff’s team created a CLI tool that walks down all subdirectories from where they’re running it. It finds all the package JSON in all your subdirectories and it creates the dependency graphs. They haven’t fully moved to a monorepo but they did start to consolidate. They have a couple of larger repos. This tool will see the dependency graph for all the NPM modules and also see the dependencies between the repos based off of the NPM module dependencies. [00:50:20] – Multimonorepo It’s not perfect to have one larger repo that has basically all of the none-deployable codes. Jeff and his team have a separate set of repos for the actual deployable code. They haven’t made the jump to where Kushal is advocating – using build tools. [00:50:20] – To open-source When you want an open-source portion of what you’re doing but not the entire company’s code base, Jeff thinks that there’s really no way out of having a separate repo for that. Google has this giant internal repo because not everything in it is open-source. Angular is open-source. That’s at least one driver that Angular is in the public Github repo and Google use so much of Angular. And some companies want the sort of open collaboration and free support and upgrades from the community. Other companies see that they’re giving away some kind of competitive advantage that they’re not willing to give up. [00:55:40] – Monorepo is better in all cases Jeff recognizes that there’s a number of organizations that have successfully implemented it but there isn’t an easy way for someone to do it. It’s not common knowledge and does not have a well-known set of tooling and best practices. There’s still a lot to go to get to the point where it’s a no-brainer and everybody knows how to do this the right way. Ward doesn’t know how to do a monorepo but according to him, if he is in an organization or starting an organization, he would go figure out how to do it and would want his organization to have a monorepo. Chuck tends to lean to monorepo but doesn't always do it either. Another caveat is even if he starts with the monorepo, that doesn’t mean that’s where he’s going to end. The answer is if you put them all in separate repos and it turns out that you need benefits of having them all in the same place, you can move them all in one repo. It may not be easy depending on how big and complicated you make your mono or the way you tie together your disparate repos. Kushal is all in. The only time that he wouldn’t do it is if he’s building disparate open-source projects and wanted them to play the open-source ecosystem. The net benefit is that everyone is moving together rapidly because monorepo is optimized for speed. But Kushal wishes that the tooling is better and that many people move to this model. Joe is also open to monorepo in a larger organization. He thinks that the separate repos keep things but monorepo can solve a lot of problems. [01:01:55] – Places to go Jeff has a bunch of articles for people who are pro-monorepo and are advocating for that. He has yet to find one that sets forth like a good mental model or decision framework. This is what Jeff hopes to create in the next couple of weeks before the conference. Picks Ward Bell Hiking Fishing Southern Sierras Chuck Max Wood Book: Profit First by Mike Michalowicz Ketogenic Diet Air-conditioning Joe Eames Book: Everybody Lies: Big Data, New Data, and What the Internet Can Tell Us About Who We Really Are by Seth Stephens-Davidowitz Rent a scooter to ride around Rome Jeff Whelpley Survey: Monorepo vs Multirepo Twitter: @jeffwhelpley Medium: @jeffwhelpey Kushal Dave Technical Design Reviews Book: The Orphan Master’s Son Twitter: @krave Medium: Workflow

AiA 152: Multirepo vs Monorepo with Jeff Whelpley and Kushal Dave On today's episode of Adventures in Angular, we have panelists Ward Bell, Joe Eames and Charles Max Wood. We have special guests, Jeff Whelpley and Kushal Dave. The discussion ranges from the organization of code bases to the benefits of using Monorepo vs Multirepo. Tune in! [00:01:45] – Introduction to Jeff Whelpley and Kushal Dave Kushal is CTO at Scroll, a start-up. Before that, he was at Foursquare, Chartbeat, Google, and IBM. He has worked in a lot of monorepo code base. Although he actually has experience working on a lot of Multirepo situations. Jeff is the CTO of a small startup in Boston called GetHuman that helps people with customer service problems. He has been on Adventures in Angular a couple of times before. He has also been in a couple of other podcasts before, as well as in the open-source community. [00:03:20] – Introduction to the issue Typically, when you’re working in just one or two people team, you don’t really have that many issues centered on dev process, coordinating changes between each other, and trying to figure out the best optimal way to organize your code. Most of the time, you understand the entire code base because you’re working with everything. It gets to be a much different problem once you get to have a larger team. In essence, everything is starting slow down because of different overhead related to the process that was needed in order to make sure got quality changes. You basically have to spend a lot of time and thought around your developer process, how you structure your code, how you physically setup, and organize your entire code base. [00:06:20] – How to organize your code bases? When Kushal worked at Google, everything is in a single giant repository. There are one or two exceptions for client code and some infrastructure things. It allowed people to feel that they could change any of the code and it made it easy to keep everybody in sync with the state of the code. There is some sort of workflow and process things that you have to change in order to get that right. Probably, the biggest one is trying to keep the repo from working in long running branches because things start to diverge. That was the model of Foursquare too. [00:08:15] – How do you run all of the CI across everything? The answer changes to different sizes. At Scroll and for most of the time that Kushal was at Foursquare, it was efficient to run all the builds on every commit. If you just have one mega build that just runs continuously, that’s good enough up until 30 or 40 developers. Once you hit that size, there’s a variety of build tools out there that you can use and understand the structure of your code base. Once you’ve used one of these build tools, declaratively indicate which artifacts depends on which libraries, and what the full dependency thing is, you can build only the relevant CI’s. You can decide whether this change only touches this binary or this test. Chuck also like the approach of having everything in master. If it was experimental, it would still go into master and their CI would effectively run the different builds with the different feature flags. If what you did broke something that somebody else was working on in a process, you could just adjust it midstream. [00:16:00] – Gatekeeper process The gatekeeper process protects the whole code base but at the same time, it’s in the layer of bureaucracy. We’ve been reviewing every piece of code before it’s allowed to land in master. Everybody on our team commits multiple times a day to master. All the changes, as much as possible are really small, especially the feature flag check. In that world, there is this bureaucracy. Hopefully, it’s not holding you up too much. The flipside of that is when you’ll feel really confident that you didn’t break anybody who depends on you and you’re going to have to revisit this change a month from now. For the past 9 months or so, Jeff tried a bunch of different configurations. He tried monorepo and other configurations from the other end of the spectrum - many small packages. As he was interviewing people with their different setups, they’ve all encountered the same types of problems. Regardless if you’re using monorepo or not, as long as you’re trying to keep your changes small and specific, and implemented quickly, it can alleviate any other pains. [00:22:10] – Guard rails The guard rails are just the reviewers. For us, every change that’s getting reviewed means that in some extent, there’s a human check on that. I’m not sure if you can but I certainly know that Reviewable and Fabricate both offer sort of wide range of configuration options. I can imagine the world in which you can programmatically keep people from landing changes that didn’t have that level. In Github, there are guard rails. That actually helps the reviewers. It’s reassuring to have some technology that this person is associated with this set of boundaries. If you want to step outside of the boundaries, they’re going to have to get some other person who understands the code that’s outside of the line to join in approving that. If their organization is big, this is something that they might have to think about. Jeff advises to really be careful about what you’re doing. Is this a change where you are just bumping version numbers or is this something that you have to change a business logic? [00:28:15] – Allowing different people to upgrade dependencies The only way Kushal has ever seen it done is a brutal all-nighter by somebody who has to sit there and get everything working. But one of the things that Google does is they develop a lot of patterns about how to refactor code to make things easier. One solution that Jeff sees is the complete opposite of the spectrum from monorepo. Dr. Gleb Bahmutov is a huge fan of open-source smaller repos - a lot of the mentality of keeping things small, separate and distinct. He’s decided that he’s going to stick in the many repo universe and just create tooling to solve some of these problems. For versioning, he runs this server that detects that a new version has been published. It will automatically try to update it and run all the tests. But according to Kushal, if you have different repos, you can move differently in terms of dependencies but if you’re now out of sync, you may suddenly have incompatible dependencies across what you’re doing. It’s a question of when you want to deal with the problem. Chuck talks about the ways you can get out of sync. With the multirepo, you can get out of sync not just on the dependencies and the build process, but also on the API’s. If you have a module that you’re working on over here and whatever are consuming it on the other side as a driver may not be updated yet so it doesn’t talk properly. Jeff also noticed that with Angular DI, if you aren’t actually using the same version, you run into issues because it has to be the exact same thing at every level or else the injection token is different. [00:36:50] – Develop within Monorepo or develop in a separate repo Chuck thinks that it depends. If there are a lot of dependencies and shortcuts that he can take by relying on the monorepo, he will do it on the monorepo like if it auto loads the correct libraries automatically. And then, they don’t have to do a whole lot of setup. If it’s small, independent, and it’s going to move quickly, then, a separate repo may be the right answer. Kushal adds that there are a lot of benefits in doing it in the monorepo. With feature flags, you have the benefit of reviewing it. It also allows you and others to keep up with everyone in terms of breaking API changes, other than having some brutal merge. Jeff will do it in a separate repo. If this an experimental thing, it disturbs people less. It alleviates the notifications that go on. That is why Kushal’s team also built a lot of custom Slack cooks in order to get some notifications tailored to the parts that they only care about. [00:44:50] – How do you work it out so that things aren’t so tightly coupled? There are no circular dependencies between your packages even transitively. As your monorepo grows you may eventually have some tooling that requires that for your build system. Can this layer have this type of functionality? Or does it need to be moved into a new package? It also means it improves your architecture. Kushal’s team is working on Java. This object that users and organizations create can know about each other’s’ objects but the users can never depend back into organizations or vice versa. You can think of the layered model of networking. We have the pure data model objects are not allowed to know anything about the service layer that interacts with the database. The database can know about those model objects. The web tier can obviously know about both the model objects and the service tier because it utilizes both of those. [00:47:30] – How are those relationships defined? They are defined in build files. If you look at Pants or Blaze or Buck, all those build systems have explicit dependency configurations so you can sort of keeping any of those invariants from being broken.  But Kushal’s team just have a Wiki page that lists out the rules. They also have a test that looks for any cycles in any package dependencies. Jeff’s team created a CLI tool that walks down all subdirectories from where they’re running it. It finds all the package JSON in all your subdirectories and it creates the dependency graphs. They haven’t fully moved to a monorepo but they did start to consolidate. They have a couple of larger repos. This tool will see the dependency graph for all the NPM modules and also see the dependencies between the repos based off of the NPM module dependencies. [00:50:20] – Multimonorepo It’s not perfect to have one larger repo that has basically all of the none-deployable codes. Jeff and his team have a separate set of repos for the actual deployable code. They haven’t made the jump to where Kushal is advocating – using build tools. [00:50:20] – To open-source When you want an open-source portion of what you’re doing but not the entire company’s code base, Jeff thinks that there’s really no way out of having a separate repo for that. Google has this giant internal repo because not everything in it is open-source. Angular is open-source. That’s at least one driver that Angular is in the public Github repo and Google use so much of Angular. And some companies want the sort of open collaboration and free support and upgrades from the community. Other companies see that they’re giving away some kind of competitive advantage that they’re not willing to give up. [00:55:40] – Monorepo is better in all cases Jeff recognizes that there’s a number of organizations that have successfully implemented it but there isn’t an easy way for someone to do it. It’s not common knowledge and does not have a well-known set of tooling and best practices. There’s still a lot to go to get to the point where it’s a no-brainer and everybody knows how to do this the right way. Ward doesn’t know how to do a monorepo but according to him, if he is in an organization or starting an organization, he would go figure out how to do it and would want his organization to have a monorepo. Chuck tends to lean to monorepo but doesn't always do it either. Another caveat is even if he starts with the monorepo, that doesn’t mean that’s where he’s going to end. The answer is if you put them all in separate repos and it turns out that you need benefits of having them all in the same place, you can move them all in one repo. It may not be easy depending on how big and complicated you make your mono or the way you tie together your disparate repos. Kushal is all in. The only time that he wouldn’t do it is if he’s building disparate open-source projects and wanted them to play the open-source ecosystem. The net benefit is that everyone is moving together rapidly because monorepo is optimized for speed. But Kushal wishes that the tooling is better and that many people move to this model. Joe is also open to monorepo in a larger organization. He thinks that the separate repos keep things but monorepo can solve a lot of problems. [01:01:55] – Places to go Jeff has a bunch of articles for people who are pro-monorepo and are advocating for that. He has yet to find one that sets forth like a good mental model or decision framework. This is what Jeff hopes to create in the next couple of weeks before the conference. Picks Ward Bell Hiking Fishing Southern Sierras Chuck Max Wood Book: Profit First by Mike Michalowicz Ketogenic Diet Air-conditioning Joe Eames Book: Everybody Lies: Big Data, New Data, and What the Internet Can Tell Us About Who We Really Are by Seth Stephens-Davidowitz Rent a scooter to ride around Rome Jeff Whelpley Survey: Monorepo vs Multirepo Twitter: @jeffwhelpley Medium: @jeffwhelpey Kushal Dave Technical Design Reviews Book: The Orphan Master’s Son Twitter: @krave Medium: Workflow

Get a new Fatal Error episode every week by becoming a Patreon supporter!Chris and Soroush dive deep on server-side Swift.Fatal Error Episode 30: Server-Side SwiftBeaconAshley Nelson-HornsteinVaporFoundation’s base64 encoding bug on Linux Vapor SlackMonoreposDan Luu on MonoreposDavid R. MacIver on Monreposgit-subtreeKituraErrors on the server on Soroush’s bloggithub.com/khanlou/PromiseFatal Error 4. PromisesFatal Error 5. Reactive ProgrammingProposal to unify Swift.String Index types

JBoss Asylum 42 Shownotes Recorded 21st September 2016 by Emmanuel Bernard (Info, @emmanuelbernard) & Max Rydahl Andersen (Info, @maxandersen) Andrew Lee Rubinger (Info, @ALRubinger)   Music by Real Rice (http://www.jamendo.com/en/track/24321) Licence Art Libre 1.3   #42: I Git the flow Give feedback at @jbossasylum and asylum@jboss.org   The Tweet: https://twitter.com/alrubinger/status/718527667268505600   Merge vs rebase, Good background: https://www.atlassian.com/git/tutorials/merging-vs-rebasing/ When using merge `git log --no-merges` is your friend.   Monorepo: https://danluu.com/monorepo/ Still stuck on svn ?    https://github.com/maxandersen/jbosstools-gitmigration    http://www.slideshare.net/maxandersen/a-tale-about-a-big-svn-to-git-migration https://emmanuelbernard.com/blog/2010/05/31/git-how-my-life-has-improved-since-last-month-when-i-used-svn/ http://in.relation.to/2010/10/13/hibernate-moves-to-git-git-tips-and-tricks/   The tab vs spaces war ? https://medium.com/@hoffa/400-000-github-repositories-1-billion-files-14-terabytes-of-code-spaces-or-tabs-7cfe0b5dd7fd Mozilla is slower with tabs bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=1154339