Podcast appearances and mentions of Erich Gamma

Scott and Wes are joined by Erich Gamma, creator of VS Code, and Kai Maetzel, Copilot Lead, to share some big news about the future of VS Code and Copilot. They discuss what it means for developers, how AI is shaping the future of coding, and why staying open to the community is key. Show Notes 00:00 Welcome to Syntax! 01:00 The inception of VS Code. 02:49 VS Code adoption. 04:31 Brought to you by Sentry.io. 04:55 Syntax Denver Meetup! 05:19 The big announcement. 06:25 The current state of Copilot and VS Code. 08:31 The challenges with LLMs running outside of the codebase. 09:31 How to make a business case for AI. 10:47 The maturing of the AI landscape. 13:01 The limitations of extensions. 14:06 Open source vs closed source. 14:49 Copilot's context is public. 19:23 Is context language-specific? 21:23 How does this affect paid Copilot features? 23:27 Secrets of Copilot's server-side. 28:36 What will be open and what will not? 29:03 Is Copilot's UI influenced by VS Code forks? 31:31 Maintaining VS Code identity in forks. 33:07 What does open-sourcing GitHub Copilot mean for Cursor and Windsurf? 38:42 Were you surprised to see VS Code forks? 40:03 Are other extensions able to tap into the AI offerings? 43:20 There's work to be done. 44:13 The timeline. 45:39 Simulation Tests (S Tests). 48:07 How to test LLMs. 49:10 The future of software development with AI. 52:47 What's your favorite model? Hit us up on Socials! Syntax: X Instagram Tiktok LinkedIn Threads Wes: X Instagram Tiktok LinkedIn Threads Scott: X Instagram Tiktok LinkedIn Threads Randy: X Instagram YouTube Threads

Following up on their recent discussion on software design (inspired by Book Overflow!), John Ousterhout and Robert "Uncle Bob" Martin join Carter and Nathan for their first ever joint interview! Join them as they discuss what it was like working together, how the discussion came to be, and what they both learned from the process!Ousterhout/Martin Discussion: https://github.com/johnousterhout/aposd-vs-clean-code-- Books Mentioned in this Episode --Note: As an Amazon Associate, we earn from qualifying purchases.----------------------------------------------------------A Philosophy of Software Design by John Ousterhouthttps://amzn.to/3XCPliz (Paid Link)Clean Code by Robert Martinhttps://amzn.to/4iJ4Ttq (Paid Link)Clean Coder, The: A Code of Conduct for Professional Programmers by Robert C. Martin https://amzn.to/3E9zf9l (Paid Link)We, Programmers: A Chronicle of Coders from Ada to AI by Robert Martinhttps://amzn.to/42aW194 (Paid Link)Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissideshttps://amzn.to/4hRbYa3 (Paid Link)Structured Analysis and System Specification by Tom DeMarco, P. J. Plaugerhttps://amzn.to/3E0Y7QD (Paid Link)Practical Guide to Structured Systems Design by Meilir Page-Joneshttps://amzn.to/4hNd8mV (Paid Link)Design by Contract: By Example First Edition by Richard Mitchell, Jim McKim, Bertrand Meyerhttps://amzn.to/4i4X6VW (Paid Link)Structured Programming by Edsger Wybe Dijkstra, C. A. R. Hoare, Ole-Johan Dahlhttps://amzn.to/42fXfzX (Paid Link)On the Criteria To Be Used in Decomposing Systems into Modules by D.L. Parnashttps://wstomv.win.tue.nl/edu/2ip30/references/criteria_for_modularization.pdf----------------00:00 Intro03:11 Origin of the debate06:52 Motivation for the debate11:35 How did you settle on the terms of the debate?14:30 Overcoming Self-Doubt and Engaging with others20:06 Influences in Developing Design Aesthetics28:45 Taking time for Deep Thinking vs Shallow thinking33:58 Writing Code and Reducing Cognative Load39:05 Encouraging healthy debate42:38 Coding Style, Retirement, and what's next49:40 Final Thoughts----------------Spotify: https://open.spotify.com/show/5kj6DLCEWR5nHShlSYJI5LApple Podcasts: https://podcasts.apple.com/us/podcast/book-overflow/id1745257325X: https://x.com/bookoverflowpodCarter on X: https://x.com/cartermorganNathan's Functionally Imperative: www.functionallyimperative.com----------------Book Overflow is a podcast for software engineers, by software engineers dedicated to improving our craft by reading the best technical books in the world. Join Carter Morgan and Nathan Toups as they read and discuss a new technical book each week!The full book schedule and links to every major podcast player can be found at https://www.bookoverflow.io

