Podcasts about clojurescript

SEASON 3 LETZ GO! Thank you to sponsors: Clojurists Together, Nubank, Zane Shelby, Dustin Getz, Robert Randolph and superuser Hey Friends! We're back! email `heylilpodcast@gmail.com` if so inclined or you'd like to suggest a guest for this season. Summary: Hang out with me and my buddy David Nolen. We learn about his background in film and music, his interest in interactive media, and his journey into programming. We learn how and why he creates a musical environment at home. Plus the story on discovering Clojure and ClojureScript.He shares the challenges of maintaining an open-source project and we reflect on the masochistic nature of software development and the importance of experience in making pragmatic decisions. He expresses pride in his open source work and emphasizes the value of simplicity in tooling. The conversation concludes with a discussion on the balance between providing hand-holding and catering to experienced users. Keywords: film, music, interactive media, programming, performance, improvisation, teaching music, Clojure, ClojureScript, new media, Lisp, Clojure, ClojureScript, open-source, software development, experience, pragmatism, simplicity, tooling Produced by: L. Jordan Miller Intro & Outro track: "CrabbyPatties" by L. Jordan Miller

Mark Wardle, Chief Clinical Information Officer, and Vaughn Vernon discuss the intersection of healthcare and technology. Mark emphasizes the need for technology to improve patient care and the challenges of integrating digital systems in healthcare.Mark also highlights the importance of Domain-Driven Design in healthcare, as it allows for a more patient-centered approach and better communication between clinicians and patients. He discusses the limitations of current electronic health records and the need for tools that support continuity of care. Mark believes that technology should be used to enhance the human connection in healthcare and improve patient outcomes.Mark discusses the application of Domain-Driven Design (DDD) in healthcare and its potential to address the complexity and challenges in the industry. He emphasizes the need to break down healthcare systems into modular components and build them based on a shared understanding of the domain. Wardle highlights the importance of technical standards, interoperability, and the use of common models to decouple systems and improve integration. He also discusses the role of open source in healthcare and the potential for disruptive innovation. Wardle envisions a future where technology enables faster iteration, better orchestration of clinical pathways, and improved decision-making in healthcare.TakeawaysTechnology has the potential to greatly improve patient care in healthcare.DDD is crucial in healthcare to create a patient-centered approach and improve communication between clinicians and patients.Current electronic health records are often not user-friendly and do not support continuity of care.Technology should be used to enhance the human connection in healthcare and improve patient outcomes. Domain-Driven Design can help address the complexity and challenges in healthcare by breaking down systems into modular components and building them based on a shared understanding of the domain.Technical standards and interoperability are crucial for decoupling systems and improving integration in healthcare.Open source has the potential to disrupt the healthcare industry by providing foundational building blocks and higher-value tools.Improving orchestration of clinical pathways and decision-making in healthcare can be achieved through the use of technology and data-driven approaches.Faster iteration, better integration, and improved decision-making can lead to a learning health and care system that continuously improves patient outcomes.Mark WardleMark is a Consultant Neurologist and Chief Clinical Information Officer in the UK. He is also a keen software developer, building a range of clinician and patient-facing applications, most recently preferring to work in Clojure and ClojureScript. He thinks digital technologies should play a fundamental role in improving and transforming health and care with Domain-Driven Design playing a key role in unbundling the electronic patient record, and turning what we think of as health applications inside-out. Hosted on Acast. See acast.com/privacy for more information.

We try out the most secure messaging app in the world, and Wes' new note system that's so great you'll want to abandon your current one.

Richard talks with David Nolen, lead developer of ClojureScript, about the rituals that emerge in different programming communities, among many other topics!

Peter Galison, Image and Logic: A Material Culture of Microphysics, 1997Brian Marick, An Outsider's Guide to Statically Typed Functional Programming, unfinishedBrian Marick, Lenses for the Mere Mortal: Purescript Edition, unfinishedProgramming languages: Clojure, ClojureScript, Elixir, Elm, PurescriptCreditsPhoto of proton-antiproton collision from UA5 collaboration, CERN, Public domain, via Wikimedia Commons.

"on a fait un POC en React et un POC en Angular. On a gardé le POC en React" Le D.E.V. de la semaine est Sebastien Lorber, créateur de ReactHebdo et contributeur principal de Docusaurus. Il va s'en dire que Sébastien est un peu la référence sur React en France en ce moment. Qui de mieux donc pour nous raconter l'histoire de ce framework qui a permit à JS de conquérir un nouveau territoire ! Après le back-end, le JS devient la techno mobile à la mode. Sébastien nous démontre aussi comment React peut être utilisé pour tout type de projet ! A quand le JS dans l'aéronautique ?Liens évoqués pendant l'émissionNewsletter: ReactHebdo.frTwitter: @sebastienlorberGithub: @slorberSite web: sebastienlorber.comLinkedin: https://www.linkedin.com/in/sebastienlorber/FaxJS: ancêtre de ReactThe Future of JavaScript MVC Frameworks: blog post fin 2013 par le créateur de ClojureScript qui a mis en évidence l'avantage de l'immuabilité coté frontend avec ReactMJML-React: pour rendre des emails en React coté serveurRemotion: pour créer des vidéos en ReactReact-Native-Web: permet de facilement utiliser React-Native sur le web (utilisé par Twitter et plein d'autres grosses boites)Hooks, Dependencies and Stale Closures: article intéractif qui explique bien le problème de stale closure souvent rencontréQwik: framework concurrent à React, créé par le créateur d'Angular Autres liens cool mais pas vraiment mentionnés:- React-Three-Fiber: pour faire de la 3D (ThreeJS) avec React- React-Native-Skia: pour utiliser le moteur 2D Skia (Chromium, Android, Flutter, ChromeOS, Fuschia...) dans React-NativeMeme tabs vs space :Dhttps://twitter.com/ddprrt/status/1212843901507252225 **Continuons la discussion**@ifthisthendev (https://twitter.com/ifthisthendev)@bibear (https://twitter.com/bibear)LinkedIn (https://www.linkedin.com/company/if-this-then-dev/)Discord (https://discord.gg/FpEFYZM)** Plus de contenus de dev **Retrouvez tous nos épisodes sur notre site https://ifttd.io/Nous sommes aussi sur Instagram, TikTok, Youtube, Twitch ** Essayez Masteos **Masteos c'est l'API de votre investissement immobilier ! Et grâce à IFTTD, ils vous offrent 6 mois de gestion locative** Cherchez l'équipe de vos rêves **Si vous avez envie de changer de job, testez My Little Team qui vous permet de choisir une équipe qui vous ressemble plutôt qu'une entreprise sans trop savoir où vous arriverez !https://www.mylittleteam.com/ifttd** La Boutique IFTTD !!! **Affichez votre appréciation de ce podcast avec des goodies fait avec amour (https://ifttd.io/boutique/) ou affichez clairement votre camp tabulation ou espace.** Soutenez le podcast **Ou pour aller encore plus loin, rejoignez le Patréon IFTTD.** Participez au prochain enregistrement !**Retrouvez-nous tous les lundis à 19:00 pour assister à l'enregistrement de l'épisode en live et pouvoir poser vos questions pendant l'épisode :)

Furkan on Twitter - https://twitter.com/furkan3ayraktar Furkan on GitHub - https://github.com/furkan3ayraktar Scrintal - https://www.scrintal.com Scrintal's story explained in Scrintal - https://beta.scrintal.com/b/final-scrintal- board--jtult Polylith - https://polylith.gitbook.io/polylith/ Polylith is a software architecture that applies functional thinking at the system scale. It helps us build simple, maintainable, testable, and scalable backend systems. Datomic Cloud - https://docs.datomic.com/cloud/ A transactional database with a flexible data model, elastic scaling, and rich queries. Reagent - https://github.com/reagent-project/reagent A ClojureScript wrapper around React. Re-frame - https://github.com/day8/re-frame Frontend framework that provides events for writes and subscriptions for reads. Datascript - https://github.com/tonsky/datascript/ An immutable in-memory database and Datalog query engine in Clojure and ClojureScript. Prosemirror - https://prosemirror.net A toolkit for building rich-text editors on the web KonvaJS - https://konvajs.org HTML5 canvas library for desktop and mobile applications Posh - https://github.com/denistakeda/posh Use Datascript to store application state Re-posh - https://github.com/denistakeda/re-posh Use Posh with re-frame subscriptions and events Firestore - https://firebase.google.com/docs/firestore Scalable NoSQL cloud database to store and sync data for client- and server-side development. stitches - https://stitches.dev CSS-in-JS with near-zero runtime, SSR, multi-variant support, and a best-in-class developer experience. shadow-cljs - https://github.com/thheller/shadow-cljs everything you need to compile your ClojureScript code with a focus on simplicity and ease of use.

Hello and welcome to another episode of WHAT the Data?! Podcast, and today we have for you a great episode with Yehonathan Sharvit. Yehonathan in this episode helped us to understand what is data-oriented programming, how can you use it, and in general an intro to why it is important to adapt the method.Yehonathan Sharvit has been working as a software engineer since 2000, programming with C++, Java, Ruby, JavaScript, Clojure, and ClojureScript. He currently works as a software architect at Cycognito, building software infrastructures for high-scale data pipelines. He shares insights about software at https://blog.klipse.tech/, writes technical books, speaks at conferences, and leads Clojure workshops around the world. He is the author of Data-Oriented programming, published by Manning. Yehonathan is passionate about making interesting things easy to understand.What's the big deal with Data-Oriented programming?Is it a new paradigm? And in what languages is the paradigm applicable?Tune in to this amazing episode and we hope you will enjoy it as much as we didIf you want to get to know our guests, even more, you can follow here: Linkedin:  https://www.linkedin.com/in/viebel/Twitter: https://twitter.com/viebelBlog: https://blog.klipse.tech/Book: https://www.manning.com/books/data-oriented-programming-------Give us feedback - https://forms.gle/sTbkzHPUo86nqM6y8Interested in joining our podcast as a guest? Fill the following form https://forms.gle/gV6hobxNmBgfdDoa6Join our mailing list - https://bit.ly/2MXfK8YYou can follow us on social media Facebook: https://www.facebook.com/whathedata/Linkedin - https://www.linkedin.com/company/what-the-data-podcastHave a data-related question? Submit it here: http://bit.ly/3rj5VBYAs always if you enjoyed this episode, please like, subscribe, and share it with your network so we can outreach new audiences.

Matheus Marsiglio é desenvolvedor de software e entusiasta de design. Está na área, profissionalmente, desde 2010 e já trabalhou com JavaScript, Ruby, CoffeeScript, TypeScript, Go, Rust, Clojure e ClojureScript. O Matheus também foi instrutor do Nanodegree de React da Udacity, instrutor no SENAI e durante a maioria da sua carreira trabalhou em startups desde em estágios bastante iniciais até lugares próximos de break even. Atualmente está na Runops tentando melhorar a vida de desenvolvedores de software e DevOps, enquanto leva uma vida dupla de ciclista e montador de bicicletas. Links Twitter do Matheus Livros Dicurso do Metodo e Ensaios Uma breve história da economia OsProgramadores Site do OsProgramadores Grupo do OsProgramadores no Telegram Canal do Youtube do OsProgramadores Twitter do Marcelo Pinheiro Edição do Episódio por: Thiago Costa Barbosa (thiagocostabarbosa@live.com)

Lloyd Wahed met with David Jarvis, Founder and CEO of Griffin on the latest Searching for Mana podcast where they discussed the challenges of being the fintech's OS for embedded finance.Griffin is building a Banking as a Service (BaaS) platform to support the fintech ecosystem, and as a new player it can look forward rather than having to be slowed by legacy. The best supplier is one that enables you to do what you do best, and that will support you with an expertise that you don't have and don't need to have. Businesses rely on complex services that they cannot possibly always be experts in. Finance, Technology, Recruitment, Law and so many other fields of specialist knowledge can be bought as a service that is leading-edge, compliant, cost-effective and user friendly. That is what Griffin is bringing to the rapidly expanding and entrepreneurial world of fintech. They enable fintech's through operating solutions for embedded finance. They build the tech stack and create the products and services their clients will need. For every solution, they create there is a product to be defined and marketed externally.David shares with us that Griffin can look forward in order to build what clients will need, not what they have needed, so new operators hit the ground running with Griffin solutions. Driving this is a team of experts, constantly building their intellectual property and domain expertise, tech nerds and professionals with authorisation experience. From there, the conversation dives into David's background and how he grew up partly in Japan, UK and US, and how he learnt about finance from his father and how that world works in those different cultures. We learn about the family's strong work ethic and entrepreneurial streak that David reflects on. He became an analyst, who learnt coding and became a software engineer in Silicon Valley with the likes of Airbnb or CircleCI. He has added to this background the ability to define a vision based on his view of how the middleware market can be better and he has the energy and intellect to drive a solutions business, build a team and attract the funding they need. David has taken full advantage of a favourable environment in the UK to build a banking business and looks set to change the world of Banking as a service.David's book on ClojureScript language: https://www.oreilly.com/library/view/learning-clojurescript/9781785887635/

