Podcasts about rustconf

Show Notes I'm Gage Hopper, and this is my weekly(-ish) show on FOSS news and software tinkering. Rust Being Destroyed By Foundation Idiocy https://www.youtube.com/watch?v=QEnuzwCWpgQ Rust's apology to JeanHeid Meneide: https://blog.rust-lang.org/2023/05/29/RustConf.html Opera One: For the adventurous https://betanews.com/2023/06/20/opera-one-ai-powered-browsing-tab-islands-linux-windows-macos/ Requires an Opera Account Amazon Retaliates Against Luis https://youtu.be/Kcohq313q00 Luis Rossmann has been doing independent repairs for over a decade Mesa 23.2 Release Speeds Up Intel Arc Cards By 11%: https://www.tomshardware.com/news/intel-arc-driver-linux-boost Wtf, RedHat? https://hackaday.com/2023/06/23/et-tu-red-hat/ Kotlin Korner Interesting things I find worth sharing about my experiences with Kotlin My handle is @hopper_mcs over on Twitter. Ciao!

Guillaume, Arnaud et Emmanuel discutent des nouvelles de mai et juin. La communauté Rust, WebAssembly. Guava, Debezium, Kafka, de flame graph, d'open source et bien sûr les large language models. On répond aussi à la question fondamentale: mais pourquoi Maven n'a pas de fichier .lock ? Enregistré le 9 juin 2023 Téléchargement de l'épisode LesCastCodeurs-Episode-297.mp3 News Langages Lors de Microsoft BUILD 2023, un des fondateurs de OpenAI a fait une excellente présentation de Large Language Models, des GPT https://build.microsoft.com/en-US/sessions/db3f4859-cd30-4445-a0cd-553c3304f8e2 Il parle du fonctionnement des LLM, comment/pourquoi ils arrivent à générer ce qu'ils génèrent Le fine-tuning, l'apprentissage renforcé avec feedback humain, l'art du prompting Des patterns comme Chain of Thought (CoT) ou ReAct (Reflect then Act) Leaning Technologies annonce l'arrivée prochaine de CheerpJ 3 : le retour de Java dans la navigateur, grâce à WebAssembly https://leaningtech.com/announcing-cheerpj-3-0-a-jvm-replacement-in-html5-and-webassembly-to-run-java-applications-and-applets-on-modern-browsers/ Avant la version 3.0, CheerpJ utilisait une approche AOT (ahead of time compilation) qui nécessitait aussi une étape d'intégration continue pour transformer aussi toutes les dépendances JAR associées à un projet Avec la version 3.0, qui devrait sortir cet été, CheerpJ adopte une approche JIT (Just In Time compilation) qui ressemble plus à l'approche de Java lui même Plus besoin non plus de version custom d'OpenJDK Les Applets vous avaient manqué ? Elles sont de retour avec WebAssembly :smile: Communauté RUST: Il y a de l'eau dans le gaz https://www.jntrnr.com/why-i-left-rust/ Plus d'infos https://gist.github.com/fasterthanlime/42da9378768aebef662dd26dddf04849 lié au backchannel et un petit groupe qui essaie de faire les choses bien mais qui derappe de l'exterieur en gros ils ont un process interne pour prendre des decisions avec ce process ils ont invité une personne pas super pro Rust a faire la keynote a RustConf d'autres du commité ont vu ca et on discuté en backchannel pour revenir en arriere de la decision (sans suivre le process) il y a eu une semaine de pause avant action mais pas annoncé le speaker a ete dé keynoté et a donc refusé de venir a la conf et paf, ca enerve des gens decisionaire et ils demissionnent Bref des gens qui veulent faire le bien mais en cercle un peu trop ferné et paf Les gens de Wasmer étendent WASI avec WASIX, on rajoutant le support POSIX, les threads… permettant de compiler vers WASM plein de projet C/C++ ou Rust, comme cURL ou autre https://wasmer.io/posts/announcing-wasix ca frotte un oeu entre innovation et standardisation dans la communaite WASM WASMER sont un peu les cowboys startuper par exemple ils ont essayé de deposer la marque WebAssemble au nez et à la barbe de la communauté donc la reaction du coeur de la communauté a cette annonce est plutôt calme WASI c'est standard mais ca prend du temps a maturer WASIX c'est cool et dispo maintenant mais c'est un produit d'une société spécifique, donc pas de portabilité Librairies Guava 32 est sorti et beaucoup de choses annotées en @Beta ne le sont plus https://www.reddit.com/r/java/comments/13w2l8w/guava_320_released_today_and_the_beta_annotation/ ont eu des API en @Beta pendant longtemps pour proteger des risques de changements en pratique quasi personne ne se limitait au non beta, et elles n'ont pas bougé ces API ou peu donc ils ont enlevé @Beta de la plupart beaucoup de parties de Guava sont dans le JDK, le cache est dans Caffeine des bons echanges dans les commentaires entre les utilisateurs et Kevin un des mainteneurs chez Google Comment démarrer avec l'API PaLM de Google, mais en Java! https://glaforge.dev/posts/2023/05/30/getting-started-with-the-palm-api-in-the-java-ecosystem/ Guillaume a écrit une petite application qui génère des histoires pour enfants avec un Large Language Model (l'API PaLM) https://bed-time-stories.web.app/ Le code est dispo sur Github https://github.com/glaforge/bedtimestories Il explique également le processus incrémentale des prompts qui aident à générer aussi le contenu de l'application https://glaforge.dev/posts/2023/06/08/creating-kids-stories-with-generative-ai/ Infrastructure Debezium 2.2 https://debezium.io/blog/2023/04/20/debezium-2-2-final-released/ Experimental, opt-in Parallel Snapshots Incremental snapshots with surrogate keys Quarkus 3 support Ingestion of Oracle changes from logical standby instances Google Spanner improvementsNew Debezium Server sinks for Infinispan, RabbitMQ, and RocketMQ New Storage APIs for Amazon S3 and RocketMQ Many MongoDB improvements Cassandra connector for Cassandra Enterprise Un article sur l'utilisation de Kafka par CloudFlare https://www.infoq.com/articles/kafka-clusters-cloudflare/?utm_campaign=infoq_content&utm_source=twitter&utm_medium=feed&utm_term=architecture-design c'est du “classique” mais bon de se le faire rappeler beaucoup d'evenements CloudFlare passent pas Kafka pour processing Kafka en tant que bus generique Ils ont imposé un message unique par topic via protobuf ils sont une Application Service team (internal developer platform) depuis peu de temps gitops pour creation de topic etc développé un connector framework declaratif pour étendre le pannel de patrons d'architecture disponibles developé des SDKs d'access a KAfka avec monitoring (prometheus) sympa a lire Post mortem du problème chez datadogHQ https://www.datadoghq.com/blog/2023-03-08-multiregion-infrastructure-connectivity-issue/ data dog a perdu tous ces services dans la plupart ou toutes ses regions pendant 3 heures avant la premiere recuperation et 10 heures au total pour la recuperation totale Equipe : 10 senior engineering leaders, about 70 local incident commanders and a pool of 450 to 750 incident responders active throughout the incident, which required four shifts to bring the incident to full resolution. cause: une mise a jour de systemd appliqué sur la plupart de leurs VM en quasi parallele qui a effacer les routes des container et ne les a aps remis ; c'est un cas qui n'arrive pas au reboot d'un noeud (init sequence) des 10000s noeuds impactés en general ils font du rollout par region en enlevant les noeuds etc mais le base os avait un legacy update channel activé (vs gere pas les equipes de datadog manuellement) les noeuds de controlleurs qui sont cense recycler les noeuds n'ont pu le faire vu le volume de noeud et surtout parce qu'eux meme étaient effectés l'autre article Cloud Le data center parisien europe-west9-a est en panne depuis 3 semaines https://www.lebigdata.fr/data-center-panne un feu s'est déclenché qui a touché une zone le DC reste opérationnel sur les zones non touchée sauf BigTable qui a besoin de la zone touchée les autres services fonctionnent sauf les applis utilisateurs qui ne tournaiuent que sur la zone affecté Outillage Podman Desktop 1.0 est sorti https://podman-desktop.io/blog/podman-desktop-release-1.0 pas grand chose a dire que c'est la 1.0 “Works on my machine” Contract testing with Pact https://hollycummins.com/contract-testing-devoxx-greece/ Conference quand on change un microservice l'autre casse les tests d'integration sont lent, instable et demande des grosses machines ou des environnements remote de dev mock / unit tests ne sont pas vraiment le code de l'autre équipe D'où Contract test qui vit entre les end to end et les unit tests. Peut partir d'un test mock et rempalcer avec pact cote consommateur en faisait tourner, un pack listener enregistre la declaration (le DSL) et le retours attendus / generés par l'appel du test copier ce fichier vers le producteur copier a la main, dans le repo, via a broker ajoute un test pact cote producteur qui va exercer le JSON et verifier que cela marche tests de pack sont plus profonds qu'un test OPENAPI consommateur utilise pact comme mock et verifie le provider wrt le contract du mock Pourquoi Maven n'a pas de fichier lock ? https://www.reddit.com/r/Maven/comments/vkcmys/why_maven_doesnt_have_a_lock_file_like/?utm_source=share&utm_medium=ios_app&utm_name=ioscss&utm_content=1&utm_term=9 conversation interessance sur les fichiers .lock dans les builds Par exemple ruby a le Gemfile.lock, npm pareil mais pas Java? Fondamentalement c'est du aux valeurs par defaut initiales et à la culture de la communauté les version range sont peu ou pas utilisés en Maven alors que le default dans d'autres plateformes la poule et l'oeuf Simplifier les flame graph avec jbang https://someth2say.wordpress.com/2023/06/04/jbang-and-flame-graphs/ discute les flame graph pour le temps comsommé et pas un call graph hauteur c'est la profondeur d'appel ne regarder que la largeur, pas l'ordre pas quand et ou une action est faite mais qui l'a fait reste discute comment utiliser jbang pour lancer le prgramme et le javaagent Les modérateurs de Stack Overflow en greve contre le flux de réponses d'intelligence artificeille https://openletter.mousetail.nl/ le ban des contenus generes par l'IA a ete levé discrètement par stack overflow peur du flux de données massif et des hallucinations difficiles à détecter sans passer du temps pas de consensus communautaire stackoverflow est une des sources trustées pour les LLM des intelligences arificielles generatives (serpent qui se mord la queue) les modérateurs font tourner l'anti spam, gere les flag levés, ferment ou effacent les entrées, genre les bots qui detectent le plagiat etc. 414 votants des les premiers heures Just, un petit outil en ligne de commande avec une syntaxe inspirée de make, pour exécuter des commandes fréquentes dans nos projets https://glaforge.dev/posts/2023/06/07/just-a-handy-command-line-tool/ Syntaxe proche de celle de make Possibilité de définir des dépendances entre tâches Support de paramètres Peut charger des fichier .env S'installe sur tous les systèmes d'exploitation qu'on aime bien et qu'on n'aime pas aussi Méthodologies AWS retire ses documentations en Open Source https://www.infoq.com/news/2023/06/aws-documentation-github/ ils ont open sourcé en espérant des contributions il y a deux ans mais sans changer les approche en interne resultat copie de repo de l'interieur vers l'exterieur tracker de travail interne != externe c'était plus compliqué leçon, embrace entièrement sinon les frictions sont compliquées Un guide pour communiquer avec l'IA: https://learnprompting.org/ Gratuit et open source Prompt Engineering ou comment rédiger vos prompts Plusieurs niveau (Basic, Intermediaire, Avancé..) Défini plein de concepts: Prompt, Few Shot Prompt, LLMs… Loi, société et organisation Migration de Twitter vers Mastodon (ou plutôt “dual run”) https://glaforge.dev/talks/2023/06/09/from-bird-to-elephant-starting-a-new-journey-on-mastodon/ Présentation de Guillaume à Devoxx France et Grèce Avec code sur Github pour un bot Mastodon: https://github.com/glaforge/stootistics Et un service en ligne pour voir la popularité de ses derniers posts sur Mastodon https://stootistics.web.app/ Conférences Aurelie Vache publie sont agenda des conferences via le site: https://developers.events/ La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 14-15 juin 2023 : OW2 openSource Conf - Paris (France) 14-17 juin 2023 : VivaTech (Viva Technology) - https://vivatechnology.com/) - Paris (France) 15-16 juin 2023 : Le Camping des Speakers - Baden (France) 15-17 juin 2023 : Pas Sage En Seine - Choisy-le-Roi (France) 20 juin 2023 : Mobilis in Mobile - Nantes (France) 20 juin 2023 : Cloud Est - Villeurbanne (France) 20-22 juin 2023 : Adeo DevSummit - Lille (France) 21-23 juin 2023 : Rencontres R - Avignon (France) 23 juin 2023 : Unconf HackYourJob - Région lyonnaise (France) 28-30 juin 2023 : Breizh Camp - Rennes (France) 29 juin 2023 : Google Cloud Summit France - Paris (France) 29-30 juin 2023 : Sunny Tech - Montpellier (France) 29-30 juin 2023 : Agi'Lille - Lille (France) 7-9 juillet 2023 : Nantes Maker Campus - Nantes (France) 2-3 septembre 2023 : SRE France SummerCamp - Chambéry (France) 6 septembre 2023 : Cloud Alpes - Lyon (France) 8 septembre 2023 : JUG Summer Camp - La Rochelle (France) 14 septembre 2023 : Cloud Sud - Remote / Toulouse (France) 18 septembre 2023 : Agile Tour Montpellier - Montpellier (France) 19-20 septembre 2023 : Agile en Seine - Paris (France) 19 septembre 2023 : Salon de la Data Nantes - Nantes (France) & Online 21-22 septembre 2023 : API Platform Conference - Lille (France) & Online 25-26 septembre 2023 : BIG DATA & AI PARIS 2023 - Paris (France) 28-30 septembre 2023 : Paris Web - Paris (France) 2-6 octobre 2023 : Devoxx Belgium - Antwerp (Belgium) 6 octobre 2023 : DevFest Perros-Guirec - Perros-Guirec (France) 10 octobre 2023 : ParisTestConf - Paris (France) 11-13 octobre 2023 : Devoxx Morocco - Agadir (Morocco) 12 octobre 2023 : Cloud Nord - Lille (France) 12-13 octobre 2023 : Volcamp 2023 - Clermont-Ferrand (France) 12-13 octobre 2023 : Forum PHP 2023 - Marne-la-Vallée (France) 19-20 octobre 2023 : DevFest Nantes - Nantes (France) 19-20 octobre 2023 : Agile Tour Rennes - Rennes (France) 26 octobre 2023 : Codeurs en Seine - Rouen (France) 25-27 octobre 2023 : ScalaIO - Paris (France) 26-27 octobre 2023 : Agile Tour Bordeaux - Bordeaux (France) 10 novembre 2023 : BDX I/O - Bordeaux (France) 15 novembre 2023 : DevFest Strasbourg - Strasbourg (France) 16 novembre 2023 : DevFest Toulouse - Toulouse (France) 6-7 décembre 2023 : Open Source Experience - Paris (France) 7-8 décembre 2023 : TechRocks Summit - Paris (France) 31 janvier 2024-3 février 2024 : SnowCamp - Grenoble (France) 19-22 mars 2024 : KubeCon + CloudNativeCon Europe 2024 - Paris (France) 28-29 mars 2024 : SymfonyLive Paris 2024 - Paris (France) 17-19 avril 2024 : Devoxx France - Paris (France) 25-26 avril 2024 : MiXiT - Lyon (France) 25-26 avril 2024 : Android Makers - Paris (France) Nous contacter Pour réagir à cet épisode, venez discuter sur le groupe Google https://groups.google.com/group/lescastcodeurs Contactez-nous via twitter https://twitter.com/lescastcodeurs Faire un crowdcast ou une crowdquestion Soutenez Les Cast Codeurs sur Patreon https://www.patreon.com/LesCastCodeurs Tous les épisodes et toutes les infos sur https://lescastcodeurs.com/