In this episode, we dive deep into the world of clean coding with none other than the master and pioneer of the field, Uncle Bob. We explore the nuances and the art behind writing effective and efficient scripts. This conversation covers the nitty-gritty of writing and editing scripts, from understanding how to break down large functions, to discussing principles like 'Single Responsibility Principle', 'Dependency Inversion Principle' and how to balance the 'DRY' (Don't Repeat Yourself) principles. Uncle Bob also shares valuable insights on testing, handling errors, naming conventions and how to work with different types of duplication in coding. He shares recommended resources and books that every coder should read. Chapters: 00:00 Introduction and Welcome 00:06 The Importance of Code Quality 00:29 Introducing Robert Martin (Uncle Bob) 01:39 Uncle Bob's Journey in Programming 02:34 Discussion on Functional Design and New Book 03:52 The Evolution of Software Development 04:28 Revisiting the Clean Code Book 04:49 The Impact of Hardware Changes on Software 06:13 The Evolution of Programming Languages 07:33 The Importance of Code Structure and Organization 09:07 The Impact of Microservices and Open Source 11:14 The Role of Modular Programming 22:07 The Importance of Naming in Code 26:31 The Role of Functions in Code 34:12 The Role of Switch Statements in Code 42:36 The Importance of Immutability 51:00 Dealing with Complex Steps in Programming 51:21 Implementing State Machines in Programming 51:46 The Pragmatic Approach to Programming 53:01 Understanding Error Handling in Programming 54:08 The Challenge of Exception Handling 57:27 The Importance of Log Messages in Debugging 01:03:05 The Dilemma of Code Duplication 01:05:51 The Intricacies of Error Handling 01:07:40 The Role of Abstraction in Programming 01:13:55 The Importance of Testing in Programming 01:19:43 The Challenges of Mocking in Testing 01:25:11 The Essence of Programming: Discipline, Ethics, and Standards Book Recommendations: Tidy First: https://www.oreilly.com/library/view/tidy-first/9781098151232/ Design Patterns: https://www.amazon.de/-/en/Erich-Gamma/dp/0201633612 Analysis Pattern: https://martinfowler.com/books/ap.html Structured Analysis and System Specification: https://www.amazon.de/-/en/Tom-Demarco/dp/0138543801 Fundamental Algorithms: https://www.amazon.com/Art-Computer-Programming-Vol-Fundamental/dp/0201896834 Sorting and Searching: https://www.amazon.de/-/en/Donald-Knuth/dp/0201896850 Structure and Interpretation of Computer Programs: https://web.mit.edu/6.001/6.037/sicp.pdf =============================================================================== For discount on the below courses: Appsync: https://appsyncmasterclass.com/?affiliateId=41c07a65-24c8-4499-af3c-b853a3495003 Testing serverless: https://testserverlessapps.com/?affiliateId=41c07a65-24c8-4499-af3c-b853a3495003 Production-Ready Serverless: https://productionreadyserverless.com/?affiliateId=41c07a65-24c8-4499-af3c-b853a3495003 Use the button, Add Discount and enter "geeknarrator" discount code to get 20% discount. =============================================================================== Follow me on Linkedin and Twitter: https://www.linkedin.com/in/kaivalyaapte/ and https://twitter.com/thegeeknarrator If you like this episode, please hit the like button and share it with your network. Also please subscribe if you haven't yet. Database internals series: https://youtu.be/yV_Zp0Mi3xs Popular playlists: Realtime streaming systems: https://www.youtube.com/playlist?list=PLL7QpTxsA4se-mAKKoVOs3VcaP71X_LA- Software Engineering: https://www.youtube.com/playlist?list=PLL7QpTxsA4sf6By03bot5BhKoMgxDUU17 Distributed systems and databases: https://www.youtube.com/playlist?list=PLL7QpTxsA4sfLDUnjBJXJGFhhz94jDd_d Modern databases: https://www.youtube.com/playlist?list=PLL7QpTxsA4scSeZAsCUXijtnfW5ARlrsN Stay Curios! Keep Learning!

Today Scott talks to Erich Gamma and Kai Maetzel about the origin story of VS Code. We'll talk about how it was originally conceived and how it evolved over time. They also discuss some of the challenges they faced while developing VS Code and how they overcame them. An overnight success in 10 years, VS Code was designed to be lightweight and fast, with a focus on extensibility and community. We'll hear about culture and technical architecture as well as what's next for VS Code and what users can expect in future releases.  

Developer Highlights, Geschenke und gute Vorsätze fürs neue Jahr - das ist unsere Weihnachtsfolge. Wir blicken auf das Jahr 2021 zurück, diskutieren Technologien die uns beeindruckt haben und nehmen uns vor allem eines für 2022 vor: Regelmäßig eine neue Folge von diesem Podcast aufnehmen! Um den Jahresabschluss mit euch zu feiern und uns für eure Treue zu bedanken, möchten wir ein paar von euch beschenken. Als Geschenke gib es unter anderem kluge Bücher wie: - Clean Code von Robert Martin - Essential Scrum von Rubin Kenneth - Design Patterns von Erich Gamma und Richard Helm - Designing Distributed Systems von Brendan Burns - How Google Tests Software von James Whittaker Für die Chance auf Geschenk, schreibt uns eine E-Mail an todopodcast@outlook.com mit dem Betreff "Weihnachtsfolge 2021", nennt uns eine der neuen Programmiersprachen die Robin-Manuel 2022 lernen möchte und schreibt dazu, welches Buch euch am meisten interessiert. Packt auch gerne ein Wunschthema in die E-Mail, das wir in 2022 im Podcast besprechen sollen. Wir wünschen euch ein wunderbaren Jahresabschluss und freuen uns auf das neue Jahr mit euch!

Keynote by Erich Gamma

In this episode, your host Jeffrey Palermo is sharing his top list of the architectures you should be paying attention to in 2021 and beyond.   The software development world is changing at a faster rate every year. As we look back, there are architectures, infrastructure, and patterns that have often turned out to be nothing more than fads or distractions in hindsight — resulting in lost productivity, dead ends, and broken promises. To avoid this in 2021, Jeffrey is reviewing a survey of modern architectures that are sure to have staying power in 2021 and beyond.   Get ready to tune in and take some notes!   Topics of Discussion: [:38] Be sure to visit AzureDevOps.Show for past episodes and show notes. [1:00] About The Azure DevOps Podcast, Clear Measure, and Jeffrey’s offer to speak at virtual user groups. [1:25] Clear Measure is hiring! Be sure to check out the link in the show notes. [1:37] About Jeffrey’s newest podcast, Architect Tips! [1:57] About today’s episode. [2:39] The different levels of architecture patterns and why it is important to know them. [4:46] At the infrastructure level, this is the pattern to pay attention to: serverless architecture. [8:03] At the system level, this is one of three patterns you should be paying attention to: domain-driven design. [10:48] Also at the system level, you should pay attention to: microservices. [12:35] Discussing the two different major architectures that distributed architectures generally come down to: event-driven and web services. [16:27] Jumping down to the application level, Jeffrey begins highlighting the four must-know architecture patterns to be paying attention to, starting with: MVC and MVVM. [19:48] A word from Azure DevOps Podcast’s sponsor: Clear Measure. [20:17] Next on the application level, Jeffrey highlights: onion architecture and layered architecture. [23:01] Next on the application level: CQRS vs. structured programming. [25:24] Last on the application level: onion DevOps architecture. [28:46] At the layer level, Jeffrey highlights several must-have patterns, starting with: the adapter pattern. [30:45] Next on the layer level: mediator and chain responsibility. [31:34] The overall family pattern that mediator and chain responsibility are a part of: hub-and-spoke. [34:10] Lastly on the layer level: observer. [36:21] For different design patterns you will want to know how to describe them and be able to create diagrams. Jeffrey recommends PlantUML for this. [37:56] At the code level, Jeffrey highlights: generic code patterns, functional programming style, and object-oriented logging. [38:38] Jeffrey closes out this week’s episode.   Mentioned in this Episode: Architect Tips — New video podcast! Azure DevOps Clear Measure (Sponsor) .NET DevOps for Azure: A Developer's Guide to DevOps Architecture the Right Way, by Jeffrey Palermo — Available on Amazon! bit.ly/dotnetdevopsebook — Click here to download the .NET DevOps for Azure ebook! Jeffrey Palermo’s Youtube Jeffrey Palermo’s Twitter — Follow to stay informed about future events! The Azure DevOps Podcast’s Twitter: @AzureDevOpsShow Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides Domain-Driven Design: Tackling Complexity in the Heart of Software, by Eric Evans DevOps Environment Poster PDF PlantUML   Want to Learn More? Visit AzureDevOps.Show for show notes and additional episodes.

اليوم نحاور ضياء حول ريادة الأعمال في المغرب, و الدروس التي تعلمها من فشل شركته الأولى. كذلك سنحاول معرفة معلومات أكثر حول مسابقات البرمجة بالنسبة للطلبة الجامعيين. و في الأخير سنكتشف النظام الذي يتبعه ضياء لتنظيم وقته و التوفيق بين مسؤولياته المختلفة. ضياء الحق الفلوس هو مدير المسابقة الجامعية للبرمجة بالمغرب التي تعرف اختصارا بــ MCPC مؤسس شركة سكوريفاي و شركة ضياء لاند إشتغل تسع سنوات بشركة نوكيا حاصل على دبلوم مهندس دولة في الإتصالات من المعهد الوطني للبريد و المواصلات الذي يعرف اختصارا بـ INPT حاصل على جازة محمد عبد الوهاب لأحسن مدرب من المسابقة العربية للبرمجة التي تعرف اختصارا بــ ACPC محاور البودكاست 00:00 - مسابقات البرمجة 31:35 - تجربة سكوريفاي 01:07:03 - تجربة ضياء لاند 01:21:07 - قراءة الكتب 01:36:24 - تنظيم الوقت 01:50:54 - Work life balance 01:56:03 - الزواج و الطموح 02:00:27 - حق المرأة في العمل و أيضا في عدم العمل 02:06:15 - هل الرياضة مضيعة للوقت 02:13:48 - الموسيقى 02:17:18 - رسالة لطلبة الإعلاميات في المغرب 02:22:44 - رسالة أخيرة لكل شاب Recommended books by the Diaa Competitive Programming book series by Steven Halim and Felix Halim Rich dad poor dad by Robert Kiyosaki Clean code by Robert Cecil Martin The 7 Habits of Highly Effective People by Stephen Covey Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides The Lean Startup by Eric Ries Disciplined Entrepreneurship: 24 Steps to a Successful Startup by Bill Aulet First Things First by Stephen Covey Contact the guest https://www.linkedin.com/in/elfallous Useful links https://www.instagram.com/lectoremshow/ https://www.facebook.com/lectoremshow

Rapid Unscheduled Dissassembly - https://en.wiktionary.org/wiki/rapid_unplanned_disassembly ・ 80s Editor Template: https://www.schrankmonster.de/2019/05/23/80s-code-editor-theme/ ・ Erich Gamma - Design Patterns Buch - https://en.wikipedia.org/wiki/Design_Patterns ・ Erich Gamma wechselt zu Microsoft - https://www.heise.de/developer/artikel/Design-Patterns-Tools-und-Co-Im-Gespraech-mit-Erich-Gamma-2750465.html ・ HAL9000: https://en.wikipedia.org/wiki/HAL_9000 ・ Caesar Cipher: http://practicalcryptography.com/ciphers/caesar-cipher/ ・ Symbolic Links on Windows: https://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/ ・ Symbolic Links allgemein - https://en.wikipedia.org/wiki/Symbolic_link ・ Typora Markdown Editor - https://typora.io/ ・ MindForger Markdown and IDE - https://www.mindforger.com/ ・ Magisches Denken - https://de.wikipedia.org/wiki/Magisches_Denken ・ Kognitive Dissonanz - https://de.wikipedia.org/wiki/Kognitive_Dissonanz ・ Nicht ganz preiswerter aber effizientester Felgendynamo: Dynamo SPECIAL - http://www.velogical-engineering.com/velogical-felgendynamo---standard-fahrrad-dynamo---leichtlauf-gewicht-effizienz ・ USB Werk busch+müller: https://www.bumm.de/de/produkte/stromversorgung/parent/3610/produkt/361bw.html ・ Minimallader selbst bauen - https://fahrradzukunft.de/12/minimal-lader/ ・ Microsoft Project XCloud: https://twitter.com/Xbox/status/1137833126959280128 ・ Shodan.io - https://Shodan.io ・ Rossmann Group Videos: https://www.youtube.com/user/rossmanngroup ・ Espressif: https://www.espressif.com/ ・ Geschirrspüler würfelt wer ihn leer räumt: https://www.schrankmonster.de/2019/02/16/how-do-you-determine-who-needs-to-clear-out-the-dishwasher/ ・ Verbraucherschutz Garantie - Recht auf Geräte in akzeptabler Qualität: https://www.heise.de/newsticker/meldung/Drastische-Strafe-fuer-LG-nach-unzureichendem-Kundensupport-4516429.html

#17: Ivor asks "How do you like to learn? People that like to learn have their own style. What's yours?" https://twitter.com/ivorsco77/status/1154039680603529218   Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides: https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612/   DevOps Paradox by Viktor Farcic: https://www.packtpub.com/web-development/devops-paradox   The DevOps 2.6 Toolkit: Jenkins X by Viktor Farcic: https://leanpub.com/the-devops-2-6-toolkit   Join the Slack team: http://slack.devops20toolkit.com/   Twitter: Darin: @darinpope Viktor: @vfarcic DevOpsParadox: @DevOpsParadox   Email: Darin: darin@planetpope.com Viktor: viktor@farcic.com Visit us at: https://www.devopsparadox.com/

You know JavaScript users love Visual Studio Code, but did you know Go and Rust are some of the most used languages in VS Code? Amanda Silver shares how you can pair program with Live Share, how Python, Go, and Rust are used in VS Code, information about one of Code's creators Erich Gamma, and how you can list and share your extensions.Links:Language support: https://aka.ms/5langGo support: https://aka.ms/5goRust support: https://aka.ms/5rustPyTorch: https://aka.ms/5pytorchLearn about Live Share: https://aka.ms/5introliveshareInstall the Live Share extensions: https://aka.ms/5livesharepackList extensions: https://aka.ms/5listext

Patrick Yeon (@patyeon) spoke with us about nonprofit spaceships then asked our opinions about embedded software. Pat is working for something something nonprofit space something something. To fill in some of the blanks, apply for a job on NonprofitSpaceship.org. Pat was previously on episode 153: Space Nerf Gun when we talked about cost-optimized satellites. We talked about several books: Turn the Ship Around! A True Story of Turning Followers into Leaders by L. David Marquet Managers Path: Leaders Navigating Growth and Change by Camille Fournier Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides Head First Design Patterns: A Brain-Friendly Guide by Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra Elecia’s command code is on github.  

Erich Gamma: @ErichGamme Dirk Baeumer: @dbktw Show Notes 01:11 - The Design Patterns Book 02:45 - The Eclipse Project 09:24 - Language Server Protocol: Overview 15:16 - What can you do with a server that implements the LSP? Incremental usage? 20:12 - Keeping the Tools in Sync and Refactoring Support 24:33 - Keeping it Performant 29:41 - What kind of proliferation of codesmart tools are there that implement the LSP? 34:51 - What are the challenges encountered trying to build abstractions that work for 40 different languages? Resources Visual Studio Code Transcript CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 97. My name is Charles Lowell. I'm a developer here at The Frontside and your podcast host-in-training. And with me today, we have two very special guests. They have been working on technologies that have run very parallel to my entire career as a software developer. And we're going to talk about that. So with us today are Erich Gamma and Dirk Baeumer who are developers on the team developing VS Code, which if you're in the frontend space is taking that area of development by storm. It's just amazing, some of the things they can do. Lots of people are using it every day. Lots of people are trying it. And so, we're going to talk about the technologies that underlie that and the story of how it came to be. So, welcome Erich and welcome Dirk. ERICH: Hello from Zurich. CHARLES: Alright. Zurich to Albuquerque. Here we go. As a first start, I would have to say my first contact with this story, I at least have to mention it because – and this is for Erich – you wrote a book that was very, very instrumental in my formation as a young developer. I think I was about 22 years old when I read ‘Design Patterns'. And I don't know. I still carry a lot of those things with me to this day, even though a lot of things have changed about the way that we do development. I still carry a lot of those lessons, I think especially things like the state pattern and the strategy pattern, and stuff like that. I want to move onto other things, but I was hoping that we could talk just a little bit about, what are the things that you find still kind of relevant today? ERICH: Well, now as you said, some of the things are kind of timeless and we're lucky to have found these things. And I still love all the patterns. But I must say, things have changed, right? So, at that time, we thought objects are very cool. And as we have evolved, all of a sudden we think, “Oh, functions are actually very cool, too,” right? Closures and so on. So, I think we got more broader and of course if you use functional programming, you have many more patterns available as you program. So, I feel some of the object thinking still applies. But that's not the only thing that counts anymore. Today it's functions, stateless, immutability, and all those things within functional programming which is [straight] and which [inaudible] in our team. CHARLES: Yeah, yeah. I would love to see an update to how do these concepts transfer into functional programming. But anyway, just wanted to say thank you for that. And it was about the same time that, a few years after, I don't know the exact same timing, I want to wind back. Because we're going to talk about VS Code but before VS Code, there was a project that both of you all worked on called Eclipse, which I also used. Because at the very beginning of my career, I did a lot of Java development. And it really opened my eyes into a level of what tooling could do for you that I didn't see before. And I was wondering how did you arrive to there? Because before that, I was using Emacs and Vim and Joe's Editor and things that were editing the text files. And how did you kind of arrive at that problem? Because I feel like it's very similar to the one that VS Code solves, but this was what, 15 years ago? ERICH: I think it's older, right? CHARLES: Really? DIRK: It's 17, 18, yeah. Yeah, yeah. It was end of the millennium, right? So to be honest, Eclipse wasn't the first development tool we worked on. Then, we worked on the company ObjectTechnologyNational. They worked on Smalltalk tools. And of course, Smalltalk had a great IDE experience, right? So back then, Java became popular. One idea was, how can you preserve the great Smalltalk coding experience? [Inaudible] CHARLES: Ah, okay. DIRK: [Inaudible] and find all references, method-level history versioning, and so on. So, that was the input that got Eclipse kicked off. And one idea we had at that time, Eclipse is our opportunity to make everything right. And as we have seen now, when we did VS Code, we could even improve what we have [inaudible] at that time. So an example, in Eclipse we thought plugins are very cool and we have kind of a microkernel. And you load all of the plugins in the same process, they have a rich API, and so on, which is great. But we found over time, if you have lots of plugins and they do bad things and they run in the same process, it's not the best thing. CHARLES: Ah. Right. And so… DIRK: [Inaudible] have a different architecture. We believe now in isolation, separation. So, we now run extensions in separate process that communicates through RPC with the IDE so that we are in full control. And we can always say you can save the tool, save the document, no matter how bad a plugin behaves and decides to do an endless loop. Because in a separate process, the hope is still one CPU is open, available for you, that it can be safe from the other process. So, that's some example, right? Eclipse has done many things right, but the multi-process architecture I think is a major switch. And the other major switch is at Eclipse time you think Java is cool. Everything has to be in Java. CHARLES: Right. DIRK: No longer think like that, and that brings up this other topic of then the language servers that we can also talk at some point. CHARLES: Right, because that's the thing, is VS Code – now I've primarily been exposed to it through JavaScript and TypeScript development. But it really, it's designed to support all kinds of different languages. So, the C++ support is really good. The C support is really good. And I assume the Java support is really good. Is it safe to say? Because I only ever used Eclipse in the context of Java. Did Eclipse gain kind of a wider acceptance further beyond Java and C++? ERICH: Yeah. I think it's fair to say Eclipse has a rich ecosystem. Yeah. I think with all the tools. And it will be interesting to see that you can close the loop, because for Visual Studio Code, when you do Java development, you actually run Eclipse behind the scenes. That's how we kind of smiled at each other, Dirk and I, when he said, “Now we close the loop.” We started with all JavaScript and then we integrate Eclipse using this language server protocol and that's how we close the loop. CHARLES: Ah. DIRK: So maybe one thing I would like to add is that when you look at Eclipse and the tool and framework landscape that existed in the Java time, at that point in time when we started with Eclipse, it was very well-defined. There was Java. It was a well-defined set of libraries you were using and frameworks you were using. And if you look at the programming and tool landscape you have today, in months you see a new framework for JavaScript popping up or there's something else or another cool X, Y, Z thing. So, the tooling you build today has to be a lot more open to these new inventions, especially since they occur in a higher frequency than they did in the past. And that had influence on how we architected Visual Studio Code to give people a lower barrier of integrating their stuff into Visual Studio Code than you typically have in Eclipse. In Eclipse you needed to program in Java. With the LSP you can program in any programming language. In Eclipse, if you really want to try to do something nice with code complete and stuff like that, you had to hook up a lot of stuff. So, we raised that to another abstraction layer where we more talked about what people provide on data and we do a lot more for them in the user interface than compared for example to Eclipse, which lowers the barrier for people to integrate languages in Visual Studio Code than the barrier you had to integrate something in Eclipse. And so, [inaudible] for that one was that there are a lot more tools and programming languages out there that have importance than 10 years ago. ERICH: I'll give you an example. So, when we did C support in Eclipse, and it was also the team that seeded it. Of course, it took over and has now a great community behind it in Eclipse. But you wrote the C tooling in Java. And of course, that means you built the parser in Java and then of course, there are great C parsers around, C frameworks. But also it means you cannot dogfood what you write. You write Java but you don't program in C++. I think which is what makes VS Code so appealing is we are a very aggressive dogfooder. We want to use ourself and of course [inaudible]. That's why [inaudible] is very good. The C++ guide, they programmed C++ and they write in C++ so that's how they make it very good, that you have this feedback loop. CHARLES: And so, what's an example? We've talked about this low barrier of entry. So, if I were wanting to say, I do mostly programming in JavaScript. Let's say I wanted to add, I know all of this already exists, this infrastructure already exists, but let's say I wanted to add smart editing to JavaScript source files. What would that process look like for me as a JavaScript developer? DIRK: To be fair, whenever it comes to language services, it's never easy. But [inaudible] lower the bar. A language always means you have to do parsing, you have to do [9:59], type bindings. You have to make it fast, scale high up, and so on. So, this is never easy. But I think if you think about the different steps you can do, the first thing, let's not take JavaScript. Let's take a new language. CHARLES: Okay. DIRK: Your new cool language. CHARLES: Or maybe we take a Lisp or something where writing the parser is very easy. DIRK: Even that, you have to resolve symbols and so on. CHARLES: Okay, okay. DIRK: Even the parsing [inaudible]. But yeah, let's take a fancy language like Lisp or whatever. So, the first level I think is you want to get some nice coloring. That's the first level. CHARLES: Yes. DIRK: So, you get some coloring. And what we do there actually in VS Code is we tap into the community from TextMate. So, we use TextMate grammars to support colors in languages, which gives us access to a long [10:51 tail] of languages. So, to change the [10:54], if your language is not too exotic, you will find the grammar that describes how to color, what the tokens are in your language, and then you can get your language colored. That's step one. The next step is of course you want to get smarts like IntelliSense and so on. Ideally of course you can say, “Well, maybe there is something already around that has abstracted the parser and you can use this library.” CHARLES: Right. Because there actually are a bunch of JavaScript parsers written in JavaScript. I know I keep coming back to JavaScript, but let's assume with this language that we've got. I may not have to write a parser but I've got one. ERICH: You've got one, exactly. You've got one, right, and then technically it's not in the same language as the tool. So, that's why I don't want to go too much into JavaScript because for instance VS Code is written in TypeScript, which [transpiles] to JavaScript, which moves a little bit, makes it not as convincing as it could be. So, let's say it's a different language. Your fancy language is written, has a parser in your fancy language, which is different than the language of VS Code which is JavaScript. CHARLES: Right. ERICH: So, then the next level is to say, “Okay, well you have your code you encapsulate it in a server that you can talk to through some protocol.” And now the challenge is what protocol do you talk to? Typically in the language, the library you get, it will use some ASTs, symbols, type bindings. And what Dirk mentioned with lowering the bar is that assuming you have those ASTs, the way you talk then with our tool is through a protocol that is not at the level of the ASTs but at a higher level. CHARLES: A higher level than the ASTs. ERICH: No, yeah. A higher or simpler level. Let's give you an example. You want to find the definition of a symbol in your fancy language. The way the protocol works is you only tell it, in this document with the URI, at this position, I want to find the definition of the symbol that is this position. The request goes over the wire to the other process. Document URI, and the textual position. And what comes back of course now in the server you used AST, you find the symbol, you find the binding of the symbol which means it gives a definition for it. Of course you use your AST to analyze it. But then what gets back to send over the wire is yet another document, the reference, and the position. CHARLES: I see. So, you're really like pinpointing a point in just the raw bytes of the document. And you're saying, “Look, what is here?” And you just want to delegate that completely and totally to this other process. So, the IDE itself doesn't know anything about the document? ERICH: It knows about the document, right? CHARLES: I mean, it knows about the textual positions of the documents and the stream of characters, but not the meaning. DIRK: True. The smarts are in the server. And you talk to the smarts at the level of documents and positions. And the [good thing is] it's a protocol, is at this level it makes it easy to integrate into one editor, which is VS Code, but also into other editors. So, that's why we came up with the idea to have a common language server protocol which allows to provide a language not only for one editor but also for many editors. That was a challenge we had in VS Code. Remember when we started, we were kind of late to the game. We said, “VS Code should be in between an IDE and an editor.” But what we liked from an IDE is of course code understanding, IntelliSense. Go to definition, find all references. But how do you get that for a long tail of languages? We cannot do it all ourselves. So, we need to get a community to tap into. [Similar to] like TextMate grammars are kind of a lingua franca for coloring. So, we are looking for the lingua franca for language smarts. And that's what the language server protocol is, which means you can integrate it in different IDEs and once you've written a language server you can reuse it. CHARLES: I guess I've got two questions. What are the kind of things that I can do with a server that implements the language server protocol? And then I guess the – so we've talked about being able to find a reference. And is there a way you can incrementally implement certain parts of the protocol as you go along? ERICH: Yeah. DIRK: Yeah, basically you can. The protocol on the server and the client side talks about capabilities. The server can for example say, “I am only supporting code complete and go to definition and find all references.” And for example, something like, “Implementation hierarchy or document symbols or outline view is not supported.” And then the client adapts dynamically to the capabilities of the server. CHARLES: Okay. DIRK: That's one thing. And the set of capabilities is not fixed. So, we add them. We just added four or five new capabilities to the protocol last week. So of course, we listen to requests that come from other IDEs, what they would like to see in the protocols that we see in Visual Studio Code, we would like to extend. And that's the way we move the protocol forward. CHARLES: Okay. DIRK: It's capability-based and not so to speak version-based. So, [inaudible] versioning at the end of today. CHARLES: Right. You can incrementally say, “I'm going to have,” if I'm starting to write a server, I can say, “Well, I'm going to only start with just find definition at point.” And that's the only thing that my server can do. ERICH: Well, there are some basics, right? Keep in mind you have two processes. And once the user opens an editor, the truth is in the buffering memory on the one process. The basic thing you have to in a language, so you have to support the synchronization of [inaudible]. Once you open a file in the editor, then the truth in the buffer, and then you have to sync it over. CHARLES: Right. ERICH: [Inaudible] close the truth on the file system and you also have to tell this to the server. Because the server has to know where the truth is. DIRK: That's correct. These two open/close handshake methods and change methods, this is the minimum you have to implement. But for example, for Node itself, we provide libraries that help you with this. And the protocol is not very complicated. It's a buffer. Then it's change events. Either it's an insert, a delete, or an edit. CHARLES: So, let me try and get this straight in my head. I think I understand. The problem is that the VS Code, or your code editor, it's actually making changes to the buffer, and it needs to communicate those changes to the server. Or does the server actually make the changes itself? DIRK: The editor does make the changes. So, the protocol is spec'd in a way that as soon as an editor opens a document, the ownership travels from the server for the content to the tool. And the server is basically not allowed to read the state of that content from disk anymore, or get it [inaudible]. CHARLES: Aha. DIRK: Therefore, the client guarantees that everything the user does in that document is notified to the server, so that the server can move the document forward. CHARLES: Okay. DIRK: [Inaudible] we see the close event, that basically with the close, transfers the ownership of the document back to the language server. And it is allowed to re-read that content from disk if it wants. CHARLES: Okay. ERICH: Here, the protocol is really data-driven. Dirk mentioned that earlier, right? So, basically what flows between the server and the tool is data. So, what do we mean by data? You ask for IntelliSense or completions at the line. What follows is just the data. A list of completions that flows then from the server to the client. And then the client decides what to do with this data and decides to modify the document by inserting the completion proposed that the user selected. CHARLES: Right. And then if it decides to make any updates, it needs to send those to the server. DIRK: Exactly. CHARLES: So, if I actually insert the method that I want to call there, I'm going to be inserting nine characters, and I need to tell the server, “Hey, I just inserted nine characters to this document,” something like that? ERICH: Exactly. CHARLES: Okay. And so now how, because I remember now one of the coolest things about the class of tools of Eclipse that I hadn't really seen in the more lightweight editors – I went from Java, like so many of my generation went from Java to Ruby and then to JavaScript – once I moved out of the Java world, one of the things that I had come to expect from my tools was that they would help me make modifications to my codebase at a very high level. So, I would be able, if I had some class that was imported into say five modules in my codebase, I could say, “I want to change the name of this class,” and then it would find the references and then make the updates to those things. So, how do you manage that? So, if I have a class called ‘Person' that I want to change to ‘User', if I change it to ‘User' then it's going to break in those five different places unless I rename it to ‘User'. That's something that was very doable in the Java world. How do you keep the code editor, the tool I guess is what you were calling it, in sync? Like the server is going to make that change or does it just come back with data and says, “Here's the references if you wanted it to change”? ERICH: Yeah, yeah, yeah. So, two things you mentioned, right? Java and JavaScript or course. Java is a typed language which means you have better understanding of the code and what the reference is. In JavaScript which is typeless, you cannot know it as much, so that's actually why we developed also, we're using TypeScript. VS Code is actually [written] in TypeScript which allows you to do these kinds of things like refactorings. But if you look at the language server protocol, it has support for rename. And the way how rename is done is again it just documents positions. You say, “At this position, I want to rename the symbol with this other name.” And then you tell this to server and the server will handle the rename by giving you back a list of positions that need to be updated. CHARLES: Ah, okay. So now, I'm starting to understand what you're talking about when you say data-driven. It's literally just telling the tool – the tool proposes, “I want to do this rename.” And then the server provides all of the information that is required to actually do the rename. But it doesn't actually do the rename itself. It just provides the data. DIRK: A couple of reasons for it. The data effects, at the end of day, it's again, edit, and it's more or less the same edits the client sends to the server when the user types in the document. This is the protocol. On top of it, something that you can create a file or rename a file, this comes as a result back to the client. And then there, since it is a client/server architecture, the whole process is async. So, we have to give the client the change to revalidate if that edit structure that comes is still valid. If it is still valid, the client basically applies it. And by applying these edits to these documents, they will automatically flow back to the server until the client either closes these documents again or saves them. So, the reason being is that some of the tools may even show you a preview. You can only select some of them and apply them. So, there's always an interaction in these refactorings and to make that possible, as Erich mentioned, the whole protocol is data-driven. We don't go the server and say, “Okay, do that rename,” and he writes that back to disk. It computes a set of transformations to bring the current state of the workspace into that new state after the refactoring. CHARLES: I see. ERICH: [Inaudible] be fully transparent. Actually, no. Refactorings, Dirk [inaudible] refactorings for Eclipse so we can go deep on that. What we don't support right now in the protocol, we support edits in the buffer but when you want to rename a class in Java, you also want to rename the file. And that's something we're currently working on to support in the specification of the language server protocol. So, we don't have that yet. But we support code actions, quick fixes, that you like from Eclipse probably. And you can use then to do refactorings like extract method, extract constant or extract local variable, things like that you can do at the level of the language server protocol. CHARLES: Wow. That is… ERICH: I think [inaudible] right now. Let me go back to the Java thing. The Java language server actually has the support for refactorings. And there is now a language server protocol implementation of this Java provided by Eclipse. So, all the support you had in Eclipse for Java or most of the support is now also enabled in VS Code. CHARLES: Right. ERICH: [We don't] really have to reimplement it because you can reuse. And that's the big thought we have. You want to reuse language smarts as much as possible because they are so hard to implement. CHARLES: Right. And so, you can do that because you're providing this abstraction between the tool and the actual smarts, which is really, really cool. I do have to… how do you make it fast? Because you're describing this tool, this client and this server, and they're syncing. They're keeping this distributed state in sync and you know, how do you keep that from coming too chatty? Or is it something that you have to consider? Or is it just, maybe I'm overthinking it because I haven't dealt with it? DIRK: So, at the end of the day, it is chatty. But it is made performant in the way that it's very incremental and partly event-based. So for example, if you type in the document in the editor, you can either decide to [inaudible] sync the full content of the document, which we do not recommend but for some basic exploration, that is something people do. And we have [inaudible] the delta-encoded mechanism. So, we sync the buffer once and then after that you only get the edits the user does. These are chatty of course since the user types them, we debounce them and collapse them on the client side and only send them if we know that the server really needs to know them because we have another request we are asking the server or after a certain timeout. So, there are smarts behind it. But the protocol is kept performant by making it an incremental protocol at the end of the day, and not sending too much data back and forth. ERICH: Right. We don't serialize ASTs. We serialize positions, a list of items for completions. And actually, the transport is just JSON RPC. CHARLES: Okay. ERICH: And actually, someone, there is different usage now for language server protocol. And there is one host, Eclipse J, which brings it again back to Eclipse. They actually run language servers remote. CHARLES: Interesting. ERICH: And if you use it, you can run it on the browser, you get IntelliSense, and of course I guess it depends on how far away you are from the server. But it seems to work, according to feedback we've heard. CHARLES: Really? ERICH: The feedback we heard from them [is pleasant]. So, they use many of the language servers. CHARLES: So, is this a product that they have where the language server is running in the cloud and you send – your entire codebase essentially goes over to the language server and you can export the smarts to the cloud? ERICH: It's one step at a time. So, Eclipse J is kind of, they have what they call cloud workspace, which means the workspace is in the cloud. And [inaudible] code smarts of the workspace in the cloud, they can run the language servers in the cloud. It's a [inaudible]. One user has one workspace, has one language server. CHARLES: That sounds amazing. And if they can make it performant. ERICH: We have done cloud IDEs, right? If you look at the history from Visual Studio Code, you also had our stuff running in the cloud at some point. That's how we started. Before we pivoted to VS Code, we built – our exploration was, that's why the project is six years old. The first two years, we explored how far you can get coding done in the browser. CHARLES: Right. ERICH: And we had some [inaudible] there. CHARLES: So, I've played around with a lot of cloud IDEs and I've found them to be neat, because every few years it comes along. But yeah, it does seem that there are certain challenges that it's nice to have a client running and just be able to have the files locally. And is that a performance thing or if VS Code is written in TypeScript, theoretically it could run in a browser, right? ERICH: Of course. The [inaudible] there still runs in the browser. Then it's used by many tools that run in the browser. Like actually, if you want to edit your source code in the browser, there it's using the same editor that's running VS Code. So, that's how we started. Cloud IDEs, yeah we were at this point. We had our cloud IDE. We could edit websites in the browser, source control them, have a command line, deploy them. What we found is it's great for some scenarios like code reviews or doing small tweaks to files. But when it comes to really development, you use so many other tools. And you want to just have them. And [inaudible] a long tool chain problem. So, as a developer, you just want to use other tools as well. And that's why you can't have them all in the cloud. CHARLES: Right. ERICH: And [inaudible] we said at some point, it was a great lesson we had that you can program in the browser. But now we want to go to have a really [seven by 24] coding, you want to have a desktop experience. So, what we then did, we moved over the code we had run in the browser using a shell, the Electron shell, and can run it on the desktop. CHARLES: But there's theoretically, you could be running your language server for example in the cloud, but everything else on the desktop. ERICH: Yeah. Some people do that. DIRK: Right. CHARLES: Okay. Wow. It's crazy. It's heady stuff. We've talked about the barrier to implement the code smarts is much lower than it has been in the past. What kind of proliferation of code smart tools are there now that implement the language server protocol? Like how many different languages would you say have airtight…? DIRK: So now, [inaudible] time where we don't count anymore. You tell us a language and I can look it up, whether it's supported. Tell me a language and I can tell you whether – no, we have a website. CHARLES: Okay. DIRK: And when I look at it, we have about 40 languages. CHARLES: Wow. That's probably about, pretty much every mainstream language. DIRK: Yeah. I cannot find what isn't there. CHARLES: Yeah. It almost kind of begs the question, is this going to be the new bar for a language? Because I remember when I was starting out, really you just needed to have some interpreter or some compiler to have “a language”. And nowadays, it's not just the language. You need to have a command line tool for managing your dependencies. And you need to have a package system with a public repository where people can publish reusable units of code. And what's become expected out of a language to succeed has upped. Is having a language server implementation going to be part of the bar, the new bar, for “Hey, I'm thinking about creating a language”? I haven't really arrived until I have a package manager, I have a command line for resolving dependencies, I have documentation, and I have a language server. DIRK: I personally think that is our dream at the end of the day, to get there. We know about languages that do so. So, a lot of these language servers come for example from the people that developed the language. For example, the WASP guys, they do the compiler and they actively work on their language server as well. So, at the end of the day, the advantage of that approach since the WASP language server is written in WASP and runs in WASP, they can reuse so much code that they already have written in WASP. That's easy for them to package that up in the server and basically the people that maintain the compiler, at least the same team, maintains the language server at the end of the day. ERICH: And that's why we call [those] a win-win for the language provider. Because if you implement the language server using the language server protocol, then it can be integrated easily by the tool provider. And it's a win for the tool provider since there is a common protocol across all these languages you have to support. You can write an implementation once and again benefit and support many different languages, which makes the matrix problem one language support for each tool into more a vector, right? It reduces the matrix into a vector. You only write language servers that get integrated into different tools. CHARLES: Right. DIRK: And [inaudible] especially I think appealing for new languages that come out, because it lowers the bar for them to get into existing tools. Because if they write a language server speaking the language server protocol integrating that at the end of the day in Visual Studio Code is basically packaging up an extension for Visual Studio Code and writing 20 lines of code. CHARLES: Yeah. DIRK: And same [inaudible] for other IDEs that exist where people implemented the language protocol client side for the tool, for example. For vim or for Atom. CHARLES: Yeah. DIRK: So, new languages I think definitely, we see that trend go onto the language server protocol because that gives them an entry point into a large tool community. CHARLES: Yeah. I'm really excited about it. I'm actually an Emacs user. And that's actually how I found out about LSP, was in my Emacs newsfeed I saw that someone was starting on LSP support, and got digging into it. And I think that one of the problems that has plagued not only Emacs but all these editors is what you're describing where for example the JavaScript support was really great – is really great – in Emacs. There's refactorings. There's IntelliSense, code completion, all that stuff. But that's because someone wrote an entire JavaScript parser and code smart system in Elisp, which is just an absurd hurdle to jump over, to expected. And so, what you expect out of your editing experience, like when I went to try – if I were to go to try Python, well it's not nearly as good as what I'm expecting. And so yeah, I think it's exciting to hear what you're describing where with having some shared set of abstractions, you can offload all of that code smart onto the community that's building these new tools so that they're really easy to integrate into your environment. I think it's really exciting. Although it does make me ask – and I think we've got time for one more question – is we've been talking about all these different languages. Java, C++, JavaScript, TypeScript, Ruby, Python, et cetera, all these, the 40 languages that you talked about that have this implementation. What are the challenges that you've encountered trying to build abstractions that work for 40 different languages? All with their different syntax, all with their different conventions. It sounds like when aside from the fact that you've actually done it, I would say it's impossible. So, I'm curious. What were the unique challenges to solve there? DIRK: I think we already touched that at the beginning, the appealing stuff of the LSP is that it's not talking about the programming language itself. It's talking about things I can do with source code. For example, requesting code complete, go to definition, find all references. And the data that flows between the client and the server is not in terms of the programming language itself. It's about editor abstractions. We talk about documents and positions. We talk about edits that are applied to documents. We talk about snippets and stuff like that. And these abstractions, since they are programing-language-neutral, are a lot easier to implement for different editors. And the [inaudible] where the [inaudible] would speak AST nodes and symbols and functions and classes and methods, that at the end of the day, would not work. Because if I ask go to definition, the result is not a function or a variable definition. It's simply a position in the document with a hint which range to select. CHARLES: Okay. Yeah. ERICH: [Inaudible] places. In only a few places, we have to really abstract across languages. Like for instance, completions. When you do completions, you don't know, is it a variable? Is it a function or a method? That's where we have to abstract. But that's one of the few places. But again, it's an enumeration. DIRK: Yeah. And that's only to present an [icon]. ERICH: Yes. DIRK: It's only to give you a nice icon in front, because when you insert it, what comes back for completion item is basically a textual edit or a bunch of textual edits that when you select that completion item, we take these edits and apply them to the document buffer. And whether you edit a functional programming language or some other stuff, Prolog or whatsoever, it does not matter at the end of the day. CHARLES: Yeah. That simplicity, and treating it at that simple of a level is what unlocks all those superpowers. ERICH: It unlocks lowering the bar. But of course, if you look at some [of the demands], refactorings, whatever, they cannot easily be funneled. Not all of them can funnel to this low-level abstraction. Then of course, the criticism of the LSP protocol is that if you have already a very rich language service, you might not get it all through the LSP. DIRK: That's true. ERICH: And the [inaudible], that criticism we see of the LSP. But it's a tradeoff, like so many things in software. DIRK: Yeah. But what we learned there looking at different types of refactorings, it's more the set of input parameters that vary much between languages. The result of a refactoring can for every programming language that is at least document-based, [inaudible] in that lingo the LSP speaks. Because at the end of the day, it's textual edits to a document, right? ERICH: So, many people like LSP but there are people that don't like it. And people that have rich language services like IntelliJ, [Cool Tool], and [inaudible], even with LSP we would only get 20% of [our cool] features. Which is a little bit downgraded and not really true. But you see, it's a tradeoff. CHARLES: Right. ERICH: And if you want to [inaudible] language available broadly, I highly recommend it packaged as a language server. Your chances that it gets used, supported by different tools, is much higher than anything else. CHARLES: Right, right. So, it's kind of like, what's the UNIX thing? The universal text interface and how it seems counterintuitive but it actually just means you can literally compose anything. Because so few assumptions are made. ERICH: I would just recommend, [inaudible], go to the website that we have about the language server protocol. I'm pretty sure it will be in the introduction or whatever. It's microsoft.github.io/language-server-protocol and then you see the implementations, all the implementation of languages, who integrates language servers, and also what kind of libraries are available, if you want to implement your language server. DIRK: And a full specification. ERICH: And the specification is there as well. Yeah. CHARLES: Yeah. If you want to go ahead and do it yourself. Well, thank you so much, Erich. Thank you so much, Dirk, for coming on the show to talk about the language server protocol. It's very exciting to me and I think it's exciting for development in general because I just think by having – even if it's 20, 30, 50% code smarts for ever single language, just the billions and billions of hours that you are going to save developers over the next, over the coming years, it's a great feeling to think about. So, thank you for all your work and thank you for coming on the show. ERICH: You're welcome. DIRK: Yeah. It was fun talking to you. ERICH: Yeah. [Inaudible] CHARLES: Yeah. If people want to continue the conversation, is there a good way that they can get in touch with you? DIRK: Usually GitHub Issues. So, where the language protocol is, it's a project on GitHub. Simply find issues. We accept pull requests. I think that's the way we communicate. CHARLES: Awesome. Again, if you want to get in touch with us, you can get in touch with us at contact@frontside.io or you can reach out to us on Twitter. We're @TheFrontside. So, thank you everybody for listening. And we will see you next time.