[קישור לקובץ mp3] שלום וברוכים הבאים לפודקאסט מספר 420 של רברס עם פלטפורמה - זהו באמפרס מספר 76. התאריך היום הוא ה-14 בספטמבר 2021, ואנחנו מקליטים באולפן הוירטואלי שלנו - רן, אלון ודותן - שלום!אז באמפרס זו סדרה של קצרצרים שבה אנחנו מספרים על מה שמצאנו ומעניין בשבוע או בחודש האחרון - לפעמים בחודשים האחרונים אם התעכבנו - ברחבי האינטרנט: Repos מעניינים ב-GitHub, בלוגים מעניינים, פרוייקטים, Utilities ודברים אחרים. אז אני אתחיל, כמיטב המסורת . . .רן - אז האייטם הראשון שלי נתרם למעשה בעבר הרחוק ע”י מיקי טבקה - תודה מיקי! - וזה איכשהו נעלם בארכיון, אז הנה אני מציף את זה שוב: זה איזשהו בלוג-פוסט מעניין שנקרא No Meetings, No Deadlines, No Full-Time Employeesזה בעצם בלוג-פוסט שמספר על איזושהי חברה, סטארטאפ, שהתחיל כמו כל סטארטאפ אחר . . . התחיל בגיוס של כסף וגיוס עובדים . . .לסטארטאפ קוראים Gumroad - זו איזושהי פלטפורמה ל-Creatives, לייצר תוכן . . . אני בטוח שזו לא הפלטפורמה הראשונה בתחום.בכל אופן - התחילו, ייצרו את הפלטפורמה - ולאט לאט נגמר להם הכסף . . . באיזשהו שלב כולם פוטרו, אבל הסטארטאפ המשיך לגדול . . .הסטארטאפ בשיאו הגיע למשהו כמו 25 עובדים, אבל הוא פיטר את כולם והוא [המייסד] נשאר העובד היחיד - ומאז הוא למעשה שכר את כולם אחד-אחד - כ-Freelancers, “עובדים שעתיים” - פחות או יותר את אותם העובדים שהיו לו מקודם.פה בבלוג-פוסט הזה הוא מספר את סיפור חייו של הסטארטאפ, ואני חושב שזה מעניין - מעיין אנטי-תזה לתרבות העבודה שקיימת היום - עם כל ה-Disclaimer-ים שיש:זה לא בהכרח יעבוד לכם - הוא בא ואומר “זה הצליח לנו - אבל בטעות, לא כי תכננו”.אבל זה מצליח - הסטארטאפ היום גדל, אני חושב שיש לו מחזור של משהו כמו 11 מיליון דולר, שזה מכובד בשביל צוות של משהו כמו עשרים-ומשהו אישעוברים דרכו משהו כמו 170 מיליון דולר של המשתמשים שלווהמאפיינים של תרבות העבודה הם כמו שאמרנו מההתחלה - אין שם פגישות, אין דד-ליינים ל-Features, כל התקשורת היא א-סינכרונית - הדבר הראשון שהעובדים עושים זה לכבות Notifications . . . לא להתקין שום דבר על המובייל, לכבות Notifications בכל מקום, לעיתים רחוקות מאוד להשתמש ב-Slack כשצריך - ורוב התקשורת היא דרך GitHub ואני חושב ש-Notion או איזושהי פלטפורמה אחרת.אבל הכל א-סנכרוני וב-Latency של 24 שעות או יותר - וטוב להם, והם מצליחים.אז זהו - אני חושב שזה סיפור מעניין, סיפור יזמי מעניין - בטח לא הסיפור הטיפוסיאולי קצת בא להעלות את הנושא של עבודה מרחוק והאיזון של Work-Life-Balanceזהו סיפור מעניין - מזמין אתכם לקרוא, הקישור ב-Show notes [כאן, הכוונה].(אלון) “הפינה הזו הייתה בחסות רן תבורי, תומך נלהב בעבודה מהבית . . .”שמע, כן - זה עובד, כמו שאמרת - זה כנראה עובד במקרה, זה עובד בסוג מאוד ספציפי של חברותוגם, בוא - אני לא מזלזל, אבל זה לא Billion-Dollar-Company כמו שכל אחד מדמיין בראש . . .(רן) ממש לא, והוא לא מנסה ככה לקפוץ גבוה מדי - הוא אומר: “תשמעו, אנחנו לא הולכים להיות Billion-Dollar-Company, אנחנו לא מכוונים לשם ואנחנו לא רוצים את זה - אבל אנחנו כן מחפשים את האיזון שמתאים לנו, וכל אחד עובד מתי שמתאים לו ולא עובד מתי שלא מתאים לו - ובהתאם לזה הוא גם מקבל את הכסף”.דרך אגב, גם המשכורות שלהם מפורסמות - הם יודעים כמה כל אחד מהם מרוויח לשעה, החל מ-$50 עד $250 לשעה, בהתאם לתפקיד - אז יש פה גם את האלמנט של השקיפות, שהוא יחסית חריג.אולי את זוכרים את Buffer, שפעם פרסמו את טבלת המשכורות שלהםאבל זהו, סיפור מעניין, לגמרי לא הסיפור הטיפוסי, ואני לגמרי לא בא ואומר “באחריות זה הולך לעבוד לכם” - כי זה לא, והוא בעצמו אומר ש”זה עבד לנו במקרה”.ועדיין אני חושב שזה סיפור מעניין ללמוד ממנו.(דותן) מה שאני חושב שמיוחד ב-Gumroad, אם אני זוכר, זה שהם התחברו לאיזושהי נישה, ואני לא יודע איפה זה היום, אבל נישה של קהילת האינדי בכלל ובאופן ספציפי כל ה-Indi-Gaming ו-Game Developers שרוצים למכור את המשחק שלהם ולא בא להם ללכת ל-Publishersאו שהם לא יכולים או שאין להם את התשתית לזהאז אני זוכר שזה מאוד פשוט - אתה בא ל-Gumroad, יוצר לעצמך חשבון ויכול להתחיל למכור עם לינק של Gumroad - וזהו.(רן) כן - אז הם סוג-של-נותנים-דוגמא: אנחנו לא רק מוכרים לקהילה כזאת, שהיא אינדי - אנחנו גם Independent בעצמנו.אז אני לא יודע אם זה הגיע מתוך האג'נדה הזאת או לא, אבל הם סוג-של חיים את ה-Spell שלהם.זהו - בלוג-פוסט יפה, לא ארוך - מזמין אתכם לקרוא, ושוב תודה למיקי.ולאייטם הבא - זה איזשהו Review קצר של ה-Stack overflow survey שהתפרסם לפני כחודש או חודשייםאנחנו עושים את זה קצת באיחור כי הרבה זמן לא הקלטנו [באמפרס]אז אני אוציא כמה כמה דברים קטנים - ויש שם די הרבה, יש המון אינפורמציה, והוא גם מוצג בצורה גרפית מאוד מאוד נחמדה [כמו בפעמים הקודמות] - אז כמה דברים שלי תפסו את העין, כי כל אחד אולי מתעניין בדברים אחרים . . .אז האייטם הראשון זה שהם באים שאומרים שהם הסתכלו על אוכלוסיית הבני 18 ומטה - הממש צעירים, המפתחים הממש צעירים - על איך הם לומדים לפתח, באילו Resource-ים הם משתמשים.והם אומרים שבניגוד אולי למה שהיה פעם, הם כמעט ולא קוראים ספרים או עושים קורסים כתובים - הכל זה Vidoes או איזה שהם Tutorials קצרים או דברים בסגנון הזה.עד כמה שזה אולי נשמע לנו אינטואיטיבי - לבוא ולראות את זה במספרים זה מאוד נחמד, אני חושב, ואולי קצת מאיר את העניים - עכשיו אני יכול לבוא ולהגיד “איך הצעירים לומדים” . . .אבל אני חייב להגיד שכל אחד מאיתנו גם באיזשהו מקום קצת צעיר וגם קצת לומד ככה, וזה כנראה מחלחל לכל הכיוונים.אבל אני חושב שזה מראה באופן מאוד מאוד מובהק את אופי הלימוד שמשתנה עם הזמן, וזה פאן תרבותי מעניין אחד שנחשף שם.עוד משהו מעניין זה Frontend Framework שנקרא Svelte, שלמעשה הגיע בכמה שנים האחרונות - אני לא זוכר בדיוק כמה זמן זה באוויר, או שנתיים-שלוש, אולי קצת יותר - למעשה זה ניהיה ה-Framework האהוב ביותר ע”י מפתחי Frontend, לפי הסקר הזה.אני חייב להעיר, “בפריזמה היסטורית”, שכמעט תמיד ה-New kid on the Block הוא זה שתמיד הכי אוהבים, ואז אחרי כמה זמן מתחילים לשנוא אותו, ככה שבואו אולי לא נפתח יותר מדי תקוות לפני הזמן . . . אבל כן, יש פה New Kids on the block . . .(אלון) רגע, בוא נשים את זה ממש בפרופורציות - ה-Framework הזה, לפי הסקר שלהם - יש לו רק 2.75% שימוש . . . אז ה-2.75% האלה אוהבים אותו, באחוז גבוה . . .(רן) כן . . . נכון . . . אני זוכר, דרך אגב, שגם React היה בנקודה הזאת, אולי אחוזי השימוש היו יותר גבוהים אבל הוא היה ה-Framework האהוב ביותר, וככה זה.אבל בכל אופן - הוא [Svelte] תופס תאוצה, אז אני מניח שמי שבעולם ה-Frontend כבר מכיר את זה.(אלון) אגב, אני חושב שהדבר הכי מעניין בעולם ה-Frontend זה שלראשונה עקפו את jQuery . . . ש-React.js עקף את jQuery, וסוף סוף העפנו את הדבר הזה . . .אז אני רוצה להגיד פה תודה אישית לכל מפתחי ה-Frontend אי-שם שלא בחרו ב-jQuery - באמת, תודה, תקבלו תקליט וגלויה [וכובע גרב].(רן) כמו שאלון אמר - לראשונה אי פעם בהיסטוריה - ואתם שומעים את זה פה, בפעם הראשונה! - ה-Framework של React.js עקף את jQuery בפופלאריות שלו, מבחינת כמות התוכן וכמות השאלות ב-Stack Overflow, וכו' . . .אז כן, הגיע הזמן, חבר'ה . . . אם מישהו ממאזיננו עדיין משתמש ב-jQuery, אתם מוזמנים להפסיק . . . או להאזין, או להשתמש - אבל מוזמנים להפסיק.אני חייב להגיד שאני התחלתי עוד לפני jQuery - למי שזוכר, היה Prototype.js . . . עוד לפני, אפילו יותר נוראי.בזמנו זה היה אולי Life-Saver, אבל כן - עם מה שיש לנו היום זה כבר באמת נראה משהו פרה-היסטורי.זהו, עד כאן . . . יש לי הרבה פריטים קלילים ומצחיקים, נשמור אותם לאחר כך - אז אליך, אלון.אלון - זה הגיע מהר מהצפוי . . . בסדר . . .אז קודם כל - אני רוצה להגיד שוב תודה לכל עובדי GitHub שמאזינים לנו ושמעו את האייטם האגדי שלי - עורך! אם אפשר לשים פה את הקטע שוב מהאייטם? נעשה הפסקה . . . [הקהל מתבקש לדמיין את הפתיח של מנהרת הזמן ולחזור ל - 410 Bumpers 73]“ . . . וזה האייטם האחרון שלי בהחלט, כי אחריו אי אפשר לעלות יותר גבוה: אני עושה פהDrop-Mic וזהו - זה הפרק האחרון, לא תראו אותי יותר, זה פרק אחרון - GitHub to VS Code:כל מה שצריך לעשות, זה מטורף - קחו Repoתוסיפו, בסוף הקוד של ה-GitHub, תוסיפו “1s” -שמתי פה לינק לאייטם של דותן - ותלחצו וזה פשוט פסיכי . . . פשוט עובדים על הקוד ב-VS Code וזה מאוד נוח לדפדף, לכתוב קוד, כל מה שאתם רוצים - זה VS Code online לכל Repo, אם Private או Public, של GitHub . . .“וחזרנו [לקו הזמן הנוכחי, בערך]. . . .אז האייטם האגדי, על זה שאם ב-Repo מוסיפים “1s” בסוף אז מגיעים ל-vscode on-the-fly - אז GitHub, לאור ההתלהבות שיצרתי בעולם עם זה, החליטו להוסיף את זה - ועכשיו אפשר פשוט בכל Repo על dot [“.”] ומקבלים את ה-vscode built-in ואפשר לעבוד על זה אז אני מרגיש ממש חלק מה-Feature הזה, אני חייב להגיד לכם . . .אבל זה Feature מדהים, חסכו לנו לשנות את ה-URL, וזה גם עובד עם Private Repos . . . (רן) נתנו לך קרדיט ב-Release notes או לא?(אלון) אני מעדיף לא להיכנס פה ל . . . העו”ד אמר לא להגיב כרגע לשאלות כאלה[הוא עדיין עסוק בלנקות מאז הפרק 1 באפריל עם זהר והבאמפרס שאחרי?](רן) אתה וזביידי באותה סירה? (אלון) רגע, תן קונטקסט, מה סתם? . . .[גם בשביל זה יש את טל פרידמן]ובוא נמשיך הלאה - אז בהמשך ל-vscode, אז לאור ההצלחה, GitHub הוציאו Cloud IDE [בשם codespaces]שזה כמו vscode - הרעיון הוא שלא צריך כלום, רק לשים על VM כמו . . . איך זה נקרא של AWS, ה-Editor שלהם? ברח לי השם . . .(רן) nine, משהו עם Nine . . .(אלון) A9 אני חושב . . .(דותן) לא, Cloud9 או משהו כזה . . . (אלון) Cloud9, נכון!זה גם חדשות . . . Brackets של Adobe נדמה לי שבוטל, בגלל שהם החליטו ללכת על vscode(אלון) בקיצור, אז עכשיו יש לנו New Kid in the Block, וזה בעצם -vscode in the Cloud, אז אפשר בלי מכונה . . . מה שמגניב זה שאפשר לקחת מחשב ממש חלש - ולקבל שם מחשב-מפלצת, עם איזה 32 ליבות, גזיליון Gb . . . להתקין שם מלא דברים ולהריץ סביבה, אז האמת שזה מעניין . . .(רן) אני רואה שיש שם אופציה או לעבוד על Desktop או ב-Browser . . . ב-Desktop הכוונה היא לחבר את ה-vscode שלך ל-Remote Container?(אלון) אתה אמור לעשות שם את ה-Run . . . לא ניסיתי את זה . . . כמו כל Cloud, אתה משלם פר-שימוש, אז כן - אתה אמור להריץ שם, אבל אתה יכול גם “בלי כלום”, לפתוח Chrome ולכתוב שם הכל עם כל ה-Plug-ins, שזה גם מעניין.(רן) מגניב לאללה(אלון) כן - אז אפשר לקנות עכשיו iPad-ים ולהתחיל לפתח מעל מערכות מורכבות . . . ונמשיך - זה היה על גבול המצחיקולים, אבל שמתי אותו פה: מישהו עשה, בתוך ה-Web, כי היינו עד עכשיו גם בתוך ה-Web - פשוט עשה MacOS בתוך ה-Web . . .זה נראה ממש MacOS, עם כל האפליקציות, ואפשר לפתוח שם, כביכול, vscode בפנים וזה מצחיק, כי זה פותח את ה vscode Web בתוך אפליקציית Web, ואנחנו קצת חיים בלופ עם עצמנו[אחרת מה היינו עושים כל הרפרנסים ל-Inception?]עכשיו - זה פרוייקט ממש חמוד, אז כל מי שאוהב את הפרויקטים שמנסים לעשות מערכת אחרת - אז זה ממש נראה כמו Mac, עשוי ממש טוב, וזה “חי בתוך ה-Web”.(דותן) קודם כל - זה עובד ממש מדהים . . . אנימציות סופר-טבעיות, ויש פה מלא Attention to Details, מלא . . . מדהים.(אלון) אני עדיין בשוק מזה שאני אשכרה משם פותח vscode, ואני אשכרה יכול להריץ . . . זה די הזוי.(רן) כן, אז חלק מהאפליקציות כבר פועלות וחלק עדיין לא, חלק הן Coming Soon - אבל מה שבאמת פועל זה באמת ממש יפה.(אלון) כן, אז זה פרויקט שעשו - מי שרוצה Calculator יכול להיכנס לזה, ללחוץ על Calculator ויש לו Calculator שם, על Mac . . . או כל מיני דברים אחרים.(רן) אז אתה יכול להתחבר מה-vscode של זה ל-Spaces ממקודם, ולפתח?(אלון) זה יכול להיות ניסיון מעניין . . . “ונפתח את זה!”, תוך כדי שאתה עובד בתוך זה . . .(רן) ולעשות Deploy . . . זה כמו לעשות Reboot ל-Server שאתה עושה אליו SSH . . . (דותן) אה, כל פעם שפותחים את זה, את ה-vscode, אז ה-ReadMe הוא של הפרויקט הזה . . . מה שכתוב פה זה שה-Framework זה Svelte, וכתוב earlier Preact, אז זה מסביר למה Svelte כזה פופלארי - כי זה React, בעצם . . . (רן) האקדח מהמערכה הראשונה . . .(דותן) כן, פיספסתי את השינוי הזה . . .סך הכל שינוי שם . . . (אלון) Preact בא אחרי React? או . . . .(דותן) לא - React . . . זה בא כדי לייצר React יותר Light-weight כזה . . . (אלון) כן - אבל הוא Pre-React . . . לא משנה . . .(רן) אם אומרים לך בפגישה “אלון, אתה צריך להיות יותר פרי-אקטיבי” . . . . מה זה אומר?(אלון) שאני עובר ל - Svelte . . . מה זאת אומרת?! אמרתי “אוקיי, קיבלתי את הפידבק, עוברים ל-Svelte . . . “(דותן) אבל לא - זה לא שינה שם . . . אוי, איזה מבלבל זה . . . (אלון) הפרויקט פעם היה . . .(דותן) קודם היה Preact, ואז הוא אומר שהחליפו ל-S . . .(רן) Svelte!(דותן) מוזר . . . .(רן) אז זוהו שני האחוזים ב-GitHub, בסקר ממקודם . . . (דותן) יכול להיות . . . (אלון) הוא - וכל הקהילה שסביבו שם . . . זה ה-2% . . . והוא אוהב את זה, הוא הצביע שהוא אוהב את זה, אנחנו כבר יודעים.נמשיך - פשוט חזרתי מדי פעם למשרדים, קצת, ויש אנשים שהטרמינל שלהם עדיין מצפצף מסתבר, ה-Bell . . . אז אמרתי שאולי יש אנשים שעדיין לא יודעים שאפשר לעשות לזה Mute . . . אז שמתי את זה - איך לעשות Mute ל-Bell ב-Terminal - למי שמכיר, לפעמים עושים את זה עם חץ למעלה או חץ למטה, אני כבר לא זוכר מתי הוא מצפצף(דותן) אני חושב שאנשים שיכולים לחיות עם ה-Bell הזה, יש להם מעלות . . . הם יכולים לסבול הכל.מי שלא שם לב לזה ופשוט חי עם זה, יכול לסבול הכל, לדעתי.(אלון) אני חושב שזה אותם אנשים שה-Slack שלהם עדיין עושה טיק-טיק . . . כאילו, הרי הדבר הראשון שאתה עושה ב-Slack זה Mute, נכון? . . .(דותן) אני מתחרפן מזה . . .(אלון) . . . נראה לי שיש חפיפה מלאה בין האנשים האלה . . .(רן) זה כמו התנייה פבלובלית - ברגע שאתה שומע את הפעמון אז אתה יודע שאתה הולך לקבל עונש . . . (אלון) כן . . . אז זה על Mac - מי שעדיין הפעמון שלו שם, אז בשקט בשקט, אל תגלו לאף אחד, ותעשו Mute לפעמוןלא שנגלה שהוא דלק לכם, ונמשיך הלאה בחיינו . . . הדבר הבא - מצאתי אוצר! יש את הספרים של Google על Site Reliability Engineering - המפורסם שבהם זה The Site Reliability Workbook - ויש גם ספר של O'reilly על Building Secure & Reliable Systemsאה, הראשון זה של O'reilly, אבל יש גם את השניים האחרים שהם מוכריםאז יש אותם Online - מלאים . . . אז מי שרוצה מוזמן לקרוא - אלו אחלה ספרים, מומלצים בחום, חינמיים, On-line-י, מלאים(רן) אני, דרך אגב, קראתי - או נראה לי ששמעתי אותם, בעצם - אמנם אין גרסא מוקלטת שלהם, אבל לקחתי תוכנה שממירה את ה-PDF . . .(אלון) יש Audible! . . .(רן) אה, יש כבר? אוקיי, אז כשאני האזנתי עוד לא היה [Audible? הם קיימים כבר לא מעט זמן, אחלה דבר . . . ][תכל'ס, ה-Release date על זה הוא מאי 2021, אז זה כנראה די חדש…]זה נשמע קצת מוזר, בעיקר כשיש כל מיני נוסחאות - מדי פעם יש להם נוסחאות ל-Latency או דברים כאלה, אז זה נשמע קצת מוזר כשה-Reader מנסה להקריא את הנוסחאות, אבל חוץ מזה זה סבבה.[אז מתי Google מוציאים כזה עם Wil Wheaton? מה, רק לחטיבה של Waze מותר שטויות?](אלון) אני זכיתי איתך באיזה כנס של Google פעם בספר, ומאז הוא אצלי על השולחן שוכב, מעלה אבק . . . סתם, לא קראתי אותו מאז - ושמעתי את ה[גרסת] Audible, בגלל זה אני יודע שיש Audible.אחלה ספרים - מומלץ בחום.האייטם הבא זה פרויקט שנקרא Airbyte - הוא נראה ממש חמוד, מאוד מתוחזק ויחסית צעיר, עושה רושם שהוא Data integration made simple, secure and extensibleזה Open Source שנותן לעשות Dashboard שרואים לפחות מה קורה עם האפליקציות - מתי הן עשו Sync, ו-API ו-Data Warehouse, דברים כאלהזה נראה כזה Aggregator של מלא דברים, עם UI ממש חמוד . . .לא הבנתי לגמרי עדיין את מה הוא בא להחליף . . . אבל הוא נראה נוח, מבחינת הויזיביליות (Visibility) שלו.מבחינת שימוש וזה - לא ניסיתי . . .(דותן) ממה שאני קורא, זה נראה כמו Redash עם יכולות טרנספורמציה לדאטה . . .(אלון) זה יותר מזה, כי אתה מקבל סטטוסים של הדאטה שלך . . . זה קצת מזכיר את ה-Airflow, את המערכת וזיאליזציה שלהם . . .(דותן) אה . . . אוקיי, זה מסביר את השם אולי? Airbyte . . .(אלון) יכול להיות . . . אני חושב שזה . . . (דותן) אתה יכול להעביר Byte אחד, כאילו?(אלון) כן . . . אחד - זה לא סקלאבילי (Saleable). . . זה Byte-Byte, למה אתה ממהר?(דותן) כשאתה עושה New Project, אתה בעצם מקבל Byte אחד - ואת ה-Byte הזה אתה מעביר? אינטרגרציה של Byte . . . (אלון) Old-School, כן, Byte-Byte נעבוד . . . (דותן) כתוב כמה Bit-ים זה, ה-Byte הזה? . . . (אלון) אה . . . הם לא מפרסמים . . . (רן) גם לא אומרים אם זה אינדיאני גדול או קטן [Endianness] . . . אבל זה נראה כמו משהו שהוא, לפחות לפי הדוגמא שלהם, משהו שמפוקס על עולם הפרסום,זאת אומרת - אפשר לעשות סנכרון, נגיד בדוגמא שלהם, ל-Facebook Ad, ל-Salesforce או Hubspot ו-Linked Ads וכו' - אז זה נשמע כאילו הוא מביא דאטה, שם את הכל באותו המקום - ואתה בעצם יכול לשלוט . . . יכול לעשות פה Monitoring ל-Workflow שלו.מה זה בא להחליף? האמת שאני לא מכיר שום כלי אחר שזה בא להחליף . . . כנראה איזושהי “סקריפטולוגיה” פנימית, לא ראיתי לפני כן כלי שעושה משהו כזה.(אלון) בקיצור - נראה לי חביב: נסו, ספרו איך היה. נהניתם? ספרו לחבריכם . . . (דותן) נראה לי שצריך לעשות פה איזושהי הסברה . . . רן, אמרת “אינדאני גדול או קטן” - אז סתם, כדי לא לפגוע באוכלוסיות מסויימות [שלא קראו את הטקסט וראו את ההפנייה . . . ] - זה Endianness, זאת אומרת “סופתי” . . . (רן) כן, זו הייתה הלצה . . . “סופתי”, כן . . . Endian(אלון) תודה, על ההבהרה, דותן - אני בטוח שאף אחד לא הבין, פשוט, וזה היה ממש חשוב.[והעו”ד כבר די עסוק, אמרנו . . . ] טוב, אז הדבר הבא זה פרויקט שנקרא ה-Joker Language- זה בעצם interpreted dialect של Clojure שנכתב ב-Go . . . .אפשר להריץ פה ClojureScript בתוכו . . .אז לחובבי ז'אנר ה-Clojure - כן, כל אותם . . . מי זה? AppsFlyer? אז כל אותם אלה ב-AppsFlyer שמאזינים - נראה לי שזה בשבילכם . . .(רן) גם Nanit, בישראל, דרך אגב, יש עוד כמה . . .[הם אפילו כתבו על זה לא מזמן](אלון) יש עוד כמה? . . . (רן) כן - NET@ [?] מכירים? יש לנו בטח כמה מאזינים שם . . . . ויש בטח עוד כמה בפינלנד ובעוד כמה מקומות בעולם . . . אבל כן - אם תמיד חלמתם לכתוב Clojure ולתת ל-interpreter ב-Go להריץ את זה - אז זו ההזדמנות שלכם . . . לכו ל-Joker.[לא זה](אלון) כן, זה מגניב.ולנושא שהחלטתי להוסיף פה לפני . . . בקרדיטים, Undocumented מה שנקרא - יש משהו שנקרא Reflect.app, לכל מי שאוהב Nodes או עדיין תקוע עם איזה Evernote או איזשהו משהו ארכאי כזה.אז אפשר לנסות לעבוד עם Reflect.app - זה עושה גם mile-map ל-Note-ים, למי שאוהב לשמור Note-ים - אתם יכולים לנסות.(רן) בוא, אני אתן קצת רקע - לפני שהתחלנו את ההקלטה, כל אחד שאל “רגע, אז איך כל אחד שומר את ה-Notes לקראת הפרק הזה?”זאת אומרת - אנחנו אוספים את זה במשך משהו כמו חודש, לפעמים קצת יותר - אז איפה כל אחד שומר?אז דותן ב-Evernote, אני שם את זה ב-Paper ואלון, במה אתה?(אלון) ב-Keep . . .(רן) ב-Keep . . . ואז התחלנו להעלות כל מיני אופציות אחרות, ו-Reflect.app הייתה אחת מהאופציות באמת, שעלו.אז זה הקונטקסט של כל זה . . . .אז תודה אלון - ואליך דותן . . .(אלון) דותן בפינתנו “Rust-Rust וירקות אחרים” . . . .(דותן) לגמרי . . .דותן - אז היום רק Rust - החלטתי לעשות לכם לגמרי כיפה אדומה, אז נתחיל:האייטם הראשון נקרא rust-tui-template - כש-TUI זה Textual UIמה שנקרא - אי אפשר להוציא את ה-BBS-ים ממני . . . זה UI שנמצא בתוך ה-Terminal, בדרך כלל הוא עם מסגרות כאלה נחמדות ולא טקסטואלי לגמרי, אבל מכיל כל מיני אלמנטים של ASCII ו-ANSI, מה שנקרא “של פעם”.והפרויקט הזה - לכל מי שרוצה לבנות App כזה מגניב, אז הוא פשוט איזשהו Boilerplate מדהים, שסוגר את כל הפינות.זאת אומרת שכשמתחילים פרויקט עם זה, מקבלים . . . בעצם כל קובץ והמטרה שלולמשל - קובץ שאחראי על ה-Widget-ים של ה-UI, קובץ שאחראי על ה-Data וה-Handler של ה-Keyboardבעצם, כשבונים אפליקציה כזאת - אפליקציה ל-Terminal - יש הרבה “צנרת” שצריכה לקרות . . . יותר מה-Browser ויותר מכל דבר אחר, וה-Template הזה די סוגר את זה.אז למי שרוצה ללמוד Rust - לדעתי זו הדרך הכי טובה: לחשוב על איזשהו רעיון, איזושהי אפליקציה של Productivity, לסגור איזושהי פינהנגיד “לקחת Notes” ,שדיברנו על זה מקודםוזה ממש נחיתה רכה לתוך זה.האייטם הבא, למי שרוצה לראות לאן אפשר להגיע - יש פה מישהו שבנה פרויקט שנקרא gobangזה לא כתוב ב-Go . . . זה כתוב ב-Rust(אלון) כמעט הפלת אותי . . . (דותן) זה בעצם Database Management Browser כזה . . . כמו כל כלי שמתמשים בו כדי לעשות Queries לתוך Database-ים כדי לראות מה קורה ולצפות בתוצאות.והכל מבוסס Text-UI - לא Command Line אלא Text-UI - נפתח חלון, כמו VIM כזה, ומנווטים בו בתוך העולם הזה . . .נראה ממש טוב, עובד כמובן מאוד מהר, תומך ב-MySQL וב-PostgreSQL . . . בעצם אפשר להסתכל ולחפור פנימה ולראות איך זה בנוי - תוך כדי שאתם בונים את מה שאתם רוצים.(אלון) עצה שלי - שים לזה רק Read-Only Connection, כי זה ב-Alpha . . .(דותן) כן, זה Read-Only . . .(אלון) . . . לך תדע אם ה-Delete פה . . . אם יש איך להריץ דברים ,שלא יהרוג אותו.(דותן) נכון - כמובן שבכל הדברים האלה צריך . . . לא להתחבר ל-Production עם הדבר הזה . . .(אלון) ... אלא אם כן זה Mongo, ואז זה לא משנה(דותן) כן, Read, Write, זה לא באמת חשוב . . . .(אלון) לא עקרוני . . .(דותן) אז האייטם הבא הוא גם בקו הזה של UI - אז יש פרויקט שנקרא Druid - לא ה-druid של ה-Data אלא UI[וכמובן שמתבקש]ב-Title, זה Data-first Rust-native UI toolkit - או במילים אחרות: סוג של מימוש React-י, עם תחושה של React, בתוך Rustכשמדברים על UI, אז זה על אפליקציות Desktop, בעצם.(אלון) במקור - אתה צריך לספר את ההיסטוריה - זה נולד כמכשיר עינויים . . .(דותן) למה?(אלון) מי רוצה לכתוב ב-Rust את ה-UI?(דותן) קודם כל - אם אתה רוצה לכתוב אפליקציית UI שהיא Cross-Platform, מה אתה עושה היום?(אלון) Web . . .(דותן) ואם אתה לא רוצה Web, אתה רוצה Native - מה אתה עושה? אולי Electron או משהו כזה . . . (אלון) כן, Electron. . . למה? זה נראה לי סיוט . . . (דותן) תלוי בדרישות . . . למשל - יש הפצת Linux שאני מאוד אוהב שנקראית elementary, וזה נראה ממש, נקרא לזה “כמו-Mac” - אבל זה מדהים, לדעתי זה Linux כמו ש-Linux היה צריך להיראות.ושם בונים Native-UI Apps - וכמובן שכשאתה בונה הפצה של מערכת הפעלה, אתה לא יכול באמת לארוז הכל ב-Electron - אפליקציה של מחשבון שתיקח לך 150Mb ותגמור לך את ה-CPU והזיכרון.[ב- Microsoft Teams זה לגיטימי . . . .]אז שם הם עושים את זה עם Vala - ו-Vala זה איזשהו “שיקוץ” כזה, זה #C מעל GTK, וזה כזה משהו שתמיד הרגיש כאילו נעשה בשביל ”לסגור פינה” - אבל כל מערכת ההפעלה בנויה בזה, והיא עובדת מדהים.אז נגיד לדבר כזה זה מאוד שימושי . . . אז זהו - זה Druid, והיום ה-Reference Implementation של UI Apps, מסתבר, זה לממש Spotify Client . . .אז בעצם הוספתי לינק למישהו שעבד עם Druid ופיתח פרויקט שנקרא psst - כמו שעושים למישהו “פססט” כזה, לחתולים . . . וזה בעצם Spotify client ממומש Native-לי, בלי Electron, רק עם Rustבעצם מקבלים, אני משער - האמת שאפשר גם לא לשער . . . לא, אין Releases - אז אני משער שזו תיהיה אפליקציה ששוקלת 4-5Mb, משהו כזה.זהו, אז בעצם . . .(אלון) עם “UI בשקל”, בסדר . . .(דותן) למה? ה-UI נראה טוב . . . כאילו, אתה יכול להסתכל על ה-Screenshot-ים, הוא נראה סבבה . . . (אלון) כן, נו - אבל אחרי זה . . . לא יודע, אני חושב שאלא אם כן אתה באמת חייב את זה, לברוח . . .(דותן) אין ספק שהקריטריון הוא שאתה חייב את זה . . . יש המון אופציות לא לבנות Native - אבל אם אתה חייב את זה, אז בעצם מה האפשרויות? האפשרויות הן - אם אתה רוצה Cross-Platform . . .נגיד, Linux יתפוס לך הרבה מאוד נפח, אז זה GTK, ו-GTK זה חתיכת סיוט . . . אז כן, אם אתה חייב, במקרים שאתה חייב - אני חושב שאין הרבה פתרונות טובים ל-Cross-Platform וזה יכול להיות פתרון טוב.הקטיגוריה הבאה של Rust שאני מתעניין בה זה משחקים - אז יש Platformers ויש כל מיני Indi-Frameworks לפיתוח משחקים, כש-Unity היום, במיוחד בתחרויות פיתוח משחקים, הוא השולט, ותמיד אני מחפש את ה . . . אני יודע של-Rust יש Sweet-spot של Performance ו-Productivity ותמיד אני מחפש לראות איך עולם ה-Indi-Games או חבר'ה שבאים ו . . . שהם לא סטודיו מטורף, ומשתמשים ב-Rust כדי לנצל את המעלות שלו כדי לפתח משחקים - וזה מתחיל לקרות.אז יש כזה משחק שנקרא Fish Fight, שבעצם עשו לו Open-Source - הוא לא היה בתקופה מסויימת, והפך להיות Open-Source.זה איזשהו Tactical 2D shooter מצחיק כזה, עם דגים שנלחמים אחד בשני - ממש מגניב, לא עלוב בכלל אלא להיפך, זה כזה . . . יש לזה “פקטור מגניבות” כזה.וזה משתמש ב-Framework ב-Rust שנקרא Macroquad - שעברתי עליו ובדקתי אותו ונראה ממש ממש טוב, לפיתוח משחקים Indiבנוסף, יש המון Learning Materials בתוך המשחק הזה, כולל Tutorial של איך לבנות משחק וכולל איזושהו Mini-Setup ל-Platformer.אז ככה, לתקופת החגים הקרובה - למי שיש לו זמן ורוצה לצלול ולפתח משחק - שזה לדעתי אחד הדברים הכי כיפיים לעשות - אז זו אחלה נקודה להתחיל בה. זהו . . .האייטם הבא נקרא Rustacean Principles . . . עכשיו, לכל קהילה יש איזושהי נקודה - אני זוכר את זה במיוחד מאיך שקהילת ה-Ruby התפתחה - יש נקודה שמתחילים לזהות “אופי של קהילה”, וכמובן שהאופי הזה נובע… אם הקהילה היא סביב שפה אז הוא נובע מאיך שהשפה בנויה ומה שהיא דורשת מהמשתתפים בקהילה.אז יש את Niko Matsakis - אחד הכוכבים בקהילה הזו [הפנייה ל-ציטוטים מומצאים של הגשש?]והוא החליט להסתכל ולעשות איזושהי אובסרבציה (Observation) ולהביא כמה עקרונות שמלווים אנשים שבונים ב-Rust, וגם את הקהילה עצמה.אני אתן כמה דוגמאות - לא יודע אם כולם ממש תואמים, אבל נגיד:למשל - ”Reliable: “if it compiles, it works - וזה נכוןאו “Performant: “idiomatic code runs efficiently - זה גם נכון . . .קהילה שהיא Supportive - שזה נכון בצורה . . . לא כמו קהילת ה-Ruby, אבל זה די נכוןוגם Productive ו- Transparent ו- Versatileאז כל הדברים האלה - אני יכול להעיד לפחות שהם נכונים.בעצם זה מוביל אותי לאייטם, שאני דווקא אתן דוגמא . . . הוא גם משמש כדוגמא לדברים האלה.אז יש חבילה בשם polars - וזה נראה לי שרן יאהב - וזה בעצם Blazingly fast DataFrames in Rust & Pythonאז בעצם לקחו DataFrames, מימשו חלק מהפעולות - או “חתיכה מהעולם” - ב-Rust - ועשו Binding ל-Pythonובעצם, אם נסתכל על ה-Benchmark-ים, שזה החלק החשוב בדבר הזה - המימוש ב-Rust הגיע, כמעט תמיד, למקום השני בכל ה-Benchmark-ים, מקום שני-שלישי.אם מסתכלים בקוד - ואני עברתי על הקוד - אין שום דבר שנכתב ב-Rust שנראה Specialized . . . אין Hack-ים, אין טריקים - כל האימפלמנטציה (Implementation) “נאיבית”.יש שם Generics, יש שם איטרציות (Iterations) מעל Collection-ים מאוד מאוד High-level . . . יש Temporary variables והמון אבסטרקציות (Abstractions)וכל הדבר הזה לא משפיע בכלום על ה-Performance . . .(רן) אני חושב שהסתכלתי על זה בעבר - זה נחמד, כאילו, הזריזות של זה זה נחמדחסרה הפונקציונאליות הגדולה שיש ב-pandas . . .(דותן) כן, זה לא מחליף את pandas, זה לא מחליף . . . זה נותן חתיכה מהסיפור . . . (רן) כן - אבל אם זה יגדל, זה יכול להיות תחליף טוב ל-pandas, אני מסכים.(דותן) כן, אז כאילו מה שאני מנסה להעביר זה שכשראיתי את הפרויקט הזה, הדבר הראשון שעשיתי זה לצלול ולהבין האם יש Hack-יםכל מיני Hack-ים של Performance, כל מיני טריקים כדי לממש דברים בצורה יותר חכמה ויותר מהירה - ואין . . .כלומר - הכל קוד “Vanilla” של Rust שאפשר לקרוא בצורה “הומאנית”, וזה אחד הדברים המעניינים.(רן) כן, ונגיד שגם דברים שקיימים ב-pandas - כשהם רצים מהר, אז זה רץ ב-++C . . . זה אומרת או שזה Alpine מתחת, או שזה מימושי ++C ספציפייםאבל שום דבר לא רץ מהר ככה ב-Python . . . אז פה בעצם אולי הם הצליחו לייצר משהו שהוא ב-Rust ויותר מהיר מ- ++C, אבל זה לא משהו שהוא אינרנטי (Inherent) . . .אולי זה מימוש יותר אלגנטי, אולי זה מימוש של איזשהו Subset של פונקציונאליות . . .(דותן) כן, צריך לזכור שמה שמקבלים בחינם, בניגוד ל-++C, זה Safety ו-Memory leaks - שאין - ובאגים טיפוסיים שמן מהסתם שייכים לעולם הזה של C ו-++Cוקוד שהוא קריא-בטירוף, הייתי קורא לזה . . . מדהים.(רן) קראת ל-++C “לא קריא” ברגע זה?!(דותן) כן.לא קריא - וגם הופך אותך ללא-שפוי לאורך זמן . . . (רן) “לא שפוי” זה עניין יחסי . . . בסדר. אין בעיה, לא נפתח פה חזית . . . הלאה.(דותן) הוספתי אייטם ל-Fast Rust Builds, כי ידעתי שאלון יקפוץ מיד עם ה-Build-ים האיטיים ב-Rust, כדי לסגור את הפינה ומראש להנחית מהלומה . . .(אלון) להרגיע לפני שזה גדל, אתה אומר . . .(דותן) לגמרי.(רן) מכיר את הבדיחה על הקומקום?(דותן) לא . . .(רן) ילד ואבא יושבים, ופתאום הקומקום על הכיריים - פעם היו קומקומים על הכיריים, שהיו שורקים ברגע שהם היו רותחים, כי היה להם מעיין פקק כזה, לפני הקומקומים החשמליים . . . - אז ברגע שהקומקום שורק, האבא רץ ונותן לו מכה ככה, עם מחבט.אז הילד שואל אותו “מה קרה? למה אתה ככה נותן מכה לקומקום?”שכחתי לציין לפני כן שהאבא נפגע בתאונת רכבת . . . ננסה שוב . . .(אלון) האמא בתאונת רכבת . . . (רן) אז האבא אומר “צריך להרוג אותם כשהם עוד קטנים”.(דותן) הרסת את הבדיחה, באמת . . .(אלון) הרכבת הייתה עושה “טו-טו” ו . . .(דותן) האמת . . . העורך יכול לתקן את זה? אחלה אתגר . . .[אה . . . ](רן) אני רק אציין שאני העורך ברגעים אלו . . . (דותן) בסדר, עדיין אפשר לקרוא לך “העורך” . . .(רן) כן, “בכובע העורך”(אלון) וואו . . . קודם כל, זה טוב לדעת שאתה עורך . . . תראה, אם אתה רק הופך את הסדר של הבדיחה שתיהיה בסדר בעריכה, אז היא תיהיה בינונית . . .(רן) אני חושב שיעריכו אותנטיות פה . . . נשאיר את זה As-is . . .אבל כמה יותר מהר? בוא נחזור רגע - “Build-ים יותר מהירים” - כמה? מה?(דותן) אז הוא מסכם את המאמר עם משהו שאני מסכים איתו - Build של Rust עם בערך 200,000 שורות קוד, עם אופטימיזציות אגרסיביות . . . ב-Rust יש סרגל שלם של אופטימיזציות שאפשר להפעילצריך לקחת בסביבות העשר דקות.שזה נשמע הרבה, אבל אתה . . .(רן) ולפני זה כמה היה?(דותן) אז הוא לא לקח . . . הוא לא עשה Use Case של “לפני ואחרי”, זה לא ממש מאמר שאתה מסתכל עליו ואומר “אוקיי, הנה הבעיה ו . . .”הוא פשוט נותן כמה טריקים ידועים לקהילההרוב זה Caching ו-Caching חכם - ולמה Caching ו-Caching חכם? כי Rust בעצם מאוד קרוב ל- C ו-++C במובן הזה, ספריות שנבנות הן ספריות שהופכות להיות סוג של Binary Libraries.ואם . . מה זה “אם?” הספריות האלה לא משתנות . . . אז בעצם אתה רוצה לעשות Caching של האוביקטים האלה כבינאריים, ואז אתה בעצם מקבל את זה “חינם” . . . אז יש עולם שלם של Build Cache, שהוא זהה כמעט לגמרי אם אתה בא מ-++C וכאלה - אז זה אחדושתיים - כל הקומפילציה (Compiling) של מפתחים, אנחנו עושים . . . .אני חושב שנגיד גם ב-Java זה קיים, וב-Kotlin - יש Incremental Builds: אתה בעצם עושה Build רק של מה שהשתנהוב-CI זה לא רלוונטי, אז אתה עושה Disable לכל המנגנון הזה ואז זה מאיץ לך את ה-Build בסוף . . . כל מיני טריקים כאלה הוא נותן שם כמה מספרים . . . אני יכול להגיד לך שאני הייתי על Build-ים של חצי שעה, ואז הקטנתי אותם לסדר גודל כזה של עשר דקות.(אלון) העיקר צחקת עלי, שאני אמרתי “מה? לא יכולת להגיד “חצי שעה זה סבבה! אתה יודע כמה קפה אני יכול לשתות בחצי שעה?””(דותן) תלוי ,יש תקופות שאתה רוצה שה-Build יקח חצי שעה, אבל כן . . . אז בקיצור - אייטם הבא: אז לקחתי פה איזשהו סיפור בהמשכים של חברה בשם CROWDSTRIKEזו חברת סייבר די גדולה, פומבית (Public), נאסד”ק וכאלה . . . די מפורסמת גם.והם מספרים סיפור שככה יצא לי לחוות אותו אחד-לאחד - והוא איך בעצם לוקחים את עולם ה-Machine Learning של Python ומחברים אותו עם Rust, כאשר ה-Python עושה את ה-Training ו-Rust עושה את הפרדיקציה (Prediction),כדי לקבל את הפרדיקציה - וזה גם מה שאני חוויתי - לקבל פרדיקציה יותר מהירה.אז הם עשו את זה בשני חלקים, והם מראים פה בעצם נתונים מדהימים - מתחילים בעצם ב-Background ו”למה?” - איזשהו Assessment כזה של שני פרויקטים שלהם -אחד נקרא “Dark Knight” - יש להם שמות מגניבים לפרויקטים - והשני נקרא “Airen”אחד בעצם מבוסס TensorFlow ו-Python ו- ++C וכל מיני שטויותוהשני בעצם מבוסס Rust ו-Pythonומראים תוצאות מדהימות, זה המאמר הראשון - אז נתחיל עם התוצאה, מראים כאן מספריםלדוגמא 2.98 לעומת 0.16 ב-Rust . . . לדעתי זה ב-milliSeconds, כן זה milliSecondsאז זה Mind-boggling, ההבדלים האלה - וכשזה חשוב לך לקבל את הפרדיקציה במהירות, אז זה מאוד מאוד משמעותימה שהם מדברים על Use-Case-ים, אז יש להם טכנולוגיה אחת לזהות URL-ים “חשודים”, ועוד אחת לזהות שינויי קבציםושתי הטכנולוגיות האלה מבוססות על Machine Learning ו-TensorFlow - וחשוב להם מאוד ה-Real-time-יות של זה . . . ולכן הם התחילו לבחון פתרונות אחרים.אז בחלק השני הם בעצם פורטים את “המכניקה” של מה שהם עשו, שזה דבר יחסית-סטנדרטי -הם בעצם לקחו חלקים מ-Python והיו חייבים לשכתב אותם ב-Rust, את כל העניין של הפרדיקציהוהם מסבירים למה זה היה שווה להםאני יכול להגיד שעברתי בדיוק את אותו תהליך אצלנו, לפני משהו כמו שנה, וזה פשוט . . הפירות של זה הם ממש עד היום.זהו - זה למי שמתעניין על איך להאיץ את ה . . . או שצריך פרדיקציה מהירה.(רן) אבל הם גם עושים את זה ע”י tf.function? זאת אומרת, בגדול, כשאתה עושה את זה דרך TensorFlow, אתה יכול לכתוב קוד Python-י ולשים איזשהו Decorator של tf.function - ואז זה מייצר Predictor מהירהשאלה אם הויזיבליות הזאת גם קיימת פה, או שהם צריכים לכתוב . . .(דותן) הם כתבו חלק מהדברים האלה מחדש . . .(רן) כן . . . אז פה, כאילו, “זה לא חוכמה”, באיזשהו מובן - כי הם כתבו משהו שהוא ממש Dedicated ל-Use Case שלהם, לא משהו שהוא גנרי זאת אומרת שאם הם אח”כ ירצו לשנות את המבנה, אני מניח, או לשנות משהו אחר - אז הם יצטרכו לכתוב משהו שהוא Dedicated שוב ב-Rustאז זה קצת כאילו להשוות תפוחים לתפוזים, באיזשהו מובןאז כן - אם אתה כותב משהו שהוא מאוד Dedicated, אז תוכל להשיג משהו יותר מהיר . . . דרך אגב, יכול להיות שאם היו כותבים בדיוק את אותו הדבר ב-++C ישירות מה-TensorFlow, הם גם היו מקבלים ביצועים כאלה . . . (דותן) אני חושב שפשוט . . . קודם כל, כשנכנסים לפרטים, אז יש פה המרה של מודלאני הלכתי דרך כמה . . . “ביקרתי בכמה תחנות”, וכשהבנתי שאת הפרדיקציה בחרתי לעשות עם XGBoostוהסיפור האישי שלי הוא שמימשתי - למרות שה-XGBoost כתוב ++C - מימשתי את זה מאפס ב-Rust, את החלק של הפרדיקציה.וקיבלתי פרדיקציה יותר מדוייקת - וגם יותר מהירה.אז כאילו באופן מסויים הנתיב הזה הוא . . . אתה חושב שאתה כאילו לוקח קוד, כשאתה מתחיל - אתה חושב שאתה לוקח קוד שאנשים עבדו עליו ועשו אופטימיזציות משוגעות וכו'אתה כותב אותו פשוט ב-Rust על הניסיון הראשון - ובריצה הראשונה אתה פשוט מקבל משהו שעובד יותר מהר . . . וזו החווייה.(רן) לא התכוונתי, דרך אגב, שעשו אופטימיזציות ב-++C - אני מתכוון שיש יותר יוזביליות (Usability)אתה יכול . . . יש יותר ורסטיליות (Versatility), שאתה יכול לעשות יותר דברים.פה אולי הם תפרו ל-Use Case ספציפי שלהם וזה עושה בדיוק את מה שהם צריכים ועושה את זה יותר מהראבל היתרון בגרסא המקורית זה שאתה יכול לעשות, אתה יודע - אתה יכול לכתוב איזו פונקציה גנרית, איזושהי רשת גנרית ב-Python, לקמפל אותה ל-++C עם tf.function - ויש לך משהו חדש.בזמן ש . . .זאת אומרת, אתה לא צריך לכתוב את זה מחדש ב-Rustאבל ברור לי לגמרי שאם יש להם משהו שהוא כבר Stable, הם כבר יודעים מה הם רוצים . . .(דותן) נכון, לגמרי, זה תמיד . . הניסיון השני והשלישי זה תמיד יותר טוב . . . .(אלון) זה כמו Framework גנרי לפתור בעיה ספציפית . . . בשביל לפתור בעיה ספציפית אתה תעשה את האופטימיזציה הנכונהאבל הקונספט מעניין, אני חושב - ברמת ה”לקחת את זה למאקרו” זה בעייתי להגיד “בוא נזרוק TensorFlow ונעבוד עם Rustאבל אני חושב . . .(דותן) הם לא זורקים . . . (אלון) לא . . .(דותן) הם פשוט מימשו את החלק של הפרדיקציה בצורה, נקרא לזה “פרטנית”, או “Custom להם”(אלון) שוב, יכול להיות שאתה יודע . . . טוב, בקיצור, כרגיל, כל מקרה לגופו . . . . אם שווה לך להשקיע בזה או לא.(דותן) הייתי שמח אם הם פותחים את הקוד של זה, אבל לא נראה שזה קרה . . . אבל לך תדע.אני, בכל אופן, אמשיך לעקוב אחרי זה.(אלון) שמע, זה חברת סייבר- חכה שמישהו יפרוץ להם ויוציא את הקוד . . . (דותן) טוב . . . נמשיך לכמה אייטמים אחרונים . . .(רן) יש ל משהו על Rust להיום?(דותן) כן, אז אני אשנה נושא . . . האייטמים האחרונים יהיו על Rust.אז הוספתי עוד לינק בשביל אלון - זה נקרא Cheap tricks for high-performance Rustאז הדף הוא ריק - כי לא צריך טריקים כאלה . . . סתם, יש שם כמה דברים.(אלון) למה רשום בשורה הראשונה “Write in Go”?(דותן) בקיצור, יש שם דברים מאוד מועטים ומאוד שטחיים - כי לא באמת צריך . . . סתם כמה פרמטרים, אין יותר מדי.את האמת, לא בצחוק: אין פה שום דבר שאומר לך איך לכתוב קוד - אני רק שם לב לזה עכשיו - איך לכתוב את הקוד שלך ב-Rust אחרת כדי שיהיה יותר [מוטה-] Performance.כל מה שיש פה זה Build flags למיניהם . . . שזה מעניין.(אלון) כי הם עדיין לא הצליחו להריץ את בקוד, אז הם מקמפלים (Compiling)?(דותן) יכול להיות . . . סבבה.אייטם אחרון - ונקנח דווקא עם Rust: זה נקרא Miriזה פרויקט שעבדו עליו הרבה זמן, התחיל כפרויקט אקספירמנטלי (Experimental) לגמרי בעולם של שפות תכנותהניסיון היה לקחת . . . הרי Rust מתקמפל (Compile) לאיזשהו “ייצוג ביניים” - Intermediate interpretation, איזשהו IR - ואז את הייצוג ביניים הזה, שאפשר לחשוב על זה כעל “Assembler-מתוחכם-High-Level” - הדבר הזה מתקמפל ל-Machine-Code ע”י מנגנון אחר.אז בעצם הרעיון שהיה ב-Rust, שהוא רעיון יוצא דופן - לקחת רק את הקוד IR הזה ולהריץ אותו ב-Run-Time, כמו Interpreter - כשהמטרה בסוף היא שיהיה פרויקט - במקרה הזה Miri - שיודע “לקרוא החוצה את החתיכות לוגיקה” האלה ולמצוא בהן כל מיני בעיות לוגיות.למצוא אופטימיזציות, למצוא באגים למיניהם - כל מיני דברים כאלה.אז הדבר הזה כבר “עלה כיתה” - הוא כבר רץ על כל מיני ספריות ב-Rust ומצא באגים אמיתייםזאת אומרת - יש טסטים, יש הכל, זה ספריות Open-Source גם . . . אבל באגים שבסוף, אין מה לעשות - זה טעויות של מפתחים, ובסופו של דבר יש באגים . . . אז זה מצא לא מעט באגים בצורה אוטומטית בספריות מאוד פופולאריות - וגם בספריות Core של השפה.אז אני חושב שאולי Valgrind וכל המשפחות האלה של ה-Tool-ים - בגישה זה זהה.בטכניקה זה שונה.(רן) אוקיי - ועד כאן החלק על Rust, נראה לי . . . עד כאן בעצם החלק הרציני של הערב.אז יש לנו סדרה של קטעים קצת יותר הומוריסטים - המצחיקולים שלנו [יש מצב שכבר שווה פתיח נפרד : - ) . . . ]אז נתחיל:הלינק הראשון נתרם ע”י מאזיננו ערן - תודה ערן!הלינק הראשון נקרא How-I-experience-Web-Today.com - וכשאתם לוחצים עליו אתם בעצם מקבלים איזושהי חוויה שכנראה ראיתם אותה בעבר, שבה אתם למעשה, נניח, עושים איזשהו חיפוש ב-Google ומקבלים איזשהו לינק לאתר, לוחצים על האתר - והדבר הראשון שאתם רואים למטה זה Cookie Privacy Statement, שאתם צריכים לעשות Accept, נגיד . . .אז נניח שעשיתם Accept - קופץ לכם Pop-up מלמעלה: של “האם אפשר לשלוח נוטיפיקציות (Notifications)?” . . . . נגיד “לא” . . . אתם אומרים No Thanks, תודה . . . ואז קופצת עוד Pop-up: “אני רוצה להראות לך נוטיפיקציות!” - ושוב אתה אומר “לא!”ואז קופץ עוד Pop-up - “תעשה לי בבקשה Subscribe ל-Newsletter!”אתם לוחצים “No Thanks” - ואז אתם מגלים ש-”!Ad-block detected”, ואתם עושים “OK” . . . בקיצור - שורה של Pop-Ups על Pop-Ups על Pop-Ups . . . . ככה פחות או יותר נראים הרבה מאוד אתרים היום באינטרנט, למרבה העצב.וגם כשאתם רוצים לעזוב - אז קופץ לכם Pop-up “האם אתם באמת רוצים לעזוב את האתר הזה?!” . . . שזה טריק ידוע וישן שמשוחזר פה.אז כן - קצת רטרוספקטיבה על איך נראה האינטרנט נכון להיום, רטרוספקטיבה אולי קצת עצובה אבל אני חושב שמשקפת נאמנה הרבה מהאתרים של היום . . . האייטם הבא שבחרתי להציג - האמת היא שהוא לא חדש, אבל הרבה זמן לא עשינו Bumpers וזה לא הוצג פה [היה לינק באחד הרפרנסים למיטבי לכת …] - זה סרטון נחמד שצילמו אצלי בחברה ב-AppsFlyer, שנקרא “אז שכרנו הד האנטר. פחות הצליח” . . . https://www.youtube.com/watch?v=FTak4_SDxUA&סרטון הומוריסטי - אני מזמין אתכם לבוא ולראות אותו.כנראה שכבר ראיתם - אבל אם לא אז לכו תראו: חמש דקות של כיף, של צחוק על קהילת ההיי-טק, קהילת פיתוח התוכנה בישראל.על איך נראה הד-האנטר של פעם בעולם של היום.לכו תראו - נחמד, ב-YouTube, ב-Facebook, בכל מקום שתרצו - אני אשים כמובן את הקישור.(דותן) זה נראה לי שזה ה-Head Hunter של העתיד . . . (רן) של העתיד?(דותן) נראה לי שזה יגיע לשם בסוף . . . (רן) כן . . . בקיצור - משעשע, גם למי שלא ב . . (אלון) יש חברות שכבר שם . . . (רן) גם מי שדרך אגב . . . . גם אשתי ראתה וגם הילדות שלי ראו - ואת כולם זה הצחיק, זאת אומרת שיש פה הומור שמדבר לכל גיל ולכל מקצוע.עשוי היטב, הפקה יפה - לכו תראו.אייטם הבא - טוויט נחמד, או ציטוט נחמד שמצאתי ב-Twitter, אני אקריא לכם:"Theory is when you know something, but it doesn't work. Practice is when something works, but you don't know why. Programmers combine theory and practice: Nothing works and they don't know why." – Unknownאז משעשע . . . זה נמצא ב-Twitter של CodeWisdom@, זה שם החשבון, CodeWisdom@ [זה ה-Handler, השם הוא Programming Wisdom], אז יש שם עוד כמה כאלה משעשעים . . . ונעבור לאייטם הבא ב-Twitter - גם הוא דרך איזשהו חשבון וירטואלי משעשע של מפתחים שנקרא I am Programmer, I have no life - והציטוט הבא מגיע [גם] משם:“When someone ask you what programming language they should learn, don't simply answer the one you prefer. First - ask them what area they plan to focus on. For example:webfrontend: JavaScriptbackend: JavaScriptmobile apps: JavaScriptgames: JavaScriptai: JavaScript”[ובעברית]זהו, אז זה סוף ה-Quote הזה . . . (אלון) אני לא יודע אם זה מצחיק או עצוב . . . (רן) כן, אני מניח שאצל דותן תעשה Find-Replace ל-Rust, בסדר . . . ואלון - אתה רשאי לבחור ב-Go . . . ונעבור לאייטם הבא . . .אז אחד מה-Release notes - אתם יודעים, כל פעם שמשחררים אפליקציה ל-App-store, צריך לכתוב ככה Release Notes - אז Slack, באחד מה-Release Notes האחרונים שלהם, כתבו ככה: What's New - מה חדש ב-release האחרון של Slack ל-AppStore - אז ככה הם כותבים:“How's everybody doing out there? Are you getting enough sleep? Drinking enough water? Eating some vegetables here and there? . . . “וכו' וכו' -בקיצור: “לא היה לנו מה לכתוב, אז שיהיה לכם יום טוב - באהבה, ביי . . . .”אז כן - אז Release Notes משעשעים, לא תמיד צריך לכתוב את מספר הבאגים שתוקנו, אם אין לכם שום דבר מעניין . . . (דותן) אה - זה אמיתי! . . . (רן) זה אמיתי . . . לגמרי אמיתי, מלפני כמה שבועות [זה Slack 21.07.20] . . . נחמדחברה שהיא Corporate כבר לא קטן, באים וככה מכניסים איזשהו Easter egg כזה חמודטוב - האייטם הבא, לדעתי נתרם ע”י אלון, נכון? שלחת לנו את זה פה ב-WhatsApp . . . (אלון) זה היה ע”י זהר [זהר!] - (רן) אה, אז תודה זהר!למעשה, אני לא יודע אם זו בדיחה או משהו אמיתי, אבל זה איזשהו מועמד לתפקיד, ששלח איזשהו תיאור של היכולות שלו, והוא כותב:לנציגי ה-HR בחברה, הוא כותב להם “הנה - זה מה שאני מציע בתור עובד”: עלות חודשית - כך-וכך $; שעות בשבוע - 40 שעות בשבוע; Emails per week - 400; קפה, או הפסקות קפה או תה - 3; Overtime - . . . “בקיצור - הוא נותן איזשהו Spec של של עצמו, והכותרת של זה היא EaaS, כלומר: Employee as a Service . . . אז זה מה שהוא מציע ב-Spec שלו . . .עכשיו, לא בטוח . . . אני לא לגמרי הבנתי עד כמה זה רציני או “בדיחתי” . . . כי יש פה איזשהו נופך של 1 באפריל, שזה יכול להיות גם וגם . . . בכל אופן - זה יותר משעשע, של Employee as a Service ואיזשהו Spec שלו, כמו Spec של instance ב-EC2 . . . (דותן) זו, דרך התשובה, להד-האנטרים של העתיד . . . (רן) לגמרי . . . הנה, סגרנו פה מעגל, טוב . . . והאייטם הבא, גם הוא הגיע אלינו מאיפשהו ב-Twitter, התפרסם בימים האחרונים ב-Twitter של מי-אם-לא דובר צה”ל . . . .אז למעשה דובר צה”ל, או IDF@, אולי אפילו לא הדובר [זה ה-Official IDF Twitter…], מפרסמים חתיכת קוד, שנראית ככה כמו ב-#C לדעתי, של קוד שאומר ככה:“if (Hamas.IsAttacking){if (Hammas.Attacks.Contains(“rockets”) && Hammas.Attacks.Contains(“arson balloons”) && Hammas.Attacks.Contains (“violent riots”)){Terroism = true;RegionStability = false;Israel.Defend();“https://twitter.com/idf/status/1437433437439369217עכשיו נפרש . . . איך נפרש את הדבר הזה? . . . (דותן) קודם כל, הם היו צריכים לדאוג לזה, לפקטור “המפתח הציני” - שזה לא מתקמפל, ושזו השורה הראשונה בקובץ, וזה שאין פה בכלל פונקציה מעל זה, ושמות משתנים שמתחילים באות גדולה ומלא מלא בלגן קורה פה בקוד . . . (רן) אז בוא נסתכל על שני הצדדים - על החצי המלא והחצי הריק של הכוס:(1) - נחמד שניסו לתקשר לעולם בצורה של קוד, בצורה שהיא קצת גיקיתאבל (2) - אם אתם רוצים להיות רציניים, בואו נעשה באמת - כמו שדותן אמר - משהו שבאמת נקרא, שגיקים מצליחים לקרוא, לקמפל להם בראש - ולא לקבל התקף חרדה של “אם אלה האנשים שכותבים ב-IDF, אז ככה נראה המצב . . . .”[מה שבר-זיק אמר . . . ](דותן) אה, אתה אומר שזה משליך . . . לא חשבתי על זה . . . (רן) כן, אז Twitter היה מלא בתגובות של “חבר'ה, רבותיי - בואו, אולי כדי שלא נראה איך נראה הקוד שלנו, כדי שלא לעודד את החמאס או אחרים . . . “אז זה נחמד, ניסיון יפה - אבל מצד שני, מישהו היה צריך לעשות לזה Code Review לפני שזה פורסם ב-Twitter.(אלון) “שבר את הרשת”, כמו שאומרים . . . (רן) “שבר את הרשת” . . . בהחלט . . .ואלון - יש לך גם כמה אייטמים קטנים - בבקשה: כן - אז נמשיך עם Twitter: מישהו העלה תמונות, באמצעות נייר טואלט, כדי להסביר מה זה Non-Zero Value, 0, NULL ו-Undefined ב-JavaScripthttps://twitter.com/jaypeedevlin/status/1425513599515168772אז Non-Zero Value זה כשיש לך נייר טואלט, ואפס זה כשהגליל ריק - ו-NULL זה כשאין גליל . . .ו-Undefined זה כשאין גם מתקן לגליל . . . .זו ההגדרה - וזו תמונה חמודה ומשעשעת, זהועוד משהו - יש את ה-Extension ל-Terminal שדיברנו עליו פעם, בשם .FIG(רן) התקנתי אותו, דרך אגב . . . (אלון) הוא מדהים . . . הוא מדהים(רן) קצת מעצבן אותי . . . קצת מעצבן - הוא נחמד ויפה והכל, אבל קצת מעצבן . . . כל הזמן קופץ, קצת מעיק לדעתי . . .(אלון) אמרתי שהוא מגניב - למה אתה הורס לי? כאילו, אני לא מבין - בנאדם בא ואומר “מגניב” ו . . . (רן) אבל אני עדיין משתמש, הוא יפה . . . (אלון) או - תודה! אני מבקש רן - תוריד את זה בעריכה, באמת [לא קרה . . . ](רן) הוא מגניב, אמרתי כבר שהוא מגניב?(אלון) כן, אמרנו שהוא מגניב, יופי . . . אני לא מאמין, אתה סותר אותי מול הילדים