In this episode, Conor and Bryce chat about the Rust Conf drama and other upcoming conferences.Link to Episode 132 on WebsiteDiscuss this episode, leave a comment, or ask a question (on GitHub)TwitterADSP: The PodcastConor HoekstraBryce Adelstein LelbachShow NotesDate Recorded: 2023-05-31Date Released: 2023-06-02Programming Languages Festival (Feb 2024) KickStarterRustConfRustConf Drama (ThePhd's Post)ThePhd on TwitterJT's PostCppNorthRust FoundationRust Trademark DebacleCrabLangGCC Front-End For RustCrystal LanguageLambdaDays 2023Italian C++ 2023HaskellElixirBryce's Haskell TweetArrayCast Episode on KX ConC++NowIntro Song InfoMiss You by Sarah Jansen https://soundcloud.com/sarahjansenmusicCreative Commons — Attribution 3.0 Unported — CC BY 3.0Free Download / Stream: http://bit.ly/l-miss-youMusic promoted by Audio Library https://youtu.be/iYYxnasvfx8

Доклады: Project Update: Lang Team by Niko Matsakis ( https://youtu.be/z9NvvyQlmhA ) Project Update: Libs Team by Mara Bos ( https://youtu.be/mXdIjMEtcWU ) Identifying Pokémon Cards by Hugo Peixoto ( https://youtu.be/K15Src3MxHA ) Move Constructors: Is it Possible? by Miguel Young de la Sota ( https://youtu.be/Lvma7VTkdx8 ) Whoops! I Rewrote It in Rust by Brian Martin ( https://youtu.be/nKszVOlNkk4 ) Hacking rustc: Contributing to the Compiler by Esteban Kuber ( https://youtu.be/vCODCbUSA_w ) Writing the Fastest GBDT Library in Rust by Isabella Tromba ( https://youtu.be/OXjz6_xIauo ) The Importance of Not Over-Optimizing in Rust by Lily Mara ( https://youtu.be/NFgXuANSPkY ) This Week in Rust: 400 Issues and Counting! by Nell Shamrell-Harrington ( https://youtu.be/F_ZA1tYnofk ) Нас можно найти: 1. Telegram: https://t.me/proConf 2. Youtube: https://www.youtube.com/c/proconf 3. SoundCloud: https://soundcloud.com/proconf 4. Itunes: https://podcasts.apple.com/by/podcast/podcast-proconf/id1455023466

Neste episódio falamos sobre a experiência do Peixoto em fazer uma apresentação na RustConf 2021.Links:RustConf 2021CfP da RustConfIdentifying Pokémon cards, by Hugo PeixotoCódigo demonstrado na apresentaçãoSlides da apresentaçãoEvent Driven, by Leah SilberSegue-nos no Twitter

Your hosts set right what once went wrong in this week's quantum episode of The Cloud Pod. A big thanks to this week's sponsors: Foghorn Consulting, which provides full-stack cloud solutions with a focus on strategy, planning and execution for enterprises seeking to take advantage of the transformative capabilities of AWS, Google Cloud and Azure. Commvault is data-management done differently. It allows you to translate your virtual workloads to a cloud provider automatically, greatly simplifying the move to the cloud or your disaster recovery solution to the cloud. live@Manning: Sign up for RustConf and Manning’s Women in Tech conferences here. This week's highlights Amazon and Rackspace may be growing closer soon. Your hosts may or may not know how quantum computing works. Google is now available for 35 more minutes out of the month. General: High Stakes Reuters reported that Amazon is looking to acquire a stake in cloud infrastructure and services company Rackspace Technology. It is unclear exactly how much of the company Amazon may buy. AWS: A Discrete Quantity of Computers You can now run Amazon Braket on real or simulated

It's a new week, and that means you can be sure that Google Next is still going on… and of course, we've got a new episode of The Cloud Pod. A big thanks to this week's sponsors: Foghorn Consulting, which provides full-stack cloud solutions with a focus on strategy, planning and execution for enterprises seeking to take advantage of the transformative capabilities of AWS, Google Cloud and Azure. Commvault is data-management done differently. It allows you to translate your virtual workloads to a cloud provider automatically, greatly simplifying the move to the cloud or your disaster recovery solution to the cloud. live@Manning: Sign up for RustConf and Manning’s Women in Tech conferences here. This week's highlights Foghorn has two new solutions we'd love for them to advertise with us. Azure advances the open-source front. Oracle wins the 4th place medal in the VMware race. What would a 4th place medal be — aluminum?!  JEDI: Wait and See The Department of Defense has been granted an additional month to issue its remand decision. Neither Amazon nor Microsoft have objected to the

In this episode, we talk about Atlassian’s remote work policy, Fortnite’s battle with Google and Apple, and Twitter’s new API. We then speak with Ashley Williams and Steve Klabnik, engineers on the Rust core team, about how recent restructuring and layoffs at Mozilla impact the future of the Rust programming language. Show Notes DevDiscuss (sponsor) Triplebyte (sponsor) CodeNewbie (sponsor) Vonage (sponsor) Atlassian Fortnite Fortnite Introducing a new and improved Twitter API Rust Laying the foundation for Rust's future RustConf

Nell Shamrell-Harrington — lead editor of This Week in Rust — takes you through highlights from TWiR 352, published on August 18, 2020, as well as short interviews with upcoming RustConf speakers Harrison Bachrach, Esteban Kuber, and Jam. Contributing to Rustacean Station Rustacean Station is a community project; get in touch with us if you’d like to suggest an idea for an episode or offer your services as a host or audio editor! Twitter: @rustaceanfm Discord: Rustacean Station Github: @rustacean-station Email: hello@rustacean-station.org Referenced resources Laying the foundation for Rust’s future Learning Rust: The Compiler is your Friend Why Rust is a great fit for embedded software Why Rust’s Unsafe Works I am a Java, C#, C or C++ developer, time to do some Rust Async Unicorns love Rust Linux Packages For Rust (2/3) - Building with GitHub Actions using Custom Actions and Docker Container Images Rust RFCs Repo RustConf This Week in Rust GitHub Repo Credits Hosting Infrastructure: Jon Gjengset Show Notes: Nell Shamrell-Harrington Hosts: Nell Shamrell-Harrington

Nell Shamrell-Harrington — lead editor of This Week in Rust — takes you through highlights from TWiR 351, published on August 11, 2020, as well as short interviews with upcoming RustConf speakers Micah Tigley, Rebecca Turner, and Samuel Lim. Contributing to Rustacean Station Rustacean Station is a community project; get in touch with us if you’d like to suggest an idea for an episode or offer your services as a host or audio editor! Twitter: @rustaceanfm Discord: Rustacean Station Github: @rustacean-station Email: hello@rustacean-station.org Referenced resources Announcing Rust 1.45.1 Announcing Rust 1.45.2 Headcrab: July 2020 progress report This Month in Rust OSDev (July 2020) Learning Rust: Mindsets and Expectations Blue Team Rust: What is “Memory Safety”, really? Creating Linux Packages for Rust Projects (1/2) Reverse Engineering a USB Device with Rust Some Learnings from Implementing a Normalizing Rust Representer [video]Learning Rust by Working Through the Rustlings Exercises Rust Language Cheat Sheet 2019 -> 2020 [audio]The State of Rust 2 with Alex Chrichton [audio]The State of Rust with Steve Klabnik RFC: ‘C unwind’ ABI Procedural vtables and wide ptr metadata Edition 2021 and beyond Credits Hosting Infrastructure: Jon Gjengset Show Notes: Nell Shamrell-Harrington Hosts: Nell Shamrell-Harrington

Nell Shamrell-Harrington — lead editor of This Week in Rust — takes you through highlights from TWiR 350, published on July 28, 2020, as well as short interviews with upcoming RustConf speakers Siân Griffin, Jane Lusby, and Ashley Hauck. Contributing to Rustacean Station Rustacean Station is a community project; get in touch with us if you’d like to suggest an idea for an episode or offer your services as a host or audio editor! Twitter: @rustaceanfm Discord: Rustacean Station Github: @rustacean-station Email: hello@rustacean-station.org Referenced resources Announcing Rust 1.45.1 Announcing Rust 1.45.2 Headcrab: July 2020 progress report This Month in Rust OSDev (July 2020) Learning Rust: Mindsets and Expectations Blue Team Rust: What is “Memory Safety”, really? Creating Linux Packages for Rust Projects (1/2) Reverse Engineering a USB Device with Rust Some Learnings from Implementing a Normalizing Rust Representer [video]Learning Rust by Working Through the Rustlings Exercises Rust Language Cheat Sheet 2019 -> 2020 [audio]The State of Rust 2 with Alex Chrichton [audio]The State of Rust with Steve Klabnik RFC: ‘C unwind’ ABI Procedural vtables and wide ptr metadata Edition 2021 and beyond Credits Hosting Infrastructure: Jon Gjengset Show Notes: Nell Shamrell-Harrington Hosts: Nell Shamrell-Harrington

Ребята говорят о RUST. Мы пригласили самого топового RUST евангилиста которого мы знаем. Присоединяйтесь в наше погружение в RUST. Таймлайны: 06:35 Opening Keynote by Steve Klabnik & Florian Gilcher - https://youtu.be/-GHa83kWCgA 17:15 The Symbiotic Relationship of C++ and Rust by Isabella Muerte - https://youtu.be/nqvGoDvQTRs 29:05 Monotron - Building a Retro Computer in Embedded Rust by Jonathan Pallant - https://youtu.be/IArQf7TX1D4 41:57 Messing Around with fn main() and Getting Away with it by Yoshua Wuyts - https://youtu.be/kts3yTyoUYc 43:30 Syscalls for Rustaceans by Gargi Sharma - https://youtu.be/QP8XtsjRdUA 57:48 Towards an Open Ecosystem of Empowered UI Development by Adam Perry - https://youtu.be/1JhEeTW08HU 01:09:00 Tokio-Trace: Scoped, Structured, Async-Aware Diagnostics by Eliza Weisman https://youtu.be/engm2Wqfgjk 01:17:52 Closing Keynote by Lin Clark - https://youtu.be/VlIydW5Fojw Мы в соцсетях: 1. Twitter: https://twitter.com/ProconfShow 2. Telegram: https://t.me/proConf 3. Youtube: https://www.youtube.com/channel/UCvasfOIImo7D9lQkb1Wc1tw 4. SoundCloud: https://soundcloud.com/proconf 5. Itunes: https://podcasts.apple.com/by/podcast/podcast-proconf/id1455023466

Leah organizes both RustConf and EmberConf, and has been organizing tech conferences for well over a decade. She talks about some of the lessons she's learned in building inclusivity and accessibility into the conferences, outside of the technical talks. Childcare, for example, is one feature she's introduced that has had a positive effect on both parents and children. Suddenly, workers don't need to fret between networking with their peers and finding quality day care. Leah cautions that the first few years she offered this space, there weren't many enrollments, primarily because attendees didn't know that the option was available. But year after year, more parents are participating. As ideas on gender are evolving, Leah has experimented with applying pronoun usage onto badges. At first, she made this mandatory, requiring attendees to provide their preferred pronoun while registering for the conference. She thought that this would help normalize the terminology, but she says her opinion has changed after speaking to several people. Instead, she provides pronoun stickers to attendees when they collect their badges at the conference. Some smaller opportunities, like building fitness activities into the schedule, also helps attendees maintain their routine and connect with other conference-goers in ways they might not otherwise be able to. Links from this episode Leah's book, Event Driven, is all about running tech conferences Leah's previous podcast, 35. Bringing Open Source to Work

Parent Driven Development Episode 013: Babies at Work?! 00:15 Welcome, Leah Silber! (https://twitter.com/wifelette) Leah is the CEO of Tilde Inc. (https://www.tilde.io/) She is also an organizer of EmberConf (https://emberconf.com/), RustConf (https://rustconf.com/) and RailsConf (https://railsconf.com/), and Ember.js Core Team (https://www.emberjs.com/team/) Member, a jQuery Core Team (https://jquery.org/team/) alum, author of Event Driven: How to Run Memorable Tech Conferences (https://leanpub.com/eventdriven/), and all around technophile. 01:08 KWu is Planning Her Son's 1st Birthday Party! + How Old Are They? Don't let first birthday parties get out of hand. Not worth it. Get a cake. Let the kid smash. Also, please stop referring to your child's age in months when they turn 2. 04:05 Babies at Work: It’s Weird that it’s Weird (https://hackernoon.com/babies-at-work-its-weird-that-it-s-weird-b285b070d456) In August 2017, Leah wrote this blog post and it was super well received. In the blog post, she talks about a lot of the objections and concern she had at first that turned out to be unfounded. It turns out, bringing her baby to work changed the mood and culture of Tilde in a positive way -- even among self-proclaimed "non-baby people". 09:26 What About The Fussy Days? Working from home can be an option especially on days like vaccination days. Having a quiet area like a conference room or an empty office gets people through short fussy spells. If that doesn't work, going home is encouraged. Leah says that having the babies at work made actually for a much happier baby! 17:56 Nursing Up to the mom! Breastfeeding in public is acceptable, and there are dedicated nursing rooms/spaces to keep it legal (and more private) It becomes normalized! People don't even notice Squatty Potty (https://www.squattypotty.com/) 23:53 Culture From The Core Stating expectations for parents/non-parents during the interview process Scaling as children age Bring the Nanny to work too! Older children must be up to date on vaccinations Becomes a routine 32:43 Does Company Size Matter? Just because there are 50 people in a company does not mean that the volume of babies is going to go up Setting a limit is an option: luck of the draw The bigger the company, the more space non-baby people have to stay away from the babies 35:02 Program Evolution Effects on Nannies Beneficial for dads too! 42:37 Avoiding Judgement Turns out, people (who aren't the child's parents) are more helpful than judgemental Pets are not babies...no, your dog can not come to work because my baby is here 48:31 Genius / Fail Moments KWu: Water coming out of the tub faucet is fascinating and acts as a baby magnet to draw them to the bathroom for a bath! (#Genius) Allison: Creating an insane schedule of hodgepodge childcare that involves massive amounts of logistics. (#Fail) Leah: Shoutout to the parents who think their kids will never walk. Her son started walking at 18 months! (#Genius) Follow & Support Please follow us @parentdrivendev (https://twitter.com/parentdrivendev) on Twitter or email us at panel@parentdrivendevelopment.com (mailto:panel@parentdrivendevelopment.com). Our website is at ParentDrivenDevelopment.com (https://parentdrivendevelopment.com). We are listener supported. Please consider Supporting us via Patreon (https://www.patreon.com/parentdrivendev) and gaining access to our our kind Slack Community. Panel Allison McMillan (https://twitter.com/allie_p) Katherine Wu (https://twitter.com/kwugirl) Special Guest: Leah Silber.

We're joined by Vaidehi Joshi to discuss her multimedia empire, conference talk prep, getting started with computer science, and the applicability of a computer science education in every day development work. We wrap the episode with live Q&A from our RailsConf audience. Vaidehi Joshi on Twitter Base CS – The Blog Posts Base CS - The Podcast Base CS - The Video Series RailsConf 2018: Re-graphing The Mental Model of The Rails Router by Vaidehi Joshi Deckset for Mac: Presentations from Markdown RustConf 2017 - Type System Tips for the Real World by Sean Griffin EmberConf 2018: Closing Keynote by Saron Yitbarek & Vaidehi Joshi Conway's Game of Life Understanding Computation: From Simple Machines to Impossible Programs: Tom Stuart Announcing Skylight for Open Source!

Operators as sugar for traits, traits as generic constraints, monomorphization, and universal and existential types. Show Notes on monomorphization, see also Sean Griffin’s RustConf 2017 talk zero-cost abstractions Sponsors Aaron Turon Alexander Payne Anthony Deschamps Anthony Scotti Antonin Carette Aleksey Pirogov Andreas Fischer Andrew Thompson Austin LeSure Behnam Esfahbod Benjamin Wasty Brent Vatne Brian Casiello Chap Lovejoy Charlie Egan Chris Jones Chris Palmer Coleman McFarland Damien Stanton Dan Abrams Daniel Collin Daniel Mason Daniel P. Clark David W. Allen David Hewson Derek Buckley Derek Morr Eugene Bulkin [Hans Fjällemark] Henri Sivonen Ian Jones Jakub “Limeth” Hlusička James Cooper Jerome Froelich John Rudnick Jon Jonathan Turner Joseph Hain Jupp Müller Justin Ossevoort Karl Hobley Keith Gray Kilian Rault Laurie Hedge Luca Schmid Luiz Irber Mark LeMoine Martin Heuschober Masashi Fujita Matt Rudder Matthew Brenner Matthias Ruszala Max Jacobson Messense Lv Micael Bergeron Nathan Sculli Nick Stevens Oluseyi Sonaiya Ovidiu Curcan Pascal Hertleif Patrick O’Doherty [Paul Naranja] Peter Tillemans Ralph Giles (“rillian”) Raj Venkalil Ramon Buckley Randy MacLeod Raph Levien reddraggone9 Ryan Blecher Ryan Osial Sebastián Ramírez Magrí Shane Utt Simon G. Steve Jenson Steven Knight Steven Murawski Stuart Hinson Tim Brooks Timm Preetz Tom Prince Ty Overby Tyler Harper Vesa Kaihlavirta Victor Kruger Will Greenberg William Roe Yaacov Finkelman Zachary Snyder Zaki (Thanks to the couple people donating who opted out of the reward tier, as well. You know who you are!) Become a sponsor Patreon Venmo Dwolla Cash.me Flattr PayPal.me Contact New Rustacean: Twitter: @newrustacean Email: hello@newrustacean.com Chris Krycho GitHub: chriskrycho Twitter: @chriskrycho

Organizing Technical Conferences TableXI is now offering training for developers and products teams! For more info, go to http://tablexi.com/workshops (http://tablexi.com/workshops). Get your FREE career growth strategy information and techniques! (https://stickynote.game) Summary I've been attending technical conferences for years, and I've always wondered about the hidden challenges involved in putting a conference together. In this show, four of the best conference organizers I know join me to share their secrets and stories. Marty Haught, organizer of many conferences including RubyConf and RailsConf, Jen Remsik and Jim Remsik, who organize the Madison+ family of conferences, and Leah Silber, who organizes EmberConf and RustConf. Learn about budgets, picking talks, and managing facilities and vendors. Guests Marty Haught (https://twitter.com/mghaught): President at Haught Codeworks (https://haughtcodeworks.com/), Director at Ruby Central (http://rubycentral.org/) organizing RailsConf and RubyConf Jen Remsik (https://twitter.com/jenremsik): Director of People Operations at Adorable.io (https://adorable.io/), Organizer of Madison Ruby (https://twitter.com/madisonruby) Jim Remsik (https://twitter.com/jremsikjr): President of Adorable.io (https://adorable.io/), Organizer of Madison Ruby (https://twitter.com/madisonruby). Leah Silber (https://twitter.com/wifelette): CEO at Tilde Inc. (http://www.tilde.io/). EmberConf (https://emberconf.com/), RustConf (http://rustconf.com/), and RailsConf (https://railsconf.com/) Organizer. Author of Event Driven: How to Run Memorable Tech Conferences (https://leanpub.com/eventdriven). Notes 03:12 - Getting Things Right and Having Empathy for Attendees 11:16 - Budgetary Aspects 14:53 - Planning Conferences in Other Cities 18:22 - Putting the Program Together and Selection Processes 29:25 - Crafting a Conference Proposal 31:12 - Encouraging and Enabling Attendee Interaction 40:03 - Conference Mentorship 41:26 - Words of Advice Special Guests: Jen Remsik, Jim Resmsik, Leah Silber, and Marty Haught.

We chat about compile times, Aaron’s new quest, books, logic programming, JetBrains, and RustConf.

Daisuke Murase さんをゲストに迎えて、Ghost In The Shell, Rust, React Native などについて話しました。 Show Notes Google Maps morphs into Ms. Pac-Man for April Fools’ Day Ghost in the Shell (2017) Wilfred/remacs: Rust Emacs The Rust Programming Language Chris Lattner on wrapping up Swift 3, starting Swift 4 Cargo: packages for Rust Taking Rust everywhere with rustup Letter.ly Abrupt.ly Loses Domain Name As A Result Of The War In Libya RustConf 2017 React Native StyleSheet Modern JavaScript for Ancient Web Developers Platform Specific Code AndroidエミュレータとVirtualBox、Docker for Macを同時に実行できない問題の対処法 Genymotion Android Emulator Using React Native: One Year Later – Discord Blog

Steven Murawski is using Rust. Show Notes: StevenMurawski.com Steven's Github Blog post: Fearless Concurrency with Rust Blog post: Abstraction Without Overhead: Traits in Rust Blog post: Rust is More Than Just Safety Blog post: Safety is Rust's Fireflower Blog post: Fire Mario, not Fire Flowers Blog post: Rust is Mostly Safety Podcast: New Rustacean The Rust Book Playlist of videos for Rust Belt Rust 2016 Playlist of videos for RustConf 2016 Habitat (GitHub) Upcoming events: PowerShell + DevOps Summit ChefConf DevIntersection (I'll see you there, too!) Steven Murawski is on Twitter Want to be on the next episode? You can! All you need is the willingness to talk about something technical. Theme music is "Crosscutting Concerns" by The Dirty Truckers, check out their music on Amazon or iTunes.

Carol Goulding: @Carols10cents | GitHub | Blog | Integer 32 Show Notes: 00:58 - Going Into Business Using Rust 03:42 - Getting Paid to do Open Source 05:31 - Prototyping Projects in Rust 06:21 - Why Rust? (Benefits) 09:58 - The Language Server 14:52 - Error Messages 19:46 - The Rust Programming Language Book 23:35 - Crates.io 27:41 - The Backend 31:11 - Working with Rust and Ember Together 33:31 - Rust Belt Rust Conference 35:59 - Integer 32 Resources: The Rust Programming Language Book The Frontside Podcast Episode 51: Rust and APIs with Steve Klabnik Rust For Rubyists Working Effectively with Legacy Code by Michael Feathers Clippy Cargo rustlings Python Koans Rust - exercism.io No Starch Tokio Diesel Rocket Nickel Iron Pencil Rust Belt Rust Conference RustFest.EU RustConf Transcript: STEPHANIE: Hello, everybody. Welcome to The Frontside Podcast. This is Stephanie Riera. I am a developer here at The Frontside and with us, we have some very special guests. We have Chris Freeman who is a former Frontsider. He is a developer at a startup here in town in Austin called OJO. I'm going to let Chris introduce Carol Nichols. CHRIS: Hi, everyone. Today we've get Carol Nichols. She is involved in a lot of different things related to the Rust programming language. She is on the Rust community team. She is the co-author of the Rust book. She's the co-founder of a Rust consulting company called Integer 32 and she's the maintainer of Crates.io. How are you doing today, Carol? CAROL: I'm great. Thank you for having me on the show. CHRIS: Thanks for joining us. I have a lot of questions for you. I'm very interested in Rust but I am especially interested in some of the stuff you're doing that's kind of ancillary to it, namely you decided to go into business using a pretty new programming language that in some ways, I think is a little bit niche-related to some other things that people might go into business for say, web development. I was hoping maybe you could talk about what is Integer 32? What led you to starting this business? What kind of consulting work do you find working in something like Rust? CAROL: Integer 32 is my husband and I, Jake Goulding and we decided to form this company because we really wanted to get paid to work on Rust. We think Rust is really interesting and that is moving the industry forward and we see a future in Rust. As far as we can tell, we are the first Rust-focus consultancy in the world, which either makes us trendsetters or really stupid. I'm not sure about that yet but we're figuring it out. We consider ourselves pretty qualified to be running a Rust consultancy. As you mentioned, I'm the co-author on the book. I've been working with Rust for a couple of years now. Jake has the most points on Stack Overflow in the Rust tag. We've got a lot of experience in getting to know Rust. We've been watching the development, helping people learn Rust so we are offering a bunch of different services. One is to build an MVP or a prototype for Rust so that companies can evaluate whether Rust would be a good fit for their problem, without diverting their whole team to be able to learn Rust enough to evaluate it properly. We've done some prototypes. We're also interested in doing training and pairing so we have some training, things in the works. We've also gotten some jobs that are adding to open source libraries in Rust. The ecosystem is still being built up and there's a lot of libraries that do whatever the person who wrote them need them to do but they're not feature complete so if someone else just needs that extra feature on some library, they can pay us to add it if they'd like. One of the things I really want to do with my consultancy is have our proprietary work subsidize our open source work because I really wanted to get paid for open source stuff. We have a different rate that we charge for a proprietary versus open source. We've had a few gigs that are adding stuff to open source libraries and I love those because we're not only benefiting the company who needs something but we're benefiting the entire community. CHRIS: When you say you work on an open source thing, do you mean like a company that happens to be a consumer of an open source library would pay you to add a feature? Or is it the maintainers of the libraries themselves are coming to you and hiring help? CAROL: So far, it has been the former but we have talked to some people about the latter but open source projects typically don't have much funding. I think that's a little rarer but definitely, were open to companies paying us to add what they need to a library. CHRIS: Has there been any friction there like you kind of showing up and say a company is paying us to try and add features to your project? Do the maintainers ever pushback or are they very happy to just have someone helping? CAROL: Yes, so far no. All the maintainers we worked with have been amazing. We're not going to come in and rewrite the whole project. We're going to come in and work with their style and make any modifications they want to be able to incorporate into their library. But as I said, a lot of libraries are gotten to a certain point and I think the maintainers would like their libraries to become more feature complete but everyone only has so much time and you don't necessarily know what's useful to people but this is a very, very strong signal that this library would be useful to someone if only it had this little extra thing. I think most maintainers are open to making their libraries more feature complete to be more useful to more people. CHRIS: Yeah, that is a pretty sweet deal from the standpoint of an open source maintainer. It's nice enough when people show up to help at all. It is especially nice to show up to help and aren't motivated by money. CAROL: Yeah. CHRIS: That's very cool. When it comes to prototyping things with Integer 32, what kind of projects are people coming to you and asking you to prototype in Rust? CAROL: A lot of them are existing projects that they have and written in something else that they want to either perform better and be safer as opposed to rewriting it in C or C++ to get performance out of it. Sometimes, they want something to interface with other Rust things. We're starting to see projects like that but mostly, they have a hunch that Rust will be good for their projects and solve some problem they're having with their current implementation. We scope their projects way down to whatever will let them evaluate, whether Rust is a good fit or not and we go with that. CHRIS: Cool. STEPHANIE: Going from there, the question that I have is why Rust? I don't know a lot about Rust so I'd like to know what would be some of the benefits of using Rust, if you're familiar with programming. If you are in web development like I'm familiar with Ember, why would I like to use Rust or learn Rust? CAROL: I could talk all day about this. I really love working with Rust. I feel like it is adding more tools to help me to write better code and taking care of little details that usually I would have to spend a lot of brainpower thinking about to get right all the time. But now I can actually concentrate on whatever it is I'm trying to get done and let the compiler take care of those details for me. The way it's implemented, it happens really fast. The way I got into Rust was I'm a Rails developer previously to this job and I spend a lot of time optimizing Rails, looking for places where essentially too many Ruby objects and memory leaks and [inaudible] a lot of trying to make Rails go faster. At some point, you can't. There's only so far you can take Ruby and Rails so I look at where I want my career to go next and I love making things go faster but I'm terrified of C. I should be nowhere near production C. You have to spend years learning all the quirks and all the ways that C can go wrong and crash and be insecure. Around this time, I know you had Steve Klabnik on the show, in the previous episode. Steve is from Pittsburgh, where I am and he came home for Christmas one year and came to a Ruby meet up and was talking about this new language called Rust and how awesome it was. Steve gets distracted by new awesome things all the time so I was like, "Yeah, yeah, okay, whatever." The next year, he came home for Christmas again and was still talking about how awesome Rust was. At that point, I was like, "There's got to be something to this." At that point, he was writing his book, 'Rust for Rubyist' which has lead into his work on the Rust programming language book. I was like, "Rust for Rubyist? I can handle this. This is something I can do and capable of," so I started reading his book and submitting corrections and things which is again, how I got involved with the Rust programming language book. If you've ever gotten the error 'undefined method on nil' or 'undefined is not a function' in JavaScripts, like in production at runtime that happens all the time. That's just normal in Ruby and JavaScript land. Rust prevents those problems at compile time so there's no null, there's no nil. It's strongly typed so it checks that you have the thing you think you have before your code even can run. There's no garbage collector so you don't have memory leaks. The system of ownership and borrowing and the borrow checker and lifetimes which is weird. It's tricky to get your head around at first because it's different than any other language. But once you get that that's the part that enables your code to go faster without needing the garbage collector. You actually don't have to think about your memory management as much as you would in C, where you have to say, "Please give me some memory." Okay, I'm done with it now. You are manually managing your memory but you don't have to think about it as much because the compiler is thinking about it for you, if that makes sense. CHRIS: I have a follow up question, kind of related to the fact that Rust is kind of performing at the level of C or C++ but a lot more friendly in the fact that both you and Steve and I think a lot of other people, have come to Rust from scripting languages, from higher level languages. I remember at first that I started paying attention on Rust like right before the 1.0 happened, I thought it sounded interesting and wrote it off because it was just insane and I had only ever done Python and JavaScript and higher level things. In a relatively short time, it has developed a level of ergonomics that I'm envious of, even in the 'more comfortable' languages, things like Cargo, things like the compiler is really great but now the compiler has really friendly and informative error messages so that 'undefined is not a function' never happens but when you try to make it happen, it now shows you like, "No, no, no. On this exact line, in this place, this is where you're doing it wrong." But I recently heard it and I'm curious if you know anything about it that there's also development on a Rust language service, kind of like I guess TypeScript test, where it's a whole set of tools that you can run under the hood that any editor can plug into so that you just get this tool box of things to help you develop in Rust that are all packaged up and handed over and all you have to do is hook into it. Have you try that at all? Are you familiar with that? CAROL: I am not. I've been watching but I haven't worked on it and I haven't tried it out yet. I am excited for the language server because it's going to enable IDEs to do more interesting things. Coming from Ruby where it's so dynamic that you can't do things like ensure that you renamed all of the places and method it's called because you can't know that. I've read books like Michel Feathers' Working Effectively with Legacy Code and a lot of the chapters in that talked about leaning on your IDE, on your refactoring tools to do automated refactoring. RubyMine has a few of those things but not all of them because it's just impossible so I'm really looking forward to having real refactoring tools that can let you do automated refactorings and things like that that are possible in other statically-typed languages but with Rust in an IDE. I haven't used an IDE in years because I haven't found them to be useful but once the language server is up and running, I'm thinking about going back to an IDE so it's definitely exciting. CHRIS: That's some pretty cool right now. There's one called Clippy which I love because of the name like it takes you back to my Microsoft Word days. There's a lot of very good stuff that they have added that I didn't expect from a 'systems language' but it has definitely benefited from a lot of things that people in the scripting world have learned. CAROL: One of the goals of 2017 for the core team is increasing people's productivity in Rust so getting people over the learning curve, providing them with tools like the language server and making it easier for people to build things in Rust without having to manage things around Rust. Just Cargo in itself has made systems programming so much better. I see people who develop in C and C++ who really try to minimize the amount of libraries they bring in because that makes your build system so much more complicated and you have to have libraries in the right place and so much more can go wrong. But with Cargo, it's just Cargo install and you have a Cargo.lock and cargo.toml that manages versions. It just work so it's been interesting watching people figure that out and change their opinions on bringing in dependencies with npm and JavaScript and Bower and Ruby Gems that we're all used to like, "Oh, there's a gem for that. Let's just pull that in and go." Systems people have been really reluctant to do that but Cargo is enabling that to be better and easier which is really exciting to watch. I want anyone listening to this who thinks, "I can't do system programming. It was too hard." No, you totally can. You can do Rust. Rust is going to let you do this and that's why Rust is really exciting because it's enabling a whole new group of people to get into the systems programming space where things need to be optimized and faster and letting people build these sorts of things without having the programs be vulnerable to crashes and security bugs and things like that. It's really, really exciting. CHRIS: Very cool. STEPHANIE: I'm curious in Rust, if there's an error, how would you know that there's an error? Is the whole thing going to stop? Is it going to break? Do you get a useful stack trace? What would I expect to see? CAROL: A lot of the errors in Rust are at compile time. It won't even let you try to run your code if you have certain kinds of problems and they tried to move as much as possible into that compile time space. There are always going to be things that you can't catch a compile time like the user enters a number that's too big for whatever you're trying to do. That's still going to be a runtime error because we can't possibly know what a user is going to put in when you're compiling. They've done a lot of work on the compiler errors as Chris was talking about, to make them friendlier and point here's where your error is, here's why it's happening, here's a hint as to how you might want to fix it. This has been really great. I was volunteering in a local code school with students just starting Ruby and I'm used to Ruby's error messages by now but they were just getting started and getting all sorts of errors and I was like, "Wow, these error messages are not helpful at all," and I forgot how bad that is and how confusing it can be for a beginner to just think you understand, think you have got it working and then you go and run the code and it's just like 'string is not a symbol' or whatever. The worst is when you forget to close the block and just expected to see [inaudible] end of file instead and it's not helpful at all. I was just like apologizing the whole time like, "I'm sorry. This is telling you that you need to write 'end' at the end of the file," but it's not telling you that in any way you could possibly know that. That made me appreciate much more all of the work that's going into Rust error messages that are really trying to help. Some people talk about, especially the borrow checker, fighting the borrow checker like they're not used to having a compiler tell them their code is wrong so often so people talk about fighting the borrow checker a lot but it's not trying to fight with you. It's not trying to make you feel bad about your code. It's trying to help you make your code better and prevent errors that might happen at runtime by catching them earlier. I actually have a little project called Rustlings that is full of little snippets of Rust that intentionally don't compile. You run them and you get an error message right away and your job is to read the error message and learn how to fix it. When I was starting out, I was really frustrated because I was trying to do something and I would get an error message and I would have to stop whatever is doing to deal with the error message. I was like, "If I could just get some practice just dealing with the error messages and learning how to fix them so that when I'm trying to do something else, I already have experience fixing that kind of error," so that's how that project came to be and people found that useful. I haven't had much time to work on it lately but it could definitely use more examples because I think people are used to error messages that are not helping. People used to back traces that are really long and don't say anything useful. Sometimes, you don't stop and read and think but the Rust error messages are really trying to help you and often times, they are telling you exactly what you need to do to change the code to work. I think getting practice seeing the compiler as more of a pair who is trying to help you and not someone who's trying to reject all your code is a different mindset that I don't think people are used to but I think it's really useful. STEPHANIE: That's excellent. I was going to ask you if there are any resources or any repos to check out for someone who is interested in getting into Rust. It's funny, last night I was poking around with Python and there's something similar to Rustlings. It's called Python Koans and it's basically like what you're already familiar if you do web development. You want to get your test to pass so it'll tell you, you need to think about this one or you need to meditate on this and then you try to get it to pass and then it says you have reached enlightenment or you have not yet reached enlightenment and you have to sit there and think about it and then run it again. It's very useful in trying to get started with language in a way that you are already sort of familiar with. CAROL: Yeah, I've definitely gotten inspiration from the Koans project that have existed in other languages. There's also an exercism track for Rust that people found really useful and of course, I'm working with Steve Klabnik on the Rust programming language book. We're rewriting the whole thing so there's an existing version that if you go to the Rust documentation and click on book, you'll get the existing version which is complete but the new version is going to be way better. Especially with the explanations of ownership and borrowing, people have said that the new version is way, way better than the old version. Someone even made the analogy of doing medical research and you see that trial case is doing so much better than the placebo case that is not ethical to continue the trial. It's more ethical to stop the trial and use the new thing because it's helping so many people. Someone was like, "You need to replace the old book with the new book right now because it's so much better," but the new book isn't complete yet. The new book is in a different repo which we can put in the show notes so I'd recommend starting with the new book and then working back and forth with the old book once you run out of content. But we're getting closer all the time so hopefully, that should be done and printed by No Starch sometime in 2017 -- CHRIS: Woah! It's being printed by No Starch? CAROL: Yeah. CHRIS: That's cool. I didn't know that. Congratulations. CAROL: I thought Steve mentioned that in the last one. CHRIS: He may have but he talked about it a long time ago and I thought he always meant the old one. How long have you been rewriting the Rust book for? CAROL: It's been a while. CHRIS: Longer than I knew about then, probably. CAROL: It's kind of like software. It's more work than you think it's going to be and estimating, it's going to be done when it's done. If you kept telling people, "It's going to be out on this time," and like Steve, "There's no way it's not getting done by then," so now he's not allowed to say it when it's going to be out. CHRIS: Nice. CAROL: I'm really grateful to see this opportunity because I don't think I would have written a book on my own and I'm learning a whole lot about the process of writing a book. It turns out there's a lot of editing, a lot of back and forth, a lot of trying to build a narrative through this long stretch of text so that you're building on top of what you've already covered and not introducing things that aren't mentioned. It's a lot of work and I'm learning a lot and I have no idea when it's going to be [inaudible] because I think there's more work that I still don't know about coming, as we get closer to going to print. It's definitely one of those things that you can't make agile because you've got to put it on paper that costs money and it's going to be around a long time at some point. It's definitely a different kind of working that I'm used to with software. CHRIS: Although, I have to say, I clicked around and I think this is the new version: Rustlings.Github.io/Book. Is that the new one? CAROL: Yes, that's the new version. CHRIS: There is a lot here and it's not quite what I would have expected to see here like it's not done yet. I've been clicking links and I have yet to find one that says 'to-do'. CAROL: I think 15 through 20 are like outlines right now. We're maybe three-quarters through with the content but then we have to go through revisions and editing and copyediting. CHRIS: I'm looking at the headings and I was a big fan of the first Rust book but I can already see it calling out things I wish had been hit on more specifically in the original book. There's a lot of good looking stuff here so I'm excited about this. I'm going to go and read this thing. CAROL: I'm excited for people to read it. CHRIS: Earlier, you were talking about one of the things that is really nice about the Rust tooling is that Cargo makes it really easy to bring in dependencies. I happen to know that you are recently, I believe the maintainer of Crates.io which is where all of Cargoes crates, which are the libraries are hosted. Is that correct? CAROL: That is correct. I have commitment Crates.io now which is very exciting. Crates.io is like Ruby Gems or npm. It's the site where people publish their libraries and you can go and search for a library for what you need. As part of the Rust 2017 goals, we want to make it easier for people to find high-quality libraries that do the things they needed to do. I've been doing some work on adding badges and categories. Rust makes major decisions on the language and on things through an RFC process, which I think Ember is doing now too. I forget which way we stole that. Do we steal it from Ember or did you steal from us? I can't remember. CHRIS: If I remember right, I think -- I could be wrong, Twitter -- Ember did it first. Rust borrowed it and then added the 'how do we teach this?' section. I think Ember took that back and added it to their RFCs. CAROL: Okay, I'm super excited about that section. Now, when you propose a change of language, you have to go through this RFC process where you write up what you want to change, why you want to change it, any downsides, any alternative designs. Then the community talks about it and makes comments when you revise it and things like that. Now, there's a new section that just got added. That's 'how do we teach this?' Before something can be stabilized in the language, you have to document it. This is still kind of starting to take effect but I'm super excited about it because people can't use something unless they know how to use it. Right now, Steve's the only person getting paid full time to work on the documentation and I need him to write the book so I'm excited that more people will be thinking about documentation and thinking about how to help people use their new features. Anyway, I have an RFC about how to rank Crates within a category that we're trying to work through. In some automated ways, we can recommend different Crates for different purposes. I'm working through that with the community to try and figure out how to best recommend Crates in different circumstances. Crates.io is written in Rust and it performs really well. It just got added to the Heroku things so you can deploy it too. Looking at the analytics and their response times for is just like the Ruby apps I work on would be thrilled to have these stats. The backend of it is Rust, the frontend is Ember and [inaudible] who was an Ember person is also interested in Rust and he thinks Rust on the backend and Ember on the frontend worked really well together. He's always trying to figure out ways that we can work together. Crates.io is an existing project that I'm still learning Ember. There's lots of words I don't really understand about like components and Bowers. I would love Ember help on Crates.io. I'm starting to pull out issues that would be good at first time issues or more Ember-focus or I have some idea of how to fix that I could help someone fix. I'm starting to tag those things with 'has mentor' in our labels so I love for people to come check out issues on Crates.io who know JavaScript and know Ember and might want to get into Rust because there are definitely some issues that need a little bit of frontend, a little bit of backend so it might be a good way for people to get into Rust. CHRIS: Very cool. I'm personally very interested in that and will likely hit you up. But I'm sure many of our listeners will as well because I think we have a lot of Ember-friendly listeners so look Carol up because it sounds like she could use some help. Actually, I'm curious, the backend, I know that pretty recently, Rust has kind of gone through this period of kind of explosion in terms of Rust as a web language. There have been a number of different things that have come out pretty recently for a web framework in Rust or there's that Tokio thing. I know Diesel is like the ORM for Rust in talking to databases. It looks like it's about to hit 1.0. There's a lot of stuff happening so I'm curious, what are you using to write the backend. I know you're using Rust but are you using one of these frameworks or have you rolled your own? How's that work right now? CAROL: Crates.io is one of the first web apps that has been written in Rust. Actually, if you look at the backend code, you'll see SQL being built by hand. It's going to the Rust postgres library so it has SQL injection protection. All the things are [inaudible] so don't worry about that but they're still like SQL with the Rust code so it's not using an ORM yet. I'm going to have to look up. There is a library that is using that I'm blanking on the name of it for but it's very low level. It just let you send HTTP requests and let you respond to HTTP. We're in kind of a Cambrian explosion period with Rust web frameworks. There's a lot of different ones. One that I'm excited about that I haven't gotten to tryout yet is Rocket. That was just released. The thing I love about Rocket is that everyone's really excited about it because it was announced and they have an awesome website with lots of awesome docs so that should be a lesson to any open source project that's launching is if you want to get excited about it, you've got to launch some docs. That will help so much. There's a lot of different frameworks happening. They're still little trilobites and little animals that can't walk on land on their own quite yet so there's still no Rails. There's the pieces of Rails. There's Diesel which would act like a record. There's Nickel and Pencil and Iron and Rocket. Tokio is the async framework that is getting more and more stable by the day. We got to try it out on a project recently and it's pretty fun. I still am working on wrapping my head around promises and futures and working in that way but I think as that stabilizes and people use that, that is going to cause like another explosion of libraries that enable really fast but safe web backend stuff, which I think is really exciting. If you're looking for the Rails experience of being able to plug things together and nicely, just declare a few things, it works but not quite there yet. But if it excites you to try out new things and figure out the best ways to do the things you want to do in Rust, this is a great time to jump in and help. CHRIS: I will say the Rocket website is beautiful and it even has this templating section, a testing library section. This is very exciting. It really looks like as the closest thing to a Rail-style web framework that I've seen in Rust so far. People should definitely check this stuff out. I'm curious, I know a lot is really interested in Rust and Ember, which doesn't surprise me because lots is really interested in Ember in general, which I think is awesome. But is there anything specific about working with the Rust and Ember together that seems, especially well suited or even like some gotchas that you guys have run into? One of the things I'm thinking of is like Ember is really big into JSON API spec and I don't know if Rust has a JSON API library for serializing things in that format. Is that something you guys have to tackle at all? CAROL: There might be. I'm not sure. Crates.io is using the Rust API adapter for Ember so we might not be keeping up with the latest of Ember. But I know there are people who want them to interface them better with each other. Actually, that's an interesting thing. Both Ember and Rust are on a six-week release trains sort of things so the way Rust people will say -- I don't know if Ember people do -- is stability without stagnation so they're both changing. Rust has backwards-compatibility guarantees so the code you wrote with Rust 1.0 is still going to compile today. You might have some warnings and there's probably new cooler stuff that you could switch to but it's still going to compile. I'm not sure about Ember's upgrade path things. Someone just sent in a pull request that we merged like three days ago to upgrade us from two Ember point versions. There were a couple of things that like [inaudible] and we weren't doing quite right and we had to fix. It's been interesting to kind of fit together, keep both of the sides, update it and upgrade it and continuing on using the best things. But I think they have similar philosophies around making things better all the time. CHRIS: Yeah, the whole stable upgrade path and backwards-compatibility guarantees is definitely mirrored on the Ember side of things. I can see that being a little kind of comforting place to be knowing that both your frontend and your backend are not going to suddenly just break on you one day because some new feature came out that breaks your router or something. That's very cool. One of the thing that I know you're involved in -- you're involved in a lot of things -- when it comes to Rust, it's very cool. But you also run or a co-run a conference, right? Rust Belt Rust? CAROL: Yeah, we had our first year in 2016 in Pittsburgh. I ran Steel City Ruby before then so I love running conferences and I love having them near me one, because it's convenient and I get to trick all of my friends into coming to visit me. But two, because there's a lot of tech stuff happening in the Rust Belt and places that aren't San Francisco or New York. People don't necessarily know about that and people who live here don't necessarily have the opportunities to travel as easy to conferences. I sort of start Rust Belt Rust, one because of the pun opportunity and one of our speakers drew a little bar graph. There were three conferences last year. There was Rust Fest in Europe which has [inaudible] amount of Rust. There's RustConf, the official Rust Conference in Portland that has a lot amount of Rust and then Rust Belt Rust has double the amount of Rust in its name so we're the Rust-serious Rust conference. We're going to do it again, in 2017 we're going to move it to a different Rust Belt city. I'm not going to say which one yet but we're closing in on a date and a venue in the Rust Belt city so watch out for an announcement on that. It was a lot of fun. We had a day of workshops and then a day of single-track talks and a lot of time for conversation. A bunch of the core team members came out and it was fun talking with a friend of mine who was trying out something with Tokio. This was in October so Tokio was still working towards their first big release and he was trying to do something with Tokio. I looked over and I saw Carl Lerche, Alex Crichton and Aaron Turon standing together and talking like 30 feet from us and I was like, "If only the three people working on Tokio were nearby to answer your question --" so he just walked over and talked about Tokio with them. I love getting people together to talk to other people working with things, talk to the people who are working on the things they're using and meeting the people behind the names on the internet so I love running conferences and having events like that. STEPHANIE: Carol, you have a Rust consultancy called Integer 32. How is that going? CAROL: It's going pretty well. We're learning a lot. One of the reasons I wanted to start it is because I felt like I wasn't learning more in my job. In my Rails job, I felt like I had kind of tapped out with that knowledge. In starting a business, I get to learn a lot of stuff like sales and marketing and taxes and invoices. Sometimes, I even get to program a little. We're still learning how to effectively find our target customers. We do have availability, if anyone listening is interested in hiring some Rust experts. Right now, I'm trying to figure out when can we bring more people on the team. I'm trying to decide if we can have an intern for the summer. It should be fun so yeah, it's going pretty well. It's been a slow build but we're lucky enough to have savings and be able to spend some time building our business but it's been really gratifying to feel like I'm in charge of my destiny somewhat, as opposed to the whims of a company. STEPHANIE: And if I were interested in some Rust consulting, what would be the best way to reach you? CAROL: We have a website at Integer32.com and a contact form on there. STEPHANIE: Thank you so much for speaking with us, Carol. It was a pleasure. I feel like I learned a lot about Rust. CAROL: Thank you for having me. STEPHANIE: All right, y'all. That's it from us. Thank you so much for tuning in. Until next time. Bye-bye.

Liz Baillie @_lbaillie | GitHub | Blog | Tilde Inc. Show Notes: 01:32 - Becoming a Developer 07:54 - Website Building 12:03 - Understanding Programming 17:34 - Coming to Peace with Ignorance 22:25 - Systems Programming 26:46 - Making Goals for Yourself 28:57 - Math and Programming 38:08 - Open Source Resources: Wicked Good Ember Liz Baillie: Journey to the Center of Ember Test Helpers Fibonacci Number Freewheel: Volume One by Liz Baillie The Flatiron School Skylight Impostor Syndrome Twilio Letter to a Young Haskell Enthusiast Hello, Con! OSCON Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast Episode 57. My name is Charles Lowell. I am a developer here at The Frontside and with me is Stephanie Riera, also a developer at The Frontside. Today, we have with us Liz Baillie, who is a developer at Tilde. I am actually really excited to have Liz on the show. I saw her at Wicked Good Ember back in June of 2016 and her talk was definitely one of the more memorable ones. You come away from a conference kind of only remembering a certain number of talks that stick in your mind and as time passes, the messages may fade but some of the message just stick with you and the one I got from her talk was a feeling of empowerment that, even though I have a lot of experience, I could approach any code base and try and grapple with it and understand it. I came away thinking, "There are a lot of code bases out there that I don't understand but if I apply a certain set of techniques and a certain level of fearlessness, I will actually get there." You know, if I want to go attack something like I don't know like Kafka or something like that, I would feel better about that. That was actually a great feeling coming away from that, a feeling of great power so thank you very much for that, Liz. LIZ: Yeah, no problem. CHARLES: Why don't we start with a conversation of how you came to be a developer? Everybody's got kind of a unique path. What's yours? LIZ: Well, I went to art school and I studied comic books. I actually have a bachelor's degree in comic books. I was a cartoonist for a number of years and at some point, maybe like 10 years ago, I had a friend who was a programmer. He's a web developer. But I didn't even what's a web developer was. But I knew he worked at home and he made his own hours and he made a lot of money. It seemed like an awesome job so I was like, "How did you get into that?" And he's like, "I don't know. I just kind of mess around and figured it out." And I was like, "Uh... I don't know what that means." Like how do you start? I have no idea. I went to the bookstore and I look at the For Dummies books and I got Programming for Dummies or something and it was like Visual Basic, I think. CHARLES: All right. What year was this? LIZ: That's 2004. I guess, it was a little more than 10 years ago. But it didn't say that on the cover. It was like 'Programming' and I was like, "Oh, cool. I'll learn programming." I don't even know what the difference of languages was or anything like that. I did a couple of exercises in that book and I had no concept of how this would become a website ever. I was making 'Hello, World' and little things that spit out Fibonacci numbers or whatever. I kind of gave up on that and I was like, "I don't care. I don't mind being poor." I'm used to it so I kept being a cartoonist, putting out books and stuff. I did a little PHP and HTML type of stuff in making websites for myself in between but I don't really consider that programming. It didn't feel like programming. CHARLES: Did you ever put any of your cartoons on the web? LIZ: Oh, yeah. Google me. They're there. [Laughter] LIZ: I might have some stuff like my web comic, I'm not sure if it's still up. But I had a web comic called Freewheel, which was about this girl who runs away from home and joins a band of magical hobos. CHARLES: That sounds like a career change to programming. It was oddly prophetic. LIZ: Yeah. It's out there. Anyway, I got to a point where, long story short, I was tired of being broken for all the time and I have to figure out some way to make money that I like doing so I thought, "I would go back to school," so I went back to school. I didn't start out with computer science but I took some math and science classes and I got really into math a lot. I really enjoyed math so I started looking into what careers can I do that are math-y. Somebody said, "If you enjoy the problem solving aspects of math, you'll love computer science," so I took a Computer Science 101 class or something like that and I got really, really into it like I just killed it. I just loved it. It was awesome. But I still didn't understand how you made that a website. In the back of my mind, I was like, "We did this thing --" We learned Python in my class so there's some program we had that like move a little turtle around and do pictures or something. I was like, "I don't understand how this makes a website." CHARLES: You got to move that turtle around a lot, especially like account for the kerning in the fonts and stuff. LIZ: Yeah. I have no idea how you make that a job, like the stuff that we were doing like spitting out Fibonacci numbers and making a little adventure game or something but how does that translate into anything else. That was in 2014 and that was around the time that web development bootcamps were starting to be more of a thing. I heard about a school called the Flatiron School in New York which is right at the time and I thought, "This sounds great. In three months, they'll actually teach me how this makes a website and finally know how does this make a website?" I applied in kind of like on a lark. I don't think I'll get in, I didn't know how can I afford it or anything and I applied and I got in. I was really lucky that my stepdad help me pay for it so I don't have to worry about it. I did that in three months and then I got a job. In November 2014, my first web job and now I know how those codes make a website so here I am today. CHARLES: What a journey. LIZ: Now, I live in Portland, Oregon and I make websites. Not really, I work on web apps, I guess is more accurate. CHARLES: So you actually went straight from the Flatiron School to working at Tilde? LIZ: No. I was in New York at the time and my first job was at an ad tech company called SimpleReach and I worked there for a little over a year before I got the job at Tilde, then I move to Portland. A year ago yesterday was my first day at Tilde. CHARLES: Fantastic. Knowing that company and knowing what they do, they must have you doing some really, really fascinating stuff. LIZ: Yeah, I do a lot of typical web stuff. I work on the Ember side of our app, Skylight. I also, more recently have been working on Rails engine that's also a gem that spits out documentation automatically, which is pretty cool. CHARLES: Now, is this documentation for the product or is it just documentation for any real site? LIZ: No, it's for our products specifically but I don't think it would be very difficult to alter for someone's personal needs, other than ours. But it's basically like if someone can write a markdown document, then we'll parse it and spit it out into HTML and all these different places so that it just updates the whole documentation site around our products. CHARLES: Basically, there's an infinite amount of stuff that has to happen to make a website because there are literally so many moving parts. What's been your favorite kind of area, I'll just say the whole website building because that really is like the tip of the iceberg. The actual iceberg goes way, way, way beneath the surface. But what's your favorite location on the iceberg so far? LIZ: I kind of like the middle, I guess. I always feel bad saying it because everybody talks badly about CSS but I just don't like it. I tried it really hard. One of my resolution this year was I'm going to try really hard and I'm going to like it more. But what I like the most is whenever I get to do pure Ruby. I learned Rust in the last year or two and anytime I get to make the stuff behind the visual aspect work or kind of like meta stuff. I'm saying this and it's totally wrong but I did my first meta programming the other day or last month. The metaprogramming that I did ended up getting cut out of [inaudible] but I got to do it before it got deleted. It was pretty cool. CHARLES: That's generally how it works. Metaprogramming is the program we do that we end up hating ourselves later for but it's really fun. LIZ: Yeah, they're like, "This is cool but this is not the most efficient to do this." It's like, "I guess, we don't have to dynamically create methods based on all our filenames. CHARLES: As far as the CSS goes, I actually see CSS like raw kale. It's actually really good for you, if you like to it eat in large quantities and it's like fantastic but it's not always the most pleasant going down. LIZ: It tastes bad. It has a terrible feel. It's like eating rubber. I am really lucky, though that I worked with a couple of people who are incredible at CSS and when I get to pair with them, it's like watching magic happen. CHARLES: Yeah, you realized, for all its quirks and strange ways that you approach it, is an outlier but it is kind of a fully-formed programming model that has a lot of depth and a lot of people have really, really generated some pretty neat abstractions and ways of dealing with CSS. But it is like, "I just want to fix this one thing," and it's basically a sea of things that I have no idea how to navigate. LIZ: It's one of those things. I always think it's funny, anyway that I come from a visual art background but the thing I like about programming is anything visual. CHARLES: That is actually really is fascinating. LIZ: Yeah, when they hired me here they're like, "You're going to be really good at design," and I'm like, "I just want to do programming." CHARLES: Like never the temptation, like this is just because you've actually kind of drank your fill of that in a past life? LIZ: I think I've talked to my coworker, Kristen about this because she actually has a design background and we paired together all the time. She's one of the people that I was talking about who are geniuses at CSS. She's a genius at it. She has a design background. We've talked about this how art and design are kind of different, like the brain stuff that I use to make a comic is really different from designing a book cover or designing an experience. It's all part of the art side of the brain but it's different compartments of the art side of the brain. I don't really have a design background as much as I have like a narrative and a drawing background. STEPHANIE: That and your interest for math that probably has a factor. LIZ: Yeah. STEPHANIE: Going back to your journey, I wanted to ask about it seems like it took you awhile to knock on different doors and finally feel like, "Now, I understand. How do I work with what I have to create a website?" We have similar backgrounds in that. We didn't start off in programming and I also went through a code boot camp. But mine was a little different where when I finish, I didn't really feel I understood what programming really was. I still felt like I understood a primitive level like just building something, just a 'Hello, World' using HTML CSS. When I finished, it took me a year and a half to actually get a full time programming job, like a legit job. Before that, I was scrambling doing three part time jobs and lots of WordPress grunt work. Even though I thought it was actual experience, it was enough experience but I feel like a lot of the programming concepts that I've had to learn and just basic functional programming, I've learned it on the job. I don't yet feel like I am a legit 'real programmer'. We were talking about the Pinocchio thing like, "I'm a real boy." But I want to be a real programmer. [Laughter] STEPHANIE: What I'm curious about is at what point did that happen? When did that click and when did you stop having -- I'm sure at some point you had -- impostor syndrome? When did that just evaporate and you're okay? LIZ: I still have impostor syndrome all the time. It's weird that it's like I have a sense of, "Oh, I can figure anything out." At this point, I know who to ask or where to look and I could figure anything out if I really wanted to. But I also feel like everyone else is better than me. I get impostor syndrome in that sense, not that I'm not a programmer but that everyone else is better than me. When did I start feeling like I was a real programmer? Definitely not at my first job. When I started my first job at SimpleReach in November 2014, I had two months in between bootcamp and the job. In that time, I made some weird little apps but nothing super serious. I made an app that I use the Twilio API to anonymously text Seal lyrics to people. It sends either lyrics from Kiss From A Rose or a fact about Kiss From A Rose. You can choose which one. I made stuff like that. CHARLES: [Singing in the tune of Kiss From A Rose] There's was so much in app can tell you so much it can touch. Okay, I'll stop. I'll stop right there. I promise. LIZ: Yeah, so I did stuff like that and I sort of wrote my own crowdfunding to go to RubyConf because I gotten an opportunity scholarship ticket that year. But I couldn't afford to go otherwise. I did a little crowdfunding thing but I did little things like that. I didn't really feel like I understood everything so I was looking on other people's code and forking stuff to make all that happen. Then I got my job and it was small-ish start up at the time and they didn't have a whole lot of on-boarding at all. It's kind of like I showed up, they gave me a computer and it took me three or four days to get their app running locally. It was just a lot of leaving me to my own devices a lot of the time in the beginning and I was kind of like, "I don't know what I'm doing. What do I do?" It took a while. As the company matured and as I matured as a programmer, they kind of develop a little more infrastructure, I guess for supporting junior engineers. As time went on, I became better and they became better at mentoring me. I don't know when I felt like a real programmer, probably sometime in the middle of that job. I gave my first technical talk, I guess or conference talk at EmberConf in 2015. I gave a lightning talk at the behest of the Leah who is now my boss. It was a five-minute talk on why testing an Ember sucked at that time. It sucked for me to learn and it was really hard. I wanted to learn it but it was really hard. Then after that, people started talking to me. They came up to me after and they are like, "Oh, my God. Blah-blah-blah." I was like, "I don't know half the stuff these people are saying. I don't understand what you're talking about." I'm going to smile and nod. But maybe a little bit after that, I kind of started feeling more that I could solve problems. I think public speaking actually helped me a lot with that like when I realized that I had something to say and that people want to hear it, then I could help other people feel empowered to learn stuff, I think that was part of it as well. CHARLES: Yeah, I really like that. Obviously, I'm going to push back a little bit on Stephanie, just in terms of the day-to-day. You definitely deliver daily as a programmer so you can look at that. You've mentioned this at the very beginning of your answer and it almost really sounds like what you came to be was more of a kind of a peace with the things that you didn't know, rather than feeling confident about the things that you did. You said something and I'm going to paraphrase it but it's like, "I got to the point where I became sure that I would be able to figure it out." Or, "I had strategies for being able to figure it out." Maybe we can unpack that a little bit because I feel that's actually very, very important and that's a skill that's important to have at any level of experience in your career, whether it's one year or whether it's 20. Certainly, that message when I saw you speak that's something that I took away as a very experienced developer. I felt actually empowered by it. What are some of those mechanisms to feel at peace with your own ignorance? LIZ: I think part of the problem for me, I started learning how to program before I went to dev bootcamp or whatever, that I was really good at stuff. I actually think that was a problem because I was used to succeeding immediately or like always doing everything right so it's hard when you start learning something and you don't realize when you first start learning programming and it's not supposed to work immediately, like you're starting with something that's broken and you're making it work. CHARLES: Right. In fact, 99% of the experience is like every time I look at a piece of software, I'm like, "Someone sat with the broken version of this for a year and then it work and that's what I got." They got to live with the working version for two seconds before it came to me and they spent the rest of the time, totally broken. LIZ: Yeah, totally. It's hard when you're used to creating something from scratch like doing comic books and like writing stories and stuff. It's never broken it's just blank and then you add to it so I'm used to that sort of workflow. Then I started in this new field where Rails is new or whatever then it's just errors as far as the eye can see until you fix it, until you configure it, you made it work. It's hard to change your mindset into that. It's easy to feel like a failure when all you see is errors and you don't know that that's normal. I helped a couple of my friends to learn to program and I think the biggest hurdle is just mentally overcoming that it's not you, you're not a failure. It's just that everything's broken until it's done. STEPHANIE: I can definitely relate to that. I was always one of those overachievers, straight A, AP class. I'm not even kidding. In my high school, they called me Hermione, which for those that don't know, that's the girl from Harry Potter. It's like you take it really personally when you feel like you're a failure. You feel like you can't deliver, you don't pull your own weight. For me, it's actually so overbearing that it can even inhibit you from doing things like public speaking or other activities. But one of the reasons why I do like to teach whenever I can is because that's when you realize, "I do know a lot of things," like how to do stuff on Git and just basic things that you don't even think twice about. I volunteered for this these high school girls and no one really gave me any instructions and I just rolled out of bed for this thing and just have them build a basic cute little web page with their picture and this and that. I had to really think hard to how do I put just a regular image tag and I had to peel back all the old layers of stuff that I don't do anymore. You don't think about those kind of things in Ember or JavaScript frameworks. I caught myself in keep on saying dom and this and that and they were like, "What is a dom?" And I'm like, "Urghh." But then I realized, I do have all this context, I guess I don't appreciate it or something. LIZ: I think talking to beginners when you're slightly above beginner-level in helping other fresh beginners is one of the best things for you as a new developer because you realized, you're like, "I actually know stuff." STEPHANIE: Yeah, that's usually the type of advice I like to give to other aspiring junior programmers. I also wanted to ask about it seems like now you're going through something similar because you tweeted or you're asking about systems programming. What's that like? LIZ: I'll start at the beginning. When I started at Tilde about a year ago, I knew that we use Rust, which is a systems programming language, a lower level language than Ruby or JavaScript. We use it for some aspects of our stacks. I thought, "That's really cool. I want to get into that nitty-gritty type of stuff so how do I learned that?” I started learning Rust but I didn't really know how to apply that knowledge. I wrote like a little adventure game in Rust and it was almost exactly the same as when I first started learning about web development, it's similar to how does this become a website, instead of like, "How does this become a computer thing?" I don't even know what systems programming is but I hear Rust is a systems programming language so I want to learn that stuff, like what is that stuff? A couple months ago, I think it was, I tweeted like, "Anybody have any probably three systems programming resources so I could learn more about systems programming?" And I got huge amount of responses. Everybody was super kind and helpful but a third of the responses were like, "Well, what kind of systems programming?" And I was like, "I..." [Laughter] CHARLES: "The kind that happens on a system?" [Laughter] LIZ: I don't know. It was kind of the same thing. I think I used this metaphor earlier but it's similar to when I first started learning programming it was like I was standing at the front of a forest and I knew that the stuff I want is in the forest but I don't even know what a tree is, you know what I mean? Eventually, I learned what a tree was then I learned what a map was and I learned how to get through that forest. But then in the middle of that forest, I was like, "Oh, there's a tunnel," like there's another stuff. "I want to get on to this tunnel," but I don't know anything about living underground, you know what I mean? Like, "What do I need? What even is there?" I have no idea so that's kind of how I feel about systems programming. At the moment, I'm trying to go into this tunnel but can I breathe down there? I don't know. Where does it lead? CHARLES: I feel like at that point when you're about to enter into the tunnel, can you intentionally apply filters for information that at that point is not useful like the difference between a stalactite and stalagmite is not useful when you haven't even gone into the cave yet and you're just like, "How do I actually just get down there with a flashlight?" How do you go about deciding which information is useful and which is not at your particular stage? Because obviously, it's all going to be useful at some point but at what point it becomes useful and what point do you just catalog it and put it for later? I feel like that's very, very hard thing to do. Do you feel like you're able to do that? LIZ: I'm not sure. I think I said this earlier but I feel like I can figure most things out at this point like if I really want to. One of the things I learned just from talking to people on Twitter about systems programming is like, "Oh, some examples of systems programming are operating system," or like a browser engine because I'm still learning Rust and I gotten to write as much lately but I know that there is servo which I believe is a browser rendering engine written in Rust, it's something like that. CHARLES: Supposedly it's going to powering Firefox at some point. LIZ: Yeah, stuff like that, I think is really interesting but now I know a little more about what to look at in terms of as far as I understand, there is probably an infinite amount of different kinds of systems: operating systems is one, maybe a browser engine is another. I can't remember the others but I'm sure people tweeted it out to me. STEPHANIE: I feel like we touched on something which is it can get overwhelming when you're starting off in something new. Trying to understand what you don't know that you don't know. LIZ: Yeah, that's the hardest thing. STEPHANIE: How can you make tangible goal marks for yourself if you don't even know what you don't know? When I first started off, when I would pair with someone that was more advanced, I remember having a realization that every time I would look for an add-on or I'm looking at someone's repo, I would take my time to read everything about it, all of the Ember documentation and I need to know everything. Then later I realized that is totally not the case. Like Charles said, people develop this filter for noise and only focusing on not the entire tool box but that one tool that they need for that one specific thing that they're doing and I realized it only when I was pairing with people and seeing that. They go to this repo, skim it, "No, this is not what we need. Let's go to the next one. Let's try to find a method that what we need," and then they would just search on the page. "Oh, this looks kind of similar. Let's plug this in," and I'm just like, "What? You can do this? You can just copy/paste someone else's stuff?" and it was amazing. But when you're starting out, you don't know all of these things and unfortunately, kind of waste a lot of time thinking that you need to know everything and you don't. CHARLES: Yeah, Cheating is totally a virtue in so many cases. [Laughter] LIZ: Totally, for sure. CHARLES: Just being like, "I don't need to understand this," but I just know that it works. You pushed at what point that happens like further and further back but that boundary of understanding is just simply always going to be there. No matter where you are, that kind of veil of ignorance, you can push it out but it's just can be further away. I am actually curious, you mentioned you got really into math, this is when you went back to school. What drew you to that and how have you applied, if you've applied? Have you found it to be an asset in your development career? LIZ: For sure. When I first went back to school, it was with the idea that this is totally different now, obviously. I thought I might become a veterinarian -- CHARLES: You need a lot of math for that, right? LIZ: Well, it's like a lot in biology and there's a lot of math and science and stuff. I had to take a bunch of science classes and take biology and chemistry so that involved taking some pre-calculus and calculus and more calculus. What I realized, though was that I hated biology and chemistry but I love the math that I was learning. I loved the process of problem solving and just figuring out puzzles. When you get into calculus, how you solve problems, they're similar to how you solve problems in programming where you have sort of a framework like I have this certain language which would be the different theorems or whatever in math and you can just pick and choose which ones will fit your problem and if you're taking a calculus test, you could be sitting next to the same person and you might come to the same answer in different ways so it's similar in programming where you have all of this documentation, you have these languages, you have use other frameworks and you can solve the same problem in a million different ways. But in terms of how people talk about needing math for programming, I don't necessarily think you need math for programming but if you already like math, it's definitely sort of a happy path, I guess because you get the same joy out of programming that you get out at solving calculus problem. But if you don't like calculus, it's okay. I don't think it's necessary. CHARLES: One of my favorite blog posts of all time is this letter to young Haskeller, I don't know if any of you guys have ever read that. It's fantastic and it's an experienced person in the Haskell community talking to someone who's just coming in and it's incredibly empathetic and wonderful. I think it's a message that needs to be heard more generally. I think it's ironic coming out of the Haskell community as it does because they definitely have a reputation for being a little bit salty and a little bit exclusive. But it's actually a very inclusive message. One of the great points they make is they say we've got the whole equation reversed. It shouldn't be, "Math is hard, therefore programming is hard." It should be, "Programming can be really fun, therefore math on which programming is based, can also be really fun." You can go both ways. If you find math fun, you can find programming fun and if you find programming fun first, you can later go and have fun with math. You can pick and choose which parts you want. I think it's a great message that needs to get out there. LIZ: I think it's also really, really important to note for anyone who might be listening that is getting in to programming, that is scared of math or has had a bad experience with math that it is not necessarily to love math. I think that scares a lot of people away and a lot of the stuff that people learn when they're first learning programming are math based. When I was in the Flatiron School, Some of the exercise we did in the beginning with just pure Ruby were Fibonacci sequence. They were sort of math-y and that turns a lot of people off and makes people scared. If someone is hearing this and has experienced that, don't be scared. You don't need to worry about it. But if you love math, then it's great but you don't have to. STEPHANIE: I'm one of those people that always had this mental block of like, "I'm not good at math." I was good at everything in school. I excelled at everything except math. I think a lot of it came from my struggle when I was a kid so you have this self-perpetuating thought that you aren't good at something. Every time you take a final or something, you blank out because you have this mental wall in your mind. What I found weird was I was doing the exact same thing. I was taking calculus for bio-sciences and physics too at the same time. In physics, I loved that class. It was so awesome and I realized that half the stuff I was doing was going backwards in all of my problems and it was fun for me. Eventually, I was taking a final for my calculus class and I didn't remember the equation that we needed for that class so I took out all the variables and I solved it as if it's a physics problem and I got the same answer and I was correct. I realized at that moment, if you just remove the negativity from your mind and you try to apply yourself in the same fashion as you would in something that you enjoy, you'll just forget for the moment that it's math, that it's something that you 'suck at'. You actually could do good in it and not get stuck. I realized I actually do like math when it's veiled as chemistry or physics. LIZ: I think a lot of people have that experience with math. They have a really bad experience when they're young and then they get stuck and they feel like they're just not good at it like somehow, on this subatomic level, you just can't change it or you're not good at it. It's not really true. STEPHANIE: Yeah. CHARLES: I actually love that example because it is, it's all integrated. We are constantly doing things like math without even realizing it. Actually, one of the things I love about the Montessori education is that's the way they actually teach it. They have all of the different great lessons, they want to convey to the children which is things like courtesy and grace, things like taking care of your things, things like music. But for all, I think they've got a bunch of different categories but they make sure that they always intersect with each other and you get that in surprising ways to make sure that if a child likes music, use the music as a way to introduce them to arithmetic. If they like arithmetic, use that as a way to introduce them to music. If they have things doing design, I don't want to say, interior designer or clothing design but practical life stuff and if that's something that a child really is drawn to, then they'll use that as an introduction to music or geography. There's all these parallels that are constantly there and you can ride whichever rail works for you to whatever area that you want to go. There is no set way to approach math. You literally can find a way that works for you. STEPHANIE: The subjects aren't mutually exclusive, "Because you're not good at this, probably you shouldn't become a programmer." CHARLES: It's not expected that every child will grow in one subject at the same rate that they'll grow in every other subject. They just let the children explore the area that they're interested in and let them go crazy. If they're really into art, they just let them explore and learn as much as they can and then slowly entice them and just show them the connections that art has to courtesy and grace to math to music to other things and let them see those connections and then follow them on their own. That's why they call it -- the kind of grown up in there -- the guide. It's really there. The way that they push is by showing them the connections but then using the kind of internal motivations of the children to move. I actually have some pretty strong feels on this. I feel like our education does leave a lot of people behind because there's this expectation that in every single subject, everybody will goose step forward at exactly the same rate and that's just a fable. It's not real. It's not how the human mind works. LIZ: Yeah. CHARLES: But yeah, I actually think, certainly for me and my connection to math has been helped by the fact of programming and now, later on after having done a lot of programming, so much more is interesting to me about math and I can see beauty in it, I think where I didn't see beauty in it before. STEPHANIE: For one of the projects that we've been working on, we have been doing an Ember upgrade. I basically needed to get some changes for one of the dependencies and I have no experience in open source, whatsoever. That happened for the past two weeks. I was making a lot of PRs to two different dependencies and that was my first experience with open source. It was less scary than I had imagined and I actually got a lot of great feedback from it. Now, I realized that it wasn't as hard as I thought it would be and most people are very receptive to your PRs or if you have questions about their open source because they need help, they need people to help them tackle all the issues that they have so I'm curious, do you have any advice for people that are interested in contributing to open source but they may find it daunting and they don't want to look dumb or do things the wrong way? LIZ: One of the things I've been interested in since I started learning programming is open source because I enjoy collaborative atmospheres and just the idea of a big group of people coming together to solve problems. It was something that I wanted to do since the beginning but it's super intimidating because when you think of people who are open source maintainers, at least to me in the beginning, they seemed way above me like Gods so I'm like, "How can I possibly be useful to these Gods?" At my last job, my manager was like, "I got a couple of goals for you and for your career." One of my goals was I want to contribute To Ember CLI Mirage. That was a goal. I just thought, "This is a great add-on. This is a great project and everyone uses it and I love it and I would love to contribute to that." I made it a goal but then in that in the middle of that time period, I got a job here at Tilde and I went to Portland. Shortly after that, I went to the repo and I was like, "I'm going to do this thing," because one of the reasons why I chose it as a project to contribute to is because I heard Sam is a really nice guy. One of the things was that I was really intimidated by the people maintaining projects is like, "Well, he's not intimidating." I feel okay about this so that's a good first step. The second step is let's find a thing to do so I look at all the issues on the repo and I find something super simple which is just adding in-line documentation. That's what I did and I was like, "Can I pick this up?" I was feeling super shy so I didn't even want to put it on the issues so I think I just pinged him on the Ember Slack and just like, "Can I help with this?" He's like, "Yeah, yeah. That's great," so I made a bunch of in-line documentation additions to the project and I made my first PR and it felt like such a way that it's not as scary at all as I thought it would be so I started contributing to other projects, things that just came up. Not so much like in your situation where it was a dependency I was using but more like I saw somebody tweet about it and like, "I just made this project and I think there's a bunch of typos. Can somebody just spell-check this for me?" I'll go in and do a couple of typo fixes. Another situation when I was reading through a repo because I want to learn and there's a project called intermezzOS which is Rust operating system, like a tiny operating system. I was just reading the code and I was like, "There's a couple of typos. I can fix this," and stuff like that and I found, through that experience, that open source maintainers are super happy to have you help in any way that you can, even if it's a little things. In the last couple of months, I started my own project which is like an app -- it's not an add-on or anything. I actually got my first couple of PRs from other people and other people are helping me build it. I don't think I've ever met but every time I get a PR, I feel like I won a prize. Every time someone contributes and I'm like, "Thank you." I cannot give you another -- [Laughter] LIZ: I love that you're helping me. You know, like I only have one hour a day to work on this thing so anything, anyone people can do to help me is so great. Now I have the experience of being on the other side and I can attest to the fact that most open source maintainers are incredibly stoked for any help they can get. Even if you're new, just find someone who's nice and ask them how you can help. STEPHANIE: Yeah, that was a realization that I had because I was communicating directly with this person in the Ember Slack as well. I had submitted a PR and later he was like, "Hey, while you're at it, do you mind adding in this one property that's missing?" And I'm just like, "All right. Sure." Later he offered if I wanted to become a collaborator because I was putting in so many PRs and like you said, he hasn't had the time to cut out a new version or to fix the things that you keep in your head, "Okay, I'm going to go back and fix this," and then someone else is like, "I want to fix this thing," go for it. That's the best. LIZ: Yeah, totally. It's a great way to learn more stuff too. CHARLES: I like the point about choosing a project that you know is not intimidating because unfortunately, there is a lot of negativity that happens out there. LIZ: Totally, I knew that and that was a big blocker for me, for a long time. CHARLES: Yeah but knowing that there are actual, I would like to say, a majority I don't know if that's true but it can feel like it's enclaves, just because negativity has a way of clouding everything and propagating but there are certainly areas where we put that way and it's very healthy, it's very collaborative and welcoming and making a definitive effort to first know that they're out there because if you have a negative experience, you make sure that you don't bounce off of that and then define them. I really like that, how you were deliberate about that. LIZ: Yeah, it seems like the most important thing, if you're a new programmer and they're like, "How do I get involve in open source," and your first advice is like, "Find someone who's really nice." It doesn't sound like the right advice but I think it is the right advice. CHARLES: That's because that's where you'll stick. LIZ: Yeah and you'll want to collaborate with that person and that project because you're not scared of being insulted or something. CHARLES: Well, that was fantastic. We can wrap it up. LIZ: I have two talks this year so far coming up. One is going to be in Toronto at the end of this month at a new conference called 'Hello, Con!' I built a type space adventure game in Rust and I built it side by side with the same game in Ruby so I can learn Rust by doing the same thing on both sides. I'm going to be talking about the similarities and differences and things I came across learning Rust as a Rubyist. I also have a similar talk in May at OSCON in Austin about learning Rust as a Rubyist but at a slightly different, longer talk. I did a version of it at RustConf last year. It's kind of in comic book form so it's all of drawings and it's sort of a story about going to a place called Rustlandia as a Ruby person and how you literally navigate that world, not just everything is sort of a metaphor. I'm getting that talk again in a longer form at OSCON in Austin in May. CHARLES: Well, fantastic. You have to stop by the office and come see us. LIZ: Yeah. CHARLES: But thank you so much -- LIZ: Thank you. CHARLES: -- Liz for taking the time to talk with us. This is a great conversation again. You know, I feel like I'm going to come away feeling that I've got more tools to deal, certainly with my daily struggles -- LIZ: Yeah, get pumped! CHARLES: -- In programming. Yeah. LIZ: Programming! Yeah! [Laughter] LIZ: -- One of the Mortal Kombat music comes in -- Tun-tun-tun-tun-tun-tun-tun-tun-tun... [Laughter] CHARLES: I remember actually seeing Mortal Kombat in a theater and I actually getting up and dancing in the theater and then the rest of the movie just sucked. It was like they spent the whole budget on the first 20 seconds of that movie. Anyhow, all right. That's it from The Frontside. Remember to get in touch with us at Frontside.io, if you're interested in UI that's engineered to make your UX dreams come true.