Show Notes: 01:02 - Why outside-in development? 05:50 - Best Practices and Implementation 09:35 - API Iteration and Design 18:31 - Is outside-in development a timeless approach to software development? 24:10 - Outside-in Creation 28:37 - Summarizing Outside-in Development and What it means to the Frontside Resources: Sketch InVision Balsamiq pretender Ember CLI Mirage bigtest Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast episode 96. My name is Charles, I'm a developer here at the Frontside. And your podcast host in-training with me today is Jeffrey. JEFFREY: Hello. CHARLES: Hello, Jeffrey. And Arash. ARASH: Good morning. CHARLES: Yeah, how are you doing? ARASH: Doing great. Thank you. CHARLES: All right. So, today this is going to be a little bit of an internal powwow where we're just going to talk about some of the patterns that we see as we develop software and just kind of a little bit of a chat on the way we do it. So, we're going to be talking today, I guess we could do like a little bit of a spoiler and just kind of co lead with what we're talking about. ARASH: Which is... CHARLES: Which is... ARASH: Drum roll... CHARLES: Outside-In development. And it's kind of the way that we've just naturally gravitated towards, towards developing software here. ARASH: So first question is why we gravitated toward that. CHARLES: I could just tell you kind of our personal history on this. Is that, I guess it was, would you say like around 2007, something like that kind of the pattern of like REST services got like really well established. ARASH: Sure, that's accurate enough. CHARLES: Yeah. It's like around mid-2000's. And so people just went kind of, you know, cuckoo for Cocoa Puffs except APIs instead of Cocoa Puffs. So it was like all the talk was about your API, what's going to be your API, and how are you going to present this to the world? And oh my goodness, you're opening up your system for extension by developers and it's really fantastic. So, it kind of became the norm, I feel, from that point forward to be thinking about what is the API that I'm going to be presenting rather than what's the application. ARASH: That's your starting point. CHARLES: Yeah, that's your starting point. So a lot of development and getting like a lot of frameworks came along to make API development really simple, regardless of run time. It was really just really simple to just set up API. And so, a lot of people did that and I think there was value in that and that you're thinking kind of about your external domain model, like how you're going to present yourself to the world. And so you really are focused on the constraints and the abstractions that you want to present and how you want to hide all the messy complexity behind your system. But the problem that you get into is in those days, especially on the web, the clients were very closely aligned with the APIs. If you're coming like from a Rails backend, you almost had one for one between your pages and your API. If I've got a user's end point, I'm going to have a user's management page. And I think as clients became more stateful and more of the kind of interactions were ported over to the client, that synchronization and one to one mapping between what your API look like and what your interface look like, that started to crumble and disintegrate. And now I think that it's actually quite, I mean there are still clearly analogs because you're talking about the same entities. But your client is really now a full-featured application. And it's got complex rendering logic, it's got complex state management, it's got all these things that happened completely and totally separate from your API endpoints. JEFFREY: And your UI ends up being aware of relationships between models. So yeah, it's just so much more sophisticated than what we used to need to do when everything was server-side rendered. When you're dealing with a heavy client side app, your API needs to be quite a bit more flexible really. CHARLES: Right. And so what we were finding was that we'd often have to change the API significantly in order to support complex interaction on the client. But the problem is, is if you've started with your API, you've invested a lot of development, you've invested a lot of design and you've really laid down not just that design, but also the infrastructure and the operations to make it real, it can be very hard to change. And so, it can exclude a lot of the desirable interactions that you would like to have merely by virtue of the fact that it's set in stone. So I think that's kind of why we found ourselves... JEFFREY: Why we discovered that inside out wasn't quite working for what we're doing anymore. CHARLES: Yeah, exactly. It was like having a rock solid API was actually a drawback rather than an asset, whereas 10 years earlier it was an asset. And so it really, kind of having that insight made us step back and wind it back and say, "OK, where is the natural starting point? Where do we want to start?" ARASH: So philosophically, what does Outside-In development mean to the Frontside? JEFFREY: It means that instead of starting with the API, looking at actually the workflow is instead we start with what's the UI. What is the client side app going to look like and what are the needs of that client side app? And that drives the development of the API rather than solely, I guess you could say, the business models that would have previously been the initial driver for what that would look like. CHARLES: Right, exactly. Letting the business models be kind of a function of the desired interaction or the desired experience and then letting it proceed from there. So really is yeah, it's starting from kind of what does the person using your system going to touch rather than what is the computer using your system going to touch. ARASH: And so if one of our listeners is interested in Outside-in development, what kind of tenets would you recommend they follow and what are some of the best practices you can put into place to align well with this kind of thinking that we're talking about here? CHARLES: I think that's a good question because there's obviously the philosophy of it, but then there's the practice and the implementation and what does that mean. And there's a lot. There's a lot of just kind of the way you approach the problem and then the tools that you're going to use. I don't know, Jeffrey, which ones should we tackle first? JEFFREY: Let's tackle the tools. Why not? We'll go backwards. We probably should cover other things first, but why not? CHARLES: We'll tackle the tools? All right, and this is actually a question I want to throw your way too is at what point do you...because you want to start really with having a good design, like a good wireframe? Do you prefer to start with say like something in InVision or Sketch or do you like to proceed straight to a working implementation? JEFFREY: For me, it usually depends on how complicated of an app it's going to be. If it is something that's, I'm just dealing with like some crud operations, a lot of times I'll just go straight to the HTML and like starting to build that in actual JavaScript and we'll probably talk about the fake backend for that. But yeah, it versus something that's a little more complicated that has maybe a more novel approach or particularly interesting workflow or something that's going to be pretty difficult to code. That's when I'll start on in Sketcher, InVision, or a tool like that. CHARLES: I think in the last project, we used Balsamiq. I mean, we don't want to get caught up on like tools, but I think that's a great tool because the other thing we did is it wasn't just one designer doing it. We actually had all of our developers going and writing Balsamiq sketches for the features that they were going to be implementing because it really means that they're going to actually put themselves in the shoes of someone using it and they're going to be thinking about what it's like to be a user. Because they've got to start drawing the boxes and lines and the buttons that people are going to click in and the text fields in which they're going to communicate with the system. JEFFREY: And what was awesome about using a sketchy type of style like Balsamiq is that it removes the developers from thinking too much about having to make sure this headline is exactly the right font size, that I'm using all the exact right colors. Like, don't worry about that yet. Let's just get the wireframes in this sketchy style first and then we can work from there. CHARLES: Because it really is. It's very valuable to have this process for yourself as one single developer to be able to view it from the outside in. And I think that looking at it one way, that's truly what it means to be full stack is that you can put yourself in the shoes of every piece of the system at each point. So I can put myself in the user's shoes, I can put myself in the client's shoes. When I say 'client', like the actual browser, the browser's shoes. I can put myself in the server shoes and I can have that perspective of each part. JEFFREY: So that got me thinking about what browsers would wear what kind of shoes, but we'll leave that conversation for another time. Who'd wear the Chrome shoes? ARASH: Chrome is definitely Nike, for sure. Speed. JEFFREY: So back to the tool. CHARLES: Just like Safari, like Hugo Boss. ARASH: It's like, yeah, that's pretty close. Netscape is like K-Swiss or something like that. CHARLES: It's got to be some defunct brand. ARASH: BK Knights. JEFFREY: Mosaic is the LA Lights. CHARLES: Those were great. JEFFREY: So once I have this design, I'm starting to move to code and I'm starting to build some UI, how can I iterate on my API from there? Because I'm starting to actually build a real app, I want to connect to something, I need a data store. What can I do there? CHARLES: We've talked about this a lot, I think on this podcast, really over the years. And this is a technique that we got from the Ember community. There's a stack of fantastic libraries. There's Pretender which allows you to stub out XMLHttpRequests using a DSL, kind of like Node Express. And then based on top of that, there's basically an entire fake API layer which allows you to build, I would say it's not even really a stub at this point. It's like actually a prototype server implemented entirely in your browser. It's called Mirage. JEFFREY: So, you think about it, almost like starting in Sketch and then going to HTML. You're starting in some pretty simple JavaScript and then you're working your way up to what that API design looks like. CHARLES: Right. And so that lets you experience all of the nuance of API designs. So it comes with like you can experiment with different serialization formats, what are my property's going to look like? You can experiment with how do I load related data? So, if I've got a list of users and I want to get all of the comments that they've ever posted on my site, you might want to load those at the same time. So whether your API's going to support that and how it's going to support that, you can't really know until you actually have a consumer of that API. So what Mirage lets you do is it lets you consume an API you haven't written yet and you get to feel what it's like on the client and you get to make changes to that interface at a very, very low cost. So there's no deployed infrastructure, there's no automatically generated documentation. There's no real consumers yet. There's no multiple clusters running in the Cloud and it's very, very, very lightweight. It's just running right there in the browser. And so what that lets you do is if you have an insight about the shape of the API, it lets you validate that insight. Or if you have an assumption that you have about your API that actually is going to be detrimental to your experience, you get to have that assumption invalidated very quickly. And so at the backend of this process, you end up with a backend that is optimally shaped to serve the experience that you're shooting for. ARASH: So once you've got that, how do you reconcile it against is this a good API that I want to expose externally because maybe it's not. CHARLES: Like what do you mean? ARASH: Imagine that we've built the UI and we've iterated on the API in a fake stubbed way with Mirage or some similar tool and we've got to a state that we're pretty happy with, with the API design that works for this UI. Now, imagine we want that API to also be available to other things. CHARLES: Right. ARASH: How do we reconcile that? CHARLES: That's actually, I think that's kind of an open question right now, right? I mean, we don't really have a good answer to it because it is a stubbed API. And ultimately you're going to have a real API. So at some point, you do have to say like, this is the shape that I want. I'm going to go ahead and create these things and I need to make sure that those two APIs actually line up. Is that what you're asking is like, how do I make sure that they line up? ARASH: Sure. That's one piece of it. CHARLES: Oh, that's one piece of it. OK, so this is actually...we'll explore this process. This is actually like a problem, I think, with the stubbed approach is you have your set of stubs and then you have kind of the real McCoy which eventually will come along. So, it's great to have a server running inside the browser, but at some point you're going to need an actual server that's running in the Cloud. ARASH: Will you? Like what does the future hold? CHARLES: I mean, yes because the data needs to move, right? The data needs to move off your laptop. Honestly, Arash asked a good point if you're making an offline application. So if you're making an offline application, this actually allows you to bring a persistence architecture to the browser that is like every other... you don't have to make a special one off case. You can treat your backend like a backend. It's just running on the frontend. So that's probably a corner case, but it's worth pointing out that there used to be like back in the day, if you're using something like Microsoft Word or Excel or some other offline app, you can go a long way without having any internet connectivity, but you get to build it in exactly the same way. And then when you are ready to have internet connectivity, you've got the architecture in place. So, the future might not hold that and you might actually be able to use this in production. I would say it's a minority of cases. Most time you actually are going to want to have a server component. Let's say that you do, now you've got your real API and then you've got your prototype API that you run your tests against or that you're running against, and they need to line up because your frontend is going to be using both of them kind of throughout the development process. So there are a couple of strategies to deal with this. I'd say one is you run automated tests against both versions and that's a whole another subject of having testable APIs. Like most APIs that we have that we develop aren't set up to do end to end testing including a lot of the ones that we've written, although I think going forward now that we have a better handle on it, we can do that. We can definitely unpack that subject at some later point like making testable APIs. But I would say that the other strategy that you can use is use some sort of third party verification mechanism where you essentially record a bunch of interactions between your application and the fake API. And then you take those recorded applications and have them in some sort of repository and you can play them back on your real API and make sure that the responses generated by your real API for those recorded interactions to match up. So it's kind of like, I don't know, it's just a machine to make sure that the APIs stay in sync. ARASH: That's a domain that we need to get better at. CHARLES: Yeah. ARASH: We're only scratching the surface there. CHARLES: We're definitely only scratching the surface there. But the power of being able to develop without a real API first is enough so I think it makes the exploration warranted. There are some established tools in this space. The biggest one that I know of is called Pact. It's both a library and a repository. So it's kind of like got a...I don't know if there's a central server for it, but it's kind you record interactions, you upload them to a Pact server and then you can verify. So you can actually have a lot of consumers. And so, it's designed not only for making sure that your stubbed API works, but it's also for making sure that you just don't make breaking API changes. You can actually collect a lot of data about how people are using your API and then you can use that as a repository for when you make a change in your API to verify that'll work for all these other people. So if I'm just some random person or some random developer using your API, I can...kind of like how you record [inaudible] statistics and stuff to make the Apple experience better or whatever. It's very common for developers to ask, to record for certain anonymous data. You can submit anonymous data in the form of like Pacts. And so that can help an API developer verify whether the change they're going to make is going to break clients out there. So that's a little bit of a sidetrack there, but it's something that you start to think about a lot more when you start to develop in this fashion. ARASH: Did you feel like Outside-In development is a timeless approach to software development? CHARLES: I do. I feel like Outside-In, it actually even pervades more of software development than actually like the building the software. Like I feel that the longer you go in software development, you realize that the highest value activity is to front load understanding. So whether you're submitting a pull request, whether you're working on a work ticket, whether you're documenting code or even writing a method, the highest value activity that you can be engaged in, in each one of those points is understanding what the hell you're doing. ARASH: And why, too. Right? CHARLES: Yeah, exactly. Why? Understanding the motivation. What's your prime directive? What is the context on which you're entering into this piece of work? JEFFREY: I'm going to go with a bit of a contrarian approach. CHARLES: OK. JEFFREY: I'm going to go with a "maybe"... CHARLES: Maybe? JEFFREY: Maybe this is timeless. CHARLES: Maybe it's timeless? JEFFREY: Because I think historically, so much of software development was working with constraints. And the particular types of software that we're working on, the most important constraints are on the frontend. What does the end-user experience look like? But historically, that hasn't been the case. Historically, the primary constraints have been what can this technology stack that I'm working on actually do? CHARLES: Like what is the computer experience that I can support. JEFFREY: Yeah. And so that was actually the bulk of the work was like how can I actually get something that I want out of this giant machine in a room with me? So, maybe it is timeless, maybe not. But I think it is the way going forward. CHARLES: OK. So I agree that there's an interplay. There is kind of a yin and yang cycle. And I don't mean the cycle of we go to where we have to think about this and then we go to where we have to think about that. But I take your point, Jeffrey, but I think of something like Super Mario Brothers, which is I would say both a miracle of experience but also a miracle of technology in the sense that I think it was hand coded in Assembler on an 8-bit controller with who knows how much memory, the whole thing. So taking that into account, they had to think very strongly about what the computer could do at that point. They were operating under some just incredible constraints. But at the same time, they were thinking about what...they very clearly were focused on what is the coolest game that we can make at this point. So you're absolutely right. You have to hold both inside your head. You don't want to go crazy. I mean, we could sit down on the Balsamiq thing and be like, the first thing we're going to do is we want a VR room with...okay, no. Let's dial it back. JEFFREY: How do you wireframe VR? I've never seen anybody try do that. CHARLES: The Frontside Podcast episode 97: Wireframing VR. JEFFREY: Interesting. CHARLES: How we wireframe VR. So yeah. I agree. I take your point. You do have to hold both in your head at the same time. But I would say start with one a little bit and then see where that can take you, that the task of gaining understanding about what you're trying to build [inaudible]. JEFFREY: Yeah. CHARLES: If you try to understand what you're trying to accomplish, then you can try to push the tech stack towards that direction and maybe push a little progress forward. And then if you've accomplished something that you couldn't accomplish before, then you can start dreaming about even better experiences. And so kind of moving...like the wheels on He-Man's magic bus or whatever. JEFFREY: This is out of my domain. ARASH: I'm so [inaudible] backwards right now. JEFFREY: Our references are not timeless. CHARLES: Haven't you seen the...what's the one where he's like singing the song like the 4 Non Blondes song? And I said, hey, yeah, yeah. You haven't seen the He-Man, like the cover of 4 Non Blondes? ARASH: Oh, like they dubbed his... CHARLES: Yeah, no one's seen it? Oh, man. ARASH: It's starting to sound familiar. CHARLES: OK. I mean, this is like we're talking... ARASH: This is like 2006 internet? CHARLES: No, this is like 2010 internet. It's not the ancient past here. ARASH: I'm going through my internet filing cabinet in my brain right now. CHARLES: Okay. It had particular significance because the friends from attorney were also part of my childhood and I realized I'm unique in that aspect. But they basically, in those days they had the Hanna-Barbera cartoons were very cookie cutter, so they basically took the Mystery Machine from Scooby-Doo and they kind of re-colored it and they put like weird tank treads that like they put really funky kind of weird futuristic He-Man wheels on it. And it went from the Mystery Machine to He-Man's kind of a ride. ARASH: They repurposed all the illustrations. CHARLES: Exactly. Hey, you got to save time. ARASH: Save time somewhere. CHARLES: Doing your framework. ARASH: Kids need cartoons. CHARLES: That's right. So anyway, that's how the wheels on He-Man's Mystery Machine worked. ARASH: This has been interesting for me because when we first started this conversation, we're looking at it as Outside-In development. But we've talked so much here about design and creation that it almost starts to feel like Outside-In development is almost too narrow. Like it's really what we're talking about here is Outside-In creation of anything useful and valuable to people. CHARLES: Yeah. It's easy to overlook like whenever you want to create something, you get so focused on the actual building of it or the making of it happen that you kind of lose sight of where it is that you're going. And I think that sometimes it's important to be able to create without knowing where you're going to kind of push the paint around the canvas, so to speak. I think that's a valuable activity, like sometimes it's important to just code without really having any clear direction. You're just kind of following your instincts. Then it's the same way you look at Picasso's study in charcoal or whatever. There'll be like a picture of a horse leg and Picasso's like, "Oh, there's a horse leg. Man, how do I capture a horse leg?" And not really having much intent. And so that's important. But I think when you're building systems or you're creating something that you want to have a real lasting impact, you do need to consider it holistically and you really need to understand why it is that you're doing what you're doing. JEFFREY: Part of what's awesome about working in software is that unlike Picasso who had to start a new piece, we can keep working on the same piece and be able to paint over it multiple times. And you can start with that outline of like, "Hey, this is the vision that we see this particular thing going." But then don't make space for like, "Let's just push the paint around and see what happens in this little section," and that's fine. CHARLES: Yeah. And I think that because software is so malleable that it can end up capturing a lot of what is typically considered design. I think this has kind of also been a theme that we've talked about kind of over the last year or so is that over the last 20 years we've kind of seen software capture a lot of what were once separate practices. So when I was first starting out, it was quality. The line between QA and development was very stark certainly at the beginning of my career. And there was a fusion that was happening right as I joined of QA and development. And we saw basically the testing revolution, realizing the testing needs to be brought into the center of development, which needs to be put forth first if you want to have quality, be something that you want. And then, a revolution that I saw kind of in the middle of my career is seeing operations. It used to be certainly for many years into the beginning of my career, like the people who maintain the software were very different from the people who wrote it and there was a big divide there. And with the Dev Ops movement, it's kind of the realization that no, if we want to have healthy operations, we need to understand what healthy operations are at the very beginning and we need to like put them at the beginning of the process. And I think that what we're seeing now, maybe a revolution that hasn't quite happened yet, but we're on the cusp of is seeing design burrow its way to the heart of development where it's like we want something to be beautiful. We want it to be frictionless. We want it to be delightful to its end users. It needs to be there from the get go and developers need to be thinking about it. It's not someone else's responsibility. It's you as the primary creator. JEFFREY: It doesn't matter how elegant of an API you've created if the end user experience is just not there. CHARLES: Yeah. So it's all about tearing down. There's been a series of walls that have come down that I've witnessed. And so I think this is one that's in the process of crumbling. ARASH: So, this has been an awesome talk. How would you summarize Outside-In development and what it means to Frontside today and in the future? CHARLES: I think that it really is about making sure that the understanding is solid. That's the core piece, frontloading understanding, realized through a stack of tools. So the tools we use are some sketch and design tool. We'll sketch out the idea we really like, ask questions and try and understand it and firm up in our idea, like have a vision of what the experience is going to be like. Then the next step is to write some acceptance tests. So to define done, define what your criteria are going to be so that if I run these automated tests, the code will in fact realize the experience that I'm dreaming about. To do that, we've actually been assembling a suite of tools over the past year to do that and we've actually started releasing them to the world. So, it's still in a...I don't want to say alpha because we're using them in production systems, but it's much more of a work bench at this point than a framework, if that makes any sense. So we have about four related tools under the big test tent. We have interaction library for stubbing out, gestures, mouse clicks, keyboard events, scrolling. We have assertion library that works with any other source. It's really an assertion extension or extension wrappers to make your assertions impervious to asynchrony. We've extracted Mirage from Ember CLI Mirage so that you can use it in any project, React, Vue, Ember, what have you. You can check it out at big test. It is for early adopters right now, but it is in production systems and if you want to acceptance test anything, command line, back client, what have you, if you're willing to write some JavaScript, you can write those acceptance tests and have them be robust. And whatever experience you're trying to create, you can validate it with that. And so, that's why we created it. JEFFREY: And that's really a good marker of where we are in our experience with Outside-In development right now is we've been doing this in practice for awhile at this point and we're crafting tools to help us be even better at it and sharing those. CHARLES: Right. And so we're pretty excited about these tools because I think they bring solutions to a lot of the problems you're going to encounter. So there's a lot more work to do and we're excited to do it. Head on, check those out. And we'll go ahead and wrap up. Just a few quick announcements. If you're going to be at Assert(js) tomorrow, the Frontside is going to be there. I'm going to be there. Mr. Wil Wilsman is going to be there. So if you're there, please do give us a shout and we'll hang out. And then on the next podcast, we are really, really excited. I'm both nervous and I just can't keep a lid on it. We're going to have Erich Gamma on the podcast to talk about the language server protocol that he's been working on. If you don't know Erich Gamma, he's one of the Gang of Four that wrote The Design Patterns Book. He was the primary architect behind Eclipse and most lately VS Code. So, if you've used any of those projects or benefited from them, which I have benefited immensely from all three, it's going to be really, really exciting. So, that's something to look forward to. And with that, I will say goodbye to you, Jeffrey. JEFFREY: Ciao! CHARLES: And to you, Arash. ARASH: Adios! CHARLES: And everybody listening along at home or in your cars or cleaning your kitchen as I do when you listen to podcasts, we'll see you next time. If you want to get in touch with us, you can always give us a shout on Twitter, we're @thefrontside or you can drop us a line, contact@frontside.io.