Social engineering lives on, Terraform turns 1.0, and more. Hosts Ken Rimple and Sujan Kapadia discuss this week's dev news. The post TechChat Tuesdays #41: Tetris in ClojureScript, Terraform 1.0, and Slack hackers appeared first on Chariot Solutions.

I talk with Mike Fikes about his quest to learn electronics, and in so doing, to make ClojureScript a workable option for programming a microcontroller. Crazy? Yes, yes it is. But also cool.

Cheers to the 14th trip around the sun of the language that’s made up of data! In this episode, Esko, Matti and Toni discuss Clojure, REPL, and how you can use them in your next project.GuestsMatti Lankinen’s programming career started from the little boy's dream of making his own games. C++ was too hard at the time, so he started making his own programming language. It was never finished. (Hands up, who can relate?)Toni Vanhala learned the alphabet by typing on the keyboard and copying BASIC programs his mother read aloud. A couple decades later, Toni got his Ph.D. after programming a custom gaze tracker, virtual humans that react to facial expressions, and a chair that senses emotions.HostEsko Lahti is an engineer who now works in the company that got him into Clojure. Now, his party trick at meetups is to rapid fire through an extensive list of parentheses jokes.Episode linksThe Clojure programming language: https://clojure.org/Shadow CLJS: https://shadow-cljs.github.io/docs/UsersGuide.htmlLeiningen: https://leiningen.org/Pedestal: https://github.com/pedestal/pedestalclojurians.slack.com community (invite link): http://clojurians.net/Reitit, data-driven router for Clojure(Script): https://github.com/metosin/reititclj-kondo, a linter for Clojure: https://github.com/clj-kondo/clj-kondocljfmt, a tool for formatting Clojure: https://github.com/weavejester/cljfmtHiccup, a library for representing HTML in Clojure: https://github.com/weavejester/hiccupIntegrant: https://github.com/weavejester/integrantCursive, the Clojure(Script) IDE: https://cursive-ide.com/Nightlight, an embedded editor for Clojure: https://sekao.net/nightlight/Reagent, React for ClojureScript: https://reagent-project.github.io/re-frame, a ClojureScript framework for UIs: https://github.com/day8/re-frameRich Hickey’s most influential talks: https://changelog.com/posts/rich-hickeys-greatest-hitsAbout ReaktorFork Pull Merge Push is a podcast by Reaktor, a strategy, design and technology company changing how the world works. Reaktor has offices in New York, Amsterdam, Stockholm, Tokyo and Helsinki, Turku and Tampere.Reaktor is always on the lookout for bright software developers to work in health, security, emerging technologies, and much more.See www.reaktor.com/careers.@ReaktorNow#FPMPod

Episode 69 - we go back to our first ever guest, Mike Fikes, creator of ambly, replete and bringing Clojurescript to microcontrollers!

Alan on GitHub - https://github.com/alandipert Alan on Twitter - https://twitter.com/alandipert Alan's website - https://tailrecursion.com/~alan/Home.html Hoplon on GitHub - https://github.com/hoplon/hoplon Holpon's website - http://hoplon.io/ - Hoplon and Javelin, Micha Niskin - https://www.youtube.com/watch?v=UoZyyo2Bwr8 - High level UI toolkit built on Hoplon: https://github.com/jumblerg/ui - cljson: https://github.com/tailrecursion/cljson - Example app using shadow-cljs with Hoplon: https://github.com/rlander/conduit - Equality operator rationale in Common Lisp: http://www.lispworks.com/documentation/HyperSpec/Issues/iss143_w.htm - Hoplon and Bacwn (pre-Datomic Datalog): https://alandipert.github.io/hoplon-demos/bacwn-hoplon/ - FRP in ClojureScript with Javelin: https://tailrecursion.com/~alan/index.cgi/doc/tip/documents/Dipert-FRP_in_ClojureScript_with_Javelin.pdf, http://www.infoq.com/presentations/ClojureScript-Javelin, https://github.com/tailrecursion/javelin - Flapjax and ClojureScript: https://www.youtube.com/watch?v=xaxF5RDdVRE#t=22m21s, https://github.com/alandipert/flapjax-demo, http://alandipert.github.io/flapjax-demo/ - Flapjax Paper - https://cs.brown.edu/people/sk/Publications/Papers/Published/mgbcgbk-flapjax/paper.pdf - Micha on Hoplon vs React - https://tailrecursion.com/~alan/micha_on_hoplon_vs_react/ Video Courses: https://www.LearnReitit.com (new) https://www.LearnReFrame.com https://www.LearnReagent.com

РОЗЫГРЫШ книги в первом комментарии! Почему TypeScript - трата времени, Flow чуть получше, но все равно победил ReasonML? Про сильные стороны и фейспалм. Видео версия https://youtu.be/nZDN6XCM1X0 Антон Тужик, Frontend Developer из SEMrush рассказывает про год использования ReasonML в продакшене. 00:00 - Вступление 00:33 - Из геолога в программисты. Курсы, книги, подкасты 11:39 - Как и почему уходили от Javascript 13:20 - Почему выбрали Flow, а не TypeScript 16:25 - Что такое Soundness 19:45 - Как типы изменили тестирование 24:18 - Как Flow показал себя 26:52 - Поиск альтернатив: Elm, ClojureScript, ReasonML, Purescript, Dart 30:57 - ReasonML - это отдельный язык? 31:32 - Зачем извратили OCaml? 32:49 - OCaml и Javascript 35:34 - Что такое BuckleScript 38:07 - Javascript на выходе, хорош ли? 47:36 - Про фейсбук и OCaml 50:34 - Чем хорош OCaml 51:36 - Причины почему ReasonML 52:20 - Interop и монадки 53:58 - Скорость разработки на ReasonML 54:34 - Как затащили ReasonML в компанию 56:23 - Рынок ReasonML 01:00:47 - ReasonML подхватывается командой 01:01:52 - Аннотации и вывод типов 01:04:00 - Кривая обучения ReasonML 01:09:53 - Про модули в ReasonML и OCaml 01:16:41 - Сколько месяцев на изучение? 01:20:59 - Hegel лучше или хуже ReasonML 01:25:38 - Инструменты ReasonML и интеграция 01:31:21 - ReasonML в компании 01:32:37 - BuckleScript и ReScript 01:42:30 - Как так вырасти за 4 года 01:47:16 - Самообразование и баланс работы

Участники: Старинин Андрей - преподаватель Компьютерная Академия ШАГ Воронеж Пушкин Сергей - Java Dev, веду канал "IT жизнь Воронежа" Антон Чикин - закончил ПММ, работал в куче разных компаний с разными технологиями, сейчас занимаюсь frontend разработкой на языке Clojurescript. В свободное время люблю покопаться в истории IT индустрии и поразбираться как мы дошли до жизни такой. Андрей Беляев - Developer Advocate в компании Haulmont. Ассистент кафедры программирования и информационных технологий факультета компьютерных наук ВГУ. ******** Сайт - https://it-edu.github.io/ Группа в VK - https://vk.com/podcast_it_za_edu YouTube-канал - https://www.youtube.com/channel/UC8UfZgI5XR9Cgf2D9b1PKgw Telegram-канал -  https://t.me/podcast_it_za_edu Twitter - https://twitter.com/ITEdu2 Instagram - https://www.instagram.com/it_za_edu/ Чат для обсуждения выпусков - https://t.me/podcast_it_za_edu_chat Архив выпусков - https://t.me/podcast_it_za_edu_archive

JavaScript Remote Conf 2020 May 14th to 15th - register now! Josh Ponelat is Software Architect at SmartBear working on Swagger and OpenAPI. He's from South Africa. Josh's father is a programmer and was heavily influenced by his father. He started with ANSI-C and hacking on shells. He studied graphic design in school. He got back into programming in PHP and MySQL and wound up transitioning to JavaScript. Host: Charles Max Wood Joined By Special Guest: Josh Ponelat Sponsors Sentry CacheFly ______________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ______________________________________ Links JSJ 409: Swagger and Open API with Josh Ponelat D3.js Swagger.io What is OpenAPI? SwaggerHub Immutable JSJ 243 Immutable.js with Lee Byron 231 RR GraphQL with Lee Byron Hacker News Clojure ClojureScript Parinfer Datomic Cloud Picks Josh Ponelat: Miro Pour Over Coffee Charles Max Wood: Interview Cake Docking Station

JavaScript Remote Conf 2020 May 14th to 15th - register now! Josh Ponelat is Software Architect at SmartBear working on Swagger and OpenAPI. He's from South Africa. Josh's father is a programmer and was heavily influenced by his father. He started with ANSI-C and hacking on shells. He studied graphic design in school. He got back into programming in PHP and MySQL and wound up transitioning to JavaScript. Host: Charles Max Wood Joined By Special Guest: Josh Ponelat Sponsors Sentry CacheFly ______________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ______________________________________ Links JSJ 409: Swagger and Open API with Josh Ponelat D3.js Swagger.io What is OpenAPI? SwaggerHub Immutable JSJ 243 Immutable.js with Lee Byron 231 RR GraphQL with Lee Byron Hacker News Clojure ClojureScript Parinfer Datomic Cloud Picks Josh Ponelat: Miro Pour Over Coffee Charles Max Wood: Interview Cake Docking Station

JavaScript Remote Conf 2020 May 14th to 15th - register now! Josh Ponelat is Software Architect at SmartBear working on Swagger and OpenAPI. He's from South Africa. Josh's father is a programmer and was heavily influenced by his father. He started with ANSI-C and hacking on shells. He studied graphic design in school. He got back into programming in PHP and MySQL and wound up transitioning to JavaScript. Host: Charles Max Wood Joined By Special Guest: Josh Ponelat Sponsors Sentry CacheFly ______________________________________ "The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is now available on Amazon. Get Your Copy Today! ______________________________________ Links JSJ 409: Swagger and Open API with Josh Ponelat D3.js Swagger.io What is OpenAPI? SwaggerHub Immutable JSJ 243 Immutable.js with Lee Byron 231 RR GraphQL with Lee Byron Hacker News Clojure ClojureScript Parinfer Datomic Cloud Picks Josh Ponelat: Miro Pour Over Coffee Charles Max Wood: Interview Cake Docking Station

Magnar Sveen og Christian Johansen fra Kodemaker er på besøk! Vi stiller hundre smarte og dumme spørsmål om funksjonell programmering generelt, og Clojure og ClojureScript spesielt. Også finner vi ut av hvordan man uttaler Adventur Delux.See omnystudio.com/listener for privacy information.