本期节目由 Cryptape 赞助，Cryptape 是一家专注于区块链底层技术开发的公司，他们的产品 CITA 完全开源并且由 Rust 编写。他们正在招人，如果你对区块链技术有兴趣，或者是 Rust 或 C++ hacker, 欢迎你给他们投递简历, 简历请发到 hi@teahour.fm, 我会帮你做转发。 本期节目邀请到了 Peng Lyu, 他是微软 VSCode Team 的一线开发人员。为什么 VScode 比 Atom 快这么多？ 让他给我们娓娓道来。 Ruby Rogues MSDN Monaco Editor Erich Gamma Gang of Four (Design Patterns) CLion Visual Studio for Mac Xamarin Hyper Windows Subsystem for Linux Brackets Textmate Electron Atom Ctags A Brief Glance at How Various Text Editors Manage Their Textual Data Electron Piece Table LSP Transmit Codesandbox Anders Hejlsberg Sourcegraph Nuclide Special Guests: Howard and Peng Lyu.

Previous Episodes with Visual Studio Code’s Team: JSJ Episode 199, Visual Studio Code with Chris Dias and Erich Gamma JSJ Episode 221, Visual Studio Code with Wade Anderson 1:45 - What’s new at Visual Studio Code Visual Studio Code’s Twitter VS Code Github Chris Dias’ Twitter Chris Dias’ Github 3:42 - Confusion with Javascript versus separate languages 7:15 - Choosing your tools carefully 8:20 - Integrated shell and docker extensions 12:05 - Agar.io Extensions and extension packs 16:15- Deciding what goes into Visual Studio Code and what becomes an extension 18:20 - Using Github Issues and resolving user complaints 22:08 - Why do people stray away from VS proper? 23:10 - Microsoft and VS legacy 27:00 - Man hours and project development 31:30 - The Visual Studio default experience 37:10 - What are people writing with VS Code? 39:20 - Community versus developer views of VS Code 41:40 - Using Electron 44:00 - Updating the system 44:50 - How is Visual Code written? 48:00 - The future of Visual Code Studios https://github.com/microsoft/vscode/issues Picks: Don McMillan (AJ) Daplie Wefunder (AJ) Daplie (AJ) Facebook feed blocker plug-in (Charles) Tab Wrangler (Charles) Smart Things (Chris) Wood Pizza Ovens (Chis) PJ Mark, Chris’ friend and marketer (Chris)

Previous Episodes with Visual Studio Code’s Team: JSJ Episode 199, Visual Studio Code with Chris Dias and Erich Gamma JSJ Episode 221, Visual Studio Code with Wade Anderson 1:45 - What’s new at Visual Studio Code Visual Studio Code’s Twitter VS Code Github Chris Dias’ Twitter Chris Dias’ Github 3:42 - Confusion with Javascript versus separate languages 7:15 - Choosing your tools carefully 8:20 - Integrated shell and docker extensions 12:05 - Agar.io Extensions and extension packs 16:15- Deciding what goes into Visual Studio Code and what becomes an extension 18:20 - Using Github Issues and resolving user complaints 22:08 - Why do people stray away from VS proper? 23:10 - Microsoft and VS legacy 27:00 - Man hours and project development 31:30 - The Visual Studio default experience 37:10 - What are people writing with VS Code? 39:20 - Community versus developer views of VS Code 41:40 - Using Electron 44:00 - Updating the system 44:50 - How is Visual Code written? 48:00 - The future of Visual Code Studios https://github.com/microsoft/vscode/issues Picks: Don McMillan (AJ) Daplie Wefunder (AJ) Daplie (AJ) Facebook feed blocker plug-in (Charles) Tab Wrangler (Charles) Smart Things (Chris) Wood Pizza Ovens (Chis) PJ Mark, Chris’ friend and marketer (Chris)