We talked to Martin (https://www.sauspiel.de/schafkopf-lernen fame) to learn about a famous Bavarian card game. Oh, also we talk about some other stuff like Erlang, Clojure and ClojureScript :)

John jr0cket Stevenson on twitter - https://twitter.com/jr0cket Practicali Guides - http://www.practical.li/ Clojure - https://practicalli.github.io/clojure/ Clojure Webapps - https://practicalli.github.io/clojure-webapps/ Clojurescript - https://practicalli.github.io/clojurescript/ Spacemacs - https://practicalli.github.io/spacemacs/ Study Group - https://www.youtube.com/playlist?list=PLy9I_IfUBzKJSgctCJaRYcnF6kZdiZ5ku Video Courses: www.learnreagent.com/ www.learnreframe.com/ www.jacekschae.com/

Поздравляем всех .Net разработчиков с профессиональным праздником! В том время как .Net Core 3.0 подходит к финишной прямой мы решили поделиться нашим опытом использования preview версии. Кроме того, мы пригласили гостя, который готов рассказать все что думает про Blazor и WebAssembly. Более того, у нас появилась новая рубрика "Новости одной строкой"! В ней мы перечисляем топики, которые не вошли в основной стрим, но достойны упоминания. Спасибо всем кто нас слушает. Не стесняйтесь оставлять обратную связь и предлагать свои темы. Ссылка для скачивания: https://dotnetmore.ru/wp-content/uploads/2019/09/DotNetAndMore-21-Blazor.mp3 Shownotes: - [0:03:52] DotNet Core 3.0 на проде - [0:08:18] Жизнь на preview версиях - [0:13:46] AspNet Core 3.0 и его фитчи - [0:18:54] Blazor - [0:23:52] Shared business logic и Xamarin - [0:46:11] Очередной оффтопик про Go - [0:52:37] C#8 на проде - [1:13;46] Новости одной строкой Ссылки: - https://andrewlock.net/series/exploring-asp-net-core-3/ Series: Exploring ASP.NET Core 3.0 - https://channel9.msdn.com/Shows/Visual-Studio-Toolbox/Blazor-Tips-and-Tricks Blazor Tips and Tricks - https://www.infoq.com/articles/webassembly-blazor/ WebAssembly and Blazor: A Decades Old Problem Solved - https://channel9.msdn.com/Shows/On-NET/Server-side-Blazor-in-NET-Core-30 Server-side Blazor in .NET Core 3.0 - https://devblogs.microsoft.com/dotnet/try-out-nullable-reference-types/ Try out Nullable Reference Types - https://devblogs.microsoft.com/dotnet/default-implementations-in-interfaces/ Default implementations in interfaces - https://www.dotnetconf.net/ .NET Conf 2019 - https://www.hanselman.com/blog/dotnetNewWorkerWindowsServicesOrLinuxSystemdServicesInNETCore.aspx dotnet new worker - https://devblogs.microsoft.com/dotnet/net-core-and-systemd/ .NET Core and systemd - https://raygun.com/blog/dot-net-debugging NET Debugging: 6 techniques you need in your arsenal - https://michaelscodingspot.com/logging-in-dotnet Logging in C# .NET Modern-day Practices: The Complete Guide - http://tooslowexception.com/net-memory-management-posters/ .NET Memory Management posters Ссылки (off topic): - https://tabnine.com/: TabNine - https://youtu.be/R4sTvHXkToQ: Александр Соловьев "Functional Reactive Programming & ClojureScript" Слушайте и скачивайте нас на сайте: https://dotnetmore.ru/podcast/21-blazor/ Не забывайте оставлять комментарии: https://vk.com/dotnetmore?w=wall-175299940_186

Mike and Wes debate the merits and aesthetics of Clojure in this week's rowdy language check-in. Plus why everyone's talking about the sensitivity conjecture, speedy TLS with rust, and more!

Mike Fikes on Twitter - https://twitter.com/mfikes ClojureScript Compiler - https://github.com/clojure/clojurescript ClojureScript Contributing - https://clojurescript.org/community/contributing Maria Geller's ClojureScript compiler talk - www.youtube.com/watch?v=Elg17s_nwDg Video Courses: www.learnreagent.com/ www.learnreframe.com/ www.jacekschae.com/

We react to Apple's big news at WWDC, check in with Mike's explorations of Elixir, and talk some TypeScript. Plus Mike's battles with fan noise, and why he's doubling down on the eGPU lifestyle.

On this week's episode, Chris is joined by Glenn Vanderburg, VP of Engineering at First.io, live from RailsConf. They discuss Glenn's RailsConf talk, "The 30-Month Migration", covering distributed data models, refactoring, and the wonders of postgres. They also discuss Glenn's famous talk, "Real Software Engineering", and what the term "software engineering" means within our communities. Glenn on Twitter Glenn's RailsConf talk - The 30-Month Migration Glenn's blog First.io Postgres MySQL Postgres Common Table Expressions (CTEs) Swanand Pagnis - It's 2017, and I still want to sell you a graph database! GraphQL Glenn Vanderburg - Real Software Engineering Agile Manifesto Extreme Programming Rust Language Kathleen Fisher Kathleen Fisher, High Assurance Systems AWS Firecracker Bike Shed with Lin Clark & Till Schneidereit on WebAssembly & WASI Fastly Lucet Chaos Engineering Chaos Monkey Joe Armstrong Erlang Property Based Testing Erlang Actor Model Clojure ClojureScript Functional Core, Imperative Shell Sorbet - Stripe library for gradual static typing in Ruby

David Nolen - https://twitter.com/swannodette Show notes: ClojureScript Release - https://www.youtube.com/watch?v=tVooR-dF_Ag Mythical Man Month - https://en.wikipedia.org/wiki/The_Mythical_Man-Month No Silver Bullet - http://faculty.salisbury.edu/~xswang/Research/Papers/SERelated/no-silver-bullet.pdf Out of the Tar Pit - https://github.com/papers-we-love/papers-we-love/blob/master/design/out-of-the-tar-pit.pdf React - https://reactjs.org/ Clojure - https://clojure.org/ ClojureScript - https://clojurescript.org/ Datomic - https://www.datomic.com/ MVC - https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller Figwheel - https://figwheel.org/ cljs-devtools - https://github.com/binaryage/cljs-devtools reagent - https://github.com/reagent-project/reagent re-frame - https://github.com/Day8/re-frame shadow-cljs - https://github.com/thheller/shadow-cljs Google Closure Compiler - https://github.com/google/closure-compiler CLJSJS - https://cljsjs.github.io/ ClojureScript with Webpack - https://clojurescript.org/guides/webpack Maria Geller's ClojureScript compiler talk - https://www.youtube.com/watch?v=Elg17s_nwDg Video Courses: https://www.learnreagent.com/ https://www.learnreframe.com/ https://www.jacekschae.com/

We celebrate the life of Erlang author Dr Joe Armstrong by remembering his many contributions to computer science and unique approach to lifelong learning. Plus some code to read, your feedback, and more!

Jonathan Boston discusses Clojure, business, the best and worst code he wrote last year, and the ClojureScript community.. ClojureScript Made Easy My Worst and Best Code of 2018 10,000 core.async processes

Шоу нотес Референсный вопрос от @devschacht circleci/frontend - пример open source фронтенда на clojurescript re-frame - одна из основных библиотек фронтендd на clojurescript kee-frame Phoenix LiveView - внезапно: опять рендерить html на сервере Николай Рыжиков — Make frontend «backend» again Robert C Martin - Clean Architecture and Design react-virtualized Pact - cross-boundary проверка контрактов REST over WebSocket Андрей Зайцев - Abstract Reconciliation noria-clj Никита Прокопов — Клиенту и серверу нужно поговорить Logux - синхронизация actions re-posh - вывести diff state из транзакционного лога PipelineDB - realtime computation on streams shadow-cljs MrAnderson - dependencies as source Datomic Ions группа hypothesis для аннотаций, картинка выпуска Послушал? Оставь отзыв На hardcode.fm hardcodefm@telegram + группа hardcodefm@facebook hardcodefm@vkontakte

Mike has salvaged a success story from the dumpster fire of the Google+ shutdown, and Wes shares his grief about brittle and repetitive unit tests. Plus Mike reviews the System76 Darter Pro, our tool of the week, and some fantastic audience feedback.

Sponsors Sentry use the code “devchat” for $100 credit Netlify Triplebyte CacheFly Panel Lucas Reis Justin Bennett Nader Dabit Charles Max Wood Episode Summary In this 50th episode of React Round Up, the panelists start with talking briefly about themselves, their work, as well as their side projects. Lucas Reis is a Senior Frontend Engineer at Zocdoc, and is working on the Zocdoc website, specifically on performance and SEO. He is also involved in sharing frontend knowledge throughout the company. Justin Bennett is a Senior Engineer at Artsy and focuses on web performance along with several open source projects. He is also interested in release processes and continuous integration. Nader Dabit is with Amazon Web Services as a Developer Advocate, working on GraphQL, React to React Native, Vue and is involved in community work too. Charles Max Wood is mainly focused on making this podcast better that includes things like getting sponsors, dealing with business issues, releasing the episodes on time, etc. He talks about his mission to help people find fulfillment from coding and enabling them to achieve their ideal lifestyle. They discuss hard and soft skills in software development, their interdependence and importance, and also the fact that the skills required to become a good developer are needed for personal development in general as well. They then mention their favorite past episodes and the growth of different programming ecosystems and communities such as React, Vue, Angular, etc. With respect to upcoming projects in React, they talk a bit about Suspense, Concurrent React, server-side rendering, performance issues, Prepack, compiler optimizations and Reason React. Finally, they each mention what they do apart from regular development work to unwind and relax. Links Artsy The Dev Rev React 16 Roadmap Reason ReasonReact ClojureScript Thinkster Disney Heroes Battlemode Picks Justin Bennett: Inter Can’t Unsee design game Lucas Reis: The Law of Leaky Abstractions Nader Dabit: React Native Open GraphQL newsletter Charles Max Wood: Libsyn WordPress DigitalOcean Microphones – Electro-Voice RE20, Audio-Technica ATR2100

Sponsors Sentry use the code “devchat” for $100 credit Netlify Triplebyte CacheFly Panel Lucas Reis Justin Bennett Nader Dabit Charles Max Wood Episode Summary In this 50th episode of React Round Up, the panelists start with talking briefly about themselves, their work, as well as their side projects. Lucas Reis is a Senior Frontend Engineer at Zocdoc, and is working on the Zocdoc website, specifically on performance and SEO. He is also involved in sharing frontend knowledge throughout the company. Justin Bennett is a Senior Engineer at Artsy and focuses on web performance along with several open source projects. He is also interested in release processes and continuous integration. Nader Dabit is with Amazon Web Services as a Developer Advocate, working on GraphQL, React to React Native, Vue and is involved in community work too. Charles Max Wood is mainly focused on making this podcast better that includes things like getting sponsors, dealing with business issues, releasing the episodes on time, etc. He talks about his mission to help people find fulfillment from coding and enabling them to achieve their ideal lifestyle. They discuss hard and soft skills in software development, their interdependence and importance, and also the fact that the skills required to become a good developer are needed for personal development in general as well. They then mention their favorite past episodes and the growth of different programming ecosystems and communities such as React, Vue, Angular, etc. With respect to upcoming projects in React, they talk a bit about Suspense, Concurrent React, server-side rendering, performance issues, Prepack, compiler optimizations and Reason React. Finally, they each mention what they do apart from regular development work to unwind and relax. Links Artsy The Dev Rev React 16 Roadmap Reason ReasonReact ClojureScript Thinkster Disney Heroes Battlemode Picks Justin Bennett: Inter Can’t Unsee design game Lucas Reis: The Law of Leaky Abstractions Nader Dabit: React Native Open GraphQL newsletter Charles Max Wood: Libsyn WordPress DigitalOcean Microphones – Electro-Voice RE20, Audio-Technica ATR2100

Arne Brasseur talks about Kaocha, Heart of Clojure, Lambda Island, and Clojureverse. Kaocha Fudge Midge Avdi Grimm - Transaction Fallacy Kaocha docs on cljdoc Clojurists Together funding announcement Clojurists Together projects Heart of Clojure Announcing Clojureverse Lambda Island Guide to Clojure REPLs Figwheel Main + CIDER + Clojure CLI video Lambda Island Guides on GitHub Clojure.org REPL guides Clojureverse Clojure workflows on Clojureverse Clojurians Slack Log Hiring Arne

Apple wades into controversy after filing some Swift-related patents and we explore WebAssembly and its implications for the open web. Plus the latest on Mike's road to Rust, some great feedback, and more!

Fredrik talks to Dan Lebrero, long-time Java developer turned Clojure developer, REPL-user, efficiency-thinker and more. We discuss the wonders of REPL-driven development, and how it works. Dan opens Fredrik’s eyes somewhat to the possibilities and how they happen. The REPL can complement TDD, and also probably kill test writing for those not completely test infected. We also discuss finding good tools, learning them, and of course building your own tools. Have you learned Bash as well as it deserves? Thank you Cloudnet for sponsoring our VPS! Comments, questions or tips? We are @kodsnack, @tobiashieta, @oferlund and @bjoreman on Twitter, have a page on Facebook and can be emailed at info@kodsnack.se if you want to write longer. We read everything we receive. If you enjoy Kodsnack we would love a review in iTunes! Links Daniel Lebrero Akvo Clojure Lisp Scala DAO - Data access object DTO - Data transfer object Dynamic typing REPL - read-eval-print loop TDD - test-driven development The extreme programming book Dan’s talk about using a REPL Clojurescript Bash Dan’s post and talk about writing tools for yourself Titles I’m just a regular guy Out of desperation I looked at Clojure I remember the day that I gave up on Java It was a very long walk The fastest feedback loop that I know of It’s a long loop The exploration phase Keep modifying your running application You are already done A proper IDE in your dev tools It just happens, and it’s immediate The immediate feedback loop I never misplace a parenthesis I never have to select things by hand I’m not sure what I’m missing Little automation tools for yourself

Antonio Monteiro talks about building Lumo, improving the ClojureScript beginner experience, typed GraphQL in OCaml, and creating a custom AWS Lambda runtime.. Sponsor: Deps - Private, Hosted, Maven Repositories Lumo CLJS GWT Pilloxa V8 custom startup snapshots Glitch with Lumo clj-commons Om Relay Falcor Ladder The REPL episode with Martin Klepsch OCaml Reason ML Lambda support for Powershell Rust runtime for AWS Lambda and GitHub project Antonio’s OCaml Lambda runtime AWS Lambda Runtime API Howard Lewis Ship on The REPL talking about GraphQL Small FP - Antonio Monteiro Developing ReasonML frontend with GraphQL Zeit

Mike Fikes talks about his recent work adding type inference to the ClojureScript compiler, the AOT cache, cljs.main, Clojurists Together, Graal.js, and Apropos.. CLJS-2865 Optimize string expression concatenation Type inference under :advanced compilation Parameter type inference Graal.js AOT cache Clojurists Together Apropos Clojure

Panel Brendan Eich Joe Eames Aaron Frost AJ ONeal Jamison Dance Tim Caswell Charles Max Wood Discussion 01:57 – Brendan Eich Introduction JavaScript [Wiki] Brendan Eich [Wiki] 02:14 – Origin of JavaScript Java Netscape Jim Clark Marc Andreesen NCSA Mosaic NCSA HTTPd Lynx (Web Browser) Lou Montulli Silicon Graphics Kernel Tom Paquin Kipp Hickman MicroUnity Sun Microsystems Andreas Bechtolsheim Bill Joy Sun-1 Scheme Programming Language Structure and Interpretation of Computer Programs – 2nd Edition (MIT Electrical Engineering and Computer Science) by Harold Abelson, Gerald Jay Sussman & Julie Sussman Guy Steele Gerald Sussman SPDY Rob McCool Mike McCool Apache Mocha Peninsula Creamery, Palo Alto, CA Main () and Other Methods (C# vs Java) Static in Java, Static Variables, Static Methods, Static Classes 10:38 – Other Languages for Programmers Visual Basic Chrome Blacklist Firefox 12:38 – Naming JavaScript and Writing VMs Canvas Andrew Myers 16:14 – Envisioning JavaScript’s Platform Web 2.0 AJAX Hidaho Design Opera Mozilla Logo Smalltalk Self HyperTalk Bill Atkinson HyperCard Star Wars Trench Run 2.0 David Ungar Craig Chambers Lars Bak Strongtalk TypeScript HotSpot V8 Dart Jamie Zawinski 24:42 – Working with ECMA Bill Gates Blackbird Spyglass Carl Cargill Jan van den Beld Philips Mike Cowlishaw Borland David M. Gay ECMAScript Lisp Richard Gabriel 31:26 – Naming Mozilla Jamie Zawinski Godzilla 31:57 – Time-Outs 32:53 – Functions Clojure John Rose Oracle Scala Async.io 38:37 – XHR and Microsoft Flash Hadoop Ricardo Jenez Ken Smith Brent Noorda Ray Noorda .NET Shon Katzenberger Anders Hejlsberg NCSA File Formats 45:54 – SpiderMonkey Chris Houck Brendan Eich and Douglas Crockford – TXJS 2010 Douglas Crockford JavaScript: The Good Parts by Douglas Crockford TXJS.com ActionScript Flex Adobe E4X BEA Systems John Schneider Rhino JScript roku Waldemar Horwat Harvard Putnam Math Competition Chris Wilson Silverlight Allen Wirfs-Brock NDC Oslo 2014 JSConf Brendan JSConf Talks 59:58 – JavaScript and Mozilla GIP SSLeay Eric A. Young Tim Hudson Digital Styles Raptor Gecko ICQ and AIM PowerPlant CodeWarrior Camino David Hyatt Lotus Mitch Kapor Ted Leonsis Mitchell Baker David Baren Phoenix Tinderbox Harmony 1:14:37 – Surprises with Evolution of JavaScript Ryan Dahl node.js Haskell Elm Swift Unity Games Angular Ember.js Dojo jQuery react ClojureScript JavaScript Jabber Episode #107: ClojureScript & Om with David Nolen MVC 01:19:43 – Angular’s HTML Customization Sweet.js JavaScript Jabber Episode #039: Sweet.js with Tim Disney TC39 Rick Waldron 01:22:27 – Applications with JavaScript SPA’s Shumway Project IronRuby 01:25:45 – Future of Web and Frameworks LLVM Chris Lattner Blog Epic Games Emscripten Autodesk PortableApps WebGL 01:29:39 – ASM.js Dart.js John McCutchen Monster Madness Anders Hejlsberg, Steve Lucco, Luke Hoban: TypeScript 0.9 – Generics and More (Channel 9, 2013) Legacy 01:32:58 – Brendan’s Future with JavaScript Picks hapi.js (Aaron) JavaScript Disabled: Should I Care? (Aaron) Aaron’s Frontend Masters Course on ES6 (Aaron) Brendan’s “Cool Story Bro” (AJ) [YouTube] Queen – Don't Stop Me Now (AJ) Trending.fm (AJ) WE ARE DOOMED soundtrack EP by Robby Duguay (Jamison) Hohokum Soundtrack (Jamison) Nashville Outlaws: A Tribute to Mötley Crüe (Joe) Audible (Joe) Stripe (Chuck) Guardians of the Galaxy (Brendan)

Panel Brendan Eich Joe Eames Aaron Frost AJ ONeal Jamison Dance Tim Caswell Charles Max Wood Discussion 01:57 – Brendan Eich Introduction JavaScript [Wiki] Brendan Eich [Wiki] 02:14 – Origin of JavaScript Java Netscape Jim Clark Marc Andreesen NCSA Mosaic NCSA HTTPd Lynx (Web Browser) Lou Montulli Silicon Graphics Kernel Tom Paquin Kipp Hickman MicroUnity Sun Microsystems Andreas Bechtolsheim Bill Joy Sun-1 Scheme Programming Language Structure and Interpretation of Computer Programs – 2nd Edition (MIT Electrical Engineering and Computer Science) by Harold Abelson, Gerald Jay Sussman & Julie Sussman Guy Steele Gerald Sussman SPDY Rob McCool Mike McCool Apache Mocha Peninsula Creamery, Palo Alto, CA Main () and Other Methods (C# vs Java) Static in Java, Static Variables, Static Methods, Static Classes 10:38 – Other Languages for Programmers Visual Basic Chrome Blacklist Firefox 12:38 – Naming JavaScript and Writing VMs Canvas Andrew Myers 16:14 – Envisioning JavaScript’s Platform Web 2.0 AJAX Hidaho Design Opera Mozilla Logo Smalltalk Self HyperTalk Bill Atkinson HyperCard Star Wars Trench Run 2.0 David Ungar Craig Chambers Lars Bak Strongtalk TypeScript HotSpot V8 Dart Jamie Zawinski 24:42 – Working with ECMA Bill Gates Blackbird Spyglass Carl Cargill Jan van den Beld Philips Mike Cowlishaw Borland David M. Gay ECMAScript Lisp Richard Gabriel 31:26 – Naming Mozilla Jamie Zawinski Godzilla 31:57 – Time-Outs 32:53 – Functions Clojure John Rose Oracle Scala Async.io 38:37 – XHR and Microsoft Flash Hadoop Ricardo Jenez Ken Smith Brent Noorda Ray Noorda .NET Shon Katzenberger Anders Hejlsberg NCSA File Formats 45:54 – SpiderMonkey Chris Houck Brendan Eich and Douglas Crockford – TXJS 2010 Douglas Crockford JavaScript: The Good Parts by Douglas Crockford TXJS.com ActionScript Flex Adobe E4X BEA Systems John Schneider Rhino JScript roku Waldemar Horwat Harvard Putnam Math Competition Chris Wilson Silverlight Allen Wirfs-Brock NDC Oslo 2014 JSConf Brendan JSConf Talks 59:58 – JavaScript and Mozilla GIP SSLeay Eric A. Young Tim Hudson Digital Styles Raptor Gecko ICQ and AIM PowerPlant CodeWarrior Camino David Hyatt Lotus Mitch Kapor Ted Leonsis Mitchell Baker David Baren Phoenix Tinderbox Harmony 1:14:37 – Surprises with Evolution of JavaScript Ryan Dahl node.js Haskell Elm Swift Unity Games Angular Ember.js Dojo jQuery react ClojureScript JavaScript Jabber Episode #107: ClojureScript & Om with David Nolen MVC 01:19:43 – Angular’s HTML Customization Sweet.js JavaScript Jabber Episode #039: Sweet.js with Tim Disney TC39 Rick Waldron 01:22:27 – Applications with JavaScript SPA’s Shumway Project IronRuby 01:25:45 – Future of Web and Frameworks LLVM Chris Lattner Blog Epic Games Emscripten Autodesk PortableApps WebGL 01:29:39 – ASM.js Dart.js John McCutchen Monster Madness Anders Hejlsberg, Steve Lucco, Luke Hoban: TypeScript 0.9 – Generics and More (Channel 9, 2013) Legacy 01:32:58 – Brendan’s Future with JavaScript Picks hapi.js (Aaron) JavaScript Disabled: Should I Care? (Aaron) Aaron’s Frontend Masters Course on ES6 (Aaron) Brendan’s “Cool Story Bro” (AJ) [YouTube] Queen – Don't Stop Me Now (AJ) Trending.fm (AJ) WE ARE DOOMED soundtrack EP by Robby Duguay (Jamison) Hohokum Soundtrack (Jamison) Nashville Outlaws: A Tribute to Mötley Crüe (Joe) Audible (Joe) Stripe (Chuck) Guardians of the Galaxy (Brendan)

Panel Brendan Eich Joe Eames Aaron Frost AJ ONeal Jamison Dance Tim Caswell Charles Max Wood Discussion 01:57 – Brendan Eich Introduction JavaScript [Wiki] Brendan Eich [Wiki] 02:14 – Origin of JavaScript Java Netscape Jim Clark Marc Andreesen NCSA Mosaic NCSA HTTPd Lynx (Web Browser) Lou Montulli Silicon Graphics Kernel Tom Paquin Kipp Hickman MicroUnity Sun Microsystems Andreas Bechtolsheim Bill Joy Sun-1 Scheme Programming Language Structure and Interpretation of Computer Programs – 2nd Edition (MIT Electrical Engineering and Computer Science) by Harold Abelson, Gerald Jay Sussman & Julie Sussman Guy Steele Gerald Sussman SPDY Rob McCool Mike McCool Apache Mocha Peninsula Creamery, Palo Alto, CA Main () and Other Methods (C# vs Java) Static in Java, Static Variables, Static Methods, Static Classes 10:38 – Other Languages for Programmers Visual Basic Chrome Blacklist Firefox 12:38 – Naming JavaScript and Writing VMs Canvas Andrew Myers 16:14 – Envisioning JavaScript’s Platform Web 2.0 AJAX Hidaho Design Opera Mozilla Logo Smalltalk Self HyperTalk Bill Atkinson HyperCard Star Wars Trench Run 2.0 David Ungar Craig Chambers Lars Bak Strongtalk TypeScript HotSpot V8 Dart Jamie Zawinski 24:42 – Working with ECMA Bill Gates Blackbird Spyglass Carl Cargill Jan van den Beld Philips Mike Cowlishaw Borland David M. Gay ECMAScript Lisp Richard Gabriel 31:26 – Naming Mozilla Jamie Zawinski Godzilla 31:57 – Time-Outs 32:53 – Functions Clojure John Rose Oracle Scala Async.io 38:37 – XHR and Microsoft Flash Hadoop Ricardo Jenez Ken Smith Brent Noorda Ray Noorda .NET Shon Katzenberger Anders Hejlsberg NCSA File Formats 45:54 – SpiderMonkey Chris Houck Brendan Eich and Douglas Crockford – TXJS 2010 Douglas Crockford JavaScript: The Good Parts by Douglas Crockford TXJS.com ActionScript Flex Adobe E4X BEA Systems John Schneider Rhino JScript roku Waldemar Horwat Harvard Putnam Math Competition Chris Wilson Silverlight Allen Wirfs-Brock NDC Oslo 2014 JSConf Brendan JSConf Talks 59:58 – JavaScript and Mozilla GIP SSLeay Eric A. Young Tim Hudson Digital Styles Raptor Gecko ICQ and AIM PowerPlant CodeWarrior Camino David Hyatt Lotus Mitch Kapor Ted Leonsis Mitchell Baker David Baren Phoenix Tinderbox Harmony 1:14:37 – Surprises with Evolution of JavaScript Ryan Dahl node.js Haskell Elm Swift Unity Games Angular Ember.js Dojo jQuery react ClojureScript JavaScript Jabber Episode #107: ClojureScript & Om with David Nolen MVC 01:19:43 – Angular’s HTML Customization Sweet.js JavaScript Jabber Episode #039: Sweet.js with Tim Disney TC39 Rick Waldron 01:22:27 – Applications with JavaScript SPA’s Shumway Project IronRuby 01:25:45 – Future of Web and Frameworks LLVM Chris Lattner Blog Epic Games Emscripten Autodesk PortableApps WebGL 01:29:39 – ASM.js Dart.js John McCutchen Monster Madness Anders Hejlsberg, Steve Lucco, Luke Hoban: TypeScript 0.9 – Generics and More (Channel 9, 2013) Legacy 01:32:58 – Brendan’s Future with JavaScript Picks hapi.js (Aaron) JavaScript Disabled: Should I Care? (Aaron) Aaron’s Frontend Masters Course on ES6 (Aaron) Brendan’s “Cool Story Bro” (AJ) [YouTube] Queen – Don't Stop Me Now (AJ) Trending.fm (AJ) WE ARE DOOMED soundtrack EP by Robby Duguay (Jamison) Hohokum Soundtrack (Jamison) Nashville Outlaws: A Tribute to Mötley Crüe (Joe) Audible (Joe) Stripe (Chuck) Guardians of the Galaxy (Brendan)

Wes joins Mike to discuss why .NET still makes sense, the latest antics from Fortnite, a brave new hope for JVM concurrency, and the mind-expanding benefits of trying a Lisp.

Suositun Te Kysytte, Me Vastaamme -sarjan kolmas osa! Riku ja Antti vastaavat kuulijoiden lähettämiin kysymyksiin. Lähetä kysymyksesi meille osoitteessa ## Heading ##bit.ly/webbidevaus! Miksi Tampere on niin hyvä paikka devaajalle? Johtuuko mustasta makkarasta vai Nokiasta, vaiko siitä että Tampereella on pari korkeakoulua joihin tulee hyviä tyyppejä opiskelemaan, jotka edelleen jäävät töihin ja perustavat yrityksiä? Pitkää aasinsiltaa pitkin varsinaiseen kysymykseen joka kuuluu seuraavasti: Millaisiin yhteisöihin tai yrityksiin kannattaisi hakeutua jos haluaa kehittyä hyväksi webbidevaajaksi? (Pekka) Fronttidevausta on tehty pitkään transpiloimalla jotain ES6-ES8 versiota selainten ymmärtämään muotoon. Vaihtoehtoisesti voi kirjoittaa ihan muulla kielellä (Elm, ClojureScript, Reason, Haskell, Scala, CoffeeScript) ja compiloida sen Javascriptiksi. Miten lähestyisitte lähdekielen valintaa ja onko teidän mielestänne mitään eroa onko lähdekieli JS-pohjainen (ES8) vai ei? Toki kaikki lähdekielet ja niiden tooling eivät ole samalla viivalla, joten voidaan rajoittaa kysymys kattamaan vain ES8 vs. Elm/ClojureScript. (Ykä) ORM vai RAW SQL? (tukkajukka) Jakson valinnat Antti: Quiver, The Programmer’s Notebook Riku: You Suck at Excel with Joel Spolsky Palautetta? Meidät saa Twitteristä kiinni tunnarilla @webbidevaus, hihasta voi nykiä myös Koodiklinikka-Släkissä.

Никита Прокопов, clojure-разработчик в компании Targetprocess, в гостях у Андрея Смирнова из Frontend Weekend. Хочешь поддержать Frontend Weekend, переходи на http://frontendweekend.ml ;) - Почему именно такой доклад был рассказан на HolyJS? 00:29 - Как пришел в разработку и почему перепробовал столько языков программирования? 02:13 - Почему в итоге был выбран Clojure и какие у него перспективы? 04:01 - Лучший ли Clojure функциональный язык и сложно ли найти разработчиков? 07:45 - Почему перебрался из Новосибирска в Москву и чего в ней не хватает? 11:08 - Для чего столько блогов и почему даже LiveJournal в актуальном состоянии? 13:13 - Есть ли какая-то образовательная цель у данных блогов? 15:44 - Какая команда стоит за Grumpy Website и как она создавалась? 18:08 - Почему используешь ClojureScript и кому в целом можно посоветовать на нём писать? 19:45 - Как и с какой целью был создан шрифт FiraCode? 22:27 - Почему был заброшен личный проект ongoodfilms.ru? 25:55 - Почему всегда кривляешься на фотографиях? 27:05 - Кем бы хотел быть, если бы не стал разработчиком? 27:46 - React, Angular, Vue или Ember? 28:41 - Какая справедливая зарплата для разработчика в Новосибирске? 29:08 - Готовим вместе с frontend-разработчиком 30:02 - Киносовет от Никиты 30:54 Ссылки по теме: 1) Доклад Никиты про обретение навыков – https://holyjs-piter.ru/talks/2wplwkamfw2wuqkeoiiikk 2) Обсуждённые блоги Никиты – https://tonsky.livejournal.com и https://grumpy.website 3) Созданный Никитой шрифт – https://github.com/tonsky/FiraCode 4) Полумёртвый сайт с рецензиями – http://ongoodfilms.ru 5) Сериал по наводке от Никиты – https://kinopoisk.ru/film/dostat-korotyshku-2017-1007465 6) Frontend Weekend Patreon – https://patreon.com/frontendweekend

Никита Прокопов, clojure-разработчик в компании Targetprocess, в гостях у Андрея Смирнова из Frontend Weekend. Хочешь поддержать Frontend Weekend, переходи на http://frontendweekend.ml ;) - Почему именно такой доклад был рассказан на HolyJS? 00:29 - Как пришел в разработку и почему перепробовал столько языков программирования? 02:13 - Почему в итоге был выбран Clojure и какие у него перспективы? 04:01 - Лучший ли Clojure функциональный язык и сложно ли найти разработчиков? 07:45 - Почему перебрался из Новосибирска в Москву и чего в ней не хватает? 11:08 - Для чего столько блогов и почему даже LiveJournal в актуальном состоянии? 13:13 - Есть ли какая-то образовательная цель у данных блогов? 15:44 - Какая команда стоит за Grumpy Website и как она создавалась? 18:08 - Почему используешь ClojureScript и кому в целом можно посоветовать на нём писать? 19:45 - Как и с какой целью был создан шрифт FiraCode? 22:27 - Почему был заброшен личный проект ongoodfilms.ru? 25:55 - Почему всегда кривляешься на фотографиях? 27:05 - Кем бы хотел быть, если бы не стал разработчиком? 27:46 - React, Angular, Vue или Ember? 28:41 - Какая справедливая зарплата для разработчика в Новосибирске? 29:08 - Готовим вместе с frontend-разработчиком 30:02 - Киносовет от Никиты 30:54 Ссылки по теме: 1) Доклад Никиты про обретение навыков – https://holyjs-piter.ru/talks/2wplwkamfw2wuqkeoiiikk 2) Обсуждённые блоги Никиты – https://tonsky.livejournal.com и https://grumpy.website 3) Созданный Никитой шрифт – https://github.com/tonsky/FiraCode 4) Полумёртвый сайт с рецензиями – http://ongoodfilms.ru 5) Сериал по наводке от Никиты – https://kinopoisk.ru/film/dostat-korotyshku-2017-1007465 6) Frontend Weekend Patreon – https://patreon.com/frontendweekend

Mike tells us how ClojureScript has finally steered him towards a decent replacement for Flash. There are many pearls of wisdom from the reframe supremo including his insights on documentation and we could listen forever to his views on finite state machines. More info and links over on https://defn.audio

Taras Mankovski: tarasm In this episode, Taras and Charles talk about a project that they work on together: Funcadelic - a Functional Programming and Category Theory for Everyday JavaScript Development. Funcadelic takes the simple idea that a single function can operate on many different data structures (typeclass oriented programming) and brings it to JavaScript. Yes, there are a lot of FP libraries out there, but this one is geared towards unlocking the magical powers of functional programming while always maintaining a tangible and accessible experience for JavaScript developers. Because if you're a JavaScript developer today, you're already using most of the structures in funcadelic! Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast Episode 99. My name is Charles Lowell, developer here at The Frontside and your podcast host-in-training. And with me today is Mr. Taras Mankovski. Welcome. TARAS: Thank you, Charles. It's a pleasure to be here. CHARLES: Yeah. So, you are ubiquitous in the JavaScript world. You do a lot of stuff with mentoring and you are involved in a bunch of different interesting projects. I think you're one of those developers who's difficult to classify, which is – that's definitely one of my favorite kind of developers. I wanted to have you on the show today because there's been a project that we've been collaborating on. And there have been some interesting ideas to come out of that and solidify through that project, at least in my head. And yeah, I thought we could maybe just talk about that a little bit. TARAS: Yeah, sounds good. It's going to be fun. : The thing that we are going to be talking about is a project called Funcadelic. It's more than really just a library, a JavaScript library on GitHub. It's kind of a different way of thinking about your code. And so, I know for me, where this really became part of my workflow was, when was it? It was about three months ago or something like that? Six months ago? TARAS: Oh, I think yeah, I think it's probably more six months ago. I think it's probably what, two months, I think probably December maybe? CHARLES: Okay. But it's hard now to imagine working without this tool on my workbench. It's been probably the biggest game-changer for me in the last, I don't know, definitely in the last several years. TARAS: Yeah, it's pretty impressive how little, how small of a library can have such a big impact in what we do day-to-day. Because it definitely makes me think differently about how I can solve problems that I solve on a daily basis when I work with React. So, it's been pretty interesting. I think for me, having worked with this library, I think what I'm getting is an understanding of how things work in a way, and a perspective on how React works, in a way that I don't think was available to [inaudible] Funcadelic. The funny thing is it's not a React library, right? It's not designed for React. It's just that… CHARLES: I don't even think that – it helps you think about React, but I don't even think it's the way that the React developers think about React, right? TARAS: Yeah, I don't think so, either. I think a lot of people are on the spectrum of understanding functional programming. And I think a lot of people use, people learn how to use React, but they don't really – I don't think a lot of people have traveled very far. I'm talking about general, majority. There's definitely people who know functional programming really well. And there's a lot of really good libraries in the JavaScript space for doing functional programming in JavaScript. But I don't think the general public, the general people that on a daily basis go into – write a render function and do ‘this.' or like ‘product.map' and then return an array of components. I don't think those people necessarily think about or get the context within which they use this tool. CHARLES: Right. And I think that's actually kind of one of the reasons I think a library like Funcadelic is so important and fills kind of a missing piece in the ecosystem, is because it really is predicated on the idea that programmers use these concepts all the time. They really are, they're foundational. But we only kind of see them out of the corner of our eye, in our peripheral vision, as being like a formal concept, like mapping. And giving a name to that. You know what I mean? Like you do the mapping, but you're not thinking about: how do I generalize over it? And I think that that for me, certainly in my journey with functional programming, I thought that it was mostly about functions. Not to say that it isn't, but that was kind of the end of the story. It's like, keep your functions pure so that the outputs are only dependent on the inputs. And away you go. And understand closures and higher-order functions, functions that return functions or take functions, and that's it. But I really feel that that's only half the story. TARAS: Part of it I think is that for people, even if you look at the kind of content that's available around functional programming, it tends to be – trying to kind of [reach] people into this idea of thinking of map, filter, reduce, kind of operations. And I think that's a place where everybody starts. But I think what happens is that you really are missing – and I think for most people. And it wasn't for me, it wasn't until you wrote the readme for Funcadelic and then I read it – up until that point I didn't really, I was also the same. I didn't know how these things were related to each other. Because there's this history and wealth of conceptual depth that connects all these things together. And these things are well-understood by people who don't – they're probably not writing JavaScript on a daily basis. They might be like Haskell programmers or Lisp programmers or ClojureScript or something like it. In other worlds, not JavaScript world. So there is all this understanding about how functional programming works but I don't think it's really leaked to the general masses of the JavaScript community. CHARLES: Yeah. TARAS: You know? And it wasn't until I started reading the readme – I'm like, “There's so many answered questions that I didn't even know these questions were asked.” You know? CHARLES: Yeah, yeah. Yeah, no. And I think you're absolutely right. It isn't accessible to the general JavaScript community. And part of that is because one person's – like when you read about these things, when I would go read about these kind of higher-order concepts, of basically classifying functions, not just of saying, “Yeah, what is the essence of a map operation? What's the essence of an apply operation?” you know, “What's the essence of concatenation?” things like that, I go read the documentation in Haskell or in Clojure. And first of all, it's hard to distinguish when you're not programming in those day-to-day, am I reading reference documentation or explanatory documentation? But even in the explanatory documentation, they're using what seems like incredibly self-referential and abstract examples. And I don't think that's necessarily a knock against those communities. I think what it is, is what's concrete to one person is abstract to another. And it's like, if you're working with those things, you're working with those sets of analogies, and then you're working with those abstractions every day, then they're concrete to you. In a sense that once it clicks in your mind and your mind kind of accepts it and rationalizes over it, then it moves from being, “Yes, it's an abstraction. But it's a concrete abstraction,” in the sense that you can have a conversation with somebody and use that abstraction as an example, as a counterpoint, and a method triangulate and reveal other abstractions. But if you're talking to somebody for whom those abstractions haven't clicked yet, then it's just, it's opaque. And it's not helpful. And so, I think that one of the things that I realized is like we are using these abstractions, we just don't have names for them. And so, I wanted to give them names and put them in the hands. And the names are weird, but they are really useful. And so yeah, maybe we could talk about some of those right now. Because I think that maybe now's a good time to actually introduce some of those abstractions. So for example, if you don't know what a functor is, it's worthless to talk about a monad, in my opinion. So, that was critical piece of information for me. Because that is like missing in every monad tutorial you ever read. At least, I must have read a thousand monad tutorials. And they kind of glossed over functor or didn't mention it. Whatever. Maybe they did but I wasn't looking. And that needs to be put front and center, that there is a natural sequence to these things. It's like, some of these abstractions are built on other abstractions and you have to – you can't skip to monad. You have to start with functor. Again, I realize that's probably gibberish gobbledy-goop to a lot of people. So really, this is what Funcadelic is about, what this conversation is about, is just saying – talking through it in real-world examples to make those abstractions concrete, so it doesn't feel strange anymore. TARAS: Yeah. It's definitely giving names to things. I think it's really helpful. One thing I really like about Funcadelic is that you're not giving names that you made up. These are names that existed for 50 years. They're historic. And so, when you talk to somebody who is familiar with functional programming and if you say ‘functor', all of a sudden, I feel much smarter. And we're actually referencing the same thing, because we are – because alternatively, you can say something like, “Something that is mappable,” right? Like a functor is essentially describing something that you can map over. CHARLES: Right. That's all it is. TARAS: Right. But you know, having a name for it, it allows you to just describe it exactly as it is. CHARLES: So yeah, there are tons of things that you can map over, right? Most of the time, we think about arrays as something that we can map over. TARAS: One thing I found really interesting in starting to use Funcadelic is that when you start thinking about things as they are like abilities – like you know with an array you can map over an array. It's something we've all been doing for a while – but then something that you end up doing a lot of. When you get familiar with an array, being able to use object map, mapping an object, becomes something you want to do at some point. Most of the time, what happens is that you're like, “Oh, I don't actually – well, I have to write this thing. How do I write this thing?” and then by the time you do this, you're like, “I'm just going to go to Lodash and I'll just get the map thing that will map an object.” At the end of the day, it doesn't quite necessarily feel right because a lot of these libraries – like, Lodash has map but it feels like there is always some kind of a compromise with how these things are implemented. It's not consistent. CHARLES: Right. TARAS: And I don't remember exactly what the problem with Lodash map was. I know for a fact there are, like there's different ways that you can map things. There are different functions available for mapping different things in Lodash. CHARLES: There's ‘map to' and ‘map in' and blah, blah, blah, blah, blah. TARAS: Yeah. All those different variations. But I think it's been really interesting. We've been using Funcadelic on a project we've been working on, on microstates. And just being able to use one function map that is going to map an array or is going to map an object and it's going to do it the same, use the same function, and it's going to do the same thing. CHARLES: Yeah. You have one function that maps over the values. And that's the thing, is you realize you can map over arrays. You can map over objects. You can map over observables. You can map over promises. You can map over trees. You can map – there's literally thousands of things that you can map over. And realizing that all of these fragmented interfaces can be coalesced into a single interface. And so, it really is, I think the biggest thing is like the power of polymorphism for a function. Because that's basically the problem that I think – it's not I want to say basically the problem. I think it is a problem that a lot of the functional programming libraries suffer from, is that the only polymorphism is object polymorphism, which is kind of the native polymorphism in JavaScript. Whereas in systems like Haskell and like Clojure, you can have a function be polymorphic. And so, one function can operate on many different kinds of data, provided it has an interface. So, when we're working in microstates, we use literally one function: map. The same, the actual same function, reference to the same function we use everywhere when we map. And we're just mapping a bunch of different things. So, I think that that's one of the reasons that I prefer Rambda, for example, over Lodash, is because it has a form of polymorphism. Most of the things like maps and lenses and applicatives and stuff, almost everything works on both objects and arrays. That's actually kind of nice. So, Rambda has a basic polymorphism. But I think one of the other things that is really empowering about Funcadelic is that it allows you to make the map function work on any data structure that you happen to come up with. Anything that you want. You can make it mappable and map will work on it. TARAS: Yeah. I think for people, it's probably quite abstract, what that actually looks like. I think one thing that's interesting is that – so for listeners, the way that would look is you have a class, you have an ES6 class, which gives name to a certain piece of data that you have in your application. And then what you can do with Funcadelic, you can then say, “This is how you would implement – if you were to map this kind of an object, if you had an instance of this object, if you wanted to map that object, you can specify: what is the function you would use?” So, even though you would use the same – you would import map from Funcadelic and you would use that map to map whatever that object is and whatever type it is, but there's a way for you to say, “For instances of this type, I would like to use this specific implementation of a map to map that object,” but use one function to do it. So, it's going to use one function that you call. But you can specify, under the hood it can specify how the actual, what is actually used to map that instance. CHARLES: Right. And then that's nice, because then you can – anything that uses a mappable object, there's a couple of reasons that that's nice. Any time you can have some sort of higher-order mechanism that just requires that something be mappable, that it be a functor. And then it's really nice because then you can have higher-order operations that they just need something that's mappable. But you don't have to use that one shot of actually having a map function as a property of the object. You can actually, you can kind of define wrapper classes or whatever, that then introduce a unique way that this object can be mapped. So, you can have the same structure and map it three different ways. Whereas you're kind of constrained by that using normal OO inheritance because you have to have a map property on your object. TARAS: Yeah. There's something else actually, when you start thinking about this. For me personally, I think the first step when we start working with objects, having mappable objects, it was the first thing that was really helpful. But then I think really quickly, right after that, I think my second thing that I started using and I think is probably my favorite feature now, is append. I think it's actually – yeah, so append is an implementation of a semigroup but I think it's simpler. A simplest metaphor would be something like object assign. So, object assign is an implementation of a semigroup, except that object assign mutates the object that you pass into it. Right? CHARLES: Right. TARAS: It doesn't create a new object for you. CHARLES: Right. So again, getting to this idea that there are some universal operations. Like there's this idea that you can take two things – I don't want to say object because that's an actual concrete type in JavaScript – two things and you can smoosh them together. And I think there was actually – wasn't there literally a big controversy about this? TARAS: Yes. CHARLES: About like, array smoosh? I think this is nice – smooshing, right? But you can smoosh things together. And with addition, I can smoosh two integers together or two numbers together and get a third number, right? Or with objects, I can take two objects and smoosh them together by merging their keys. Or I can take two strings and I can smoosh them together and I can end up with a string that's concatenated. Or I can take two arrays and smoosh them together and I've got now an array that's been concatenated. So, what's interesting is these are all very, very different types that I've just described. And yet, there is some fundamental operation about them. And I think this is actually something that's bad about JavaScript is there's five different names for all those operations that we talked about, but it's really one unifying concept. And that might seem like a small thing, but when you have five different interfaces for one fundamental construct, that leads to fragmentation and you can't treat that data uniformly. And it ends up like, paper cuts, paper cuts everywhere. Whereas if you can unify all of these into a small, one thing, which is like we can append two objects, and then we're going to have an implementation of append for array. And behind the scenes it's going to call smoosh. And we've got a universal – we've got an implementation of append for object, which is going to assign the keys in an immutable way and return a new object. Or we're going to have an implementation of append for string which is going to concatenate the strings. You might even, I don't know a hardcore FP nerd would have to probably correct me because this is just totally conjecture, although I know it's probably a solved problem – is maybe you could say we append two functions together. And that returns a function which is composed, right? That might be a way that you could say – what would it look like? Is function a semigroup? Can we append two functions together? And maybe you end up with like a pipe or a function composition or something like that. But I think that highlights, when you have these universal interfaces, because literally I feel like most of the stuff that we have been working with, there's literally five, there's like five interfaces. And everything is one of these five interfaces. And it kind of flips you on your head, because the classic programming wisdom that I have certainly have espoused for at least the last 10 years is that you don't want to race to find abstractions. That's dangerous. Because you can get locked into the wrong abstraction, right? Wait. Let the abstraction emerge. And I'm a lot less bullish on that concept now that I've discovered these things, because that wisdom is cultivated in a world where there are [billions] of abstractions, if you're giving unique names to everything and the combinations between them. But if you are coming up in a world where there's five basic abstractions, then it actually pays off to ask the question, “Is this thing a functor? Is it a semigroup? Is it a monad? What would that look like?” It's a nice thought experiment that doesn't require that much investment. You can think about it for a couple of minutes. And usually, you can come up and say, “Yes, yes. It totally is,” and I can start using it. And now I've introduced this really powerful abstraction. Or you say like, “No, no it's not.” And then that information is just as valuable. And so, it's very low-cost to experiment with abstractions. And so, I kind of think of it as – I know I'm on a little bit of a rant here but this has kind of been a major revelation for me – is that when you have very few abstractions which you compose in myriad ways versus having a whole bunch of abstractions that can't be composed very much, the cost for experimenting with abstraction and making the wrong abstraction is several orders of magnitude lower. And so, you don't have to be as cautious. And you can actually use trying on abstractions as a tool, rather than a very, very high risky undertaking. And just to kind of close that thought out, I think that – I don't know if anybody else but me remembers the world before we decided we were going to make all of our web services RESTful – like when people first started building all these web services, we were just going crazy with the endpoints. And there was no rhyme or reason. Kind of weird arbitrary levels of nesting. Sometimes, you'd throw in an ID as a query param, sometimes you'd throw it in as part of the path. And then I definitely remember, it was probably around, I don't know, 2010 for me where I listened to a podcast where James Edward Gray was talking about S3 and ‘Was it a RESTful interface?' and the O'Reilly book. And it really clicked for me. And realizing that if you constrain yourself to thinking about your API at least as these fundamental operation of manipulating resources, and you were constrained to four verbs and everything, you want to have ID-based URLs and resources and as flat as possible, those constraints actually are very enabling for consumers of your API and for actually authoring an API. And I think it's the same principle at work here. Anyway, so I'll end that rant. [Laughs] TARAS: Yeah. I think it's, I think people could probably, for those who haven't been in programming as long as Charles has been, it's probably easier – Charles I think people could probably relate to what's happening with components now, I'd imagine. Because having components essentially look the same across every framework, they all have props and they all render, return some DOM, or some variation of that. But it's kind of the same thing. You take some data and then you return something that is going to become DOM. And I think having that as a rule for what a component is, you can then make really complicated applications using these fundamental building blocks. And then you don't have to – there's not really much thinking on, “Well, how am I? What interface is this component going to have?” Okay, well you know it's going to accept props. And you know it's going to render some DOM when you actually render it, right? CHARLES: Right. TARAS: That simplicity I think is really helpful. And I think it's one of the things that – I think one of the things about Funcadelic that I really like is there's kind of a really small set of rules that are really helpful. And these rules are actually, they make it predictable. Because one thing that I find really challenging with using Lodash or using Rambda is that because there are so many functions, it's difficult to know what is actually going to happen when I do something. So, a good example would be like if you use omit from Lodash, Lodash omit will then, it will actually – one thing you can do is you can materialize your getters. So, if you have getters in your objects, those getters can become values on the new object that's created. So, that's one thing that could happen. Or if you use omit, your symbol, if you have values… CHARLES: What does omit do, by the way? I'm actually… TARAS: Omit is a pretty popular way to exclude functions. Basically like a filter equivalent for an object. It's usually used to remove some props that are coming into a component. But it can do some – it can actually change the type of the object. One thing you know for sure is if you use something like omit or if you use assign, if you have an instance of something, guaranteed, working with that object in a mutable way is going to cause some really strange things. I think with omit, if you were to have an instance, it would definitely not give you an instance of the same type, like an object of the same type. It will give you just a regular [inaudible]. And there is no real way – you could create an instance. I don't know what assign would do. I'm guessing that it would just take an instance and would put things on it. But it's really not – I think this kind of ambiguity doesn't work very well when you're trying to build something, when you really just need to know exactly how your tool behaves. I think that's one thing that with Funcadelic, because it's such a small API and because you know for a fact that the library is designed to be immutable and it's designed to preserve type information, then you know that if you use one of the operations, you will get most likely the same kind of object. And you're not – well, you will the same kind of object and it's not going to mutate that object. And so, there are some of these guarantees that are actually really helpful and [inaudible] is liberating, I think. CHARLES: Right. TARAS: Especially when you're trying to do more challenging things, not trivial, just copy some properties from one object to another. But when you're actually doing more sophisticated things, in those use cases, having these kind of rules is extremely powerful. CHARLES: Yeah. And I've definitely resisted and I think will continue to resist expanding the API surface area that much. Because it is, I think there's only five or six functions in there. But what you get for those functions is extremely powerful and extremely predictable. I think it might help to give a concrete example. Like when you were talking about object assignment. Like if you have a car class in your application and you want to do an immutable object assign, well the kind of stereotypical way to do that or the typical way to do that is you assign. You create an empty object and then you assign one car to it and then you assign the next car to it. And now you've merged these two car things, right? But then the problem is, you're going to get an object out of that, not a car. It's just going to be a vanilla object. Now, it's going to have all the properties of both, but it's not going to be a car. And that could be a problem if you've got any custom methods on the prototype, any computed properties on the prototype. It's going to be a problem. Whereas Funcadelic, you can append two cars together and you're going to know that it's going to have both of the properties. You're going to know that it's going to be of type car. And you don't have to worry about running the constructor or anything like that. It's just going to have – the properties are going to be carried over properly. If you're using a library like Lodash or Rambda or something that doesn't account for type, because in order to append two things or map something, the implementation actually lives with the type, not with the function. The function is polymorphic, but the implementation lives with the type. You can then actually, you can always return the proper type. Because it's ultimately – like if your map operation or your filter operation or your what have you operation doesn't take type into account, then there's no way to actually preserve type. But because we delegate in Funcadelic, it's core to the concept. And so, it's actually a very trivial thing to do, which is why you get that repeatability. TARAS: One of my favorite things about append and semigroup implementation for object is that you can overload getters on an existing instance. So, what you get is you get a new instance with the getter that you passed to append applied to that instance. And this is kind of trippy but it's actually really powerful because – so, let's say you have an instance of an object and that instance has some getters on it. And those getters use some properties of this object to compute their value. And so, when you want – if I need to create a copy of that object in such a way that the getters still continue to work properly but I need to override how one specific getter works for one specific instance, one specific scenario, one specific use case in my code, then I can just use append. So, the first argument is the original instance, second argument is an object that has the getters that I want that I want to overload the getters on the original object. And then append will squish those things together, smoosh those things together, and give me a new instance that has the getters that I passed in, in the second argument. And all the same things that the first object had. And that object will work. This new object will be a fully-functional object just like the original object that I still have a copy of, that I can use. But this is really interesting because one thing that I'm finding with having these kind of tools in my toolset is that I've had features that I needed to implement on a project. And the people that I work with are really technical. So, they know where problems are going to be. And so, the would write requirements for how something – for a feature that needs to be implemented. And knowing the problems, they're like, “Oh, by the way. You're going to have a problem in this area when implementing this kind of specific functionality.” And for me, I'm like, having this toolset, I'm like, “I don't see it as a problem at all.” It's so easy for me. Because I know that if I need to implement – so if I have something that has expected behavior, but I need to create something that behaves very similarly but slightly different in one particular use case, I can always just copy that object and then overload its behavior. And it's still going to be a fully-functional object. And I think that alone is just not something that you can do usually. It's not something that's available. CHARLES: Yeah. It's a technique that I think was discovered. Maybe it's not original to us. But it's just, the tools enabled it in the sense that it's like having a flashlight in a dark room. It's like, that technique was always there. It's just when it becomes so concise that it's so easy to just append one more computed property to a thing, then you just wouldn't have thought to do it otherwise. TARAS: What's interesting about this too, for me, is that – and this goes back to the context conversation that we had earlier – is that I think React brought into our lives functional programming kind of, in a big way. Because part of programming React applications is working with functional components and working with functional concepts. And a lot of the things, like Redux, a lot of these things are powered by functional programming. And they work together. They compose well together because they're all from the same paradigm. But the problem is that there are all these concepts developed together over time. And they've been tested together and they've been formulated together in languages like Haskell. But the ideas that make all of these stuff work really well together, they haven't really become available in the JavaScript community. And it feels like, it's like we're all using a language that we don't fully understand. And it's like we're all – a lot of people in the JavaScript world who works, when it comes to functional programming, it's kind of like having English as a second language. It's like, you can use the words but you don't understand the humor. And it's kind of like, you can't make a joke. It's kind of like that. You can't really express yourself correctly when you don't have full grasp of the language. And I feel like how we use functional programming in JavaScript is a little bit like that. And by starting to bring these ideas, moving the wealth of knowledge from the source into the realm where we actually need to use it now, we can actually start to take advantage – leverage all these insights that actually enables all of this. It's not like – so, the idea of how to write React and think in a reactive way or think in a functional way, those things are not just owned by the React core team or they're not owned by an elite group of developers who really understand how functional programming works. It's just available to everyone. And all you need to do is just learn some of these concepts that glue all these ideas together that are fundamental pieces of how functional programming works. CHARLES: Right. That's a great point. And it points back to kind of the original reason that I wrote Funcadelic and then started and then continued to work on it with you, is that it really was – it was actually meant as a – it started out as an educational exercise. What would these things look like if they were translated into JavaScript? And it turned out that it rapidly became core to my workflow and way of thinking. And so, it really is, there are weird names to these universal concepts. It is true. It is a foreign language. I really like that analogy. But foreign languages sound weird, and when people are talking in a foreign language, you can feel excluded. And the really, the reason that we wrote Funcadelic and the reason it's there is to make them accessible, these things accessible to you. So that those abstract foreign words can over time turn into concrete concepts that you're completely comfortable with, just like any word in any language. At some point, you approached it having no idea what that sound represented. And so, it really is trying to – the emphasis there is not to noodle about and dwell on the names of the concepts but to take the real things that you are actually doing, give them names and formalize them, to enable you to participate in this new functional world that you're describing. Because I love that sentiment. It does not belong to the React core team. It doesn't belong to an elite set of developers on this project or that project. It literally is a universal tool that is 100% achievable. And people don't even realize how close – if they've been working with JavaScript for a couple of years, how close they actually are. TARAS: Yeah. I think they're really – for most people, if they were to read the readme and then – well, I think one of the problems, it kind of works with the language metaphor, is that you need an immersion, right? I think one of the reasons why Funcadelic really stuck and functors and semigroups and [filterable] and all of these things really stuck for me, and I'm thinking about how using monads and monadic operations or applicatives and all that stuff – the reason why it all stuck for me is because I've been able to talk to you about it. And I think for people, finding a network that will allow them to practice immersively, to think about functional programming, not just occasionally – I mean, you could do it occasionally as well, it just takes much longer. But once you really, once you have a few conversations where you try to dissect a problem in a functional way and you think about what these pieces are made of, it becomes very natural, very quickly. CHARLES: Yeah. I think that's actually a really great point. And the thing is, you can immerse yourself incrementally. So you can just say, “You know what? I'm just going to start using append.” Anywhere that I would concat two strings or I concat two arrays or I would do object assign – screw that. You can even just say, “Instead of using object.assign, I'm going to use append,” and start there. Or to say, “I'm just going to start with mapping.” I think also the thing that's nice about it too, is the buy-in can be incremental. But you're right. You do need immersion. You do need practice. You need to actually use, you need to use the functions and you need to be able to use them one at a time, so that your mind can close over them. So then, you can kind of move onto the next one. TARAS: Yeah. CHARLES: So, that might be one way, is to say – because you know, I don't think I really understood. I was already using append and map ubiquitously before I really understand applicative/apply. So, you don't have to grok it all at once. You can definitely bite it in chunks. And the best way to do that is to start with one concept and really just attack it mercilessly. And then also understand that there's a natural sequence there. TARAS: I would add a little bit of a caveat to that. I think there's a thing about using – doing something for learning purposes and there's another thing about shipping things. What's interesting with Funcadelic and what's interesting about a lot of these ideas from functional programming is that I think they give you benefits that you might have not previously thought. Like for example, if you're going to concat two strings together, doing it with append is probably the most robust way of doing it, relative to just being able to use [inaudible]. CHARLES: Yeah, that's true. You wouldn't want to use a string [inaudible], wouldn't you? TARAS: Yeah. But there are areas when using – there are times when things are just not possible otherwise. Like for example, if you wanted to treat an instance of a class in an immutable way, this is simply not possible in any way. So, if you're going to say, “I'm going to work with a bunch of these instances of ES6. And I want to keep them as instances, because they have certain behaviors that I want to have. I want to have a getter, or I want to have a method on it. And I want to keep these things fully full instances, not broken, not be turned into objects. I want them to be normal instances but I want to work with them immutably. When I need to make a change, I want to get a new object and not modify that object.” So, if you set yourself that goal and you say, “This is what I'm going to do,” then you really are not left with very many options. You only really have, you have to use append from Funcadelic. And because alternatively, you're going to implement something yourself. You might as well just use append. And [I think] that's a good place. I think if you're starting to, if you need to make something lazy, if you need to delay an execution of something – so, instead of pushing that execution, instead of using object assign and then computing everything ahead of time, you can use append. And you can create a getter and you can delay the computation of that value until the point when the user actually reaches for that value. If you want to start doing that kind of stuff, you really are not left with very many options. And append is the way to do it. But that's the thing, is when you start to set these kinds of standards for yourself, you level up in a way that is very significant. I think it's like a natural progression of learning. You start off learning and anything goes, as long as you can make this website work, it's like, “I'm happy.” And then over time you get better and better at it. And then when you get good at building applications, your next step might be like, “What if I was stricter about it? What if I could actually – what would that open up for me? What would that allow me to do?” I personally think about it that way. CHARLES: Yeah. I think that's a good way to think about it. You mentioned having a network for discussing these concepts and trying to internalize them. Let me first and foremost offer myself as somebody. If this is a hill that you are interested in climbing, and I think it is a very worthwhile hill to climb because of the perspective that you will gain from its summit, please reach out to me. You can contact me at cowboyd on Twitter or cowboyd@frontside.io. I'd be happy to discuss these kinds of things, because I think that these tools are just incredibly powerful and will improve you. So, if folks want to get in touch with you, Taras, where would that be? TARAS: I'm tarasm@gmail.com and tarasm on Twitter. CHARLES: Alright. Well, thank you everybody for listening. And as always, if you want to get in contact with us at Frontside, you can just email us at contact@frontside.io or give us a shout on Twitter at @TheFrontside. Thanks everybody. We'll see you all next time for episode 100.

Diese Woche ist Joy Clark (Twitter) zu Gast. Joy arbeitet bei INNOQ und ist auf zahlreichen Meetups in Düsseldorf zu finden (Clojure Meetup, rheinjug, Lambda Düsseldorf). Zudem ist sie einer der Hosts des CaSE Podcast. Wenn ihr aus der Nähe von Düsseldorf kommt solltet ihr am 26.5. zur EntwickelBar kommen. Diese wird unter anderem von Joy organisiert. In der heutigen Folge sprechen wir über Clojure und was die Sprache so besonders macht. Joy gibt mir dabei einen umfangreichen Einblick in die Features der Sprache sowie Stärken und Schwächen. Wir sprechen natürlich auch über den Einstieg in die Sprache. Wenn ihr hier bereits mit Atom arbeitet, solltet ihr einen Blick auf parinfer und proto-repl werfen. Wer trotz Clojure nicht ganz auf Typen verzichen möchte, sollte sich Clojure specs ansehen. Vor ein paar Monaten war ClojureScript im Podcast bereits ein Thema (Folge mit Lisa Passing). In der Folge hat Lisa mir dann auch mehr zu ClojureBridge erzählt. Weitere Links Joy war bereits einmal Gast und hat damals über Sketchnotes mit mir gesprochen Clojure Cheat Sheet Programming Clojure Talk "Simple made easy" von Rich Hickey ClojureScript Koans Maria.cloud Joys Talk über Clojure Web Apps

We'll talk about our experience developing an SPA' browser and native versions that share 90 sth % of their code using React and ReactNative and about the advantages of using a functional language like ClojureScript combined with the re-frame framework which has an architecture similar to Redux but with great conceptual improvements such as effects and coeffects that improve testability by eliminating the need of mocking inside the SPA business logic, or reactive subscriptions which make views dumber and can also reduce the number of renderings.

In this episode I talk with Eric Normand. We catch up with what he has been up to since last episode, talk re-frame in ClojureScript, his newsletter, Clojure SYNC, online community discussions, and more.

Diesmal durfte ich Lisa Passing bei Travis besuchen. Bevor wir uns auf das eigentliche Thema stürzen sprechen wir über end-to-end Encryption und Crypto Parties (z.B. in Berlin). Lisa verzichtet sehr bewusst auf Social Media und erzählt ein wenig, wie es sich so ohne Twitter, dafür aber mit eigenem Hashtag, leben lässt. Schon eher zum Thema passt die ClojureBridge in Berlin bei der Lisa aktiv ist und die sich an Frauen und nicht-binäre Menschen richtet, die gerne lernen möchten, wie man programmiert. Wie besprechen auch direkt, wieso Clojure geeignet ist um programmieren zu lernen. Lisa selbst fängt hier übrigens häufig mit einem Spiel an, wenn sie eine neue Progammiersprache lernen möchte. Aber natürlich sprechen wir auch über Clojure, dessen Verbindung zu Lisp und klären, warum Daten Code sind und Code auch Daten sind. Beim Thema ClojureScript legen wir mit dem Clojure Compiler los, der wohl auch zukünftig ganz ohne JVM auskommt. Schon jetzt sorgt der Compiler übrigens Dank Google Closure Compiler dafür, dass Eure Anwendung am Ende nicht zu groß wird. Der Einstieg in Clojure und ClojureScript ist übrigens nicht immer einfach: hier und da fehlt es noch an Dokumentation und auch das Tooling ist, besonders am Anfang, kompliziert. Also empfiehlt es sich hier durchaus andere um Hilfe zu bitten oder auch mal eines der zahlreichen Meetups zu besuchen. Grundsätzlich ist die Community jedenfalls sehr hilfsbereit. Was noch fehlt wäre ein Buch zum Einstieg in Clojure/ClojureScript. Hier hoffen Lisa und ich einfach mal auf Joy Clark. Beim Tooling setzt Lisa auf Emacs da dieses selbst in Lisp geschrieben ist und man demnach die Konfiguration mit Lisp anpassen kann. Man kann aber natürlich auch mit den gängigen Editoren und IDEs arbeiten und dort ein Plugin nutzen. Nützlich ist auch die ClojureScript REPL, die wir dann auch beleuchten und besprechen, wie sie die Entwicklung unterstützen kann. Hier kann man hier übrigens figwheel nutzen. Natürlich spielen auch Build Tools eine Rolle und hier könnt ihr gleich zwischen Leiningen (Leiningen versus the ants) und Boot wählen. Leiningen folgt dem Ansatz "Convention over configuration" während Boot hier alle Freiheiten überlässt. Beide Tools sind verbreitet und können Euch auch immer wieder begegnen. Am Ende schwärmt Lisa noch ein wenig von Clojerl (Clojure auf der Erlang VM) und falls ihr auch in der Bash gerne Klammern schreibt, solltet ihr Euch mal Closh ansehen. Warum JavaScript jetzt eigentlich doch nicht irgendwie funktional ist, könnt ihr uns, wie jedes weitere Feedback, gerne über den Github Issue mitteilen.

We talk with David about the mind blowing possibilities that have emerged with ClojureScript over the past few years and how it is set to rocket into the future. Please check the web site for more detailed show notes https://defn.audio If you wish to support the show you can use Patreon https://www.patreon.com/defn

Joy Clark talks with David Nolen about ClojureScript. David introduces the language and discusses the direction that the language is heading in. He talks about how the language is compiled to JavaScript and how it takes advantage of the the Google Closure Compiler. They then talk about designing user interfaces and how functional programming relates to UI design. To wrap up, David mentions different libraries and frameworks that can be used and recommends tools which can be used to get started programming with ClojureScript.

Joy Clark talks with Alex Miller about Clojure. Topics include the Clojure language and how it compares to other languages as far as features and maintainability are concerned. The benefits of dynamic languages are also discussed, and clojure.spec is introduced as a way to gain the benefits of statically typed languages. Alex also talks about ways to structure Clojure code and gives a great list of tools and materials for getting started with Clojure.

JSJ 272: Functional Programming and ClojureScript with Eric Normand This episode of JavaScript Jabber features panelists Aimee Knight and Charles Max Wood. Special guest Eric Normand is here to talk about functional programming and ClojureScript. Tune in to learn more! [00:1:14] Introduction to Eric Normand Eric works for purelyfunctional.tv. The main target market for his company is those people who want to transition into functional programming from their current job. He offers them support, shows them where to find jobs, and gives them the skills they need to do well. [00:02:22] Address that quickly Functional programming is used at big companies such as Wal-Mart, Amazon, EBay, Paypal, and banks. They all have Clojure but it is not used at the scale of Java or Ruby. So yes, people are using it and it is influencing the mainstream programming industry. [00:3:48] How do you build an application? A common question Eric gets is, “How do I structure my application?” People are used to using frameworks. Most start from an existing app. People want a process to figure out how to take a set of features and turn it into code. Most that get into functional programming have development experience. The attitude in functional programming is that they do not want a framework. Clojure needs to be more beginner friendly. His talk is a four-step process on how to turn into code. [00:05:56] Can you expand on that a little? There are four steps to the process of structuring an application. Develop a metaphor for what you are trying to do. Developing the first implementation. How would you build it if you didn’t have code? Develop the operations. What are their properties? Example: will have to sort records chronological. Develop relationships between the operations. Run tests and refactor the program. Once you have that, you can write the prototype. [00:13:13] Why can’t you always make the code better? Rules can’t be refactored into new concepts. They have to be thrown away and started completely over. The most important step is to think before beginning to write code. It may be the hardest part of the process, but it will make the implementation easier. [00:17:20] What are your thoughts on when people take it too far and it makes the code harder to read? He personally has written many bad abstractions. Writing bad things is how you get better as a programmer. The ones that go too far are the ones that don’t have any basis or are making something new up. They are trying to be too big and use no math to back up their code. [00:20:05] Is the hammock time when you decide if you want to make something abstract or should you wait until you see patterns develop? He thinks people should think about it before, although always be making experiments that do not touch production. [00:23:33] Is there a trade off between using ClojureScript and functional JavaScript? In terms of functional programming in JavaScript don’t have some of the niceties that there are in Clojure script. Clojure Script has a large standard library. JavaScript is not as well polished for functional programming; it is a lot of work to do functional programming it and not as much support. [00:27:00:] Dave Thomas believes that the future of software is functional programming. Do you agree? Eric thinks that it seems optimistic. He doesn’t see functional programming take over the world but does think that it has a lot to teach. The main reason to learn functional programming is to have more tools in your toolbox. [00:31:40] If this is a better way to solve these problems, why aren’t people using it? There is a prejudice against functional programming. When Eric was first getting into it, people would ask why he was wasting his time. Believes that people are jaded. Functional programming feels foreign because people are used to a familiar way of programming; they usually start with a language and get comfortable. [00:40:58] If people want to get started with it, is there an easy way in? Lodash is great to start replacing for loops. It will clean up code. There are other languages that compile to JavaScript. For example, Elm is getting a lot of attention right now. It is a Haskell like syntax. If you want more of a heavyweight language, use TypeScript or PureScript. ClojureScript is into live programming. You are able to type, save, and see results of the code immediately on the screen in front of you. Picks Aimee: The Hidden Cost of Abstraction  What Functional Language Should I Learn  Eric Steven King, On Writing  Youtube Channel: Tested   Charles Ionic Framework Links Purely Functional TV  Blog  Building Composable Abstractions 

JSJ 272: Functional Programming and ClojureScript with Eric Normand This episode of JavaScript Jabber features panelists Aimee Knight and Charles Max Wood. Special guest Eric Normand is here to talk about functional programming and ClojureScript. Tune in to learn more! [00:1:14] Introduction to Eric Normand Eric works for purelyfunctional.tv. The main target market for his company is those people who want to transition into functional programming from their current job. He offers them support, shows them where to find jobs, and gives them the skills they need to do well. [00:02:22] Address that quickly Functional programming is used at big companies such as Wal-Mart, Amazon, EBay, Paypal, and banks. They all have Clojure but it is not used at the scale of Java or Ruby. So yes, people are using it and it is influencing the mainstream programming industry. [00:3:48] How do you build an application? A common question Eric gets is, “How do I structure my application?” People are used to using frameworks. Most start from an existing app. People want a process to figure out how to take a set of features and turn it into code. Most that get into functional programming have development experience. The attitude in functional programming is that they do not want a framework. Clojure needs to be more beginner friendly. His talk is a four-step process on how to turn into code. [00:05:56] Can you expand on that a little? There are four steps to the process of structuring an application. Develop a metaphor for what you are trying to do. Developing the first implementation. How would you build it if you didn’t have code? Develop the operations. What are their properties? Example: will have to sort records chronological. Develop relationships between the operations. Run tests and refactor the program. Once you have that, you can write the prototype. [00:13:13] Why can’t you always make the code better? Rules can’t be refactored into new concepts. They have to be thrown away and started completely over. The most important step is to think before beginning to write code. It may be the hardest part of the process, but it will make the implementation easier. [00:17:20] What are your thoughts on when people take it too far and it makes the code harder to read? He personally has written many bad abstractions. Writing bad things is how you get better as a programmer. The ones that go too far are the ones that don’t have any basis or are making something new up. They are trying to be too big and use no math to back up their code. [00:20:05] Is the hammock time when you decide if you want to make something abstract or should you wait until you see patterns develop? He thinks people should think about it before, although always be making experiments that do not touch production. [00:23:33] Is there a trade off between using ClojureScript and functional JavaScript? In terms of functional programming in JavaScript don’t have some of the niceties that there are in Clojure script. Clojure Script has a large standard library. JavaScript is not as well polished for functional programming; it is a lot of work to do functional programming it and not as much support. [00:27:00:] Dave Thomas believes that the future of software is functional programming. Do you agree? Eric thinks that it seems optimistic. He doesn’t see functional programming take over the world but does think that it has a lot to teach. The main reason to learn functional programming is to have more tools in your toolbox. [00:31:40] If this is a better way to solve these problems, why aren’t people using it? There is a prejudice against functional programming. When Eric was first getting into it, people would ask why he was wasting his time. Believes that people are jaded. Functional programming feels foreign because people are used to a familiar way of programming; they usually start with a language and get comfortable. [00:40:58] If people want to get started with it, is there an easy way in? Lodash is great to start replacing for loops. It will clean up code. There are other languages that compile to JavaScript. For example, Elm is getting a lot of attention right now. It is a Haskell like syntax. If you want more of a heavyweight language, use TypeScript or PureScript. ClojureScript is into live programming. You are able to type, save, and see results of the code immediately on the screen in front of you. Picks Aimee: The Hidden Cost of Abstraction  What Functional Language Should I Learn  Eric Steven King, On Writing  Youtube Channel: Tested   Charles Ionic Framework Links Purely Functional TV  Blog  Building Composable Abstractions 

JSJ 272: Functional Programming and ClojureScript with Eric Normand This episode of JavaScript Jabber features panelists Aimee Knight and Charles Max Wood. Special guest Eric Normand is here to talk about functional programming and ClojureScript. Tune in to learn more! [00:1:14] Introduction to Eric Normand Eric works for purelyfunctional.tv. The main target market for his company is those people who want to transition into functional programming from their current job. He offers them support, shows them where to find jobs, and gives them the skills they need to do well. [00:02:22] Address that quickly Functional programming is used at big companies such as Wal-Mart, Amazon, EBay, Paypal, and banks. They all have Clojure but it is not used at the scale of Java or Ruby. So yes, people are using it and it is influencing the mainstream programming industry. [00:3:48] How do you build an application? A common question Eric gets is, “How do I structure my application?” People are used to using frameworks. Most start from an existing app. People want a process to figure out how to take a set of features and turn it into code. Most that get into functional programming have development experience. The attitude in functional programming is that they do not want a framework. Clojure needs to be more beginner friendly. His talk is a four-step process on how to turn into code. [00:05:56] Can you expand on that a little? There are four steps to the process of structuring an application. Develop a metaphor for what you are trying to do. Developing the first implementation. How would you build it if you didn’t have code? Develop the operations. What are their properties? Example: will have to sort records chronological. Develop relationships between the operations. Run tests and refactor the program. Once you have that, you can write the prototype. [00:13:13] Why can’t you always make the code better? Rules can’t be refactored into new concepts. They have to be thrown away and started completely over. The most important step is to think before beginning to write code. It may be the hardest part of the process, but it will make the implementation easier. [00:17:20] What are your thoughts on when people take it too far and it makes the code harder to read? He personally has written many bad abstractions. Writing bad things is how you get better as a programmer. The ones that go too far are the ones that don’t have any basis or are making something new up. They are trying to be too big and use no math to back up their code. [00:20:05] Is the hammock time when you decide if you want to make something abstract or should you wait until you see patterns develop? He thinks people should think about it before, although always be making experiments that do not touch production. [00:23:33] Is there a trade off between using ClojureScript and functional JavaScript? In terms of functional programming in JavaScript don’t have some of the niceties that there are in Clojure script. Clojure Script has a large standard library. JavaScript is not as well polished for functional programming; it is a lot of work to do functional programming it and not as much support. [00:27:00:] Dave Thomas believes that the future of software is functional programming. Do you agree? Eric thinks that it seems optimistic. He doesn’t see functional programming take over the world but does think that it has a lot to teach. The main reason to learn functional programming is to have more tools in your toolbox. [00:31:40] If this is a better way to solve these problems, why aren’t people using it? There is a prejudice against functional programming. When Eric was first getting into it, people would ask why he was wasting his time. Believes that people are jaded. Functional programming feels foreign because people are used to a familiar way of programming; they usually start with a language and get comfortable. [00:40:58] If people want to get started with it, is there an easy way in? Lodash is great to start replacing for loops. It will clean up code. There are other languages that compile to JavaScript. For example, Elm is getting a lot of attention right now. It is a Haskell like syntax. If you want more of a heavyweight language, use TypeScript or PureScript. ClojureScript is into live programming. You are able to type, save, and see results of the code immediately on the screen in front of you. Picks Aimee: The Hidden Cost of Abstraction  What Functional Language Should I Learn  Eric Steven King, On Writing  Youtube Channel: Tested   Charles Ionic Framework Links Purely Functional TV  Blog  Building Composable Abstractions 

Chris and Ed do an extremely rare daytime recording of the show on the American Memorial Day holiday. But why is a Canadian not working on an American Holiday? You’ll have to tune in to find out why along with some thoughts on mentoring and why the current crop of browser-centric testing tools are completely shit. Thanks to Ben Ramsey for his poetry choice and Chance Garcia for allowing us to bring another health issue to people’s attention. Do these things! Support us via our Patreon Buy stickers at devhell.info/shop Follow us on Twitter here Rate us on iTunes here Listen Download now (MP3) Links and Notes Please support Ed’s efforts to make OSMI his main gig! Both Chris and Ed will be at CakeFest 2017 WebDriver is an API in heavy use at Mozilla (and elsewhere) for doing browser automation work Ed talked about a testing tool called Fake from his webOS development days that promoted a very different testing paradigm Chris has done browser automation in PHP using Behat, Mink and a lot of swearing Most current browser-centric UI testing tools are Rube Goldberg machines Great blog post from the ClojureScript community showing off property-based testing and immutibility Also some great work being done in PHPUnit with snapshot testing

Wes from Linux Unplugged joins Mike to host a special edition of the show. They chat about the merits (or not!) of Electron, Mike’s week from hell & their true feelings about Javascript. Then they discuss Clojurescript, React Native, & the benefits of a more functional programming style. Plus Docker, Devops & of course the Beer of the Week!

In this episode I talk with Justin Woo. We talk his introduction to functional programming; the transition from ClojureScript to Elm to PureScript for side projects; the appeal of PureScript; evangelizing PureScript and more.

Kyle Simpson: @getify | Blog | GitHub | getify@gmail.com Show Notes: 04:19 - Styles for Learning as a Newcomer 08:41 - The Structure of the Journey “If you're waiting until you're already an expert on a thing to share it with somebody else, you've waited far too long because we missed out on the most important part which was the journey.” 12:52 - Understanding a Problem vs Solving One "I want to inspire people to be uncommonly curious." 29:02 - How do you know when to stop? 35:02 - Knowing Math and Learning Programming 43:40 - The Importance of Mentorship Resources: LABjs The JavaScript Austin Meetup Pedagogy Saron Yitbarek (CodeNewbie): I don't belong in tech: Trying to find my place in the place I love, and constantly failing Dr. Seuss' The Sneetches (Star-Bellies Reference) Big O Notation You Don't Know JS: A Book Series Functional Light JavaScript Kyle's Frontend Masters Training Videos Transcript: CHARLES: Hey, everybody and welcome to the Frontside Podcast episode 50. I'm your host, Charles Lowell. With me, also from the Frontside, is Stephanie Riera. And with us today is a very special guest, Kyle Simpson, a fellow Austinite. We're going to talk about education and teaching JavaScript. You hear this name everywhere you go. I remember when I first moved to Austin, back in 2009, I moved back to Austin, I went to my very first JavaScript Meetup and there was this guy sitting there doing some live coding on this crazy thing called LABjs which was just like mind-blowing stuff that was going on that was doing crazy on-the-fly modules floating. And this was like back in 2008/2009, so awhile back. And that was my first experience. And then just moving inside tech circles, he just like popped again and again and that's just like the story. It seems like Kyle is like ubiquitous. I was at Clojure Conf last weekend and one of the speakers actually gave a shout-out to Kyle Simpson. So, I don't know Kyle if you do much Clojure, but you definitely have an impact, an outsized impact in the JavaScript community and outside the JavaScript community at large, all throughout tech. It's really a pleasure to get to have you on the show. So, welcome Kyle. KYLE: Thank you so much. It's a huge honor to be here. I'm glad to be doing this in our home city of Austin. It's fun to actually get a chance to pull again with the Austin community because a lot of my work takes me on the road. I sometimes joke that I know more about JavaScript communities in other cities than in my own since when I'm home, I'm usually with the family. And when I go to meetups, it's usually in other cities. But it's fun to be here. It's interesting you bring up that JavaScript Meetup, the original Austin JavaScript Meetup. It started in January of 2009. Actually Joe McCann, most people will know that name. He's kind of a rockstar in the Node community and one of the founders of NodeSource. I think he's up in New York City now. But he started the Austin JavaScript Meetup in January. February, I started kind of came on and we ended up kind of tag teaming running that meetup for the next couple of years. In the early days of that, you're talking about LABjs, I remember that was summer of 2009. The early days of starting up a meetup when you have 5 or 6 attendees on a really good night, mostly consists of about a week before the meetup, "Oh, we don't have a speaker. One of the two of us has to figure out something to speak about." So, I would often kind of take on that task and I would say, "Okay, what's something I'm interested in," or, "What's a library I could write that I could talk about something when I was coding?" CHARLES: So that actually born out of the need to actually present something at the Austin JavaScript Meetup? KYLE: Yes, actually LABjs, it was something at work at that time that I was trying to solve but I wasn't really making a library out of it. It was just some code that I was toodling around with. I was like, "Wow, crap! It's 3 days before the meetup. I better come up with something to talk about." So I wrote the very first version of LABjs to present at that meetup and I got a bunch of good feedback from people that were looking at it and saying, "Oh, that's cool." So I kind of ran with it. That's literally my first kind of major open source project. Most people probably originally heard of me if they've been around the tech world for a while, they originally heard of me because of that one. CHARLES: Wow! I had no idea I was there. KYLE: You were there for the origination. I was the unveiling to the world of LABjs. CHARLES: It's like the Woodstock of JavaScript. KYLE: Those were some early days of meetup stuff. You're like pick up a pizza and a couple of beers from the store on the way to the meetup and there wasn't a lot of organization but we had a lot of fun. Now, the Austin JavaScript Meetup 6 or 7 years later is, it rocks! There's 50 or 60 people every single month that attend. There's been several change-overs of leadership over that couple of years but it's still fun to think about kind of helping Joe get that off the ground way back in 2009. CHARLES: Yeah, that was fantastic. You've been in it a long time and that actually kind of brings me to one of the things that I'm curious about is you've been doing this for a long time. You've been writing JavaScript for a long time and yet you're very much connected to the Day 1 learners and the people who were coming in just kind of from at the very bottom floor. And one of the things that I find in my interactions with the people who are starting out or people who are beginning is that it can be very difficult to know what's appropriate to teach a style that's effective or teaching them because you don't have that empathy of you're so far removed from the experience, that struggle and that challenge of really clawing your way into programming. And yet that doesn't seem to be an issue for you or maybe it is. I'm just curious, one, do you perceive that as something that you have to deal with and how do you do it? KYLE: I would say that part of the way that I'm able to keep a pulse or a finger on what it's like to first start learning something comes from my own learning style which is that I, to learn a thing, I can't follow tutorials. As a matter of fact, every time somebody comes up with a new major awesome tool or framework and they put out this great tutorial and everybody raves about it, I secretly have that huge flare up of impostor syndrome because I know that I will feel really dumb if I try to go through a tutorial and learn it in that fashion. That's just not how I learn stuff. The way I learn stuff is very, very slow and methodical. It generally is taking a thing apart and trying to figure out what each of the different pieces is doing, understanding at that deeper level, and then reassembling the pieces. The reason I mentioned that is because I like to describe my process of teaching and I really think this generalizes to people beyond me that it's my process. I think that my process for teaching is just to have a narrative journey and that it's all about a process. It's not about a single event because I don't think that learning is transactional or I don't think it should be. I think learning should be a process. And so, for me, that process starts with an initial thing that I'm looking at. I get an idea of what it's about, the problem domain that it's in. I probably develop an instant sense of 'ooh, I don't really like that' or 'ooh, that's kind of interesting'. But if I'm going to learn a thing, it's not going to come through a tutorial. It's not going to come through reading a Read Me and being like, "Okay, I'm good to go," and I can sort of copy and pasting. For me, it's going to take, in some cases, reinventing parts of it as I put those pieces back together so I can really understand the choices that were made. I do a lot of reading of somebody else's source code. As an example of this ongoing journey that I'm learning, I was recently at a conference and I heard a discussion of Redux. And of course, Redux is something that tens of millions of people, I mean everybody seems to be an expert on this stuff and I don't know Redux. I don't know React. I don't spend a lot of time at that layer of the stack. But I was listening to a talk and I was thinking, "Well, that sounds interestingly similar to the stuff that I was playing around with back in 2010." It's kind of event oriented and single source of truth for the model and stuff like that. "That's cool. I should go and learn that more." So, that's on my pretty near future to-do list to kind of learn stuff. And there's a really good chance that that process, that journey that I go on to learn about Redux is going to spin off at least some sort of code that I play around with, whether that's using Redux or writing something kind of like Redux to show off how I've been thinking about the idea. And then I'll probably write about it. I know for sure that I'm going to be mentioning it in one of the chapters of my current book on functional programming. So, I'll be talking about it, at least a little blurb about how it fits into the overall scheme of things. And then probably eventually once my journey has gone a little bit further, eventually there'll be some kind of class that I spin up in a module or in one of my classes that I talk about Redux and where that comes from. And that's not because I've been on the high training. As a matter of fact, it's the opposite. I'm the latest adaptor for most of these things but that is a very long slow methodical process for me to learn something and then turn around and try to teach it to other people. CHARLES: Is the idea then that you want to kind of share that journey that you've taken or try to encourage the next learner to take a similar or different journey? How do you structure that learning once you do decide to package it up? KYLE: The structure of the journey -- I think that's an interesting way of articulating the question. What is the structure of the journey? And I would say that the structure of the journey generally, from my perspective, starts from understanding a concept, the why behind the concept, what is the problem I need to solve, and what is motivating solving the problem. And then it moves into the how are we going to do it, what are the possible ways to do that, and that really is the part of that process that you spend most of your time digging into and understanding the deeper level of the thing. So, not just using the library but understanding really how it does it and the choices that it made. And then it moves to the what. And that is inverted from the way most people's learning seems to go about because people learn most typically by, "I find the cool thing because it was in some newsletter that I read about. It seems like it would help on my job project, so I dropped the thing in, put in a couple of the snippets from the Read Me and it's working great, and maybe someday later, I'm going to go back and dig into it a little bit." I'm completely reversed. So, that's my structure for learning and I recommend that people, at least from time to time, take a similar path. It doesn't have to be exactly that way, but take a similar path to breaking down the learning. I'm sure as we go along in this discussion, I'll be able to elaborate on that more. I don't want to just churn on and on forever. But I really do think it's important for people to dig in deeper. So my process is that and the way that I teach is to take people on that journey with me. The way that I teach is to say, "This is the journey that I'm going through. This is the stuff that I understand." For the listeners that aren't teachers, there's some interesting -- I don't want to get too much into the weeds about teaching -- but there's something interesting about teaching. There's this fancy word called Pedagogy which is not the thing that you're teaching but the strategy that you want to use to teach it, the narrative that you want to take a person through. And I spend an awful lot, probably more of my time thinking about that than about the topic itself. So, my practice is to use a lot of silly metaphors. Like I'm teaching promises and I talk about future cheeseburgers and stuff for those that have read or heard from me before, they'll know the future cheeseburger. I use silly stuff like that because this stuff can be really dry and difficulty and I want it to stick in your head. I want the how to stick in your head. So, I invite other people. That doesn't mean that you have to take the entire journey that I did to learn a thing, but I really want to inspire people to learn at that level to be uncommonly curious. And I hope that when they see that I've done it and that I'm transparent about how my process works, I hope it inspires other people. CHARLES: Yeah, and I think wrapped-up in that is tied back to my usual question is because you yourself are in fact you're going through this process, it's very easy then to empathize people who are going through the same process. I really like that. KYLE: And I think everybody should look at the process of getting up to speed on the thing as an opportunity to go on that journey and to document and share that journey with others. You don't have to have the word 'teacher' in your job title to be a teacher. I think all engineers should be seeking to go outside of themselves and to explain things, if for no other reason than the purely selfish reason which is you learn it better by re-explaining it to somebody else, but all boats will rise with the tide. And so, I have taken, for years now, the perspective every time I learn a thing, I'm going to turn around and share it with somebody else. It's exactly the same thing that's interesting and almost ironic that we started our discussion today about that meetup and about LABjs. I was learning a thing and figuring out a thing and I turned around and shared it with other people and it turned out to make an impact. But the impact isn't the important part. The important part was the journey, it's not the end goals. I was always tell people, "If you're waiting until you're already an expert on a thing to share it with somebody else, you've waited far too long because we missed out on the most important part which was the journey." STEPHANIE: Kyle, you touched on something that I wanted to ask you about. You talked about the first phase being understanding a problem, and then the second one being how do we fix this. And last week, I believe, CodeNewbie has her own podcast. And she released a post on Medium and it's called 'I Don't Belong in Tech'. And she talks about how her instinct is to understand the problem versus solving it. It seemed like she feels she is an outcast in the tech community because most people are really excited about solving problems and she doesn't feel like she is solution-oriented. And I kind of wanted to ask you, is that the case? Do you think the people that excel in programming are people that are just naturally excited about solving problems? And if that's not the case, then what do you recommend for people that may not think in that fashion, they don't intuitively feel like solving problems and they feel like they approach it in a different manner? It seems like people have different learning styles. KYLE: I agree completely that people have different learning styles. And that question you just asked is so rich with so many things to mind. So, I'm excited to dig into that a little bit. I 100% agree that people have different learning styles and I think that it is why it is important for there to be people in the community who are spending their time and attention thinking about teaching and about improving educational processes. I do not think that curriculum teaches itself. And I'm somewhat suspect of the movement that we have as an industry towards almost praising or taking it as a badge of honor the label of self-taught. It's almost become its own cult that you're a self-taught person versus somebody who came through it from a more traditional path where a person was carefully thinking about how to present to you and how to teach you whether that was at a university or a tech school or mentorship or any of the others. People that are self-taught often wear that as a badge of honor. It's almost a rite of passage that you got to a level of understanding and experience and expertise because you boot strapped yourself up as opposed to the more top-down approach. And I am suspect of whether or not that's healthy for us to suggest to people that there are these two factions. It's kind of like the old Dr. Seuss book of the star bellies and the non-star bellies. I have the star belly because I got my Computer Science degree. And if you know that book and if you don't know the book, you should go look it up. But what happens in the book is at some point, there's a flip and now the people with stars are the excluded ones and the people without aren't. So I don't think it's healthy for us to promote the idea that we need two entirely different approaches that there's a person who can only be a self-taught and that's a thing, and then there's a person who gets more formal education. I really think it's important for people to spend time thinking about how stuff should be presented and not just throwing information out there for people to learn themselves. This is kind of a crazy metaphor. But if you had a one or two year old kid and you wanted them to learn to swim, the developer mindset often says, "Well, just throw them in the deep end and they'll figure it out." But that isn't how we actually would teach them to swim. We would be very, very patient, very, very cautious with them. We'll start with the shallow end, there being an adult there and they would guide them through that. And I think there's virtue in having some of your learning even if you're one of those listening that does value the whole self-taught thing or that has worked for you in the past. I think there's also value in people going through a more formalized process. Like I said, there's lots of different channels for that modality. But I think the formalized modality has value to it. And of course, that's what I spend my time thinking about. I put out a lot of information - my books and my training videos. There's a lot of that material available for people to self-teach but I really hope that what that does is not encourage people to stay disconnected but rather, to attract people to create relationships around learning because I think relationship-based learning is the most effective modality for leaning. And we've proven that for thousands of years in lots of other parts of society, but we haven't really taken that to heart in the developer world, and I think we need to more. You're right, going back to the original question that there are lots of different ways that people learn. I know CodeNewbie. What's interesting about that premise, I share a similar perspective on those that want to learn to solve a problem versus those that want to learn to figure out how to solve problems. I have a statement that I make which I will preface with I understand that sometimes it can be a little bit off but I hope that listeners will take this from the spirit that I'm trying to give it in. I think that one of the things we can do is begin to think a little bit more about what we're doing even though all of the other structure and process scaffolding around us incentivizes and encourages the opposite. I think what we see is that the developer-oriented mindset typically is more interested in first solving a problem and maybe later understanding it. Whereas I think the engineering mindset -- for lack of a better label, I'll call it the engineering mindset. That's my bias because I came up through a more traditional engineering CS degree. But I think the engineering mindset, the one that most people would say is heavily focused on problem solving and that kind of thing. I think the engineering mindset seeks first to understand the problem and maybe later solve it. If you have developer mindset that wants to solve a problem without really fully understanding it, I think one of the outcroppings of that is the churn that we see in the development community. We see people constantly every two or three years trying to go recreate a whole new stack of things because we're saying, "We need to do this thing differently." And I have seen that cycle four or five times in my career. And so, I can say with pretty strong certainty right now that somewhere in the world, there is a guy or a girl that is a 16 year old that is working on what is going to eventually replace React. I don't know what it is, I don't know who the person is, but I'm pretty sure that we're at some point going to say, "Wow!" And when that shift happens, we're going to come back and think to ourselves, "How could we have ever thought that React was the most amazing thing in the world," and we very quickly forget. So, one of the outcroppings is that continuing cycle because people are seeking to fix problems as quickly as possible and not everybody takes the time to really think about it. The authors of those tools, they think really deeply about these problems. They think so deeply about them. I am amazed the kinds of thought that goes into creating one of those frameworks or libraries. And I have a lot of deep respect to the Ember community, the React community, the Angular community. Those people spend a lot of time thinking about those problems. But the people that use them, use them as tools to get their job done honestly and earnestly so. But they very rightly focus on what can I get done with React rather than 'can I understand what React is really trying to do and use it to its best ability'. And we incentivize that. We incentivize that by saying that the people that advance at work, the people that become the senior developers at work are more likely the people that shipped more code. They're more likely the people that closed more bugs. And one path to getting there is you're just a really quick coder or you're one of those mythical unicorn 10x developers. But a lot of people aren't. I'm certainly not. I am not a fast developer. I'm one of the slower developers. I am very, very careful about what I write. So, I can't survive in that environment where I have to advance because I can write code quickly. Rather for me to survive in those environments, I advance or up my stature, if you will, because I understand the thing deeper than anybody else. And I think there's places in the workplace for both, so I'm not disparaging those that write a lot of code quickly. But one of the outcroppings of writing code quickly if jumping as quickly as you can to solving a problem, is that you often times find a local maximum. A mathematic theory about -- just visualize a curve kind of like the landscape of hills. If you're climbing a hill as quickly as possible and you get to the very top of the hill, it might not have been the tallest hill that you could have climbed. But you got to the top of the hill really quickly and you got the next promotion, you went on to the next thing. So, I think those value. Sometimes in your career and some people in the community who want to take a step back and understand a thing deeper, dig into a thing deeper, and I encourage people to have that as part of their toolset, that they would be that uncommon level of curiosity. Take a moment and by a moment I mean a couple of months, maybe a cycle at most of six months, take a step back from the just everyday churn of shipping a feature and fixing a bug and making the button blue, take a step back and say, "What are some of the things that I have been touching or I have been hearing people talk about," and dig into that thing and learn it. And learn it really deeply and really understand it, and maybe reinvent it if you need to. But really deeply get it. And then kind of resurface and look around and say, "All right, let me find the next thing." And so, I think those cycles are healthy for people. And I think the engineering mindset should be something that each of us strives to adopt at least some in the workplace as opposed to being almost drunk on the idea that the best developers among us are the ones that ship code the quickest. CHARLES: I think also too there is like if you do take the time and you then make that investment upfront, it engenders a lasting speed. In the same way that if you look at a child taking its first steps which is kind of the initial solution of a problem, it takes intense concentration. And it takes all the muscles or trembling and stuff just to coordinate the balance to take those first steps. But then once the child kind of understands the process fully -- like none of us, at this point in our lives, think about walking. It's just something that we do naturally. But because the human brain is wired at that point to take whether it's walking or any other kind of motor skills to really understand the motion and rewire the brain optimized for that motion so that it becomes second nature, so that you benefit from that again and again and again. And I feel having spent a long time in the industry seeing the speedups that can actually be gained by doing it slow. In other words, you expand that understanding to fill the room and then the door is only a few millimeters away, if that makes any sense. KYLE: I think it does. And I think for those that are listening just to address what questions may be popping up in people's heads because as a teacher, you learn to anticipate questions ahead of time. So I can see, even from our discussion so far, that somebody may be asking, "Okay, you're talking about some really nice theory here, but what about the practicality of it? What are the benefits of the thing? I don't have time to go learn React but I can get my job done by applying React to my business process." So, I think there are some practical things that we can point to that that come from being that uncommon level of curious, that deeper and slower and more methodical learning. One of those, I'd like to say -- and people always kind of smirk at me when I say this -- I call them getify's laws. They're just statements that I make. They're statements of my opinion and really the only thing that I'm an expert on is my own opinions and I'm never at a lack for those. It's just an opinion but I believe that you can't hope to solve a problem if you don't first understand it. Or to put another way the getify's law - if you don't understand why a piece of code works, you have no hope of understanding why it broke and how to fix it. So we do a lot of code that works and we don't know why. I would say probably the majority of code that gets shipped were just sort of only kind of tenuously understand it. And sometimes it's really tenuous. Sometimes it's house of cards development where you build a thing and you're not really quite sure why it works but you put a comment there that says 'don't touch this' and 'don't break it' or whatever. And then we back away and hold our breath and hope that it stays in place. That is a way to ship code quickly. The agile mindset has permeated so deep down that on every line of code we're thinking [inaudible], we're thinking, "Just get the thing working and get the test passing and then we'll worry about whether it's the appropriate way to solve the problem. We'll worry about that later." Many times we don't get a chance to worry about it later until there's a fire, until something's broken. And that fire could be that bug or that brokenness could be it's not doing what it's supposed to do or more often, that fire is it's doing it but it's impossibly slow, it's impractically slow. And now, we have to go back and think, "We thought we only had five pieces of data to ever work with, but now we have 50,000 and the algorithm completely falls apart. We can't do an [inaudible] scan anymore," or whatever. So that very narrow myopic short term mentality can be effective for people to get stuff shipped and to advance in their jobs, but it falls apart when things start breaking. If you're talking about a car and you said, "I don't need to know how a car works, so I can just drive a car." And that's entirely true. But if we took that to its logical extreme, you could say, "I don't even need to know that my vehicle runs of gasoline or electricity," or whatever. "I don't even need to know anything about the liquids that go in that make my car work. I just sit down behind the driver wheel and drive and it works." And that will work until your gas tank runs empty. And then at that point, you have no idea how to fix your problem. So you're going to have do some reading and worse, you're going to be at the mercy of somebody else. Having an instinct, having a clue about something about what's going on into the hood is pretty important when we go off the happy path and start trying to fix problems, whether that is fixing bugs or improving performance. Those are, I think, some very important practical takeaways that come from some people some of the time being the uncommonly deep learner. Just for fun, for my son in his school, I've been working on building a game that he's doing as part of his school through this Mathematics competition, I've been building a computerized version of this game. And those that have been following my Twitter have seen some interesting tweets about that. But I've been building an AI, a strategy turn based AI so that you can play against the computer for this thing. Tackling that requires you to kind of really understand or at least be able to fiddle your way through some deeper "CSC" kind of topics. But I got it working and it was too slow. You have to wait for the computer for 20 or 30 seconds for it to figure out its next move and that's slow. So then I started thinking about how I'm going to optimize this. Do I need an object pulled to pull stuff in and be able to reuse arrays or something? I was at a loss as to how to do that efficiently. I was completely lost. And so, I had to learn that thing. I had to think very carefully methodically. If I had let some sort of artificial deadline and say, "No, you just got to ship the game," it would have worked but it would have been impractical. And so, taking that time to think about it -- actually, I finally did. It took me days but I finally arrived at a solution for managing, sharing references that actually works from a performance perspective. It is practical now. I think there are practical takeaways. It's not just all the theory behind being a deeper learner. CHARLES: I've been thinking like where do you know where the stopping point is? Because the world is just packed with knowledge. When I was starting out as a programmer, there were people who just code assembly for fun and assemble their own microprocessors and stuff because that's what they did when they were coming up. But all of that stuff exists like we're standing on it. We've kind of lived on the level of the city street but beneath that is the subway and beneath that is the power grid and the gas pipes and the hog water pipes and all that stuff. Who knows how much more layers of urban development lie beneath some of these cities that are certainly way more rich than Austin. None of that stuff is present here. KYLE: I was going to say I didn't know there was a subway. I wish there was. CHARLES: Once I realized what the analogy was, I was standing in the Austin streets, I kind of transitioned to New York without telling anybody. My point is that in the computer world -- let's just keep it there -- let's say you're working with JavaScript and you're running on top of the browser. Most of modern browsers are written in C that are also using C libraries that are written on native platform tool kits whether it's OSX or Linux or Windows which then are written on top of these operating systems which then are written on top of these compiled assembly language that run on these microprocessors. It's a deep, deep ocean, so to speak. And we spend most of our time skimming around on the surface in our boats. And so, I guess the question is how do you know when to stop and how do you know when enough is enough? Ultimately, there is a tension between a deadline and the amount of time that you're going to invest in learning. And I think that there are definitely -- I feel very strongly that it's skewed way towards the deadline and that we need to kind of pull that tug of war back in the other direction. So the question is then how far is far enough? Or is it just really until you feel comfortable? KYLE: I see the world of what we do in computers and in software development as layers of a cake if you want to mix in a whole bunch of different metaphors here. There's lots of layers of abstraction that we create to utilize technology more effectively in our lives. And in a sense, the technological revolution from the 1940's onward has really been a story of adding layer upon layer upon layer upon layer just like a big tall cake of different abstraction because lots of different people need to eat at different layers. They need to get their jobs done, if you will, at different layers. There are people who need to get their job done the assembly language, the deep guts of your computer talking to the 1's and 0's kind of thing. And then there are people that need to work in the C libraries. And then there are people that need to work in the operating system tool kits. And then there are people that need to work in the browser. And then there are people that need to work in JavaScript. And then there are people that need to work on frameworks. And then there are people that need to work on transpilers that build the frameworks that then get compiled down. So we just keep adding more and more layers because there's more and more people that were opening up the world to, to participate. And not everybody is going to play on the same level. If your choice is to be a JavaScript developer, if your choice is to be a React developer, if your choice is to be somebody who builds those almost meta tools like the transpilers that go from one language to another, if you're a ClojureScript developer or whatever, my recommendation is that whatever layer of cake you eat out, whatever layer you've chosen to make your primary focus, I think you should be striving to become an absolute expert at that layer. And that is not a transactional thing when you just go watch the right video or read the right book and then you check it off. That will be, in most respects, a lifelong process. But I think you should strive to be as much of an expert at that layer as you can. But to become an expert at that layer, one of the most important things is to begin to have an understanding, a level of competency at the layer below it. So if you're a React developer, having a layer of JavaScript below it means that you want to have some pretty good core competency in the JavaScript language. In a sense, that's what my job is dedicated to doing is assisting people at playing at these higher levels at the frameworks and tools levels by understanding JavaScript more deeply. But if you're a core JavaScript developer and that's all you do, you should have some competency at the layer below that which we might say would be the browser API level or maybe the C level and understanding something about how memory is going to get managed to let you have some intuition about that. And so, the further you go down in the stack, you start to see that diminish but it never gets to zero. I don't think there should be any engineer out there that aspires to have absolutely no knowledge whatsoever of what a processor is or what 1's and 0's are or any of that. But that might not be your everyday task. If that's 4 layers removed and you have a lot less understanding of that layer, to be effective in your job, you should be an expert at your layer and be seeking to have a core competency level of understanding at the layer below that. I think that's how you start to answer, Charles, your question of how do you figure out where to stop is at this point in your career -- because many people will dance around and eat at different layers of the cake as they go. But whatever point you are at in your career now, be looking to understand how to eat all that layer of cake and then understand the one below it. I would say that would be the most effective strategy that I've come up with. CHARLES: I like that. I like that a lot. STEPHANIE: I want to become an expert in JavaScript. But sometimes I have doubts in my ability to "become a programmer" or think like a programmer. I feel like the people that excel in programming, and you could tell me if I'm wrong, I don't know if you've noticed this as well or haven't. But it seems like the people that excel at programming are the people that are naturally good at math. It's like they think in terms of math. I don't know if they're seeing algorithms in their brain or what it is. And I don't know if other people relate to this as well. But I'm a natural problem solver. I like problem solving but I don't think in terms of math. And I've taken a lot of math courses for my undergrad degree. I took Calculus for Biosciences like two and a half times, and so I beat my brain enough to understand those concepts. But I don't know if you have also seen that, if that is the case. And if it is the case, is there any advice for the hopeless programmers like myself that are not naturally good at math. But I am interested and I do want to be good at this. KYLE: There's hope, Stephanie. There's definitely hope. STEPHANIE: [Laughs] KYLE: Again, lots to unpack here and I thank you for asking that question because I actually do have a particular sensitivity to the mindset that seems to come around between people - again, the haves and have-nots. There are people that naturally gravitate to or understand math and there are people for whom math has always been an opaque topic that they keep running into over and over and they haven't been able to really fully engross themselves in or wrap themselves in. They haven't been able to get it, if you will. And as an educator, I don't teach math for a living. But as an educator, it deeply troubles me. As a parent, my son, Ethan, is about to turn six. He's in Kindergarten for the first time, so it is right on the front of my radar screen to think about how we teach these things. And I want for everybody to be able to grasp important concepts like obviously reading is important, but Math is one of those core concepts that I think is important for people to not be intimidated by. And I think we do ourselves a really big disservice and have for many, many years by approaching the teaching of that topic as there's one right way to know how to do math. In a sense, I think, we're seeing a shift to know there's lots of ways to learn and we should embrace that. Just like we said there's lots of different ways that people learn. There's lots of different ways to approach. There's lots of different pedagogy, if you will, around approaching math and I embrace that idea that we should be doing that. I think we should be starting that with our Kindergarteners and working all the way up. And I'm glad that there are educators that are thinking about that because my generation was taught that either you get it this way or you're just "not a math person". And I sat and sat alongside in my Science and English classes all the way through schooling even at University, I sat along people that were math people and on the other side of me were people that were "not math people". It's sad and it sucks that we would divide people that way or that people would choose to divide themselves that way because they struggle with math. My sphere of influence right now is my two kids - my son, Ethan, and my daughter, Emily. I really want for both of them, whether they become math nerds or nor, whether they have a minor in math like I do or it's just a thing that they learn, I want them to not be intimated by that. I want them to understand it. And I hope that I will be able to, in the sense, partner with the educational system. Our kids are in Austin IST Public Schools and they will be for their whole lives, as our plan, but I hope to, in a sense, be augmenting that by saying, "I understand that this is struggling for you, but let me help to at least not be intimidating, at least be a thing that you can grab on to and understand even if it's not interesting to you, it won't be scary to you," because I have family members and I see it personally that have self-labeled and self-[inaudible] themselves as "not math people" and they struggle their entire lives as a result. And I don't want that to happen. So, I'm glad I got at least a little chance to have some advocacy there to say I hope that people aren't being that way and aren't promoting patterns that treat people as either you know math or you don't. I was one of those people that gravitated towards math. But I can tell you for a fact that I do not use most of my math background on a regular basis as a programmer, and even if I try. As you're asking the question, I was doing some self-assessment here. What are the things that I know from math? Like I understand for example that a function is putting in an X value and getting out a Y value and when we plot that, we see a parabola on the graph. I get that concept. So, there's a tie in between the visual and the actual written out math for me. And I understand in calculus when we have the integral. I understand that's the area underneath the curve. So, I get those concepts. But does any of that stuff actually play into my day-to-day work? Not really. Maybe a little bit about functions since I'm starting to be a bit more attuned to the functional programming these days, but it really doesn't play into my job. But there is a part of math that really does play in almost daily, and that's what we call discrete math. That's more of the computer science-y take on math. And discrete math is things like understanding number systems, things like understanding the difference between representing something as a binary or representing it in base 10 or hexadecimal. There are certain concepts that we talk about like Big O Notation - that's one of those computer science-y concepts. When I was writing this game AI, I had an intuition about a loop inside of a loop is going to perform worse than just a single level of loop. But I didn't spend any time whatsoever actually calculating the Big O complexity of my algorithm. I just had some intuition about it. And the reason I have this intuition about it is because I took a discrete math class. So, if I could say anything to the people listening, for those that aren't math people or for some reason or another didn't really gravitate towards it, to be better at programming, I would encourage you to at least think about discrete math as an area to study to get some better understanding around, because I do think those things help. But I don't think that most of math, the stuff that most people struggle with, like algebra and matrices -- I was terrible at matrices. I hated them for some reason. I don't think most of that ever comes in. I learned what an icon vector was but I've never once coded it. So I don't think that you have to feel intimated coming at programming if you weren't one of those "math people" but there are some parts of math that do end up playing quite a bit into the programmers' everyday life. CHARLES: I think for me certainly whenever you have a particular problem, then that's an opportunity to actually explore the math behind it. I think a lot of times we put -- there's this kind of inverse relationship -- we put the cart before the horse. It's like you got to learn math and then you learn the programming. But it's almost like the equation ought to be reversed in the sense that it's like trying to -- let me just cast about for a random analogy here -- it's like learning the theory of fishing without actually living on the coast and going out on a boat every day. You can certainly study it and it can be interesting. Yes, we tie the line to the pole and we put it in the water but unless you actually have that problem of like, "Now, I'm trying to catch fish," you actually are connected to it in a way that's going to help you understand what solutions work and which ones don't. I often feel like we frontload way too much on the theory. I feel it has to be connected to practice, I guess is what I'm saying. Because certainly my experience, I come from a CS background, but I didn't switch to CS until my junior year of college. And that after I'd basically dropped out of school for two years to work at a startup. And I remember it made a lot more sense because I had this prior programming experience. It's like, "Oh…" Whereas, I think a lot of my classmates, they were kind of dumbfounded by, "What does this even mean? I don't understand. I don't understand how this connects to anything." But if you have that kind of experience, then the learning can come in hand with it but it has to be more of an organic process as opposed to one coming before the other. That's my experience. KYLE: I love what you're saying there and I want to build off of that to unpack some of my most recent passion and focus in the area of education and with developers because I really think what you're saying is the foundation is the same belief I have. So, I'm right there with you. If you look at humans and the way humans have passed along information and skill to the next generation, if you look at that over the course of history, we have mountains of precedent around the idea that skills are passed along through the mentorship model. Some like to call it the master apprentice model. It's the more classical way to think about it. But just the more modern way is to call it mentorship. For example, chefs. You would never suggest that the best chef at the best restaurant in town and the way that that chef got there, the way that that chef got to be the best chef in town and have the best restaurant was that they sat in a classroom and learned all the theory about how to bake a chicken. First, before going and baking the chicken, there's lots of ways that they could have gotten to be better but probably the least effective way would have been for them to learn all the theory upfront and then just go work in a kitchen for year after year after year after year and almost accidentally -- we call it the School of Hard Knocks -- accidentally learn all those experiences. That's how a lot of people define experience is experience these mistakes over time getting practice making perfect. That does work and lots of people have done that. And I certainly would say a lot of my story is that way, but I wish that I'd had a mentor. I wish that I'd had somebody like what happens with chefs to sit there and say, "I'm not just going to let you figure it out on your own and screw up a bunch of chickens. What I'm going to do is give you a little bit of information about cooking a chicken. Like for example, what the temperature of the oven needs to be, how to tell what the temperature of the chicken is to know that it's fully cooked, what materials you need and what utensils. But we're going to spend 10 minutes in the classroom talking about it and then we're going to go sit in a kitchen and you're going to watch me bake a chicken. And you're going to watch very carefully. And I want you to ask a lot of questions about what I'm doing and I'm going to talk to you about it every single step and the decisions that I'm making. And then I'm going to do that again and again and again and again. And over time, you're going to start to pick up on and glean some of my experience from observation. And then eventually, once you are starting to feel more confident about it, we're going to flip the tables and now, you're going to start baking the chicken but you're going to do it step by step methodically and I'm going to watch you and be very closely paying attention. And I'm going to ask you questions and I'm going to say 'why did you squirt that there and why did you do this and why did you turn on the oven right now'. And I'm going to ask you about that stuff and challenge you to make sure that you really got all the different pieces of what it takes to master this skill. And then I'm going to do that again and again and again. And after we feel pretty good about chickens, we'll go back to the classroom and we'll talk about cooking steak and then we're going to repeat this process over and over." That is much more the picture of how that mastery of that skill is replicated in another person is that mentorship model. And we've seen that with stone masons and carpenters and plumbers and chefs and caterers. And on down the line through most of human history, we can see that that is how skills are passed along. What I think we're missing is that there's a lot of value to be gained by applying those models to software development. As a matter of fact, I think if you ask most developers, regardless of the skill level even if they were a senior developer -- although certainly the intermediate and junior developers are more willing to admit it. But I think if you really ask in their heart of hearts, almost all the developers would say, "Oh, I'd love to have a mentor to help me get better but I don't know how or I can't afford it or there aren't any available or I don't know what to do," because we haven't prioritized as our part of the industry making education more effective. And so, when you talk about 'I need to practice a thing, not just know the theory', you're absolutely right. You're absolutely right that sitting in a classroom and learning a bunch of stuff which ironically that's what I do. I teach corporate training classes, I threw out a bunch of information then I know as I'm throwing out that information, the vast majority of it isn't going to be retained because the only stuff that will be retained is the stuff that somebody gets a chance to practice pretty quickly. And by pretty quickly, I think probably that horizon level is about three days beyond when you've learned it. If you don't get a chance to really practice, and I don't mean just the artificial stuff that we teachers come up with like a silly little toy examples and the foobar kind of stuff, I mean really practice in a context of something that matters and that you're thinking about it and you need to solve it. If you don't get a chance to practice some of that theory within about three or four days, you're going to lose it. So, I present to you a set of information in a week-long training course that you really ought to actually learn. And by learn, I mean more than just hear the theory but also practice it. You really should learn that over 12 to 24 months. But I give it to you in 40 hours because that's, again, the industry incentivizes how quickly can I check off the check box then my developers learn how to become React developers or that we learned about JavaScript. Instead of focusing on how do I really get them to know it. And the only way to really get somebody to know it is to have somebody watching over them as they practice what was taught. You teach a little bit and you have a bunch of practice. And that practice can't be just the developer has to figure it out on their own and make their own mistakes and figure it out through Stack Overflow, it has to be monitored, it has to be proactively mentored. And they have to take a little bit of learning, a lot of guided practice. Pipeline that across, that's how we make this educational process for developers become much more efficient, much more effective. And so in a sense, what I'm trying to do is disrupt my own educational model and try to [inaudible] myself as a business by saying, "I teach it in the classroom but every time I walk out of that classroom, I feel empty inside," because I feel not just tired physically because it is exhausting, but I also feel empty inside because I know that what's really missing is that I just contributed to yet another transactional learning experience. But what really is important is for people to know that learning that is most effective is learning that's relational. Learning has to be paired with people because at its heart, what we do as developers is a people game. It's not an 'instruct the computer' game. The 'instruct the computer' is a side effect of what we do in connecting with people and passing along information and skill and knowledge. We've got to do that because we are throwing all kinds of money and time and effort at figuring out how to make people learn better through books and videos and conferences and tech schools and the list just goes on and on and on. And it's good that there's a wide buffet for people to pick from, there's no question. But most of that stuff isn't as effective as it ought to be, and that is why people have to keep doing it over and over and over again. They have to try all these different things because they don't get satiated by picking the one right thing that they ought to have fixed. I happen to be obviously very bias, but I happen to believe that a lot of the problems that developers face, a lot of the overhead of code maintenance and all of that stuff, it could be solved if people were trying to implement mentorship for developer education. And that's what I'm trying to do. My recent efforts are around upending or reimagining the normal corporate developer training. Of course I still offer that. And if anybody wants me to come teach, I can still do that. But what I'm moving towards and building a startup to offer mentoring at scale because I believe that's where we move it from transactional relationship. We make it about people and then we get a chance to really practice what we're learning. That's how you take a person, and get them from being junior to being intermediate or from intermediate to senior is that they have to have practice. Would you rather them figure it out on their own and make lots and lots of mistakes or would you rather them be guided and monitored as they go through that process of practice? I think the latter would be a lot more effective. CHARLES: For people who are excited about this, who want to figure out ways in which to engage in this relational learning, this can be a very expensive proposition especially for smaller companies. But even for larger companies, one of the things you're hoping to address is a way to make this when you say 'do it at scale, make it more accessible' in terms of those time and resources. KYLE: In a sense I would be failed at the start if I didn't feel like I had a model for scaling mentorship. If I was just on here and [inaudible] saying, "Hey, everybody. You should go mentor," and I had no way of doing that, then everybody will say, "Okay, that's all well and great. Thanks." And as soon as this podcast ended, they'd just go on back to their normal day jobs and fix anything. I really do believe that there are ways to scale out and to make it effective. That doesn't necessarily mean that the price tag is cheap because time is expensive. And what we're saying is you need expert time paired with your people to get them to where you need them to go. But I want to push back on the notion that expense makes things inaccessible, because I want to point out -- this is almost like I'm doing a customer pitch. But I just want to point out that there's an awful lot of things that we spend money on as managers of software development teams. For example, I've talked to managers of software development teams and they've said, "We probably spend 70% to 80% of our time maintaining our existing code and fixing bugs, and only maybe 20% of our time implementing new stuff." Some people listening would say, "Good lord, I'd love to have 20%. We probably spend 5% of our time on that and 95% on maintenance." So those numbers differ. But there's a lot of overhead associated with running a software development team. And one of my theories which I believe we will prove out as we scale this out, one of my theories is that if you want people to avoid having to come back and return on something. One of the ways to do that is to empower them with better education before they write that line of code. I think even though yes it will be more expensive to get your developers mentored, you will actually not spend more as a company, you will spend much less because you'll be investing that money much more effectively in the things that actually make them retain and get a chance to practice that. It also means that hiring will be cheaper because you'll know much more deeply what your company wants and needs and that will make it a lot easier to identify the right candidates. It means that the total cost of ownership of yourself will be vastly less. So there's lots of dollars here that I think we can pull that we are, in a sense, wasting or misappropriating to make it more effective to invest in mentorship. I think what we need is a process and a model instead of tools to do that, and that's my mission. That's my goal. CHARLES: I am very, very excited to see that, because I know that that is something that one, holds the value. Here at the Frontside, we see as one of our core beliefs and one of our core aspects or mission is to level people up and make sure that they can improve themselves as a developer and improve the quality of the products that they develop. But it's definitely something that we've struggled with. So, I'm really curious and excited to see the outcome of this. So, we'll be on the lookout for it. Is it still under the radar? KYLE: There's no company name to announce yet. There's no website or Twitter account. But I can say that it's been under active development now for four to six months. I have a team of founders with me and we are formalizing our process in trying to get funded for that. I hope within the next few months that there'll be a much bigger announcement about where we're headed with it because I'm all in on believing that it's not just good enough for me to keep churning. I get emails and tweets weekly. I get a couple to maybe five or ten sometimes in a week of people saying, "Hey, I read your book," or, "I watched your Frontend Master's training video," or whatever, "And that's awesome. I'd love it if you could help me with something. Could you spend some time? How much would I need to pay you to get a few hours of your time to sit here and talk with me?" And it pains me to get these kinds of requests. And the reason it pains me is because I would absolutely love to spend that kind of time with people, but that kind of time is so valuable right now. Time is so valuable because the process of mentoring currently is incredibly time intensive. It's very, very expensive to do this. And that's why I think it's not done very widespread is because people haven't figured out how to make it effective, from time and money perspective. And I know that pain personally. I have to turn people down and say, "I'd love to but I'm too busy because…" and then fill in the blank with a thousand things. I'd love to have that time. What I really want is I really want to be able to do this effectively and to scale it, because people are hungry. They want to learn. I believe that what we need to do is unlock that hunger, not necessarily inspire people. I think we need to unlock and empower that hunger that people naturally tend to have to want to get better at what they do. And I think this is one of the ways that we can help people get better. STEPHANIE: I also wanted to point out that for companies that are interested in doing this, not only do junior or apprentices benefit from this model but the senior developers also benefit from this. I have personally seen someone on my team, Alex, from all the times that we've been pairing and talking about JavaScript concepts, I have seen an exponential growth in just the way that he explains things. And they do say the one that does the teaching does the learning. And I have seen that in him and I think it's something that every team could benefit from. KYLE: I 100% agree. And to build on that, I would say what we're really doing with that is we're helping people find more purpose for what they do. And who doesn't want to have more purpose and more meaning? We're giving people a way to -- as I said, all boats rise with the tide. We're giving people a way to help other people around them. And it doesn't have to be like some macro scale thing where you become an international conference speaker. You don't even have to speak at your local city meetup. You can just pair with the person next to you and help them learn the thing that you're learning, and then learn from them. And you've made the world better, you've made the workplace better, you've made yourself better. It goes back to what I said before - I think we have to get better. The biggest thing that's lacking from us developers right now, in my opinion, the emotional muscle that we need to work on the most is recognizing empathy for our fellow human beings for the people around us because I really deeply in my core believe and my DNA I believe that what we're about is people and not about the code that gets written as a result of this connections. If we can focus on building the relationships around this. You don't have to go pay for the service of the startup that I'm building. You can implement this just like what Stephanie just said, by looking for opportunities whether it's coding, whether it's code review used as a way to learn, whether it's doing a brown back lunch, you can look for ways to build the culture of learning into the workplace around you and people will benefit from that. You will inspire people to get bigger and better as a result of providing that environment. CHARLES: Fantastic! If people need to get hold of you, Kyle, what is the best way to reach out to get in touch? KYLE: The best way to get in touch with me is to find getify. That's how people know me online. That's my Twitter handle, that's my GitHub handle, it's also my Gmail address. So, getify@gmail.com. Reach out to me in any one of those channels, probably through Gmail is best. If you'd like to talk more about education, if you'd like me to come and help your team, I would love to come and do a workshop and then build a relationship with you or we can begin this mentoring process as I spin that up. If you're interested in that, if you're hoping to learn from some of my resources, you can check out my book series. I have the You Don't Know JS books that I wrote that many people know about. That's up on my GitHub. I'm almost done with my next book which is Functional Light JavaScript, you can check that out on GitHub. All that stuff you can read for free. You can also buy it if you'd like to -- and I always appreciate people if they want to support me. But check out my books. I have training videos available on FrontendMasters.com. I think I have nine courses and we've already scheduled a few more that I'm going to be teaching later in the Spring. That's a fantastic platform. There's 50 or 60 really incredibly well-versed experts that are teaching on that platform. So, check out Frontend Masters. Some of those videos are also out on Pluralsight. You can check them out as well. Check out books, check out the training videos, get in contact with me if I can help you in some way with training at your company. But I would love it that even if that isn't the channel, if you take nothing else away from the podcast, go talk about learning stuff deeper within the workplace. That will be the best takeaway that we can get from this podcast. CHARLES: Yeah, definitely. I think the things that we talked about here really apply far beyond JavaScript and even really far beyond the technical trade of programming. All right, that's a wrap. Bye everybody!

関連リンク 2016-12-06のJS: Ember.js 2.10、Front-End Tooling 2016アンケート、Svelte - JSer.info The State of Front-End Tooling 2016 - Results - AshleyNolan.co.uk - Blog and Portfolio for Ashley Nolan Svelte • The magical disappearing UI framework 一から始めるJavaScriptユニットテスト - Hatena Developer Blog 新しめのCSS設計まとめ 〜2016年冬〜 - Qiita 8種類あるSVGスプライト それぞれの特徴を比較してみた - 週刊SVG Chromatic Aberration in CSS tv JVNVU#93847769: Mozilla Firefox における解放済みメモリ使用 (use-after-free) の脆弱性 Firefox 0-Day targeting Tor-Users - G DATA GitHub - trueadm/inferno: An extremely fast, React-like JavaScript library for building modern user interfaces GDG神戸 React のソースコードを読んでみよう！ - マルシテイア Rails5.1に向けてフロントエンド周りで起こっている革命まとめ - Qiita GitHub - rails/webpacker: Use Webpack to manage app-like JavaScript modules in Rails GitHub - clojure/clojurescript: Clojure to JS compiler GitHub - omcljs/om: ClojureScript interface to Facebook's React

Jamison Dance: @jergason | Blog | GitHub | Fivestack | Soft Skills Engineering Podcast | React Rally Show Notes: 00:58 - The Elm Programming Language 01:36 - Who should try Elm? What is the attraction? 03:09 - Scaling an App Across a Team; Conventions 06:19 - Routing 07:48 - Writing Tests 09:38 - Jumping Into Elm from a Component-based Framework 12:20 - Tooling 17:28 - Productivity 19:21 - The Elm Community 25:13 - Could Elm Replace JavaScript? 28:28 - Lessons Learned from Elm to Write Better JavaScript 33:45 - The Elm Syntax 35:49 - Checking Out New Languages and Communities 37:31 - Data Modeling Resources: Elm Packages elm-format Evan Czaplicki: Let's Be Mainstream! User-focused Design in Elm The Elm Guide Elm on Slack The Elm Tutorial Jamison Dance: Rethinking All Practices: Building Applications in Elm @ React.js Conf 2016 Transcript: ALEX: Hey, everybody. Welcome to The Frontside Podcast Episode 49. I am your host, Alex Ford, developer at The Frontside. With me as well is Chris Freeman. Chris, do you want to introduce yourself? CHRIS: Hi, everybody. I'm Chris. I'm also a developer at The Frontside. ALEX: We have a really special guest for today. I'm really excited. Jamison Dance is with us. JAMISON: Hello. ALEX: Jamison runs Fivestack Software Consulting Company, hosts Soft Skills Engineering Podcast, organizes React Rally Conf, and spells 'array.length' incorrectly sometimes. Is this true? JAMISON: It is true, yeah. I think I have a special ESLint plugin to yell at me now when I do that or something. But that has caused some pain in my life. CHRIS: Oh, that was very brave. Thank you. ALEX: We're going to be talking Elm today and writing better JavaScript with Elm. This is really exciting for me. I've gotten the chance to dive into the Elm tutorial a little bit, which is an absolutely beautiful tutorial if you haven't checked it out yet. JAMISON: Yeah, Elm is a programming language that runs in the browser and compiles down to JavaScript. It's a pure statically-typed programming language, which if that doesn't mean anything to you, don't worry. The take away for you is that Elm tries really hard to make it easy to write programs that don't crash and are easier to refactor and easier to work on and maintain, basically. CHRIS: And Elm is a language in of itself but it is pretty specifically intended for front-end development. Is that correct? JAMISON: Right now, there are some long term plans, but yeah. For now, it's front-end for building UIs and applications in the browser. ALEX: I heard about Elm. When should I check it out? Who do you see jumping into this language? JAMISON: I think it's aimed at people that want to build robust applications which is so vague, it sounds meaningless. Maybe I talk about what attracted me to it. The two things where I was interested in functional programming -- that's kind of like the technical language wonk, like geeky side of it. But the other side is I've worked for a while in some fairly large JavaScript applications and I've seen the nightmares that I can create for myself In just building something that works and is just really hard to work on. So the idea of a language that's focused on keeping your productivity high as the application skills and as the team skills was really attractive to me. Like the bio says, if I spell array.length wrong, sometimes I catch it, sometimes I don't, then my program breaks. Elm has a compiler that runs on all your code and basically, make sure that your code cannot crash. You could still have bugs and you can still just make your code do the wrong thing but it helps eliminate whole categories of errors. It just makes them impossible to create in Elm. If you're interested in functional programming or if you're interested in just building stuff that is easy to work with, like this kind of this curve of productivity over time where some environments and some languages start out really high, it's really easy to build something fast at the beginning and then maintaining it is just really hard so the productivity drops over time. Elm is trying to kind of flatten that out so your productivity stays high throughout the lifetime of your application. CHRIS: I actually have a question about that. I'm planning on bringing this up later but you gave me such a good segue that I feel compelled. You mentioned that one of the things that is nice about Elm-type system is that it helps scale an app, especially when it comes to a team. My experience there are kind of true different facets to what scaling an app across a team looks like. One is the categories of bugs that something like [inaudible] compiler helps you catch. But the other is, and this is totally coming from the fact that I use Ember every single day, that conventions also help scale across a team. I'm curious like what I've looked at with Elm, it looks like they definitely have the type system there and error messages there to help quite a bit. But I haven't seen conventions arising yet in terms of a lot of things, about how you build a front-end application. I'm curious, is it that those conventions are there and just haven't found them yet or they're still very much in development? Or is that not even really a goal for Elm in the same way that it might be nothing like Ember or Angular. JAMISON: You mentioned first the kinds of bugs that the compiler will help you catch. I want to talk about that really quickly. If people aren't familiar with what a compiler or type system will do at build time, it checks all of your code to make sure that all of the variables and inputs and outputs from functions match up. So you say this function takes in an 'int' and returns a string and it will go find everywhere that calls that function and make sure that they're always passing in an 'int' and return it, so that it always return a string. It kind of does that throughout the whole flow of the program. It eliminates those kind of areas where you just get the interface wrong. The program is huge. You don't remember all the inputs to a function so you just like passing an object when it expects a string or something and then later on it will explode. You don't get those errors with Elm which is the first kind of thing you're talking about. You mentioned that conventions and I'm not on the Elm core team or whatever. I don't have any special insight but my experience is Elm very much wants to create strong conventions around how you build applications. The Elm architecture is kind of a way to build front-end applications that is basically baked into the language. There isn't like a UI framework for Elm. It is Elm. That to me is a huge point on the strong convention side. There isn't like an Elm fatigue because there isn't a choice between a hundred different UI frameworks in Elm. Some patterns around how you build apps this small, I think are still being established but I think there are strong conventions already and the trend of the Elm community is towards picking strong conventions. You'll see Evan, the creator of the language, He'll talk about how he wants to have one really good library instead of 15 overlapping libraries of varying quality to solve the same problem. Elm has conventions already. The places where it doesn't have strong conventions are I think places that will get filled in but the goal is to pick up the language and you get everything you need to build an application attached to it that's all kind of figured out for you. CHRIS: It's been interesting you mentioned the thing about it's better to have one good library, rather than 15 libraries of varying quality. I've seen that a little bit in practice. One of the things that I started looking for pretty early on when I was messing with Elm was what client-side routing look like. There are a couple of different routing libraries. But if you look at them, you can see that they're actually kind of this progression, like you can see how they have built on each other and they're kind of like building up the stack of abstractions toward one final solution. It's very interesting because it's not like those other libraries that are still there. If you really wanted to use just a regular URL parser and build your own, you could. But you can also see this development towards something that anyone could take off the shelf and start using. JAMISON: Yeah, and Elm has been around, I think it was 2011 when it first started. But really, Elm as like a popular thing that people hear about and use in production is only a couple of year's old maybe. There are still some things that are evolving like that. I think you're right that they're evolving towards convention instead of, in my mind JavaScript values, the proliferation of tons of different ideas and just wild exploration. Elm seems like it values a little more consensus and aligning the community behind one solution. I think it's happening, if it's not there yet, it'll get there, I guess. ALEX: I have a question about writing test in Elm and how that feels different than writing tests in JavaScript because the way I find myself writing tests right now is I understand the language to be fragile and I understand some frameworks have some fragility because of that language so I find myself writing really strong tests that are easy to break. I imagine that maybe in Elm, that's a little bit different with this very strong convention that you're talking about. JAMISON: Yes, some of it is around not having to be as defensive in your testing. If you wanted to get really, really down in the nitty-gritty in JavaScript, there are just an incredible array of different inputs you would have to test to make sure someone doesn't pass in like [inaudible] to this function where you think it's an array or whatever, like you just don't have to write any of those tests because the compiler catches that. We haven't talked about purity at all and this concept in functional programming where your functions can't cause side effects. They can't just go make a network request or write to disc or console.log like right in the middle. The functions take an input and return an output. You can do that in JavaScript. You can write your functions that way but because that feature is built into the language, it's the only way to write functions in Elm which makes it really easy to test functions because you just pass them stuff and you check what they return. In my experience, that makes them easier to test. You still build UIs and you still make network requests so you still construct some HTML at some point in your program. You can if you want to test that the HTML looks right or that elements have certain classes and stuff. But I guess what I'm saying is the tests feel like they're testing the behavior more than the edge cases when I write tests in them just because the compiler eliminates a bunch of weird edge cases you don't have to worry about. ALEX: Coming from a component-based JavaScript framework, what is going to be my experience jumping into Elm? How is that going to feel different for me? JAMISON: That's a great question. Myself and almost everyone I've seen get started in Elm that comes from something based around components that the instinct is to create components in Elm for everything. You have a select box in Ember or React or whatever and you wrap it in components. You can just reuse it everywhere. In Elm, if you try to do that, you will hate it and think Elm is broken and horrible and just sucks. It's because the Elm architecture comes with, I guess, you could call it boilerplate, there's some work you have to do to build a component that can do IO and respond to events and stuff. That work is... I don't know, maybe like a dozen lines of code. Then there's some work to wire those components up together, that's maybe a couple more lines of code. So if you have like 300 components in your Elm application, you'll have... I don't know, like thousands of lines that just wiring stuff together code which won't really buy you that much because in my experience, using components is an attempt to make things understandable and isolate concerns. You get a lot of that from having peer functions and having a strong a static-type system. In Elm, you end up making a lot wider components, instead of having this deep tree of lots of components nested inside of each other. You'll have a much flatter but wider tree. That took a while to get used to but I think it makes sense for the language now. You can still create reusable things but you focus more on creating reusable functions instead of creating components that are black boxes, that you kind of package up and pass around. You can still do reuse but it's a little bit different than reuse in a component-based framework. This is a thing. I would say, in the last year, there's been a lot more discussion on blogposts and screencasts and stuff on a year ago, a couple of people were talking about it but there weren't really lots of great examples of this and now, I think, even the Elm Guide has some examples of reuse without components. ALEX: Yes. One of my favorite things about component-based JavaScript is because I've learned to test them so well. Even though, sometimes they can turn into a configuration ball, I've been able to make them very reliable, even if they are deeply nested so going away from that scares me. JAMISON: Yeah, it totally scared me. It felt wrong and weird and bad. But now, it doesn't. I don't know, I'm used to it, I guess, and I still write a lot of JavaScript. It's not that hard switching back and forth between those two mental models but I definitely had to develop a different mental model when writing Elm code. CHRIS: I'm interested in talking about some of the tooling. I know Elm has a lot of tooling. They have elm-reactor and they have the compiler. But I think I know that you also do the kind of dip into some of the JavaScript tooling if you are getting into bigger Elm application. You're probably still going to need something like a Webpack or Browserify, I guess. I'm curious what's your experience with that has been? JAMISON: You can definitely just write an Elm application and then compile it into this JavaScript file then drop that in a script tag on your page and it will all work. The complexity can get very low. If you want to do more advanced stuff like talking to JavaScript, You can still do all that without any additional tooling, if you would like. If you have a lot of dependencies in your JavaScript or you have a large JavaScript application or code base that you want to integrate with Elm, then you can use something like Webpack or Browserify. In my experience, it's no more painful than Webpack or Browserify. All the rest of that stuff already is. I don't know, there's an Elm Webpack plugin that will run the Elm compiler and allow you to import your Elm application into JavaScript file and I think there are similar stuff for Browserify and some of the other module bundlers. I don't think there's anything radically new on the Elm side as far as bundling up your application or anything like that. It just kind of works like you expect. The places where, I think Elm tooling is cool in ways that I haven't seen that much in JavaScript are in the Elm package manager. If you are building a package yourself, it has automatic semantic versioning built in so they have a type system. They can detect when your interfaces change automatically. If you try and release a version that you change the interface and you don't bump the version, they will like yell at you because that's a breaking change. There's some cool stuff around that that you get with the language having a static-type system. The debugger is a new thing as of a couple of weeks ago. That's built into the language. You might have seen similar stuff in other frameworks but it's all kind of extra add-ons. In Elm, because it has kind of a framework built into the language, they can also build in a debugger for that framework in the language. You can enable debug mode, pull up an application, click around, do a bunch of stuff, and then it'll record a log of all those actions and you can scroll back through them and jump to any point in that timeline to reload the state of the application to that point. You can export that log to a JSON file and then kind of send that around, have someone load that log in, and it'll get your application back into the same state. It's a really good for creating bug reports. You click some button 15 times and then it breaks -- do that, export the logs, send that to someone else. Instead of having to follow all the steps, they can just load your state and then figure out what's broken about that. I think that there are some tooling advances that are enabled by both the language itself, like the static type system and also the focus on strong conventions and frameworks built into the language. Does that makes sense? CHRIS: Yeah, absolutely. As you were talking, I thought about was that some tooling that you lean a lot on in JavaScript is kind of rendered unnecessary by the error messages in Elm. All of the things that you may bring in an extra tool to catch in JavaScript when in Elm will just tell you when it compiles and it will give you this just unbelievably friendly, informative, and easy to diagnosed error message that tells you like, "This is the exact line where this happened. Maybe you mean to do this instead," because it can make all sorts of inferences about, like what you probably meant to do based on the type signature you gave to a function or something. I could see that going a long way toward making a subset of tools just unnecessary in Elm. JAMISON: Yeah, a lot of tooling around JavaScript has sprung up to address... I don't know, not weaknesses but areas where people have identified JavaScript needs a little help now. If that's passive aggressive enough way to say it. The language is 20 years old. It was created way before people were building giant, million line code bases in it. But Elm is much younger and has the benefit of a lot of history and hindsight. It turns out you can avoid a lot of tools if you eliminate their need. I have had that weird feeling where I'm building a JavaScript project and it feels like I'm flying a 747. There's a thousand switches everywhere. I'm like powering up a bunch of different things. It feels like I'm being really productive because I'm configuring ESLint in Webpack, in Flow, and all these different tools. Then I go to Elm and I just start typing and it feels like I'm less productive but I've just skipped so many steps. It is a different feeling. ALEX: Would you say that maybe you feel so productive in JavaScript because it has such a strong community, with so many examples and so much shared code? Elm being a younger community, and this is strictly an assumption, may not be at that maturity level where you can share code and have that particular level of productivity. JAMISON: Yes. There are definitely third party libraries in Elm. There's probably a few orders of magnitude difference in the community sizes between Elm and JavaScript. There are just way more people writing JavaScript. The likelihood that someone will have ended up at your weird feature that you need for some random program is probably a little higher. There are some numbers differences. In my experience, the people that are really into Elm right now enjoy solving their own problems because it does feel like they're a little bit more of your own problems to solve. It's a tradeoff. I was going to say, if you value 100% focus on building business features, JavaScript might be better but I don't necessarily think that's the case. Using a bunch of third party code comes with a cost and some of that cost is you have to understand the API and some of it is you have to kind of take some responsibility for knowing where it breaks down. In Elm, I think that responsibility is lessened by the language because the API is a lot easier to understand when you can look at the types that the API creates and uses. It's a lot harder for it to just break your stuff. I think you could make the argument that even though there's a giant repository of JavaScript code out there, a lot of it might not be great for your program. But if you're using Elm, the smaller amount of code that is out there already could be easier to use and help you even more productive. ALEX: I would like to try to segue into the Elm community now and what that looks like? What is this Elm community? How do you get involved, say, I'm coming from JavaScript or any language and I love it? Maybe my work doesn't use Elm just yet but how can I contribute? How can I continue to write more Elm code for not just my specific use cases? JAMISON: I think my favorite thing about the Elm community is its focus on friendliness and learnability. I call it 'ruthless focus'. They are aggressively committed to building a language that is easy for people to pick up. If you are coming to Elm for the first time, you're pulling your hair out because it looks totally different from JavaScript. That might not make any sense to you. But a lot of the ideas that Elm has come from other languages like Haskell or ML languages and those languages, I would say, are proudly hard to get into. It's like a badge of honor to learn Haskell and then you like bleed to do it and then you enter this elite club where you got to talk about monoids all day. Elm is like a strong negative reaction against that, like they want this to be a language that people can learn and get some of the benefit. Because there are cool things in languages like Haskell so the goal is to take some of those cool things and other cool things from other places too. But put them in a package that is easy for people to pick up without devoting their life to an arcane branch of mathematics. I think they do a really good job of that. I've done Haskell pretty hard a few times and I'll bounce off it some more. I don't feel confused about Elm at all in anyway. In Elm, it's not like I'm some genius that can pick it up. It's that they have eliminated a lot of complexity and made it friendly and easy to learn. I think that carries over into the community. They're really interested in helping people who are new to functional programming or are new to programming in general. They're also just nice. if there's an Elm Slack channel that you hang out in and like any internet chat channel, sometimes people will get a little testy and in the Elm one, they're so good at defusing situations, calming people down, like apologizing, and like being human beings. You don't see a lot of rage-y arguments where people say mean things about each other. I've been really impressed with that. I want to talk a little bit more about what the community is like and then maybe talk about how to get into it, if that's okay. I would say the community is -- I know, it's evenly split but it seems fairly evenly split between people coming from JavaScript's who don't have any functional programming experience and people coming from functional programming who don't have any UI experience. It's interesting seeing those two very different groups come together and they're both attracted to Elm for different reasons and they kind of pull it a little bit in different ways. But it makes an interesting group of people to be around because you learn a lot of cool UI stuff, a lot of cool functional programming stuff. ALEX: Sounds like a recipe for success, really. JAMISON: Yeah. I think if they can make functional programming not have the snootiness that it has sometimes in genders and people, then I think functional programming is great technically. I think the culture around it can be just obnoxious. So I think if Elm can take the good things without the bad things, that's amazing and that's kind of what it's trying to do. As far as getting into the Elm community, are you talking about writing open source or contributing to open source or just where they hang out? ALEX: Yeah, I was talking about contributing to open source but maybe Elm is just a better community for a certain style of contribution and maybe that looks like a blogpost and a coding example of how to do something yourself. JAMISON: Like any new technology, there are definitely in the kind of evangelism phase. If you do write a blogpost that says nice things about Elm, there's like a horde of people that will swarm all over it because they like people to say nice things about Elm. There's a bunch of people like writing books, doing screencast, speaking on it, introducing people to it, and that's well received very well. I think there's at least one podcast on Elm already. So all that to say that I think the community receives kind of education and I guess, you can call it evangelism stuff very well and they're excited about that. If you are interested in contributing to open source, you can actually go to Package.Elm-Lang.org and you can see all of the Elm third party libraries and they all have these GitHub for the backing of its package manager. They all have source links right there. You can just find any random library and get to its source. I think the community is pretty open to contributions from people. If you want to see Elm source code and contribute to it, they're very open to that. This is kind of a culture shock to me coming from other communities where you can't just like show up, submit a patch to Elm core, and then have a discussion, and get it accepted or rejected. They're not super open to direct code level contributions. They would prefer more use case feedback, discussion, and suggestions. Then the core team will take all these feedback in, think about it, come up with a plan, and then implement it, instead of take a lot of little patches from people. Some of the core libraries are a little bit harder to directly contribute code to but they are very open. If you try and use it, you run into something that doesn't work the way you expected and you can create a small example that demonstrates that. They're super open to discussions about that to influence the direction of the API. CHRIS: I think over the course of JavaScript and front-end development, there has been kind of waves of abstraction over JavaScript. There were just libraries and there were things like backbone and then it kind of moved into doing something like CoffeeScript or TypeScript and a couple others where the idea is -- ALEX: Good old Objective-J. CHRIS: Yeah, exactly. You might be transpiling down a JavaScript but there are still very much a clear link between something like CoffeeScript and JavaScript. Elm seems like it is one of a new batch of approaches where we're actually going to just sidestep JavaScript almost entirely. Like it is going to be like JVM bytecode or a browser and we're going to build an entirely new language on top of that. I know there's also a bit like ClojureScript, Scala.js, and PureScript and I'm curious, do you think that is going to be a continuing trend that front-end development is going to land on a mainstream solution that might not actually be JavaScript at all? Or do you see it as eventually circling back and pulling a lot of these features into JavaScript itself? JAMISON: I don't think that front-end development will be Elm in like five years or whatever. I don't think it's going to replace JavaScript at all. I think it might definitely influence tooling libraries or the language itself. The Elm architecture looks a lot like Redux because the Redux author read Elm and they're like, that's cool and then they wrote it in JavaScript. There are other places where like time-travelling debugging. I believe the JavaScript thing came from the Elm time-travelling debugger as well. There are cases where it has influenced JavaScript's already and I think that will continue to happen. Flow is a gradual-type system. You can lay it on top of JavaScript and they have done a lot of work on their error messages influenced by Elm. It's super cool to see all those influences back into the JavaScript community as a whole. I think there are classes of people who are more interested in doing some sprinkling of JavaScript on to pages. They might not even be like programmers really. They're kind of like designers who do a little bit of coding and I don't know if Elm makes sense for that kind of role where you just need to add a little bit of interaction. You can do that but it doesn't seem like a thing that group would focus on. It's just really hard to change the world. I write a lot of JavaScript so I'm bias but it feels like it's the most popular language in the world and being the most popular Language in the world is not a thing that's easily overthrown. But I think it will grow, like programming will look more like Elm does just in general in the future and I think JavaScript will as well. But I also think Elm will continue to grow. There's a lot of excitement about it and there's not a ton of people bouncing hard off of it. There's some people they're looking at it and they're like, "Eh, not yet." Some people just look at it and hate it. But from people that use it, I don't see a lot of those people dropping out. I've seen most of them sticking around. I think the trend is definitely -- Elm will grow. But I don't know if that will take over the world. ALEX: Then what lessons are developers bringing back to say and to write better JavaScript? JAMISON: I think a lot of people are learning about types and data modeling. If you learn programming through JavaScript, the idea that there's this defined shape that your data has and some tool will help you make sure that your data always looks like that is kind of like strange and foreign. I think a lot of people are learning that there's value in that. If you grew up in the MongoDB / Angular world like everything is schema-less, you just kind of slam some JavaScript objects everywhere, it all works, then it breaks, and you don't know why and you need to track it down. But I think seeing the value and thinking a little bit more clearly about what your data looks like and then forcing that through tooling is one lesson. That is taking a little bit more root in JavaScript. All the stuff around functional programming in JavaScript is like achieved buzzword status by now. But there is definitely still some education happening around how it's easier to test peer functions, how they're easier to understand and reuse, and how it's good to write them. I think Elm will continue to push that. Some of it though is there are some ideas you can take from Elm but it's just so much easier to use them to their fullest potential in a language and environment built around those ideas. You can kind of like cram a type system on to JavaScript. It's still really easy to get around and it does not model side effects at all. The elm type system modeled side effects so it helps you reason about where my program can talk to a network, where it can do things that are going to take a while to come back, and kind of sandbox those things into a place where you expect them, instead of have them sprinkled all over your program. CHRIS: I definitely feel that uncanny valley of trying to bring FP -- functional programming -- things back into JavaScript when it comes to pattern matching. That's something that in Elm or Elixir or any number of more functional languages. Pattern matching enables a lot of these higher level patterns that don't always translate super great back to JavaScript land. JAMISON: Yeah, the uncanny valley is a great way to put it. There are a lot of things that you can do that will lead to better JavaScript. But you always have to take the environment that you're working in into consideration. There are just some things you can't do or some things that are going to be more pain than they're worth to do. On the other hand, it is kind of nice to just type console.log wherever you want or type like '$.getJSON' or whatever. The added security that Elm brings comes at a cost of locking you down a little bit and that can be a little frustrating to people sometimes. But I think the payoff is worth it. ALEX: A side story. About six months ago, I tried to get into the Haskell programming book. That's currently being worked on. That's because I want to learn some functional programming lessons, maybe bring them back into my JavaScript, or just learn something new. It's useful to learn a new language and bring it back to your work. Of this 1300 page book, I got just past Chapter 2 and I was in a Haskell book club like everybody held each other accountable to finish this book. I did not make it. I could not figure out how to bring any of these lessons back into my code which is what I wanted to do here. Elm takes that functional programming concept and says, "We're applying it to UI right away." There's no, "How do I apply this? How do I side step this?" No, you're doing it immediately. Really, you're getting me excited to jump back into this tutorial and learn it and check out the community, just to be able to bring this back to my day to day and bring those lessons and do it. JAMISON: Yeah, the first time I tried to learn Haskell, I learned that I could sort an array of integers in memory and that was it. That was as far as my Haskell skills took me so I definitely feel you there. In Haskell, they'll tell you it's a research language so they have a lot of reasons why it kind of works the way it does and learning it takes the pathway it does. Elm is definitely not a research language. It's trying to be incredibly pragmatic so you build UIs. In the guide, that's how they teach you the language. It's the stuff you normally build. Thank you for bringing that up. I think, it's a thing that they focus on. I'm glad you picked it out. ALEX: Yeah, at the learning curve is the syntax but you're still solving those same problems. If you're coming from UI, you already have that context. That is probably the majority of the hard work -- it's solving problems that are meaningful to you. JAMISON: Yeah, for me the syntax, I had learned enough Haskell that the syntax wasn't hard -- how to make HTTP requests and do site-affecting things like that. It was the hang up for me but Elm, there is a way to do it and they show you and that's how you do everything and it all works the same way and it's fairly easy to understand. I don't want to call it easy because that makes people that struggle to feel that but they put a lot of work into making that both robust so it won't break your program and also learnable. CHRIS: One thing I would love to mention about the syntax, I have learned a number of languages, I guess and the Elm syntax was definitely one that threw me the most and it put me off for, I guess it wasn't so much just the syntax, it was the syntax combined with how people do things that I would call more like style choices. JAMISON: The formatting? CHRIS: Yeah, Elm formats things in weird ways. Except that there is a tool called 'elm-format'. Once I've discovered that it has a really great editor integration for a lot of editors, it effectively remove that problem because I discovered that I can essentially write garbage basically in my editor and I can say that anything will make it look beautiful. It's fantastic. It removes such a big barrier for me when I was trying to learn it. JAMISON: Yeah, elm-format, there were some great debates about it while it was being created but now that it exists, it's awesome. Speaking a little bit more of tooling, Elm comes out with new releases of the language with some backwards and compatible changes. But along with that, they release a tool to upgrade your Elm code automatically. It's not perfect and it won't run on 100%. It won't fix everything but with most projects, it fixes everything. Again, the benefit of having such a strict language is there's tools that will just upgrade all your stuff for you. That's pretty awesome. It lowers the cost of evolving the language because they can keep adding new things and changing things without just leaving the community in the dust like we've seen in some other stuff. That's kind of an Ember-ish thing, I guess. Ember has the whole stability... What is it? Something without stagnation? Stability without stagnation? CHRIS: Stability without stagnation. JAMISON: Where you just get all these free upgrades that are really easy to opt into and Elm has that same philosophy. ALEX: What made you decide to check out Elm, to check out this community? Do you like to jump into new languages, new communities, and poke around and see what sticks? Or is there something that attracted you to Elm in particular. JAMISON: Yes to both of those. I do poke around in a lot of new languages. I have a good friend, Sean Hess who's really into functional programming and he's a Haskell true believer. I am not but he is, so he teaches me stuff by Haskell. I think, he told me about it. I might be misremembering though. It might have been just some random blogpost or podcast somebody did a few years ago. But I was already excited about new languages and functional programming and I had tried to learn Haskell and bounced off so the idea of a functional programming language that takes some good ideas from Haskell, that runs in the browser that's new. It was like all the shiny things that I look for altogether in one thing. I tried it and I liked it. I, also was really impressed by Evan Czaplicki, He's the creator of Elm. His philosophy around creating a language and the goals he wanted to accomplish with it. There's a really good talk he gave and called 'Let's be mainstream' which talks about some of the stuff we talked about around if functional programming is pure statically-typed functional programming is so amazing and it has all these people that love it and swear it's the only way to write software, why no one does it? Why the number of people use it is so small? His thesis is basically because the languages that do this are kind of user hostile so he's trying to make it a user friendly, the one that takes all those ideas. I just really liked that philosophy. CHRIS: I want to go back to something that you mentioned a little bit ago and that was data modeling because that is definitely something that I noticed being extremely helpful, any time I'm using a statically-typed language. It is very much something that I brought with me back to JavaScript. But I was wondering, Maybe you could talk a little bit more in depth about what data modeling really means in terms of Elm, the type system, the record type, and that kind of stuff. JAMISON: Yeah, if you've worked with statically-typed languages like Java or C++ or something, you might have an idea of things like classes as a way to model data where you create a class and you say it has all these fields on it. I think, in the Elm type system, I'm going to say it's a lot better than those languages because it has a lot less ceremony and it is a lot more powerful. Elm has type inference which means you don't have to declare the type of everything. It can just figure it out from a lot of places. That's the thing that makes your code a lot friendlier to write. To model data in Elm, there are two main ways to do that. One is with these record types that you mentioned, Chris. You basically declare an object that has a certain shape like I'll make a type called 'user' and it has a user ID and a hash password and... I don't know, a list of my favorite cats or whatever. Then you can just refer to that user type in function arguments or in return types or anything like that. In Elm, because you created that type, it knows that these are all the fields it has. If you try to access a field that's not on there, it'll yell at you because you're doing something that won't work. Because you have to think through all of the different fields that are on your types, it forces you to do a little bit more. It's kind of like the other side of TDD instead of writing test first. You have to think about your data first. You could call it type-driven development, I guess. CHRIS: That's awesome. JAMISON: In my experience, that's helpful. In the same way, TDD is, right? It helps you to do a little bit of design first. Think about how you're going to interact with the program in some way. Instead of writing tests, you're thinking what data do I need here. They also have these things that you could call them -- there are a bunch of different names for them: algebraic data types, I guess. Some people call them tagged unions. They're kind of like enums where you say this type can take any of these finite list of values. But instead of an enum being like an integer, like it is in some languages with a fancy name wrapped around it, the enum types can contain other value. You can say... what's a good example for this? You could say a user is either an authenticated user with a user record inside it or an unauthenticated user. Then when you're using that type in your program, you check, "Is this user type the authenticated user?" Then, if so it has this user field inside of it that you can pluck out and use. Or, "Is it an unauthenticated user?" Those two different things, the super enums, the algebraic data types plus the record types are really powerful for modeling what data looks like in the real world. I haven't run into that many issues where it's been hard to do something I want to do with just those two concepts. Type systems are hard to explain over the air but hopefully, that helped a little bit. ALEX: I thought that was great. CHRIS: I think a good example of the algebraic data type thing is looking at messages in Elm versus actions in Redux. If our listeners are familiar with those, they are very, very, very similar at a high level. But in Redux, you just have string then you do a switch statement or something and you match on some strings. You hope that you synced everything up correctly. JAMISON: Yeah, you say, "This action has a message and then has a payload that looks like this." See if it match against the message and then hope that the payload somebody sent actually looks like you expect it to look. CHRIS: Yeah, whereas in Elm, you can actually say, "My message type is a union of all of these different things," and now, Elm knows exactly what you're saying and you can't accidentally send the wrong payload to the wrong update function or something. It's one of the cases where I found that there's a very, very clear similarity in JavaScript and it highlights, I think a lot of the nice features that Elm brings to that equation. JAMISON: Yeah and there's even more strictness around that, like you have to handle every message type in Elm. So if you say, "This function takes in a message and does something with it," and then you check against what kind of message it is, you have to check every case or Elm won't compile because they don't want you to just blindly miss something, I guess. But in Redux, you could just happily forget a thing in your case statement and then you send a message and it doesn't do anything and then you have to kind of trace through it and debug why that's happening. There's just more helpful stability stuff built in. CHRIS: Cool. I am so incredibly happy with how this podcast went. I'm just excited to start coding and start getting into Elm. I think people and developers maybe at an inflection point with JavaScript and just going and checking out something else that they can immediately apply back to their day to day. I think, it's so incredibly valuable and something that I'm going to be looking to explore very certain. JAMISON: The value pitch is pretty strong because everyone that's written JavaScript has just written code that breaks when things get passed around that they don't expect. I do that all the time and Elm makes that impossible. You can break it in other ways but you just eliminate this class of errors that plagues your existence in JavaScript. If you want to experience that life, check out Elm. It's got a lot of other good things too but just writing code that does not crashes is a pretty strong pitch, I think. ALEX: Jamison, are there any resources that you might recommend for someone who wants to get started with Elm? JAMISON: Somebody mentioned the guide a few times. Everyone says that about every language, check out the official tutorial or whatever, and they have wildly varying quality. The Elm guide is the thing that worked a ton on. It's pretty good, I think and geared towards people that have no knowledge of Elm, no knowledge of functional programming stuff. That's a Guide.Elm-lang.org. Then there's a Slack channel. If you just go to Elm-lang.org, it will have links to the Slack channel and there are lots of helpful friendly people there. I think those are the two best resources because with those, you can find all the other stuff. CHRIS: There's also another one that I really like to mention which is the elm tutorial. I think, it's Elm-tutorial.org. I found it to be a really great compliment to the official Elm Guide. I think it walks through a little more in building a full app where the Elm Guide kind of touches on a bunch of different related topics. But they're not necessarily one narrative. The Elm tutorial did a really good job of tying all that together for me. JAMISON: Yeah and this is been around for a long time and has kept it up through the evolution of the language. This is good stuff. ALEX: Jamison, thank you for coming on the Frontside Podcast. We really appreciated talking to you. JAMISON: Thanks for having me. ALEX: If you love Jamison's voice, you should check out his React Conf talk from 2016 also about Elm. It's a wonderful talk. Go check that out as well. JAMISON: Thank you. Can I pitch my other stuff too? Is that kosher? ALEX: You can absolutely pitch it. CHRIS: Soft skills engineering! JAMISON: Yeah, I do a podcast called Soft Skills Engineering with my friend Dave Smith where we talk about all of the non-technical stuff in writing code. It's like you [inaudible], you can submit questions, and we answer them. If you're interested in talking about building software together, you should talk to the Frontside first. But after that, you can find me at Fivestack.computer. That's where my consultancy lives. Consults is maybe a strong way of describing it. That's like saying the three toddlers standing on top of each other in a trench coat is like an adult. But if you want to work together, then check that out. ALEX: Great. All right. That wraps it up for us. Thank you very much for listening and we'll talk to you next week.

Descripcion del programa Hoy es un programa muy especial, por un lado porque por fin puedo presentar dos iniciativas que se están realizando en la Madrid, la primera es un Meetup,OpenSource Weekends que se realiza mensualmente un sábado al mes de 10:30h a 14:30h y la segunda es la apertura del Call for Papers de una conferencia que estamos organizando y que tendrá lugar en Campus Madrid el 18 de febrero de 2017 llamada FrontFest. Hoy como invitado traigo a una persona que conocí en un Meetup de los múltiples que se realizan en Madrid y que nos ayudará a entender el ecosistema de herramientas que usamos día a día y para que sirven. Hablaremos de task runners, de transpiladores y gestores de dependencias entre otros. ¡Como siempre esperamos que lo disfrutéis! Encuesta para pedir Feedback Posibles topics, entrevistados y duración del programa Eventos en Madrid OpenSource Weekends FrontFest Recomendaciones Preguntas rápidas: Luis de Dios Quién me ha inspirado: Linus Torvalds Recomiéndanos un recurso: Sitepoint Recomiéndanos un recurso: Genbeta Dev Recomiéndanos a un invitado: Ilya Grigorik ¿Qué tema te gustaría que tratásemos?: Otros lenguajes de programación para el Frontend ¿Qué tema te gustaría que tratásemos?: Web Asambly Contacta con: Luis de Dios Twitter Github Links del programa How JavaScript package managers work Yarn a new package manager JS frontend pagckage managers Package managers comparison Yarn benchmarks Charla de automatización en el frontend ECMAScript 2016 compatibility table Bower NPM Yarn JSPM Broccoli Gulp Grunt Babel Webpack Codekit WebAssembly elm Clojurescript Scala Recomendaciones de Nacho Repositorio de ejemplo de Grunt/Gulp Crea tu workflow front-end con Gulp.js Contacta con el programa Web de WeCodeSign Twitter de WeCodeSign eMail de WeCodeSign Web de Ignacio Villanueva Twitter de Ignacio Villanueva

In this episode, LaToya Allen, developer at Big Cartel and founder of SheNomads talks about apprenticeship and mentoring, finding community while working remotely, how companies can be more inclusive for hiring women and people of diverse backgrounds in technology, and avoiding burnout and maintaining balance. LaToya Allen: @HashtagLaToya | latoya@shenomads.com Links: CodeNewbie Ep. 34: Newbie Story: LaToya Allen The SheNomads Podcast Garage Cowork (Polanco) Dear Tech Companies: Focus on Diversity, Not Foosball The SheNomads Job Board Women in Tech Wellness: Chicago Resources: Practical Object-Oriented Design in Ruby by Sandi Metz Exercism.io The CodeNewbie Twitter Chat Transcript: BRANDON: Hello everybody and welcome to Episode 44 of the Frontside Podcast. I'm your host Brandon Hays and I help run the Frontside. STEPHANIE: Hello, I'm Stephanie Riera and I am a developer at the Frontside. BRANDON: Awesome. And we have a special guest today, LaToya Allen. So you're a developer at Big Cartel, is that right? LATOYA: That is correct, yes. BRANDON: Cool. We wanted to talk a little with you today about your day job, your work with SheNomads, your recent blog post about inclusivity and how you balance all that stuff for people. We wanted to start, if we could, by having you introduce yourself for the listeners that don't already know you. LATOYA: Sure, my name is LaToya. I am a software developer at Big Cartel and I'm also the founder of SheNomads. BRANDON: Cool. We actually listen to your podcast and found out some cool stuff about you. One of the things is you used to tend bar. Would you be okay telling us a little bit about your story about how you got into software, what you did before that, and why you're doing this now? LATOYA: Absolutely. I was bartending in Chicago, trying to figure out what I wanted to do with the rest of my life because I knew that it wasn't staying up until 5 in the morning, making Martinis for folks even though it was fun and I do appreciate that time of my life. One day my yoga class got cancelled and I needed something to do. I ended up stumbling upon some coding tutorials and I really fell in love with it. I noticed that hours had gone by, I wasn't bored, I really felt engaged, and it didn't really feel like work to me. It felt like something that would be a cool hobby. I, like many people at that time, felt that you needed a college degree to become a software developer, so I really looked at it as more of a hobby. I started going to different meet-ups in the city and I discovered that wasn't true. And I was lucky enough to find people that are willing to help teach me when I was very early in my career. BRANDON: Cool. And I guess the rest is history now, right? You've had a couple of jobs since then and you went through an apprenticeship program and after the apprenticeship program, you're developing lots of different kinds of software. Are there any software projects you're working on now? I know I met you at Ember Conf but you're doing less of that now. Are there any software projects now that you're fun and exciting, like what languages are you using? LATOYA: At work, we are primarily a Rails app. I've been doing a lot of work in Rails, a little bit of JavaScript. I had the opportunity to learn Ember when I came on to Big Cartel. So, that was pretty cool. As far as side projects, I started an open-source project for SheNomads as a way to help teach folks how to do simple things like create a pull request in GitHub or just the basics of working with Rails. But SheNomads has become an entirely different thing since I started that, so I don't do any coding outside of work right now, unfortunately. [Laughs] STEPHANIE: How long was your apprenticeship? LATOYA: I was an apprentice at 8th Light in Chicago and I was there for one year as an apprentice. STEPHANIE: And is that where you learned Ember? LATOYA: No, when I left 8th Light, I landed a job working in FinTech for 6 months. And then after that, I went to Big Cartel and Big Cartel is actually where I learned Ember. STEPHANIE: What was your apprenticeship experience like? Do you have any advice or anything that you think really helped you along the way? LATOYA: I got to learn from some pretty great people such as Mike Ebert, Colin Jones, just off the top of my head. I learned from a ton of people when I was there. Ginny Hendry was also very helpful. Basically at 8th Light, they really focused on test-driven development and pair programming which test-driven development is a lot of fun and tests are great, that they're very in these days. I got to learn how to test-drive applications and languages such as Ruby, JavaScript, Clojure which is probably my favorite language that I'd never get to work in because it's not popular enough, I guess. I think I did a little bit of REST while I was there as well. And then I was working in frameworks such as Sinatra, Rails, and I worked in ClojureScript as well. STEPHANIE: Nice. I also wanted to ask if during this journey of becoming an engineer, were there any experiences that helped shape the way that you think today? And I'm asking this because I'm curious to find out where the 'She' in SheNomads comes from. And why not just make this a very general digital nomad type thing? Why was there a focus on being a woman? LATOYA: Because I am one. [Laughs] I'm a woman. I think that people tend to think in gender in terms of their own. So for me, it was just fair enough for all to come up with the name SheNomads. STEPHANIE: Gotcha! Obviously, there is a difference, it seems like, in becoming an engineer when it comes to being a woman. I've participated in a lot of events and usually I have women come up to me afterwards and talk to me. And they usually tell me their experiences and how they know that they haven't been participating. They know they haven't been going to hackathons and other events. And I asked them why and 90% of the time, their answer is they're just intimidated. They don't want to be the person raising their hand in a room full of guy developers and hoodies. They don't want to be seen as the amateur or the person that doesn't know. So, I wanted to see how your experience was if it was similar to that or if it was any different and see if there is anything you learned along the way. LATOYA: Look, we all know that tech has problems. I live at two different intersections in the majority of people that are in tech being I am both a woman and I am black. Being a woman – not just a woman, but being a woman of color in tech does come with its challenges. For me personally, I have never been one to shy away from raising my hand in a room or speaking up in a room. But I think that tech in a lot of ways did dole that part of my personality because I wasn't being listened to. I wasn't being considered. For example, there are plenty of times where I've been in a meeting, I've been showing my code and someone else takes credit for my work. And I just don't even bother to say anything because honestly, it's like, "What's the point?" At that point, you just find another job. Or I've been in situations where I say something to someone about the code or about a test or about a change that we should consider and then someone who happens to be male turns around and says basically the exact same thing. And while no one really reacted to what I said, people say, "Oh, that's such a great idea." I have also been in meetings where people don't even look me in the eye for the entire meeting which is very awkward when you're sitting in a room for an hour and you're the only woman in that room. And the person leading the meeting can't even bother to look you in the face. So I think that it's been an interesting journey. [Laughs] And don't get me wrong, there've definitely been a lot of positives with it. But to your question, those are some of the things that I've experienced and it certainly made me aware of how women or people who live at different intersections of the majority of folks in tech get treated and how we need to do better. STEPHANIE: Yeah. I think you and I are kind of outliers. I'm also a woman of color, I would consider, I'm a Latina. Nothing really stopped me from attending meet-ups and hackathons and I've always been very straightforward about what I know and what I don't know. So, that's never really been an issue for me but usually, I'd be probably one of two women out of a room of like 40 people. It's not very comforting. So that's why I'm wondering is there anything for women that aren't like ourselves, do you have any advice for women and for companies that want to be more inclusive, what can they do, how can they be more proactive or get over that fear or intimidation? LATOYA: Absolutely. So, one of the first things that I tell them to do when they are thinking about getting into tech is find communities that will be supportive of you because there weren't a lot of boot camps because Chicago was full of meet-ups. And because there were meet-ups like Chicago Women Developers, I was able to find that community [inaudible] and women were very forthright in sharing their experiences, both good and bad in tech. So, it definitely helped to prepare me a bit. [Laughs] But also when I had bad days, when I had times where I knew I wasn't being treated equally, it was easy to say, "You know what? I'm going to a meet-up after work because I can knock with you people." So, definitely finding a community. STEPHANIE: Sometimes, I feel like those negative experiences where you feel like you're not being respected or you're not being treated equally, at least for myself, that was like adding wood to the fire. That just made me want to succeed more. It made me want to become a developer. It just made me more passionate. I guess for other people, it can have the opposite effect. But I feel like the best revenge is to have them see you succeed. BRANDON: I wanted to ask kind of a follow-on question there about SheNomads. You talk about finding community being really important and you were lucky because you're in Chicago. But now, it seems like you're doing more travelling and there are other people that travel a lot. Is that where you found kind of a hole, the people that travel sort of nomadically? It can be difficult for those people to find a community. Is that where that comes from? Or what was the genesis of SheNomads? LATOYA: SheNomads started because when I landed the job at Bog Cartel, I knew – and I discussed this when I was interviewing with them as well, so it's very transparent. I knew for me working remote from home, that working remote from wherever I wanted home to be within reason as long as there's WiFi and espresso, I promise you I can work from there. [Laughs] So, I started my podcast actually because I had no idea how to work remotely. I had no idea how to pack a suitcase for three months and I didn't know how to find good co-working spaces. I didn't want to feel isolated while I was in the road. So, it kind of evolved. I started a Facebook group for it as well and that was very helpful because for example, I was in Tel Aviv, I was there for two weeks and I didn't know anyone and I really wanted to meet other women who worked in tech. And through the Facebook group, I was able to meet someone who ended up taking me to a co-working space that's sponsored by the government there with free food, free coffee, free WiFi where a lot of other people who happen to be digital nomads who work in tech were as well. For me, it ended up being this thing. It ended up being like an international community but that wasn't the intent when I started it. It's just like a lucky coincidence. BRANDON: And so now, you're putting a retreat together around that. Can you tell us a little bit about that? LATOYA: Yes. After I started the podcast, I started talking to them about their experiences. I knew that I wanted to really dive into it. I wanted to find a digital nomad retreat. But the thing is that the ones that I was coming across were very reflective as the tech industry as they are now. They're very young, people working for like 18-hour days and drinking beer for the rest of the time. And I looked at the attendees and it's like, "Okay, you're all men." [Laughs] And I didn't really want this thing for a week or two in a house full of drunk 22-year old dudes. It's just not for me. BRANDON: You don't want to stay in the front house, huh? LATOYA: Yeah. For me, I like my sleep, I like my yoga, I really like doing things like journaling and standing a long time. And I also enjoy what I do. So for me, I was like, "Okay, I want to be somewhere beautiful where I can have free WiFi, where I can practice yoga, and where I can talk to other people who want to work remotely but maybe want to explore a city." So I was working for Mexico City and I happen to have found the most beautiful house just south of the park. And I was speaking to one of my friends who was a yoga instructor and she said, "Yes, I will come. I will lead morning yoga. I will lead candlelight yoga at night. We could do some [inaudible] actions of people who are into it." And then I had been working in a co-working space in Mexico City and I told them about my idea. They offer to sponsor 30 hours for each attendee and that's Garage Cowork, it's in Polanco which is a gorgeous neighborhood in Mexico City. And then I used to work with a friend who's now the CTO of MealSharing.com. He said, "Hey, first of all I wish I could be at this retreat." But since it's women only, we talked about MealSharing.com sponsoring an authentic Mexican cooked meal for us. So, that's how they got involved. BRANDON: It sounds like things kind of fell together in a way that actually is going to create an experience that, I have to imagine, you're happy with the idea of. LATOYA: Absolutely. I'm very excited because if this already existed, someone else will be getting my money. But since it didn't, I just said let's make this happen and I feel very lucky that it all just kind of come together very organically. STEPHANIE: You recently had an article on Medium. I wanted to ask about that. What made you feel compelled to write this article about how companies approach what they write on their careers page? LATOYA: I had been talking to a friend who started tech a little after I did. And we had both attended the Sandi Metz POODR workshop together which is amazing. If anyone listening to this is a Ruby dove and you want to up your skills, I would highly recommend it. So we attended that workshop together, it was a great experience. I keep talking to women who are significantly underpaid, underappreciated, and are having all of these problems in tech. And so, I was just lying in bed on a Sunday night, working at careers pages and I was thinking about reasons that women leave tech because they keep coming in but it almost seems as if we're losing them too quickly. And I was thinking about these reasons why. I was looking at careers pages and it dawned on me that the careers pages of these companies were not very inviting and that I would not want to work on the companies based on those careers pages. Even though some of them, I knew people that worked at them and I knew that they were all about diversity and inclusion and they were paying women practically, if not the same, as what they're paying men. And I knew that they were positive work environments, so I knew that people were learning from them but the way the companies were presenting themselves was so different. So I thought, "If I was applying for jobs," and I'm not, I'm very happy at Big Cartel and I'm very happy with what I'm doing with SheNomads but if I was, I wouldn't apply at their company and this is why. And I just sat there that Sunday night in my bed, flipping through careers pages and I just noticed a common theme and it was that they weren't very inviting. They seemed to think that alcohol was a bigger selling point to the people they wanted to attract than things like maternity or paternity leave. Their pictures looked like they were trying to throw a party or something. I don't know. It was just – I was very surprised. STEPHANIE: Yeah, it seems to be the popular thing right now like this whole Silicon Valley vibe culture type thing. But it's interesting. I have two friends that are both recruiters for tech companies and mainly trying to find developers here in Austin. And last weekend, we were having the same conversation about how they don't like to admit it, but they have seen over ageism and just general discrimination. How they have seen countless times people that were definitely qualified for the position but because – I think one of their examples was a young lady but she was Indian. And this company that was looking, they were all white guys and they had rejected her because she wasn't "culture fit". But I find that very interesting because I think, as a company, you would actually benefit from having people of all kinds of backgrounds, someone who's 20 years old to someone who's in their 50's or 60's. They must have different sets of knowledge and experiences that could benefit the grander picture. LATOYA: You would think so, you think companies would think that way but unfortunately, a lot of people don't. For starters, if you are a person who isn't interested in working with women or people of color, you're going to look at a careers page in the opposite way that I would. You don't want to work with people over the age of 35, people with brown skin, people who identifies varying genders. Those careers pages are going to attract you. STEPHANIE: Right. LATOYA: Which is unfortunate but that's just the world that we live in right now, and I have had people say this to me as someone who is a woman and someone who is a person of color. But a lot of companies, unfortunately, once they have a base of all straight cisgendered males, for them it becomes a liability to bring in women or people that live at other intersections because they have to worry about things like the woman getting hit on because she's the only woman that these 30 or 40 men can look at all day which is ridiculous, I think. But at this point in time, sometimes they just say it's a culture fit thing when really this is a law-suing happen thing. BRANDON: I saw this rag regressive 1940's thing about a woman in the workplace. [Laughter] BRANDON: And it's both hilarious and really sad because that actually sort of regressive feeling has just kind of morphed into that law suit type of thing. It's the same exact thing of just like breaking that sort of mono-culture and people are fearful of it because they don't know what the consequences are going to be. That cost-benefit calculation doesn't happen because a lot of people in tech haven't experienced what a diverse workplace is and does and the benefits of bringing people from different backgrounds would care about different things. And so, I'm curious. We kind of talked a little bit and one of the things I want to ask you about we already kind of covered is why people don't do that. Why do people continue doing that if it's not that productive? I'm curious to see if there are things that you've seen companies do like what attracted you to Big Cartel and other companies that would be able to bring some people from different backgrounds? What are the things that companies do currently or you'd like to see them do that would make it more attractive and more inclusive? LATOYA: I think one thing right off the bat that I noticed about Big Cartel and one thing that I noticed about many companies in tech that I'm really excited about is that they put people first. And I think that when you operate from that standpoint, you're not going to have problems that come with creating a diverse or inclusive workspace. You're not going to have women wanting to leave because you're treating them like human beings. So, that's first and foremost. I think some companies really care about the people that work for them. They really care about their client base, their user base. So, for me personally, I always recommend that if people aren't happy at their current situations and they want to find something more inclusive, look for companies that put people first. That's the first thing. I think the benefits that they offer and the way that they talk about their benefits are really important. I have no intention of being a mother; there are lots of great mothers out there and it's a lot of work in the world's best [inaudible] in my mind, anyway. I also wouldn't ever interview with a company that didn't have a good maternity leave policy. It's one of the things that I look for upfront. So, even just putting your maternity leave policy and paternity leave, if you have it, on your careers page can be a really big seller. I think starting early on, once you have your core team in place, if you haven't already had women or people of color or someone who isn't like you, this may be a good time to stop and think about why that is and what you can do to pull in diverse candidates. And there's also reaching out to communities that do have them, like SheNomads is one example of many communities that exists. There are also bigger more established communities like Girl Develop It, for example. Reach out with them, host a couple of meet-ups at your space, if you have it. If you don't, figure out a way to work with them. BRANDON: Right. So you're saying if you make it a top-of-mind goal, you will find ways to reach out because there are people out there looking. LATOYA: Yeah. BRANDON: But they may just not be in your immediate vicinity. In my experience, that's the actual problem. The problem is that it's not in my proximity to see and know these people that are involved in these communities. And so, connecting into those communities naturally, organically, and through effort is a way that I've actually seen people grow that. That's how you can kind of go from saying 'I care about diversity' to actually growing a diverse and inclusive workplace. LATOYA: Absolutely. I think another thing that folks that can do is have a remote position. You get a remote culture going if it's something that you're comfortable with. I understand not everyone wants to work from home and not every company will do well having remote positions open. But if it's something you're open to, that is a great way to do it because you might be living in an area where all the people are like you. So, you're going to have trouble getting someone to drive in a car. So, there are two other ways that I was thinking that people can attract diverse candidates. I'm actually launching a Job Board for SheNomads. I got to the point -- it's actually once the article came out on Medium that a lot of people were emailing me wanting to know how they could find jobs and a lot of companies were emailing me wondering how they could find diverse candidates and like what they could do to be more welcoming to other communities. So I said, "You know what I'm going to do? I'm putting together a job board." BRANDON: So where is the job board? LATOYA: The job board you can find on SheNomads.com. BRANDON: Cool. There are a lot of things – and this is really what I wanted to drill into was the blog post helps kind of point at the problem, "Hey, your careers page is sending messages that are actively turning away people that you want working for you. You say you want a diverse workplace but it's so far down the list of your actual priorities, or at least whoever it is that's running your careers page, that you're actively turning people away that you don't even realize you're losing people through that funnel that are bouncing out before you even have a chance to meet them and know them and know what they can bring to you." And so, that's actually a really big deal and a big problem in tech. I also appreciate your jumping in and that we have some sort of concrete things a person can do. Get involved with GDI or with Women Who Code. We had a thing here in Austin and I ran the local Ember meet-up for several years and it's a lot of work and it was really challenging. One thing we noticed was that there were only two or so women, on the average, at a meet-up of 30 people. And I recognized it as a problem but I didn't feel like there was anything I could do about it. And so, I handed the reins of running the meet-up over to a group of people that included the women. And sure enough, the women were like, "You know, we might be able to do something about this." Stephanie actually got involved with this, and they held an event for women and it's changed the makeup of that meet-up significantly. You can have an impact on this stuff. You just, sometimes, have to step out and think differently about the problem. LATOYA: Yes. BRANDON: I'd like to shift gears a little bit and talk about – you're involved in so much stuff. Running SheNomads, running retreats, you have a full-time job, you're traveling a bunch and balancing all of that stuff, I have to imagine, is really tricky. And I'd like to dive into that and have you kind of talk about like do you ever get burned out? Do you feel like giving up? What do you do to manage that? Do you have preventative maintenance that you do? What is it that you do to try to keep all that together? LATOYA: One thing that I find very interesting is you asked me specifically about burn out because burn out is something that I recently experienced. I am not good at knowing that I'm setting myself up for burn out. I'm not even good at knowing that I'm in burn out until I'm there. For the most part, I think that I've gotten better as my tech career has evolved. So for example, when I first started, I was working a lot of hours. There were days when I had to be in the office at 7 in the morning because I was mentoring people who were in London even though I was in Chicago. So for me, there is no more of that. [Laughs] One thing that I really like about working at Big Cartel is that most of the team is on the West Coast, so I get to do things like sleep and if I want, I can go to the gym, I can run all of my errands before I even start my work days. Once I start my work day, all of I have to do is worry about work as opposed to waking up and not having time to do nice things for myself, not having time to run errands and I'm starting my day having all of these stuff on my mind. For me personally, working remotely allowed me to become a more balanced person as well. I don't like riding trains with crowded people. When I was working downtown, it would take me an hour to get to work every morning. If I have to go downtown in the middle of the day, it might take me like 20 minutes or half an hour just because there's not as many people running around. Also for me, I didn't particularly like going to the grocery store. At times, you can go to the grocery store if you have a 9 to 5 job. If I realize that I don't have anything for dinner, I can just tell my pair, "Hey, do you mind if we take a 20 minute break?" And then I can go to the grocery store and get whatever I want, knowing that I'm the only person at the grocery store. I mean, it gets a little bit to my inner introvert but I know myself well enough. Let's see here. Practicing yoga is something that's very important to me and taking walks as breaks is something that's very important to me. I think when you love what you do, it can be hard to take breaks. So, it's always nice to be pair programming with someone and have them say, "We haven't taken a break in a while." I find that when I work on my own, I don't take as many breaks. When I take a break, I pop my yoga mats always open. So, I'll do yoga for 10 minutes or take a nice little walk outside or just get away from my computer for a while. BRANDON: It sounds like working remotely kind of gave you the flexibility you need to implement your own self-care regimen, the one that works for you. LATOYA: Yes. And I would not have even thought to implement this regimen had it have not been for working remote, I think, because it's not as easy. It's bad enough being one woman amongst a hundred men but then you're that cliché woman with a pink yoga mat walking around the office trying to find some space. BRANDON: I actually did use to work in an office that had a yoga studio on site. LATOYA: That is so nice. BRANDON: Things like that do exist but I have to imagine that's about as uncommon as it gets. LATOYA: Absolutely. I had the idea of starting a meet up which I started in Chicago called Women in Tech Wellness. Basically, we get together and we practice yoga for an hour. And then after that, there's a little bit of networking. Luckily for me, Braintree is sponsoring the event which is so great because it allows us to keep it free. I think having free and low cost events in tech are really important because there are people that are trying to figure out how to break into this and if they have to spend $10 or $15 to go to a meet-up, they're not going to go. Also, it's nice to go to a meet-up where you might be stressed when you show up because you just left work but you know in an hour, you're going to be feeling really good. Plus the Braintree office in Chicago has this amazing atrium where we do the yoga. So when you're lying on your mat, you're looking straight up into the sky and you see plants and you see all of these amazing stuff. It's just a great place to do yoga. So, thank you Braintree. [Laughs] BRANDON: I think that's really cool. I have one question, though. Do you ever have the ironic circumstance of the things that you create to help you and other people find balance wind up actually contributing to your overall sense of being overwhelmed? LATOYA: Oh, absolutely. There's only 24 hours in a day and right now, I am all of SheNomads at SheNomads party of one. [Laughs] I would love to get to the point where I can afford to hire a couple of people just to help even if it's part time. So, absolutely. Doing a podcast is a lot of work, booking guests is a lot of work. I would say that organizing the meet-ups is fairly easy just because I'm lucky enough to have people that wanted to step in and help there. But yeah, I think having a few things on your plate other than work is always going to contribute to a little bit of imbalance. BRANDON: Stepping back and looking at the arc, you haven't been in tech for a million years but you've been in it long enough to start drawing some themes through it. If you look at your career like where it's been and approximately where it's going, are you starting to feel like there are some themes to the stuff that you do and some themes that are kind of common threads in it? LATOYA: I can tell you some themes in common threads. Yes, for my personal tech career. For me, I really care about code and I really care about people, so I'm glad that I was able to early on learn clean code and learn how to refactor and learn test-driven developments. First job I had at 8th Light taught me all those things. I think for me, that is a theme that will be throughout my career. Test-driven development, who knows, 10 years from now there could be a better way to write clean code, but for now, it's the best way I know how. And finding community, even though I am absolutely happy with where I'm working. Big Cartel does a great job at creating an inclusive space, but still I like being a part of a tech community. I know that's not for everyone but it's something that I think I will continue to do. BRANDON: From just my casual place of observation of seeing what you do, definitely finding and creating the communities that you want to see exist certainly seems to be a theme. And I think it's really cool that you do the SheNomads stuff. I think it's really cool that you run that podcast. For a person that hasn't been doing this for 15 years, I think it's really awesome that you found a community early on. It's something that certainly has accelerated my journey as a developer. I haven't been a developer forever, either. So I appreciate seeing you do all that stuff. I think it's a really good example for other people that getting involved can benefit everybody and you can have an impact in ways that are sort of uniquely yours. I mean, certainly the stuff that you do is sort of unique to you and your perspective and I think that's really cool because it winds up benefiting a lot of other people. LATOYA: Thank you. I wish I would have said that as my answer. [Laughter] BRANDON: It's sometimes easier to see from the outside in, even as a casual observer. STEPHANIE: I did want to make a comment about balance. That's something that's very important for me. It's something that I've been trying to implement in my daily life. I recently started going to the gym and I try to work out either early in the morning or in the afternoon after work. Sometimes, I realize that even when you try to do something, you still don't accomplish what you're trying to do like keeping that balance. I started this about two months ago. And last week, I realized that I was not in balance at all. I spent Monday, Tuesday, and Wednesday really focused on trying to learn certain things. I was going over Clojure actions and trying to destructure and get rid of components and change the actions from where they originally were. I'm a junior developer, so I feel like if you are an apprentice, it's really hard to not be in this state of overdrive of like you really want to accomplish things. You really want to learn as much as you can and just be a sponge and absorb everything. But if you're spending eight hours, give or take, going over these things, at the end of the day, I just feel sometimes my brain is just like it's done. I can't even formulate sentences. I can't function. I just get home and I want to keep working on this but I just literally can't. I think on Wednesday, I just had a horrible headache and I got home and I was like, "I'm just going to lay down for a little bit." Laying down turned into a 3-hour nap and I will go [inaudible] 8:00 and I felt so much better. And then on Thursday, when I came in, everything just made sense to me. All of the problems and everything that didn't make sense before made sense. And I hadn't reviewed, I hadn't done anything, all I did was I got a nap. But I feel like there's definitely this struggle when you are wanting to achieve and prove yourself and to get to this next level, it's really important to try to remind yourself to give yourself breaks even during the work day because if you can't continue, if you're at this point of mental fatigue, it doesn't matter how much longer you're sitting in front of the computer, trying to read about it in the documentation, it's just not going to do anything. So, I wanted to ask if perhaps you ever had those moments of frustration especially in the beginning as you're trying to learn all of these difficult concepts. LATOYA: For me, yes. I love taking naps. I consider myself a professional. Luckily, Big Cartel is very flexible, so if I feel like I need a nap instead of lunch, I might take a 2-hour lunch break because I'm taking a nap. And for me, there's just something about resetting my brain through sleep that allows me to be more productive in a way that's just walking away from my computer and doing something else. Also, I spent two months this summer working abroad. So, I worked from the UK, Israel, Spain, Portugal, and Norway. So I worked abroad for two months and because of the time difference, I would wake up in the morning and work for three hours and then I would have all day to do whatever I wanted which primarily meant being a tourist in some of the most beautiful places, I've been very lucky to place my eyes upon. And then I would do another three or four hours pair programming at night and I think that I was able to get more done and I had a greater sense of clarity because I had such a big break. I was only working for three or four hours and that's it and you're taking three or four break because no one else is awake yet. It's almost as if you're working two separate days. I think I would like to go back sometime soon, actually, and do that again because I'm not getting up at three in the morning here to work for three hours and then take a break. STEPHANIE: Definitely. And that makes sense. It makes sense to stimulate your brain in a different way. Looking at the beautiful buildings and reading about the history and walking around and being outside. Even just a 30-minute break can just be just so wonderful and be like a refresher for the brain. Nice. Before we go, I wanted to ask if you have any shout outs. LATOYA: I do. I will give you three resources that I tell everyone who's a junior developer, where they should look in to break into tech and what they should look for. Number one, I kind of already mentioned a little bit, but Sandi Metz has a great book called POODR. She also has a POODR workshop. If you can go to that, I highly recommend it. I know that she offers scholarships for that as well, so you can apply. Number two would Katrina Owens' Exercism. It's a great way to learn how to code. It's also an open-source project. So not only can you go to exercism.io and pick a programming language and work with people on teams to learn how to code. But if you want to contribute to the open-source project, you can. And the third thing would be the CodeNewbie twitter chat. I love it. I really need to get my stuff together and be there on Wednesday nights. I believe it's Wednesday at 8 or 9 Central – don't quote me on that. But those are the big three things I like to shout out, even though you only asked for one. [Laughs] STEPHANIE: That's perfectly fine. I was going to ask you anyway if there were any open-source projects or programs that you are involved in. LATOYA: Yes, I have been involved in exercism in the past. I think I might have mentioned this, but I tried doing open-source project with SheNomads but I would need someone who's like at least a mid-level developer to come in and help out all of the juniors and the people that are trying to get started to learn how to code because my time is very thin these days and I'm trying to maintain some level of balance. STEPHANIE: Right. And that's a huge challenge too. So, lots of time management and just time is a resource itself. BRANDON: There are a lot of mid-level developers out there that are looking for, "Hey, how can I contribute to open-source?" So, it sounds like you have a project that if people out there are looking for a way to contribute to something meaningful, then you have stuff that you could certainly use help on. LATOYA: Absolutely. If you want to contribute, you can email me or tweet me, find me on Facebook, do whatever, and I will happily add you as a contributor to the project. BRANDON: That actually is the last question I want to ask. How do people get a hold of you to volunteer for this or ask additional questions or find out more about the retreat? LATOYA: The three best ways are number one, you can go to SheNomads.com and if you wanted to find out about the retreat or the job board, there are contact forms there. Number two, I am always on Twitter. You can tweet me at either accounts. My personal account is @HashtagLaToya and then I have a SheNomads account, so it's @SheNomads for that. And then the third way is email. My email is LaToya@SheNomads.com and I always am up for answering any questions you may have. BRANDON: Awesome. LaToya, thank you so much for coming. I really appreciate you sharing your experiences with us and you've certainly learned some unique things. I think your take on self-care actually is really sharp and something that people don't think were talked about enough. And it probably [inaudible] as a developer in lot of ways and I think people can learn a lot from that. I wanted to thank everybody else that's listening to this. I'm Brandon Hays. I'm on Twitter also @tehviking. We are @thefrontside on Twitter. And Stephanie, you are also on Twitter, is that right? STEPHANIE: Of course. I'm Stephanie Riera and I'm @stefriera. And thank you so much, LaToya. It was a pleasure talking to you. BRANDON: Absolutely. Thanks everybody and thank you, LaToya. We will see you all next time.

Leveraging transpilers is extremely helpful in allowing us to extend the JavaScript language in ways JavaScript engines cannot. There are a lot of amazing transpilers available in the JavaScript community and we all love transpilers, but there are things developers should be aware of when we’re using transpilers. Items mentioned in the episode: Babel, CoffeeScript, TypeScript, Traceur, Sass, Less, Stylus, Chrome V8, Firefox SpiderMonkey, IE Chakra, TC39 Committee, React CLI, ClojureScript, Ohm, CodePen, Racket, Erlang Panelists: Ryan Burgess - @burgessdryan Augustus Yuan - @augburto Jem Young - @JemYoung Derrick Showers - @derrickshowers Ryan Anklam - @bittersweetryan Brian Holt - @holtbt Sarah Federman - @sarah_federman Picks: Ryan Burgess - Stranger Things Ryan Burgess - Jem Young - Transpilers: not so fast my friend - Empire JS Augustus Yuan - Github Go to Definition Chrome Extension Augustus Yuan - StackOverflow’s Documentation Beta Jem Young - Explosions in the Sky - The Wilderness Jem Young - Digital Ocean Derrick Showers - Babel Try It Out Derrick Showers - Google Inbox Ryan Anklam - Google Keep Ryan Anklam - Wafia - Heartburn Felix Cartel Remix Brian Holt - HyperTerm Brian Holt - Visual Studio Code Sarah Federman - Elle - Women in Tech 2016 Sarah Federman - Less: The World’s Most Misunderstood CSS Pre-processor*

What happens when your database is part of your application? Kenneth & Len are joined once again by Robert Stuttaford from Cognician to talk about Datomic. According to the Datomic website, Datomic is a distributed database designed to enable scalable, flexible and intelligent applications, running on next-generation cloud architectures. Robert shares with us how Datomic became a natural choice for them after switch to Clojure. Before Clojure, ClojureScript and Datomic their site was written in PHP and backed by MySQL. Choosing Datomic was very natural since they've already subscribed to Rich Hickey's "simple vs easy" mindset. Its immutable nature is a great fit for Clojure, and by following an "append-only" storage model they got loads of benefits. We discuss a wide variety of concepts, including how Datomic models data, the different ways it can be stored, how transactions work, the ability to travel back in time to see what your data looked like, and so much more. We were happy to learn that Datomic is accessible to everyone on the JVM, so learning Clojure isn't an initial requirement, but learning some Clojure will go a long way in informing your usage of Datomic. We would encourage everyone to experiment with Datomic and enjoy this different, flexible approach to modeling data. Follow Robert online: - https://twitter.com/RobStuttaford - http://www.stuttaford.me/ - http://www.cognician.com/ Here are some resources mentioned during the show: * Datomic - http://www.datomic.com/ * Datalog - https://en.wikipedia.org/wiki/Datalog * Logic programming - https://en.wikipedia.org/wiki/Logic_programming * Simple Made Easy by Rich Hickey - http://www.infoq.com/presentations/Simple-Made-Easy * Exploring four Datomic superpowers - http://www.slideshare.net/lucascavalcantisantos/exploring-four-datomic-superpowers * Learn Datalog Today - http://www.learndatalogtoday.org/ * Datomic Training Material - http://www.datomic.com/training.html * Clojure Cookbook - https://github.com/clojure-cookbook/clojure-cookbook * The Joy of Clojure, Second Edition - https://www.manning.com/books/the-joy-of-clojure-second-edition * Clojure Remote Keynote: Designing with Data - https://www.youtube.com/watch?v=kP8wImz-x4w Also listen to https://zadevchat.io/27/ for our previous discussion with Robert on Clojure. And finally our picks Robert: * "Learning Mindset" (Mindset by Carol Dweck) - http://mindsetonline.com/ * Lego - http://www.lego.com/ Thanks for listening! Stay in touch: * Homepage - https://zadevchat.io/ * Socialize - https://twitter.com/zadevchat & http://facebook.com/ZADevChat/ * Suggestions and feedback - https://github.com/zadevchat/ping * Subscribe and rate in iTunes - http://bit.ly/zadevchat-itunes

Joel Burget Joel Burget (@dino_joel) The Recurse Center The algebra (and calculus!) of algebraic data types Pigment hopper-lang/hopper: a sound modern language for computation and transactional resource logic PureScript Elm Flow gaearon/react-hot-loader: Tweak React components in real time. bhauman/lein-figwheel: Leiningen plugin that pushes ClojureScript code changes to the client Nuclide buckie/juno: Smart Contracts Running on a BFT Hardened Raft Sentry: Track exceptions with modern error logging for JavaScript, Python, Ruby, Java, and Node.js TypeScript - JavaScript that scales.

Denne gangen ser vi til språk som oversettes til JavaScript og vi har besøk av Inge Solvoll som snakker om ClojureScript og Geir Sagberg som snakker om TypeScript. Shownotes: http://bartjs.io/episode-2-no-country-for-old-javascript/

Join us as we explore Clojure, the robust, practical and fast programming language. Kenneth, Kevin & Len talk to Robert Stuttaford (@RobStuttaford), co-founder and CTO of Cognician, about the Clojure programming language and his experience using it for the last few years. We discuss the language itself as well as some tools. We sing the praises of Rich Hickey, even if it just for his great talks, and stroll around the ecosystem including the obligatory stop at Datomic. Robert really did a great job of guiding us through the landscape and we're very excited about Clojure after this call. We'll definitely have Robert back in the future to cover Datomic and other parts of Clojure we didn't cover. Quick aside, the conversation was very organic and we skipped the formal introductions, and we had a few small technical snags with the recording, but the content is still great and we hope you enjoy listening as much as we did recording. Follow Robert and Cognician on the web: - https://twitter.com/RobStuttaford - http://www.stuttaford.me - http://www.cognician.com Here are some resources mentioned in the show: * emacs - https://www.gnu.org/software/emacs/ * Spacemacs - https://github.com/syl20bnr/spacemacs * Clojure Programming (O'Reilly) - http://www.clojurebook.com * Robert's emacs.d - https://github.com/robert-stuttaford/.emacs.d * Simple Made Easy by Rich Hickey - http://www.infoq.com/presentations/Simple-Made-Easy * Rich Hickey's Greatest Hits - https://changelog.com/rich-hickeys-greatest-hits/ * Lisp - https://en.wikipedia.org/wiki/Lisp_(programming_language) * DotLisp - http://dotlisp.sourceforge.net/dotlisp.htm * Clojurescript - https://github.com/clojure/clojurescript * edn (extensible data notation) - https://github.com/edn-format/edn * schema - https://github.com/plumatic/schema * Isomorphic JavaScript - http://isomorphic.net * Homoiconicity - https://en.wikipedia.org/wiki/Homoiconicity * algo.monads - https://github.com/clojure/algo.monads * Logic programming with core.logic - https://github.com/clojure/core.logic * Excel-REPL - https://github.com/whamtet/Excel-REPL * Arcadia, Clojure integration with Unity 3D - https://github.com/arcadia-unity/Arcadia * ClojureScript + React Native - http://cljsrn.org * Planck ClojureScript REPL - http://planck-repl.org * Clojure for the Brave and True - http://www.braveclojure.com * clojurians on Slack - http://clojurians.net * #clojure on Freenode * Clojure Google Group - http://groups.google.com/group/clojure * ClojureBridge - http://www.clojurebridge.org * Clojure Cup - http://www.clojurecup.com * Nikita Prokopov - https://github.com/tonsky * Datomic - http://www.datomic.com And finally our picks: Kenneth: * Simple Made Easy by Rich Hickey - http://www.infoq.com/presentations/Simple-Made-Easy Len: * Structure and Interpretation of Computer Programs - http://www.sicpdistilled.com/ * SICP Lecture Videos - http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/video-lectures/ Robert: * emacs - https://www.gnu.org/software/emacs/ * Mindfulness meditation - https://en.wikipedia.org/wiki/Mindfulness * Tim Ewald - Clojure: Programming with Hand Tools - https://www.youtube.com/watch?v=ShEez0JkOFw Kevin: * Spacemacs - https://github.com/syl20bnr/spacemacs * Coggle - https://coggle.it Stay in touch: * Socialize - https://twitter.com/zadevchat & http://facebook.com/ZADevChat/ * Suggestions and feedback - https://github.com/zadevchat/ping * Subscribe and rate in iTunes - https://itunes.apple.com/za/podcast/zadevchat-podcast/id1057372777 PS: We'll be at RubyFuza in Cape Town on Feb 4th & 5th, and at Devconf in Fourways on March 8th. Please come say hi!

In this episode I talk with David Nolen. We talk his background in Functional Programming, entry into Lisps and Clojure, ClojureScript, Om and Om Next, and the ideas Om next is taking from React, GraphQL, and Falcor.

We talk about Len's Funemployment, React, React Native, Clojure, ClojureScript, giving better conference talks, and Angular 2. Cross-Platform Native Development with Javascript React Native with Nick Lockwood Clojure/conj 2015 Mobile Apps with ClojureScript - Jearvon Dharrie - YouTube Quick Start (om.next) Om Next - David Nolen - YouTube Angular 2 Generator

Carin Meier joined the show to talk about Clojure, ClojureScript, her book Living Clojure, all the fun things she loves about math, physics, and creating a programming language.

Carin Meier joined the show to talk about Clojure, ClojureScript, her book Living Clojure, all the fun things she loves about math, physics, and creating a programming language.