Previous Episodes with Visual Studio Code’s Team: JSJ Episode 199, Visual Studio Code with Chris Dias and Erich Gamma JSJ Episode 221, Visual Studio Code with Wade Anderson 1:45 - What’s new at Visual Studio Code Visual Studio Code’s Twitter VS Code Github Chris Dias’ Twitter Chris Dias’ Github 3:42 - Confusion with Javascript versus separate languages 7:15 - Choosing your tools carefully 8:20 - Integrated shell and docker extensions 12:05 - Agar.io Extensions and extension packs 16:15- Deciding what goes into Visual Studio Code and what becomes an extension 18:20 - Using Github Issues and resolving user complaints 22:08 - Why do people stray away from VS proper? 23:10 - Microsoft and VS legacy 27:00 - Man hours and project development 31:30 - The Visual Studio default experience 37:10 - What are people writing with VS Code? 39:20 - Community versus developer views of VS Code 41:40 - Using Electron 44:00 - Updating the system 44:50 - How is Visual Code written? 48:00 - The future of Visual Code Studios https://github.com/microsoft/vscode/issues Picks: Don McMillan (AJ) Daplie Wefunder (AJ) Daplie (AJ) Facebook feed blocker plug-in (Charles) Tab Wrangler (Charles) Smart Things (Chris) Wood Pizza Ovens (Chis) PJ Mark, Chris’ friend and marketer (Chris)

Check out allremoteconfs.com to get in on all the conference action this year -- from the comfort of your own home!   02:13 - Chris Dias Introduction Twitter GitHub 02:21 - Erich Gamma Introduction Twitter GitHub 02:31 - Visual Studio Code @code 03:49 - Built on Electron JavaScript Jabber Episode #193: Electron with Jessica Lord and Amy Palamountain 04:25 - Why another tool? Visual Debugging Keybinding Support 08:12 - Code Folding 09:00 - Will people move from Visual Studio to Visual Studio Code? 12:06 - Language Support C# 18:06 - Visual Studio Code and Microsoft Goals 22:47 - Community Support and Building Extensions 28:31 - The Choice to Use Electron 32:41 - Getting VS Code to Work on the Command Line 35:02 - Tabs 38:49 - Visual Studio Code Uptake and Adoption 40:11 - Licenses 44:46 - Designing a UX for Developers 58:15 - Design Patterns Picks LEGO Star Wars: The Force Awakens Video Game - Announce Teaser Trailer (Joe) Firebase (Joe) Progress bar noticeably slows down npm install: Issue #11283 (Jamison) Darkest Dungeon (Jamison) Trek Glowacki Twitter Thread (Jamison) Mogo Portable Seat (Chuck) Clear Acrylic Wall Mountable 10 Slot Dry Erase Marker & Eraser Holder Organizer Rack (Chuck) Bitmap Graphics SIGGRAPH'84 Course Notes (Erich) Salsa (Chris) The Microsoft Band (Chris) Making a Murderer (Chris)

Check out allremoteconfs.com to get in on all the conference action this year -- from the comfort of your own home!   02:13 - Chris Dias Introduction Twitter GitHub 02:21 - Erich Gamma Introduction Twitter GitHub 02:31 - Visual Studio Code @code 03:49 - Built on Electron JavaScript Jabber Episode #193: Electron with Jessica Lord and Amy Palamountain 04:25 - Why another tool? Visual Debugging Keybinding Support 08:12 - Code Folding 09:00 - Will people move from Visual Studio to Visual Studio Code? 12:06 - Language Support C# 18:06 - Visual Studio Code and Microsoft Goals 22:47 - Community Support and Building Extensions 28:31 - The Choice to Use Electron 32:41 - Getting VS Code to Work on the Command Line 35:02 - Tabs 38:49 - Visual Studio Code Uptake and Adoption 40:11 - Licenses 44:46 - Designing a UX for Developers 58:15 - Design Patterns Picks LEGO Star Wars: The Force Awakens Video Game - Announce Teaser Trailer (Joe) Firebase (Joe) Progress bar noticeably slows down npm install: Issue #11283 (Jamison) Darkest Dungeon (Jamison) Trek Glowacki Twitter Thread (Jamison) Mogo Portable Seat (Chuck) Clear Acrylic Wall Mountable 10 Slot Dry Erase Marker & Eraser Holder Organizer Rack (Chuck) Bitmap Graphics SIGGRAPH'84 Course Notes (Erich) Salsa (Chris) The Microsoft Band (Chris) Making a Murderer (Chris)

Check out allremoteconfs.com to get in on all the conference action this year -- from the comfort of your own home!   02:13 - Chris Dias Introduction Twitter GitHub 02:21 - Erich Gamma Introduction Twitter GitHub 02:31 - Visual Studio Code @code 03:49 - Built on Electron JavaScript Jabber Episode #193: Electron with Jessica Lord and Amy Palamountain 04:25 - Why another tool? Visual Debugging Keybinding Support 08:12 - Code Folding 09:00 - Will people move from Visual Studio to Visual Studio Code? 12:06 - Language Support C# 18:06 - Visual Studio Code and Microsoft Goals 22:47 - Community Support and Building Extensions 28:31 - The Choice to Use Electron 32:41 - Getting VS Code to Work on the Command Line 35:02 - Tabs 38:49 - Visual Studio Code Uptake and Adoption 40:11 - Licenses 44:46 - Designing a UX for Developers 58:15 - Design Patterns Picks LEGO Star Wars: The Force Awakens Video Game - Announce Teaser Trailer (Joe) Firebase (Joe) Progress bar noticeably slows down npm install: Issue #11283 (Jamison) Darkest Dungeon (Jamison) Trek Glowacki Twitter Thread (Jamison) Mogo Portable Seat (Chuck) Clear Acrylic Wall Mountable 10 Slot Dry Erase Marker & Eraser Holder Organizer Rack (Chuck) Bitmap Graphics SIGGRAPH'84 Course Notes (Erich) Salsa (Chris) The Microsoft Band (Chris) Making a Murderer (Chris)

Get your JS Remote Conf tickets! Freelance’ Remote Conf’s schedule is shaping up! Head over here to check it out!   02:17 - Jessica Lord Introduction Twitter GitHub Blog 02:40 - Amy Palamountain Introduction Twitter GitHub Blog 03:14 - Electron Atom 04:55 - Cross-platform Compatibility 05:55 - Electron/Atom + GitHub 07:16 - Electron/Atom + React ? 07:57 - Use Cases for Electron muan/mojibar mafintosh/playback npm-scripts-gui Amy Palamountain: Building native applications with Electron @ Nordic.js 2015 15:09 - Creating Electron Apps on Phones 17:25 - Running a Service Inside of Electron   Visual Studio Code Adventures in Angular Episode #44: Visual Studio Code with Erich Gamma and Chris Dias 19:46 - Making an Electron App Photon conors/photon Photon Components N1 24:09 - Sharing Code 27:40 - Plugins for Functionality electron-accelerator electron-packager electron-prebuilt 31:08 - Keeping Up-to-date/Adding Features 33:14 - Pain Points NuGet 36:22 - Using Electron for Native JavaScript Jabber Episode #186: JSJ NativeScript with TJ VanToll and Burke Holland PhoneGap Reactive Native NativeScript 39:48 - What is a “webview”? 42:12 - Getting Started with Electron 43:28 - Robotics/Hardware Hacking with Electron JIBO Picks Autolux - Future Perfect (Jamison) Move Fast and Break Nothing (Aimee) [egghead.io] Getting Started with Redux (Dave) Destructuring and parameter handling in ECMAScript 6 (Dave) JS Remote Conf (Chuck) Freelance Remote Conf (Chuck) React Remote Conf (Chuck) Pebble Time Steel (Chuck) UglyBaby Etsy Shop (Amy) Jimmy Fallon: Kid Theater with Tom Hanks (Jessica)    

Get your JS Remote Conf tickets! Freelance’ Remote Conf’s schedule is shaping up! Head over here to check it out!   02:17 - Jessica Lord Introduction Twitter GitHub Blog 02:40 - Amy Palamountain Introduction Twitter GitHub Blog 03:14 - Electron Atom 04:55 - Cross-platform Compatibility 05:55 - Electron/Atom + GitHub 07:16 - Electron/Atom + React ? 07:57 - Use Cases for Electron muan/mojibar mafintosh/playback npm-scripts-gui Amy Palamountain: Building native applications with Electron @ Nordic.js 2015 15:09 - Creating Electron Apps on Phones 17:25 - Running a Service Inside of Electron   Visual Studio Code Adventures in Angular Episode #44: Visual Studio Code with Erich Gamma and Chris Dias 19:46 - Making an Electron App Photon conors/photon Photon Components N1 24:09 - Sharing Code 27:40 - Plugins for Functionality electron-accelerator electron-packager electron-prebuilt 31:08 - Keeping Up-to-date/Adding Features 33:14 - Pain Points NuGet 36:22 - Using Electron for Native JavaScript Jabber Episode #186: JSJ NativeScript with TJ VanToll and Burke Holland PhoneGap Reactive Native NativeScript 39:48 - What is a “webview”? 42:12 - Getting Started with Electron 43:28 - Robotics/Hardware Hacking with Electron JIBO Picks Autolux - Future Perfect (Jamison) Move Fast and Break Nothing (Aimee) [egghead.io] Getting Started with Redux (Dave) Destructuring and parameter handling in ECMAScript 6 (Dave) JS Remote Conf (Chuck) Freelance Remote Conf (Chuck) React Remote Conf (Chuck) Pebble Time Steel (Chuck) UglyBaby Etsy Shop (Amy) Jimmy Fallon: Kid Theater with Tom Hanks (Jessica)    

Get your JS Remote Conf tickets! Freelance’ Remote Conf’s schedule is shaping up! Head over here to check it out!   02:17 - Jessica Lord Introduction Twitter GitHub Blog 02:40 - Amy Palamountain Introduction Twitter GitHub Blog 03:14 - Electron Atom 04:55 - Cross-platform Compatibility 05:55 - Electron/Atom + GitHub 07:16 - Electron/Atom + React ? 07:57 - Use Cases for Electron muan/mojibar mafintosh/playback npm-scripts-gui Amy Palamountain: Building native applications with Electron @ Nordic.js 2015 15:09 - Creating Electron Apps on Phones 17:25 - Running a Service Inside of Electron   Visual Studio Code Adventures in Angular Episode #44: Visual Studio Code with Erich Gamma and Chris Dias 19:46 - Making an Electron App Photon conors/photon Photon Components N1 24:09 - Sharing Code 27:40 - Plugins for Functionality electron-accelerator electron-packager electron-prebuilt 31:08 - Keeping Up-to-date/Adding Features 33:14 - Pain Points NuGet 36:22 - Using Electron for Native JavaScript Jabber Episode #186: JSJ NativeScript with TJ VanToll and Burke Holland PhoneGap Reactive Native NativeScript 39:48 - What is a “webview”? 42:12 - Getting Started with Electron 43:28 - Robotics/Hardware Hacking with Electron JIBO Picks Autolux - Future Perfect (Jamison) Move Fast and Break Nothing (Aimee) [egghead.io] Getting Started with Redux (Dave) Destructuring and parameter handling in ECMAScript 6 (Dave) JS Remote Conf (Chuck) Freelance Remote Conf (Chuck) React Remote Conf (Chuck) Pebble Time Steel (Chuck) UglyBaby Etsy Shop (Amy) Jimmy Fallon: Kid Theater with Tom Hanks (Jessica)    

In questo nuovo episodio della serie Event Trailer, una serie centralizzata sulla pubblicizzazione di eventi di rilevanza nazionale, ma anche locale, parliamo dell'evento Microsoft più atteso degli ultimi 10 anni: Future Decoded.Il nostro ospite Roberto Andreoli viene intervistato da Massimo Bonanni "a domicilio", ovvero direttamente dagli studi della bellissima serie #TecHeroes per parlarci di questo evento, di grande importanza sia per chi fa parte dell'ecosistema Microsoft sia per chi non ne fa parte, in cui si avrà modo di raccontare tantissime tecnologie, declinate per ogni tipo di pubblico, che sia esso developer, IT implementer o studenti, che usi tecnologia Microsoft oppure no.Durante la puntata ci verrà presentata l'agenda dell'evento che, come vedremo, è composta da due grandi momenti: la keynote del mattino, che ospita, per la prima volta in Italia, Satya Nadella, CEO di Microsoft Corp., ma anche tanti altri ospiti di rilevanza internazionale, quali Carlo Purassanta e Fabio Santini, ma anche Giorgio Sardo, Amir Netz, Erich Gamma introdotti da Roberto Andreoli e le Tracks del pomeriggio che vedono protagonisti sia i Technical Evangelist che gli esperti delle Community. Inoltre, Roberto e Massimo ci presentano anche le altre attività parallele che animeranno il pomeriggio: Hands on Lab, Community Theatre e #TecHeroes. Infine ci parleranno di tutte le informazioni logistiche utili per iscriversi e raggiungere la bellissima location che ospiterà l'evento.Questa puntata, cosi come le altre registrate insieme a #Techeroes, sono disponibili ovviamente anche sul loro canale, qui trovate il webcast.Per iscriverti all'evento o per altre informazioni segui questo link.

Get your tickets for Angular Remote Conf! Enter the ng-conf ticket lottery!   03:44 - egghead.io Lukas' AngularJS Fundamentals egghead.io Course 04:58 - Pluralsight 06:26 - Code School: AngularJS Tutorial 06:38 - Dan Wahlin: AngularJS Fundamentals In 60-ish Minutes 06:52 - DEVintersection Conference 07:30 - Stack Overflow + Plunker 08:02 - Angular Remote Conf 08:50 - AngularConnect 08:58 - Onsite Training Oasis Digital 11:10 - Backends Lukas Firebase Node Ward Legacy Codebases Chuck Ruby RailsClips 14:09 - John Papa's Angular Style Guide 14:24 - Lukas’ Blog 15:04 - ng-newsletter 15:39 - ng-book 16:29 - Getting Started with Angular AngularJS.org 18:41 - Working with Designers Lukas Reubbelke: Just Enough Angular for Designers D3.js Adventures in Angular Episode #58: D3 with Aysegul Yonet 20:14 - Hack Reactor 20:42 - Angular Boot Camp 21:22 - Khan Academy 21:30 - Angular 2 Resources & Skills You Should Know Exploring ES6 by Axel Rauschmayer TypeScript Adventures in Angular Episode #41: TypeScript with Dan Wahlin JavaScript Jabber Episode #167: TypeScript and Angular with Jonathan Turner and Alex Eagle Visual Studio Code Adventures in Angular Episode #54: Visual Studio Code with Erich Gamma and Chris Dias Babel JavaScript Jabber Episode #171: Babel with Sebastian McKenzie Angular.io Angular Articles by Pascal Precht 25:54 - Podcasts JavaScript Jabber Angular Air 26:33 - Angular Unit Testing 27:22 - AngularJS on YouTube Picks Slack (Ward) The Pillars of Reality Series by Jack Campbell (Lukas) Angular Remote Conf (Chuck) Essentialism: The Disciplined Pursuit of Less by Greg McKeown (Chuck)  

Get your tickets for Angular Remote Conf! Enter the ng-conf ticket lottery!   03:44 - egghead.io Lukas' AngularJS Fundamentals egghead.io Course 04:58 - Pluralsight 06:26 - Code School: AngularJS Tutorial 06:38 - Dan Wahlin: AngularJS Fundamentals In 60-ish Minutes 06:52 - DEVintersection Conference 07:30 - Stack Overflow + Plunker 08:02 - Angular Remote Conf 08:50 - AngularConnect 08:58 - Onsite Training Oasis Digital 11:10 - Backends Lukas Firebase Node Ward Legacy Codebases Chuck Ruby RailsClips 14:09 - John Papa's Angular Style Guide 14:24 - Lukas’ Blog 15:04 - ng-newsletter 15:39 - ng-book 16:29 - Getting Started with Angular AngularJS.org 18:41 - Working with Designers Lukas Reubbelke: Just Enough Angular for Designers D3.js Adventures in Angular Episode #58: D3 with Aysegul Yonet 20:14 - Hack Reactor 20:42 - Angular Boot Camp 21:22 - Khan Academy 21:30 - Angular 2 Resources & Skills You Should Know Exploring ES6 by Axel Rauschmayer TypeScript Adventures in Angular Episode #41: TypeScript with Dan Wahlin JavaScript Jabber Episode #167: TypeScript and Angular with Jonathan Turner and Alex Eagle Visual Studio Code Adventures in Angular Episode #54: Visual Studio Code with Erich Gamma and Chris Dias Babel JavaScript Jabber Episode #171: Babel with Sebastian McKenzie Angular.io Angular Articles by Pascal Precht 25:54 - Podcasts JavaScript Jabber Angular Air 26:33 - Angular Unit Testing 27:22 - AngularJS on YouTube Picks Slack (Ward) The Pillars of Reality Series by Jack Campbell (Lukas) Angular Remote Conf (Chuck) Essentialism: The Disciplined Pursuit of Less by Greg McKeown (Chuck)  

Get your tickets for Angular Remote Conf! Enter the ng-conf ticket lottery!   03:44 - egghead.io Lukas' AngularJS Fundamentals egghead.io Course 04:58 - Pluralsight 06:26 - Code School: AngularJS Tutorial 06:38 - Dan Wahlin: AngularJS Fundamentals In 60-ish Minutes 06:52 - DEVintersection Conference 07:30 - Stack Overflow + Plunker 08:02 - Angular Remote Conf 08:50 - AngularConnect 08:58 - Onsite Training Oasis Digital 11:10 - Backends Lukas Firebase Node Ward Legacy Codebases Chuck Ruby RailsClips 14:09 - John Papa's Angular Style Guide 14:24 - Lukas’ Blog 15:04 - ng-newsletter 15:39 - ng-book 16:29 - Getting Started with Angular AngularJS.org 18:41 - Working with Designers Lukas Reubbelke: Just Enough Angular for Designers D3.js Adventures in Angular Episode #58: D3 with Aysegul Yonet 20:14 - Hack Reactor 20:42 - Angular Boot Camp 21:22 - Khan Academy 21:30 - Angular 2 Resources & Skills You Should Know Exploring ES6 by Axel Rauschmayer TypeScript Adventures in Angular Episode #41: TypeScript with Dan Wahlin JavaScript Jabber Episode #167: TypeScript and Angular with Jonathan Turner and Alex Eagle Visual Studio Code Adventures in Angular Episode #54: Visual Studio Code with Erich Gamma and Chris Dias Babel JavaScript Jabber Episode #171: Babel with Sebastian McKenzie Angular.io Angular Articles by Pascal Precht 25:54 - Podcasts JavaScript Jabber Angular Air 26:33 - Angular Unit Testing 27:22 - AngularJS on YouTube Picks Slack (Ward) The Pillars of Reality Series by Jack Campbell (Lukas) Angular Remote Conf (Chuck) Essentialism: The Disciplined Pursuit of Less by Greg McKeown (Chuck)  

We talk with Chris Dias and Erich Gamma about Visual Studio Code. Polyfill as a service. And at some point we'll talk about procrastination.

Don’t miss out! Check out Angular Remote Conf!   02: 10 - Will Buck Introduction Twitter GitHub AngularMN 02:57 - Membership & Attendance 04:48 - Starting a Group Dinners Code Katas Coworking 08:35 - Networking with Other Groups and Organizers 09:38 - Corporate Sponsors 10:35 - Prizes & Giveaways Amazing Prize-O-Tron JetBrains Frontend Masters Pluralsight O’Reilly Media egghead.io 13:54 - Advice for Creating Meetups Content Fishbowls Katas & Hacknights Social Hours Sponsorship Advertising Meetup.com Google Groups 19:47 - Topics & Speakers Hack Nights Best Practices Beginner Topics Lightning Talks Karaoke 27:11 - Getting Started in Rural Areas Remote Hangouts Nomad JavaScript 29:31 - Beginner Stories Ruby Rogues Episode #216: Code Review Culture with Derek Prior Arrogance vs Confidence Impostor Syndrome Scott Hanselman: I'm a phony. Are you? 39:04 - Land Grab Your Social Media Slack   Extras Adventures in Angular Episode #44: Visual Studio Code with Erich Gamma and Chris Dias Picks Galactic Civilizations III (Joe) Legendary Encounters: An Alien Deck Building Game (Joe) Good Mythical Morning Podcast (Katya) Coin (John) [Pluralsight] Introducing Visual Studio Code by John Papa (John) Angular Remote Conf (Chuck) Mastermind Groups (Chuck) Midwest JS YouTube Channel (Will) Last Week Tonight with John Oliver (Will) Heroes of the Storm (Will)

Don’t miss out! Check out Angular Remote Conf!   02: 10 - Will Buck Introduction Twitter GitHub AngularMN 02:57 - Membership & Attendance 04:48 - Starting a Group Dinners Code Katas Coworking 08:35 - Networking with Other Groups and Organizers 09:38 - Corporate Sponsors 10:35 - Prizes & Giveaways Amazing Prize-O-Tron JetBrains Frontend Masters Pluralsight O’Reilly Media egghead.io 13:54 - Advice for Creating Meetups Content Fishbowls Katas & Hacknights Social Hours Sponsorship Advertising Meetup.com Google Groups 19:47 - Topics & Speakers Hack Nights Best Practices Beginner Topics Lightning Talks Karaoke 27:11 - Getting Started in Rural Areas Remote Hangouts Nomad JavaScript 29:31 - Beginner Stories Ruby Rogues Episode #216: Code Review Culture with Derek Prior Arrogance vs Confidence Impostor Syndrome Scott Hanselman: I'm a phony. Are you? 39:04 - Land Grab Your Social Media Slack   Extras Adventures in Angular Episode #44: Visual Studio Code with Erich Gamma and Chris Dias Picks Galactic Civilizations III (Joe) Legendary Encounters: An Alien Deck Building Game (Joe) Good Mythical Morning Podcast (Katya) Coin (John) [Pluralsight] Introducing Visual Studio Code by John Papa (John) Angular Remote Conf (Chuck) Mastermind Groups (Chuck) Midwest JS YouTube Channel (Will) Last Week Tonight with John Oliver (Will) Heroes of the Storm (Will)

Don’t miss out! Check out Angular Remote Conf!   02: 10 - Will Buck Introduction Twitter GitHub AngularMN 02:57 - Membership & Attendance 04:48 - Starting a Group Dinners Code Katas Coworking 08:35 - Networking with Other Groups and Organizers 09:38 - Corporate Sponsors 10:35 - Prizes & Giveaways Amazing Prize-O-Tron JetBrains Frontend Masters Pluralsight O’Reilly Media egghead.io 13:54 - Advice for Creating Meetups Content Fishbowls Katas & Hacknights Social Hours Sponsorship Advertising Meetup.com Google Groups 19:47 - Topics & Speakers Hack Nights Best Practices Beginner Topics Lightning Talks Karaoke 27:11 - Getting Started in Rural Areas Remote Hangouts Nomad JavaScript 29:31 - Beginner Stories Ruby Rogues Episode #216: Code Review Culture with Derek Prior Arrogance vs Confidence Impostor Syndrome Scott Hanselman: I'm a phony. Are you? 39:04 - Land Grab Your Social Media Slack   Extras Adventures in Angular Episode #44: Visual Studio Code with Erich Gamma and Chris Dias Picks Galactic Civilizations III (Joe) Legendary Encounters: An Alien Deck Building Game (Joe) Good Mythical Morning Podcast (Katya) Coin (John) [Pluralsight] Introducing Visual Studio Code by John Papa (John) Angular Remote Conf (Chuck) Mastermind Groups (Chuck) Midwest JS YouTube Channel (Will) Last Week Tonight with John Oliver (Will) Heroes of the Storm (Will)

02:28 - Chris Dias Introduction Twitter GitHub 02:38 - Erich Gamma Introduction Twitter GitHub 03:38 - Visual Studio Code @VisualStudio [YouTube] Chris Dias: Visual Studio Code @ Build2015 IDE (Integrated Development Environment) Core Inner Loop Opinionated Workflow 06:25 - Task Running Support 09:13 - Cross-Platform 09:58 - Branding and Searchability #vscode UserVoice Site for Visual Studio Code Feature Requests 13:51 - Philosophically, what were the driving factors behind Microsoft releasing a cross-platform tool? 19:10 - Preview => Release Timeline Extensibility 22:04 - Core Features Multicursor Intellisense Debugging Lightweight Environment Project Structure TypeScript Integration 33:13 - Testing Problem Matchers 36:31 - Angular 1 Support 37:29 - Snippets 38:04 - Debugging Support 40:07 - Speed 41:00 - Features and Tooling (Con’t) Peek Find All References 45:40 - Getting the Latest Versions Auto-Update Windows Insider Program 47:13 - Visual Studio Code vs Sublime Text Picks Chris Dias, Erich Gamma and John Papa - Visual Studio Code: A Deep Dive on the Redefined Code Editor for OS X, Linux and Windows (John) Visual Studio Code Connect Link (John) Rob Eisenberg: Getting Started with Aurelia and TypeScript (Ward) Blue Man Group (Katya) ng-vegas (Joe) [YouTube] ng-vegas Channel (Joe) The CodeNewbie Podcast (Chuck) Ask Me Another (Chuck) [YouTube] Getting Started with Angular 2 Developer Preview (Chris) Jonathan Turner: Using TypeScript in Visual Studio Code (Chris) Emmet (Chris) The Computing Universe: A Journey through a Revolution by Tony Hey and Gyuri Pápay (Eric)        

02:28 - Chris Dias Introduction Twitter GitHub 02:38 - Erich Gamma Introduction Twitter GitHub 03:38 - Visual Studio Code @VisualStudio [YouTube] Chris Dias: Visual Studio Code @ Build2015 IDE (Integrated Development Environment) Core Inner Loop Opinionated Workflow 06:25 - Task Running Support 09:13 - Cross-Platform 09:58 - Branding and Searchability #vscode UserVoice Site for Visual Studio Code Feature Requests 13:51 - Philosophically, what were the driving factors behind Microsoft releasing a cross-platform tool? 19:10 - Preview => Release Timeline Extensibility 22:04 - Core Features Multicursor Intellisense Debugging Lightweight Environment Project Structure TypeScript Integration 33:13 - Testing Problem Matchers 36:31 - Angular 1 Support 37:29 - Snippets 38:04 - Debugging Support 40:07 - Speed 41:00 - Features and Tooling (Con’t) Peek Find All References 45:40 - Getting the Latest Versions Auto-Update Windows Insider Program 47:13 - Visual Studio Code vs Sublime Text Picks Chris Dias, Erich Gamma and John Papa - Visual Studio Code: A Deep Dive on the Redefined Code Editor for OS X, Linux and Windows (John) Visual Studio Code Connect Link (John) Rob Eisenberg: Getting Started with Aurelia and TypeScript (Ward) Blue Man Group (Katya) ng-vegas (Joe) [YouTube] ng-vegas Channel (Joe) The CodeNewbie Podcast (Chuck) Ask Me Another (Chuck) [YouTube] Getting Started with Angular 2 Developer Preview (Chris) Jonathan Turner: Using TypeScript in Visual Studio Code (Chris) Emmet (Chris) The Computing Universe: A Journey through a Revolution by Tony Hey and Gyuri Pápay (Eric)        

02:28 - Chris Dias Introduction Twitter GitHub 02:38 - Erich Gamma Introduction Twitter GitHub 03:38 - Visual Studio Code @VisualStudio [YouTube] Chris Dias: Visual Studio Code @ Build2015 IDE (Integrated Development Environment) Core Inner Loop Opinionated Workflow 06:25 - Task Running Support 09:13 - Cross-Platform 09:58 - Branding and Searchability #vscode UserVoice Site for Visual Studio Code Feature Requests 13:51 - Philosophically, what were the driving factors behind Microsoft releasing a cross-platform tool? 19:10 - Preview => Release Timeline Extensibility 22:04 - Core Features Multicursor Intellisense Debugging Lightweight Environment Project Structure TypeScript Integration 33:13 - Testing Problem Matchers 36:31 - Angular 1 Support 37:29 - Snippets 38:04 - Debugging Support 40:07 - Speed 41:00 - Features and Tooling (Con’t) Peek Find All References 45:40 - Getting the Latest Versions Auto-Update Windows Insider Program 47:13 - Visual Studio Code vs Sublime Text Picks Chris Dias, Erich Gamma and John Papa - Visual Studio Code: A Deep Dive on the Redefined Code Editor for OS X, Linux and Windows (John) Visual Studio Code Connect Link (John) Rob Eisenberg: Getting Started with Aurelia and TypeScript (Ward) Blue Man Group (Katya) ng-vegas (Joe) [YouTube] ng-vegas Channel (Joe) The CodeNewbie Podcast (Chuck) Ask Me Another (Chuck) [YouTube] Getting Started with Angular 2 Developer Preview (Chris) Jonathan Turner: Using TypeScript in Visual Studio Code (Chris) Emmet (Chris) The Computing Universe: A Journey through a Revolution by Tony Hey and Gyuri Pápay (Eric)        

Johannes Thönes talks with Erich Gamma, Ralph Johnson and Richard Helm from the Gang of Four about the 20th anniversary of their book Design Patterns. They discuss the following topics: the definition of a design pattern and each guest’s favorite design pattern; the origins of the book in architecture workshops; the writing of the book […]

Enregistre le 17 juin 2011 Etienne Juliot http://twitter.com/ejuliot Obeo http://obeo.fr Eclipse http://www.eclipse.org/ MDA http://en.wikipedia.org/wiki/Model-driven_architecture http://www.blackducksoftware.com/ Apache http://www.apache.org/ Eclipse Indigo http://www.eclipse.org/indigo/ Eclipse Gemini http://www.eclipse.org/gemini/ Eclipse Virgo http://www.eclipse.org/virgo/ http://dash.eclipse.org/ Eclipse Jetty http://www.eclipse.org/jetty/ Eclipse EclipseLink http://www.eclipse.org/eclipselink/ Eclipse ECF http://www.eclipse.org/ecf/ Eclipse RAP http://www.eclipse.org/rap/ SCA http://en.wikipedia.org/wiki/Service_Component_Architecture SDO http://en.wikipedia.org/wiki/Service_Data_Objects Hudson http://mmilinkov.wordpress.com/2011/05/04/hudson-now-at-eclipse/ Jenkins http://jenkins-ci.org/ Eclipse Tycho http://www.eclipse.org/tycho/ Eclipse Mylyn http://www.eclipse.org/mylyn/ Eclipse eGit http://www.eclipse.org/egit/ Eclipse jGit http://www.eclipse.org/jgit/ Eclipse Intent http://wiki.eclipse.org/Intent Eclipse Acceleo http://www.eclipse.org/acceleo/ Forte http://en.wikipedia.org/wiki/Forte_4GL JugSummerCamp http://sites.google.com/site/jugsummercamp/ Eclipse IDE http://www.eclipse.org/home/categories/index.php?category=ide  Eclipse WTP http://www.eclipse.org/webtools/ IntelliJ IDEA http://www.jetbrains.com/idea/ NetBeans http://netbeans.org/ Eclipse Orion http://www.eclipse.org/orion/ jQuery http://jquery.com/ Eclipse P2 http://www.eclipse.org/equinox/p2/ Eclipse 3.7 Eclipse WindowBuilder http://www.eclipse.org/windowbuilder/ NetBeans Matisse http://netbeans.org/features/java/swing.html Eclipse E4 http://www.eclipse.org/e4/ Erich Gamma http://en.wikipedia.org/wiki/Erich_Gamma Jazz https://jazz.net/ eXo IDE http://www.exoplatform.com/company/en/resource-viewer/Getting-Started-Guide/discovering-exo-cloud-ide Nous contacter Contactez-nous via twitter http://twitter.com/lescastcodeurs sur le groupe Google http://groups.google.com/group/lescastcodeurs ou sur le site web http://lescastcodeurs.com/ Flattr-ez nous (dons) sur http://lescastcodeurs.com/

IBM Distinguished Engineer and Jazz technical lead, Erich Gamma, talks with Michael O'Connell about the open development of the Jazz platform and where things are headed.

This episode is a conversation with Erich Gamma. We covered the four things he is known for in chronological order. We started with design patterns and the Gang-of-Four book of which he is the lead author. We then looked at JUnit, the testing framework he coauthored with Kent Beck and how it introduced unit testing to the masses. The next topic is obviously Eclipse, where Erich and his lab in Zürich is responsible for the Java Development Tooling. We also briefly discussed The Eclipse Way, the (obviously) successful process the Eclipse team uses for developing Eclipse itself. Finally, we're looking at Erich's current endeavour, the Jazz project. Jazz is a technology for collaborative software development.

This episode is a conversation with Erich Gamma. We covered the four things he is known for in chronological order. We started with design patterns and the Gang-of-Four book of which he is the lead author. We then looked at JUnit, the testing framework he coauthored with Kent Beck and how it introduced unit testing to the masses. The next topic is obviously Eclipse, where Erich and his lab in Zürich is responsible for the Java Development Tooling. We also briefly discussed The Eclipse Way, the (obviously) successful process the Eclipse team uses for developing Eclipse itself. Finally, we're looking at Erich's current endeavour, the Jazz project. Jazz is a technology for collaborative software development.

This episode is a conversation with Erich Gamma. We covered the four things he is known for in chronological order. We started with design patterns and the Gang-of-Four book of which he is the lead author. We then looked at JUnit, the testing framework he coauthored with Kent Beck and how it introduced unit testing to the masses. The next topic is obviously Eclipse, where Erich and his lab in Zürich is responsible for the Java Development Tooling. We also briefly discussed The Eclipse Way, the (obviously) successful process the Eclipse team uses for developing Eclipse itself. Finally, we're looking at Erich's current endeavour, the Jazz project. Jazz is a technology for collaborative software development.