Podcasts about pojo

Sometimes... it's not worth a phone call. Enough about Lekter's beautiful baby Pojo, it's AJ's time for a new family addition!

The first introduction of the newest Cabin Family member (definitely not the second time) Porter John Scott Lekteman-Garbutt! Pojo, if you're listening to this in your later years just know... we'll do better next time.

Dans ce long…. épisode, Emmanuel, Guillaume et Arnaud discutent de l'actualité avec Chicori (un runtime WASM en Java), Jakarta Data, Quarkus 3.10, Spring AI, Hibernate 6.5, mais aussi quelques retours aux basiques (timezones, rate limiting, …). Gros focus sur les nouveautés annoncées à Google I/O 2024 et dans l'écosystème IA en général avec les annonces d'OpenAI, Claude, Grok et d'autres. Différents outils sont aussi couverts comme Git, IntelliJ, ASDF, BLD, S3. Et enfin des sujets sur la haute disponibilité de Keycloak, la ré-indexation sans downtime, les challenges des implémentations alternatives, le mode vigilant dans GitHub, Redis et les changements de license, et les investissements de Microsoft et AWS en France dans le cadre du programme #ChooseFrance. N'hésitez pas à nous soumettre vos questions sur https://lescastcodeurs.com/ama nous y répondrons dans les prochains épisodes. Enregistré le 17 mai 2024 Téléchargement de l'épisode LesCastCodeurs-Episode-312.mp3 News Langages Un runtime WASM en Java https://github.com/dylibso/chicory Projet tout nouveau, encore loin de la maturité Mais intéressant à suivre pour exécuter du code WebAssembly dans une application Java le projet n'a pas 15 jours non plus quand même :) Faire tourner des plugins WASM dans la JVM (e.g. plugins) On peut faire des heap dump en cas de OutOfMemoryException en compilation native https://quarkus.io/blog/heapdump-oome-native/ depuis JDK 21 Un exemple avec Quarkus Et le GC epsilon 100 exercices pour se mettre à Rust https://rust-exercises.com/ Librairies Hibernate 6.5 est sorti https://in.relation.to/2024/04/25/orm-650/ cache full pour les entités et leur collections (le défaut est shallow) Java record pour les @IdClass Les filtres peuvent être auto activés par défaut (vs à faire sur chaque session). Les filtres sont pas mal pour gérer par exemple des soft delete Keybased pagination pour éviter les trous de résultant en cas de modification d'entités en parallèle de.une recherche paginée. S.appuie sur une clé unique et ordonnée genre ISBN Une tech preview de Jakarta Data En parlant de Jakarta Data, deux articles sur le sujet https://in.relation.to/2024/04/01/jakarta-data-1/ https://in.relation.to/2024/04/18/jakarta-data-1/ concept de repository pas lié à une entité mais à une relation logique entre les recherches interagit via stateless session et est un bean CDI Code généré bien sur 4 opérateur crud et les requêtes save est up sert Type sage au sens ou le nom des méthodes n'est pas la logique de recherche Annotation et nom des paramètres et c'est type safe via un annotation processor ou string dans @Query qui est type safe aussi via le processeur discute plus de type safety et pagination Quarkus 3.10 avec quelques nouveautés https://quarkus.io/blog/quarkus-3-10-0-released/ flyway 10 arrive avec support natif Hibernate search supporte le standalone POJO mapper notamment pour elastic search (pas que ORM) Modification des propriétés Quarkus.package automatiquement remplacées par quarkus update et Quarkus 3.9 a fait son grand renommage réactif https://quarkus.io/blog/quarkus-3-9-1-released/ Clarifier que les extensions réactive n'imposent pas des apis réactives et seulement leur cœur implémenté en réactif ou offre optionellement des apis reacrive Les gens pensaient à tors que les réactives imposaient le modèle de programmation la encore quarkus update à la rescousse Un article sur l'api structured output pour Spring AI https://spring.io/blog/2024/05/09/spring-ai-structured-output un article descriptif sur quand cette api est utilisée Et les détails de son usage Comment passer une TimeZone dans spring boot et ce que cela impacte en terme de composants https://www.baeldung.com/spring-boot-set-default-timezone du basique mais toujours utile Task ou app Programmatiquement Sur certains lifecycles de Spring Infrastructure Un article et la vidéo de Devoxx France sur la haute disponibilité de Keycloak, comment c'est implémenté https://www.keycloak.org/2024/05/keycloak-at-devoxx-france-2024-recap l'infra d'identité est une infra clé Donc gérer la haute disponibilité est critique C'est un article qui pointe sur une vidéo de Devoxx France et la doc de keycloak sur comment tout cela est implémenté Cloud Comment se ruiner avec des buckets S3 https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-can-make-your-aws-bill-explode-934a383cb8b1 Amazon fait payer pour les requêtes non autorisées Il suffit de connaître le nom d'un bucket pour faire payer son propriétaire Amazon travaille pour fournir une solution / un fix. il est tombé par hasard sur un nom de bucket utilisé « pour de faux » par un outil open source populaire Bien rajouter un suffixe à ses buckets peut réduire le risque Mais pas l'éliminer un fix a été livré par amazon https://aws.amazon.com/about-aws/whats-new/2024/05/amazon-s3-no-charge-http-error-codes/ Data et Intelligence Artificielle Guillaume résume GoogleIO https://x.com/techcrunch/status/1790504691945898300?s=61&t=WImtt07yTQMhhoNPN6lYEw AI overview plus besoin d'aller sur les sites Google I/O 2024 Google I/O 2024 résumé en vidéo de 10 minutes https://www.youtube.com/watch?v=WsEQjeZoEng et en 100 bullet points https://blog.google/technology/ai/google-io-2024-100-announcements/ Message de Sundar Pichai https://blog.google/inside-google/message-ceo/google-io-2024-keynote-sundar-pichai/#creating-the-future Project Astra, un assistant universel, sur smartphone avec qui on peut avoir une conversation normale et à qui montrer avec la caméra ce qui nous entoure https://www.theverge.com/2024/5/14/24156296/google-ai-gemini-astra-assistant-live-io Nouveau modèle Gemini 1.5 Flash, quasi aussi performant que le nouveau Gemini 1.5 Pro, mais beaucoup plus rapide (premiers tokens dans la seconde) et aussi moins cher https://blog.google/technology/developers/gemini-gemma-developer-updates-may-2024/ Gemini 1.5 Pro est Gemini 1.5 Flash sont disponibles avec une fenêtre de contexte d'un million de tokens, mais il y a une liste d'attente pour tester une fenêtre de 2 millions de tokens https://aistudio.google.com/app/waitlist/97595554 https://cloud.google.com/earlyaccess/cloud-ai?e=48754805&hl=en PaliGemma un nouveau modèle de vision ouvert dans la famille Gemma (pour faire du Q&A du sous-titrage) et preview de Gemma 2, avec une version à 27 milliards de paramètres https://developers.googleblog.com/en/gemma-family-and-toolkit-expansion-io-2024/ Gemini disponible dans les IDEs : Android Studio, IDX, Firebase, Colab, VSCode, Cloud and Intellj Gemini AI Studio enfin disponible en Europe Gemini supporte le parallel function calling et l'extraction de frame dans les vidéos Trillium, la 6ème version des TPU (Tensor Processing Unit), les processeurs spécifiques ML dans Google Cloud, 5 fois plus puissant que la génération précédente et 67% plus efficace en énergie https://cloud.google.com/blog/products/compute/introducing-trillium-6th-gen-tpus Le projet NotebookLM rajoute une fonctionnalité de Audio Overview qui permet de discuter avec son corpus de documents avec une conversation vocale https://notebooklm.google.com/ On peut appliquer le “grounding” avec Google Search pour l'API Gemini, pour que le modèle Gemini puisse chercher des informations complémentaires dans Google Search https://cloud.google.com/blog/products/ai-machine-learning/vertex-ai-io-announcements Annonce de Imagen 3, la future version de du modèle de génération d'images Imagen qui améliore la qualité et possède un très bon support du texte dans les images (objectif de disponibilité à l'été) https://blog.google/technology/ai/google-generative-ai-veo-imagen-3/#Imagen-3 https://deepmind.google/technologies/imagen-3/ DeepMind annonce Veo, un nouveau modèle de génération de vidéo très convaincant qui peut faire des vidéos en 1080p de 60s, mais en combinant plusieurs prompts successifs, il peut générer des vidéos plus longues qui s'enchainent https://deepmind.google/technologies/veo/ VideoFX, ImageFX et MusicFX, des expérimentations de Google AI intégrant Imagen 3 et Veo (pas encore disponibles en Europe) https://blog.google/technology/ai/google-labs-video-fx-generative-ai/ Gemini Advanced https://blog.google/products/gemini/google-gemini-update-may-2024/#context-window Les utilisateurs de Gemini Advanced (l'application web) utilisent Gemini 1.5 Pro avec la fenêtre de contexte de 1 million de tokens, la possibilité de charger des documents de Google Drive, et bientôt la possibilité de générer des graphiques. Gemini Advanced rajoute aussi la capacité de générer des itinéraires de voyage (avec intégration de Google Flights, etc) Fonctionnalité Gemini Live pour avoir une conversation vocale naturelle avec Gemini https://blog.google/products/gemini/google-gemini-update-may-2024/#gemini-live Gem : des plugins pour Gemini Advanced pour créer ses propres assistants personnalisés https://blog.google/products/gemini/google-gemini-update-may-2024/#personalize-gems Ask Photos, on peut poser à Google Photos des questions plus complexes comme “quelle est ma plaque d'immatriculation” et Photos devine que parmi toutes les photos de voitures lequelle est certainement la nôtre et extrait le numéro de plaque https://blog.google/products/photos/ask-photos-google-io-2024/ Même dans Google Messages vous pourrez échanger avec Gemini Google Search https://blog.google/products/search/generative-ai-google-search-may-2024/ Rajout d'un modèle Gemini spécial search intégré qui permet à Google Search de répondre aux questions de la barre de recherche avec une raisonnement multi-étapes, en étant capable de faire de la planification, en mode multimodal (texte, image, vidéo, audio) Planning de repas et de voyage, supporté dans Gemini, va arriver aussi dans Search Gemini 1.5 Pro est disponible dans le panneau latéral de Gmail, Docs, Sheets, Drive https://blog.google/products/workspace/google-gemini-workspace-may-2024-updates/ SynthID va même fonctionner pour du texte https://deepmind.google/discover/blog/watermarking-ai-generated-text-and-video-with-synthid/ Gemini Nano bientôt disponible dans les prochaines version de Chrome, pour utiliser le LLM directement dans le navigateur Android Seconde béta d'Android 15 https://android-developers.googleblog.com/2024/05/the-second-beta-of-android-15.html Private space pour garder des apps secures avec un niveau d'authentification supplémentaire Google collabore avec Samsung et Qualcomm sur la réalité augmentée dans Android https://developers.googleblog.com/en/google-ar-at-io-2024-new-geospatial-ar-features-and-more/ Project Gameface arrive sur Android (pour diriger Android avec les yeux, avec les expressions du visage, pour l'accessibilité) https://developers.googleblog.com/en/project-gameface-launches-on-android/ Gemini Nano va passer en multimodal, pas juste du texte Circle to search étendu à 100 millions de téléphones supplémentaires supportant Nano et va permettre de poser des questions, par exemple pour l'aide aux devoirs des enfants https://blog.google/products/android/google-ai-android-update-io-2024/#circle-to-search Detect phone scam on device with Gemini Nano Talkback, l'application pour l'accessibilité dans Android, va tirer parti de la multimodalité de Gemini Nano Bientôt de la génération d'image qu'on pourra intégrer dans ses mails, ses messages Wear OS https://android-developers.googleblog.com/2024/05/whats-new-in-wear-os-io-24.html Travail sur l'économie d'énergie pour faire durer les montres plus longtemps avant la prochaine recharge. Par exemple, 20% de consommation en moins lorsqu'on court un marathon ! Plus de type de données pour les activités physiques Project IDX accessible sans liste d'attente https://developers.googleblog.com/en/start-building-with-project-idx-today/ Firebase annonce 3 nouveaux produits https://developers.googleblog.com/en/whats-new-in-firebase-io-24/ Data Connect, un backend-as-a-service avec PostgreSQL https://firebase.google.com/products/data-connect App Hosting, hosting d'application Next et Angular https://firebase.google.com/products/app-hosting Genkit, a GenAI framework for app developers https://firebase.google.com/products/genkit Dart 3.4 avec support de Wasm comme target de compilation https://medium.com/dartlang/dart-3-4-bd8d23b4462a OpenAI lance son nouveau modèle: gpt-4o http://openai.com/index/hello-gpt-4o/ https://x.com/openaidevs/status/1790083108831899854?s=46&t=GLj1NFxZoCFCjw2oYpiJpw Audio, vision et reconnaissance de texte en realtime Plus rapide et 50% moins cher que son prédécesseur 4-turbo https://claude.ai/ est disponible en europe Claude, le modèle est créé par Anthropic: Claude est un assistant IA basé sur un grand modèle de langage entraîné selon des principes éthiques stricts. Il accorde une grande importance à l'honnêteté, l'impartialité et le respect de l'être humain. Son raisonnement repose sur une compréhension profonde des concepts plutôt que sur de simples associations statistiques. Il cherche activement à corriger les éventuels biais ou erreurs. Claude est polyvalent et peut s'adapter à différents styles de communication et niveaux de complexité selon le contexte. Il maîtrise de nombreux domaines académiques et scientifiques. Il est capable d'introspection sur ses propres processus de pensée et ses limitations. La vie privée et la confidentialité sont des priorités pour lui. Claude continue d'apprendre et de s'améliorer grâce aux interactions avec les humains. Son but est d'être un assistant fiable, éthique et bienveillant. quelqu'un sait comment ils font pour raisonner et pas juste LLM statistiquer? Comment ils prouvent cela ? C'est du code à part? Grok le modèle de X/Twitter/Musk est aussi dispo en Europe https://x.com/x/status/1790917272355172401?s=46&t=GLj1NFxZoCFCjw2oYpiJpw un truc unique c'est qu'il utilise les tweet comme reference sur ce qu'il dit. Par exemple demande les meilleurs Java Champions et c'est sur les tweet recents , probablement une sorte de RAG ou une sorte de fine tuning sur les derniers tweets, je ne sais pas L'algorithm des modeles de diffusion expliqués https://x.com/emmanuelbernard/status/1787565568020619650 deux articles, un general et lisible l'autre plus abscon mais avec certains details interessants sur le downsizing étapes ajout de bruit à des images (learning) pour après appliquer le process opposé le reverse diffusion process On prédit le bruit à enlever, on l'enlève et on repère le processus. Et tout cela est influencé par le prompt. Reindexation sans downtime des données de documentation de Quarkus, en quarkus bien sûr https://quarkus.io/blog/search-indexing-rollover/ utilise hibernate search Utilisé Elasticsearch / opensearch Article qui explique une des approches pour reindexer sans downtime via index alias Outillage Un article qui parle de l'outil de build bld, peu connu, qui permet d'écrire ses builds simplement dans une classe Java https://sombriks.com/blog/0070-build-with-bld-and-why-it-matters/ IntelliJ 2024.1 est sorti https://blog.jetbrains.com/idea/2024/05/what-s-new-in-intellij-idea-ultimate-2024-1/ complétion de ligne entière (deep learning) Assistant AI amélioré Spring Boot support amélioré sur bean completion et génération de diagramme Support de dev containers simplifié Amélioration support quarkus avec notamment icône dev ui et config des tests Support OpenRewrite Server wiremock et plein d'autres choses En version beta public, Homebrew permet de vérifier la provenance des packages (bottles) https://blog.trailofbits.com/2024/05/14/a-peek-into-build-provenance-for-homebrew/ Basé sur le système “build provenance” de sigstore https://docs.sigstore.dev/verifying/attestation/#validate-in-toto-attestations qui repose sur les attestations in-toto https://in-toto.io/ Mettez à jour git en version 2.45.1 pour fixer des failles de sécurité https://github.blog/2024-05-14-securing-git-addressing-5-new-vulnerabilities/ CVE-2024-32002 (Critique, Windows & macOS) : Les repos Git avec des sous-modules peuvent tromper Git pour lui faire exécuter un hook (élément de script) à partir du répertoire .git/ pendant une opération de clonage, permettant l'exécution de code à distance (Remote Code Execution). CVE-2024-32004 (Important, machines multi-utilisateurs) : Un attaquant peut concevoir un repo local qui exécute du code arbitraire lors du clonage. CVE-2024-32465 (Important, toutes les configurations) : Le clonage à partir de fichiers .zip contenant des repos Git peut contourner les protections, et potentiellement exécuter des hooks malveillants. CVE-2024-32020 (Faible, machines multi-utilisateurs) : Les clones locaux sur le même disque peuvent permettre à des utilisateurs non approuvés de modifier des fichiers liés physiquement (hard link) dans la base de données des objets du repo cloné. CVE-2024-32021 (Faible, machines multi-utilisateurs) : Le clonage d'un repo local avec des liens symboliques (symlinks) peut entraîner la création de liens physiques vers des fichiers arbitraires dans le répertoire objects/. Architecture Visualisation des algorithmes de rate limitation https://smudge.ai/blog/ratelimit-algorithms Méthodologies Le problème de l'implémentation alternative https://pointersgonewild.com/2024/04/20/the-alternative-implementation-problem/ Article par un développeur qui a développé des Just-in-Time compiler pour différents langages Remarqué que développer une implémentation alternative d'un langage (par exemple) n'a jamais vraiment rencontré le succès Les gens préfèrent l'original à une alternative qui est dépendante de / a peine à suivre l'implémentation d'origine Pour son cas, sur le JIT, il a travaillé sur un JIT intégré directement dans CRuby (plutôt que faire son implémentation alternative comme TruffleRuby), et sont JIT est intégré maintenant dedans directement Plus facile de rejoindre / s'intégrer au projet plutôt que d'être une alternative pour laquelle il faut convaincre les gens de l'adopter Le mode vigilant dans GitHub https://x.com/emmanuelbernard/status/1790026210619068435 c'est la suite du blog wsur la signature des commits que j'ai fait ul y a quelques temps https://emmanuelbernard.com/blog/2023/11/27/git-signing-ssh/ Maintenant, GitHub rajoute de plus en plus d'infos si les signatures ne matchent pas ou ne sont pas présentes Loi, société et organisation Une perspective sur Redis et les changements de license par un devrel AWS OpenSearch https://www.infoworld.com/article/3715247/the-end-of-vendor-backed-open-source.html les sociétés regardent l'impact légal des licenses source available pour elles même en usage interne Ça casse l'écosystème de spécialisations au dessus du produit (logz.io au dessus d'elastic démarré avant le changement de license) Redis top 10 contribs à AWS et Alibaba er Huawei et 3 redis. Donc c'est pas redis qui contribue tout. La plupart des ingénieurs de redislab ne bossent pas sur redis OSS, mais sur cloud et entreprise Peut être la fin des single vendor oss Il n'y a que les cloud providers qui peuvent fournir du OSS sans affecter leur structure du coût C'est un ex AWS en fait. Maintenant indépendant Microsoft va investir 4 milliards en France (datacenters et IA) https://news.microsoft.com/fr-fr/2024/05/13/microsoft-announces-the-largest-investment-to-date-in-france-to-accelerate-the-adoption-of-ai-skilling-and-innovation/ Il ne sont pas les seuls dans le cadre du programme #chooseFrance https://www.info.gouv.fr/actualite/choose-france-un-record-de-15-milliards-deuros-dinvestissements-etrangers Mais cela n'est pas sans laisser de questions sur l'avenir de notre activité avec les US qui externalisent désormais leur silicon valley https://www.cybernetica.fr/la-france-laboratoire-de-la-silicon-valley-2-0/ Outils de l'épisode ASDF un gestionnaire de version multi-runtime https://asdf-vm.com Arnaud l'avait recommandé mais je restais sur rvm apres des deboires, je suis passé a asdf, qui fonctionne mais pour le jdk j'utilise sdkman pour les javaistes ca parrait plus poussé Conférences Les videos de Devoxx France sont en ligne https://www.youtube.com/playlist?list=PLTbQvx84FrARars1vXos7mlPdvYJmsEoK La liste des conférences provenant de Developers Conferences Agenda/List par Aurélie Vache et contributeurs : 16-17 mai 2024 : Newcrafts Paris - Paris (France) 22 mai 2024 : OpenInfra Day France - Palaiseau (France) 22-25 mai 2024 : Viva Tech - Paris (France) 24 mai 2024 : AFUP Day Nancy - Nancy (France) 24 mai 2024 : AFUP Day Poitiers - Poitiers (France) 24 mai 2024 : AFUP Day Lille - Lille (France) 24 mai 2024 : AFUP Day Lyon - Lyon (France) 28-29 mai 2024 : Symfony Live Paris - Paris (France) 1 juin 2024 : PolyCloud - Montpellier (France) 6 juin 2024 : WAX 2024 - Aix-en-Provence (France) 6-7 juin 2024 : DevFest Lille - Lille (France) 6-7 juin 2024 : Alpes Craft - Grenoble (France) 7 juin 2024 : Fork it! Community - Rouen (France) 11 juin 2024 : Cloud Toulouse - Toulouse (France) 11-12 juin 2024 : OW2con - Paris (France) 11-12 juin 2024 : PGDay Lille - Lille (France) 12-14 juin 2024 : Rencontres R - Vannes (France) 13-14 juin 2024 : Agile Tour Toulouse - Toulouse (France) 14 juin 2024 : DevQuest - Niort (France) 18 juin 2024 : Mobilis In Mobile 2024 - Nantes (France) 18 juin 2024 : BSides Strasbourg 2024 - Strasbourg (France) 18 juin 2024 : Tech & Wine 2024 - Lyon (France) 19-20 juin 2024 : AI_dev: Open Source GenAI & ML Summit Europe - Paris (France) 19-21 juin 2024 : Devoxx Poland - Krakow (Poland) 26-28 juin 2024 : Breizhcamp 2024 - Rennes (France) 27 juin 2024 : DotJS - Paris (France) 27-28 juin 2024 : Agi Lille - Lille (France) 4-5 juillet 2024 : Sunny Tech - Montpellier (France) 8-10 juillet 2024 : Riviera DEV - Sophia Antipolis (France) 6 septembre 2024 : JUG Summer Camp - La Rochelle (France) 6-7 septembre 2024 : Agile Pays Basque - Bidart (France) 17 septembre 2024 : We Love Speed - Nantes (France) 19-20 septembre 2024 : API Platform Conference - Lille (France) & Online 25-26 septembre 2024 : PyData Paris - Paris (France) 26 septembre 2024 : Agile Tour Sophia-Antipolis 2024 - Biot (France) 2-4 octobre 2024 : Devoxx Morocco - Marrakech (Morocco) 7-11 octobre 2024 : Devoxx Belgium - Antwerp (Belgium) 10 octobre 2024 : Cloud Nord - Lille (France) 10-11 octobre 2024 : Volcamp - Clermont-Ferrand (France) 10-11 octobre 2024 : Forum PHP - Marne-la-Vallée (France) 11-12 octobre 2024 : SecSea2k24 - La Ciotat (France) 16 octobre 2024 : DotPy - Paris (France) 17-18 octobre 2024 : DevFest Nantes - Nantes (France) 17-18 octobre 2024 : DotAI - Paris (France) 30-31 octobre 2024 : Agile Tour Nantais 2024 - Nantes (France) 30-31 octobre 2024 : Agile Tour Bordeaux 2024 - Bordeaux (France) 31 octobre 2024-3 novembre 2024 : PyCon.FR - Strasbourg (France) 6 novembre 2024 : Master Dev De France - Paris (France) 7 novembre 2024 : DevFest Toulouse - Toulouse (France) 8 novembre 2024 : BDX I/O - Bordeaux (France) 13-14 novembre 2024 : Agile Tour Rennes 2024 - Rennes (France) 21 novembre 2024 : DevFest Strasbourg - Strasbourg (France) 28 novembre 2024 : Who Run The Tech ? - Rennes (France) 3-5 décembre 2024 : APIdays Paris - Paris (France) 4-5 décembre 2024 : Open Source Experience - Paris (France) 22-25 janvier 2025 : SnowCamp 2025 - Grenoble (France) 16-18 avril 2025 : Devoxx France - 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/

Não adianta fugir, IA é uma realidade e veio para mudar a realidade que conhecemos. Mas hoje vamos além do hype. O que de fato a inteligência artificial está fazendo pelos negócios? Como startups e grandes empresas estão assimilando essa tecnologia? Para responder essas perguntas, Pedro Waengertner conversa com Felipe Pojo, Sr Business Development Manager for Artificial Intelligence na AWS, e Kim Silvestre, sócio da ACE Cortex. Visões e insights de quem está vendo e vivendo na pele essa transformação. Vem com a gente!Inscreva-se no treinamento gratuito da AWS sobre Computação em Nuvem >> http://acestartups.talento-cloud.com/ https://acesummit.com.br/

Search for the Wedge-tailed Hillstar in Pojo, Bolivia. If you're enjoying CHASING FEATHERS and want to buy me a coffee, visit: https://www.buymeacoffee.com/chasingfeathers Theme: La Boqueria (Sting version) by Loius Nichols. Courtesy of Epidemic Sound ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.epidemicsound.com/track/uWeGdACji6/⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠ Feel free to contact me at cfchesse@gmail.com or https://web.facebook.com/charleyhesse

An airhacks.fm conversation with Sascha Moellering (@sascha242) about: Schneider CPC, starting programming with C-16, enjoying Finger's Malone, upgrade to C-128, playing Turrican, Manfred Trenz created Turrican and R-Type, publishing a Pommes Game, programming on Amiga 1200, math in game development, implementing a painting application, walking through C pointer and reference hell, from C to Java 1.0 on a Mac 6500 with 200MHz, using Metrowerks JVM, using CodeWarrior, CodeWarrior vs. stormc, Java is a clean language, working on SpiritLink, using Caucho Resin, starting at Accenture, from Accenture to Softlab, building a PaaS solution with JBoss for Allianz, managing hundreds of JVMs with a pizza team, implementing a low latency marketing solution with Vert.x, starting at Zanox, an episode with Arjan Tijms "#184 Piranha: Headless Applets Loaded with Maven", starting at AWS as Account Solution Architect, using quarkus on lambda as a microservice, using POJO asynchronous lambdas, EJB programming restrictions and Lambdas, airhacks discord server, Optimize your Spring Boot application for AWS Fargate, Reactive Microservices Architecture on AWS, Field Notes: Optimize your Java application for Amazon ECS with Quarkus, Field Notes: Optimize your Java application for AWS Lambda with Quarkus, How to deploy your Quarkus application to Amazon EKS, Using GraalVM to Build Minimal Docker Images for Java Applications Sascha Moellering on twitter: @sascha242

Phare Citadelle clôture sa saison avec un dernier événement les 17/18 et 19 novembre prochain : Phare ô vins, festival du vivant ! Organisé avec la cave à manger “Marcus”, le caviste Jean Walch “Au Fil du Vin Libre”, le sommelier Pierre Berthier et le blogueur David Neilson (Back in Alsace), Phare ô vins prend la date officielle du vin primeur comme prétexte pour se réunir et échanger. Au programme : une cinquantaine de vigneron.ne.s avec plus de 180 références de vins vivants à déguster, achat en direct auprès de la cave “Au fil du vin libre” délocalisée pour l'événement, des brasseries artisanales, des plats réconfortants concoctés par Oscar (Marcus) et Léa (Phare Citadelle), les huîtres de Green Oyster Cult, des ateliers culinaires pour les enfants orchestrés par Bérengère (ex Comptoir à Manger), conférences avec plusieurs vignerons, la brasserie Bendorf, et l'association Stück, des concerts et dj-sets. Trois jours de découvertes et de rencontres avec celles et ceux qui font du vin vivant un médium, vecteur de transmission et de transition. Plus qu'un salon de dégustation, il s'agit d'un festival démocratique célébrant le vivant autour du vin libre à Strasbourg, capitale d'une région visionnaire dans le domaine. En contrepartie d'un billet acquitté un verre de dégustation est offert, il permettra de découvrir les nombreuses références présentées dans la grande halle de Phare Citadelle. Jeudi 17 novembre : 14:00 - 20:00 Vendredi 18 novembre : 11:00 - 18:00 Samedi 19 novembre 2022 : 10:00 - 18:00 Inscription:  https://my.weezevent.com/phare-o-vins La liste des vigneron.ne.s présent.e.s Alice Bouvot, Anaïs Fanti, Axel Prufer, Benoit Camus, Benoit Killian, Brasserie Papyllon, Brasserie Pikadili, Brasserie Perle, Catherine Riss, Christian Binner, Christophe Lindenlaub, Clément Bony, Clément et Sylvain Goepp, Clos Fantine, Daniel Millet, Didier Grappe, Des Grottes, Eric Kamm, Gerard Blaess, Kleinknecht, Jean-Francois Ginglinger, Jean-Pierre Frick, Jean-Pierre Rietsch, Jeff Coutelou, Jerome Guichard, Jerome Jouret, Julien Albertus et Sophie Kumpf, Les Grandes Vignes, Les Vignes de Paulette, La Sauvagère, La Sénéchalière, Les Vins Drach, La Ferme des Sept Lunes, Leonard Dietrich, Les Deux Terres, Léo Dirringer, Théo Schloegel, Théo Einhart, Louis Maurer, Louis Julian, Philippe Jambon, Philippe Pibarot, Paul Reder, Patrick Meyer, Pierre Weber, Roche Buissière, Stéphane et Régine Bannwarth, Spiral,Tunia, Vino del Pojo, Yannick Meckert —-- Les offs de Phare ô vins En accès libre pendant les 3 jours Vous pourrez profiter du bar et de la nourriture concocté par Oscar et Léa dans la halle de Phare Citadelle. Des ateliers culinaires pour les enfants avec Bérengère, des dj-set, une conférence sur la consigne, la présence de l'association "le Stück" sur les trois jours... Plus d'informations à venir —------- TARIFS Entrée + verre de dégustation Possibilité d'acheter du vin sur place, la cave Au fil du vin libre sera délocalisée pour l'occasion En co-création avec le Marcus, le Fil du Vin Libre, Pierre Berthier et David Nielson   Buvons modérément, buvons libre et surtout avec émotions. S'gilt  Tu peux aussi partager l'épisode en Story via Spotify ou en faisant une capture d'écran de ton app favorite. N'oublie pas de me tagguer pour que je repartage ton post ! Merci   Soutenez-nous !

Ms. My My Music showcase artist spotlight: City Boyy PojoSupport the show

This week Randall sits down with Enduro Bearings co-founder, Matt Harvey. Randall and Matt go deep on the origin story of Enduro Bearings (circe 1996), bearing science and myth, and how this often overlooked component enables the ride experience. Episode Sponsor: Athletic Greens Enduro Bearings Support the Podcast Join The Ridership  Automated Transcription, please excuse the typos: Enduro Bearings [00:00:00] Craig Dalton: Hello, and welcome to the gravel ride podcast, where we go deep on the sport of gravel cycling through in-depth interviews with product designers, event organizers and athletes. Who are pioneering the sport I'm your host, Craig Dalton, a lifelong cyclist who discovered gravel cycling back in 2016 and made all the mistakes you don't need to make. I approach each episode as a beginner down, unlock all the knowledge you need to become a great gravel cyclist. This week on the show, I'm handing the microphone back to my co-host Randall Jacobs. Who's got Matt Harvey. Founder of Enduro bearings on the show. You might've heard us talk about Inderal bearings a few times in the, in the dirt episodes, as I was deciding and debating what bottom bracket to run on my new custom bike. Well, I decided on the Enduro stainless steel bottom bracket. And I couldn't be happier with the performance thus far. I was happy that Randall volunteered to take a deep dive into bearing technology. With Matt, as I think he's got better perspective on the technical elements. And certainly there's no one better to talk about this product than Matt himself. Before we jump in i need to thank this week sponsor athletic greens Athletic greens is literally a product that I take every day. I discovered athletic greens many years ago, as I was recovering from my treatment for Hodgkin's lymphoma. I was looking for something that had the vitamins, minerals and probiotics that I needed to kind of just give me baseline support. After I was through that difficult period of my life. I realized that this was sort of a baseline thing I needed for all my athletic endeavors as well. With one scoop of athletic greens, you're absorbing 75 high quality vitamins minerals, whole food source, superfoods. Probiotics and APTA gins. To help you start your day, right? It's a special blend of ingredients to support your gut health. Your nervous system, your immune system, your energy, your recovery, your focus and aging. All the things. I encourage you to check it out, to see if it's something that might fit for you to make it easy. Athletic greens is going to give you a free one year supply of immune supporting vitamin D and five free travel packs with your first purchase. All you have to do is that the athletic greens.com/the gravel ride. Again, that's athletic greens.com/the gravel ride. To take ownership of your health and pick up the ultimate daily nutritional insurance. With that said, I'm going to hand the microphone over to Randall. For his interview with matt harvey from enduro bearings [00:02:37] Randall Jacobs: So I cut you off last time we spoke because there are just too many things that I was interested in diving into. And there's the obvious technical aspects of what goes into making a bearing? Of the myths about bearings that we might debunk and things like this. But before we dive in, just tell us a little bit about yourself. [00:02:57] Matt Harvey: well, I've always been in bicycles ever since I can remember. So I started out as a BMX rat, you know, when I was like 13, 12 or 13, and I started working at a bike shop when I was 13. So I immediately into the mechanical, well, spraying, WD 40 on POJO drive, tra is an exactly super high end mechanical things, but that's how it started. So, you know, and you know, through there, I worked in bike shops, my business partner. Now I met in a bike shop when I was 17. We worked in the same bike shop. I ended up working at Fisher mountain bikes. I got an engineering degree, ended up working at Fisher mountain bikes, wide industries Bianchi bicycles, starting out in warranty. Became a product manager, went to Italy, did their mountain bike wine designed a bunch of road bikes and mountain bikes full suspension road bike that got written in Perry RBA. and that was kind of like when I was looking at bearings because everybody was using plane bearings or bushings at the time. And the Fisher RS one with Mert Lawwell work. That was his design. And one of the first full suspension bikes, I think. Well, not first, but you know what I mean? Like current more modern production type, full suspension bike, I should say. Cuz suspension, bikes go back. You know, turn of the last century. So, so that's when I was starting to look at bearings and rolling elements and that's when they were getting popular. And that guy I worked with at a bike shop when I was 17, he was in the forklift business by then. And he was starting to make bearings for old forklifts. And you know, we hadn't lost touch and we were talking and I started doing drawings for him cuz he needed CAD drawings for certain things. I was working at Bianchi. And then we, at one point we decided, Hey, this could become a business. So let's start making bearings for forklifts and bicycles. And that's what we still do. 30 years later. [00:04:58] Randall Jacobs: Well, and I'm curious, we'll, we'll dive into the Enduro bearing story in a minute, but I wanna dive more into that background cuz there's a few things that I find interesting one is, you have what sounds like a technical understanding of the bike that comes from, getting your hands dirty at a young age. I share that experience. And in fact, working on bikes I think is a great way for any person to learn how mechanical systems work. But then also you worked in warranty, so you saw what was going wrong. How did your experience working in shops and working in warranty inform your perspective on product. [00:05:30] Matt Harvey: yeah. They're all related, right? You can't separate it. Obviously at one point I realized I needed more school to do what I was thinking about doing, I wanted my boss's job. I wanted to do what he was doing, which was designing bikes, but I didn't have the background or experience. So I went back to school, but yeah, I mean, Your hands are in the bikes, you ride bikes. So you get a certain aspect, which is super important, the practical aspect, but then you know, getting into engineering and so forth, you have to have, you know, the math, the, you know, the history, the you know, and then you get into business. You need business stuff too, but there there's a lot of corners. You need to go explore to put the whole thing together. I, I think, and, and that's what I ended up, ended up doing. So at, at the beginning it was practical aspect, you know, seed of the pan stuff, cuz I'm just working on stuff. And that's the way, a lot of the way a lot of things happened in the late eighties, early nineties, that's kind of the period I was working on it. But you mentioned warranty. Yeah. I learned a lot in warranty cuz I saw everything that got broken. [00:06:43] Randall Jacobs: Yeah. [00:06:44] Matt Harvey: at Bianchi bicycles and it was the eighties and. Ola was king, you know, shaman was coming with index shifting, but you know, things were being made in in Italy or, or Taiwan or, or various countries at the time, still a lot in the us. And, and then there was people were trying to, you know, save money and then things break. And what happens with heat treating what happens with why did that thing break? Why was there too much heat treating? Well, I wanted to find out, well, that seems like a good thing. How can there be too much heat treating? So, you know, you learn, I, you see the broken parts, you see a box of broken pedals and that's not good. Nobody likes to break a pedal, but you find out like why things get crispy and break and and all the, so I, I wanted to learn about especially metal steel, aluminum at the time it was Prebon fiber. [00:07:40] Randall Jacobs: Mm [00:07:40] Matt Harvey: But so yeah I, you go into, I went into back to school in metal shop too. And but I, I was lucky because I also had, I was going to Taiwan. I was still working for Bianchi. I was going to factories, seeing things you know, forged, spin, welded you know, all the different ways you make things. So I was, I was getting a practical eyes on learning experience in Taiwan where all the production was kind of going. I was also going to Italy and, you know, Italy was still making a lot of stuff. Then Bianchi was making bikes at the main factory there. I mean, they're getting back to it again, but at the time it was sort of Asia was taking over on a lot of the production. So it was kind of split between, you know, Asia and Italy at the time. [00:08:26] Randall Jacobs: So you were right in there at a number of big transitions in the industry. The advent of the mountain bike, which was very much a us and in particular bay area phenomenon . And in fact I've talked about different tariff codes in for mountain bikes there was a significant domestic manufacturing operation. And materials were that much more critical cuz you had this really high stress application that hadn't really been done before. Like those clunks were not were not holding up all that well. And then the transition to index shifting that's another major transition in the industry. That's the reason why Shao is so dominant today. And also Asia manufacturing, a lot of which was people in the us and European bike industries who were going over and helping to, transfer that knowledge and set up that production in what is now, Taiwan in particular some of the, the best, highest end manufacturing for bikes anywhere. It's no, it's no longer a cost thing. It's a quality thing. [00:09:23] Matt Harvey: Yeah. And in the beginning they were, they had the ability to make really high end stuff, but the knowledge needed to come from the people who were practically riding bikes, because they weren't practically riding bikes. They knew how to make things, but they had to know how to make it now, you know, the Taiwanese it feeds back a lot of times they, they do new products that they develop their own new products that are really great. So, but yeah, you're right. Those were the early days of figuring all that stuff out. [00:09:53] Randall Jacobs: Well, and I'd, and I'd say I definitely see more domain knowledge on the product side in Taiwan than there was in the past, but still it, it does seem that the, the most successful Taiwanese manufacturers are those that have, European or American team that is in the market and kind of on top of the trends and the trends are still largely driven by those two markets. [00:10:15] Matt Harvey: sure. But you know, in Taiwan now it's an entire, since I started there, it's an entirely new generation that has now grown up in the bike industry. And there a lot of 'em are riders now and stuff. And back then nobody was riding mountain bikes who worked at the factories or made stuff or design stuff. But now you have a lot of people there that are enthusiast. And I mean, as big an enthusiast as anybody in the world for [00:10:39] Randall Jacobs: Yeah. True. [00:10:40] Matt Harvey: riding. And so it's, it's an entirely new generation that. I mean, it's great. They've embraced it and they know it and they develop things materials and design it's incredible. And at the time, you know, historically you go back, so Italy was, you know, Italy and France were the huge innovators back when right. They came out well, derailer, it's a French word and Italians didn't embrace it immediately. They had other things, other ideas. But at the time when I went there, it was an interesting time because Italy was king, but not quite becoming, you know, they, they didn't catch the mountain bike wave. They were looking at specialized and these innovators at the time Fisher, all, you know, Richie, all the people that were innovating and they couldn't keep up, they didn't quite cuz they're, they were a mature market and not looking at that. So I was the American brought in to be the eyes and. Practicality of that part which I was, you know, it was a little frustrating cuz you couldn't quite keep up and then the name Bianchi and mountain bikes at the time no people are gonna buy a, a Fisher or a Richie or something or an Ibis, you know? So that was a uphill battle and that, and that's why European brands or track, you know, they bought mountain bike brands. They bought, you know, Gary Fisher brand and to sell it because they were known as a road bike company. And that's what people were doing at the time. So it wasn't always necessarily not great ideas at these companies. It was marketing to, you know, you have to have it all. [00:12:16] Randall Jacobs: it's interesting, like you think about camp. No. Which was a really great and, and major player, and they're still significant, but substantially diminished, vis Avi Shao and STR the, the two, you know, arguably we have a duopoly in our industry and it's those two and camp Nolo makes some good stuff, but they didn't come out with hydraulic disc brakes until much later. and, and even then I think they work with McGurk on that. I don't know if that's in house now. They're more recent offerings with the ECAR group, I think are, are innovative. And I'd like to see them contest from more spec because the industry does benefit from competition. But yeah, it's interesting to hear your perspective on how the industry has evolved. What year did you enter? When were you working in those shops? [00:12:59] Matt Harvey: So first bike shop was 1976. And then let's see, I worked in shops until about 81 and I ended up starting at Bianchi warranty in the 82, maybe through 80, 85. And then I went over to Fisher. I went back to school. I, I simultaneously worked at Fisher and was in school and, and then I started moonlighting at white industries because Doug white was, he was pretty, he was making titanium spindles for Fisher. So that's how I made the connection there. And I would go over to his shop. They were pretty close by. There was a lot of people around then Dave GU DKG make, he still makes seat clamps. He was making motorcycle stuff. You know, there was salsa. Everybody was kind of in the same area and everything was happening up in Marin then. So, you know, I talked to lot of people, Peter Johnson, all these people that were making stuff. And so I went back when I finished school. I it just coincided with Bianchi needing a product manager for a mountain bike specifically. So they, I got rehired at Bianchi as product manager, and then it was a lot of a lot of whirlwind you know, once a month to Taiwan. Once every two months to Italy, I was on the plane all the time, doing a lot of stuff and developed two mountain bikes there. And that was a transition of going from bushings to rolling elements bearings and seeing that, you know, the bearings weren't hacking it. I wanted bearings cuz they're faster, you know, than bushings bushings are slow in a suspension linkage. And if you're going over a high you know, water bars or high frequency stuff, [00:14:46] Randall Jacobs: Yeah. [00:14:46] Matt Harvey: they're, they're just too slow. Bushings can't react. So rolling elements work better, but they were wearing out fast. So it was trying to figure out how to do better ones. And then that was kind of my transition into bearings. My friend from the bike shop was he was down at his shop in Emoryville making LAR much larger bearings, like five, six inch diameter bearings for forklifts, but they were max type, which we use in suspension, bearings. And I go, oh, that's a cool idea. Forklifts use these full complement bearings full of balls. And why don't, why don't we do that for mountain bikes, but just a make a micro version. And that was the beginning of trying to make bearings for suspension, bikes, and kind of the beginning of it. [00:15:32] Randall Jacobs: so let let's talk about that. I remember a lot of it was cup and cone for bearings. I remember bushings in mountain bike linkages, and then cartridge bearings, when did those come to the four? Is that where you started or were you doing loose ball initially? [00:15:46] Matt Harvey: No, it was cartridge bearings, but yeah, you're you're right too. Like cup and cone were often max type bearings, as you say, no retainer, you know? And, but [00:15:56] Randall Jacobs: which is to say the balls are, are rubbing up against each other, spinning an opposite direction. So there's a high degree of friction between those two surfaces of the balls versus having a retainer with a lower friction coefficient separating them. [00:16:09] Matt Harvey: that's true. But surprisingly the friction between the balls is actually extremely low. Believe it or not. I mean, theoretically, you would imagine that there is, but the balls are so smooth. And I've studied this a little bit. There there's very little friction from the balls rubbing against each other without a retainer. It is a little bit better with a retainer, but it's almost immeasurable. It's really small coefficient of friction between [00:16:35] Randall Jacobs: Oh, that's super interesting. Are there applications where you would not want a retainer then? [00:16:40] Matt Harvey: Usually, bearings run smoother with a retainer. The thing about max bearings is you have to get the balls in there. So there's a a side hole, if you will, to feed the balls into their slots and, and it, it gets into the ball path and that creates more friction than the ball's rubbing against each other, especially in an axial, like if they get off center and they rub against that fill slot. So that's why they're really good for pivot bearings. Not really recommended for hub bearings or, or bottom bracket bearings for that matter. [00:17:19] Randall Jacobs: yeah. Cuz you have those, those non radial loads that are being applied to them. [00:17:23] Matt Harvey: right now, the old [00:17:25] Randall Jacobs: I just wanna state, we did, we did promise a properly nerdy podcast for this. So we're gonna get into the weeds. I'm loving this. I hope that our listeners will as well. There's a lot that goes into bearings that we kind of take for granted [00:17:37] Matt Harvey: sorry, I can go into the weeds pretty quick. Just you [00:17:40] Randall Jacobs: that's, that's the point? That's the point? This I, this is, this is as much for me as it is the audience. So let's go into the weeds. And so you have this, I was actually going to ask how you get the bearings in there in the first place. So you have a, a single location where there's a, a notch, and then you have this retainer that makes sure that the bearings never track into that notch. [00:17:59] Matt Harvey: Well, yeah. So in a retainer bearing, you can assemble the bearing without a fill slot. So you put in all the balls on one side and it kind of, well, I'm not gonna demonstrate it here, but they, they all go in on they're all on one side of the lower race and you kind of snap it together in the, so there's no fill slot on a retainer. There's only so many balls you can get in there because of that design and, and that was developed in Germany in the late 18 hundreds. And then max Barings, or, you know, those were the first ones actually in S hubs going back to 1860 1870s and their angular contact Aless hubs. Yeah. [00:18:39] Randall Jacobs: that's a, I think Bontrager had a line of wheels called OLIS. Is that the same, [00:18:44] Matt Harvey: Yeah. I think they revived the name. But yeah, it's an old, it's a really old hub name and developed for bicycles. Like the first precision bearings are interchangeable. Part bearings were developed for early bicycles. Rolling elements that standardized rolling elements, [00:19:02] Randall Jacobs: Were they even bicycles at that point? Or were they like velos or some of these [00:19:07] Matt Harvey: speeds. [00:19:07] Randall Jacobs: yeah, so, [00:19:09] Matt Harvey: safety bicycle was until 1885. So, but you know, same bearings were used in those and, and bone shakers or, you know, the various things that you saw developed, you know, three wheels and four wheels and so forth back [00:19:25] Randall Jacobs: and this term, this term Velo you know, velocipede and safety bicycle for those who don't know the, the history of the evolution of the bicycle. Can you talk a little bit about that? [00:19:35] Matt Harvey: yeah. So I think philosophy is anything that rolls by human locomotion, whereas safety bicycle, you, penny farthing is the large wheel up front because it was pre chain gearing. And that's how you got your gearing was to use a really big wheel in the front or medium, you know, various size wheels. The race bikes had a huge wheel. Extremely dangerous. And then they called it the safety bicycle with two wheels, the same size chain drive, because it was much safer than a bone shaker or penny far with the big wheel. Cuz the crashes on those were horrendous. [00:20:13] Randall Jacobs: sure you're starting from a high point. And then if you hit anything, you're going, lawn dart but then still fixed gear. And then you had to have ratchet mechanisms or some sort of free hub or free wheel and all these things that we take for granted they had to be invented and evolved and materials had to be there and, and the production tolerances had to be there for all of this to exist. [00:20:34] Matt Harvey: That's right. It, it took it, it was pretty quick how the the development of the bicycle, all the things that came became developed came in quick succession. It's amazing how early things were invented that. We see as quite advanced. In fact, I was just looking at something recently, cuz you know, there's a two speed rear hub that has become pretty popular in the industry classified and you know, the first two speed rear hub was actually like 1896. That's how far back stuff [00:21:03] Randall Jacobs: was, what was the company behind that? [00:21:06] Matt Harvey: it was called, believe it or not. The name of it was they, it was so early. They just called it the hub. That was the name of the company. And I forget the guy who developed it, but he called it the hub and it was extremely popular at two speed rear hub. And then there was like five companies within two years making them back [00:21:25] Randall Jacobs: Got it. [00:21:26] Matt Harvey: We, we are getting into the weeds here but you know, it all comes together. It makes sense because people are always looking for, you know, right now it's a front derailer thing with full suspension bikes. It's hard to put a front derailer on the bike and you know, so the two speed hub here, we have it again because it solves a problem. But it's interesting to know that it was developed a hundred years or over a hundred years ago too. [00:21:52] Randall Jacobs: Sure. Yeah. Yeah. And it's also like the, the solution that you had in the bearing space, it had a context. It's another one of these enabling technologies that had to be put in there to have, you know, you look at something like the Delta suspension design that Dave weel came up with for, for evil and just the number of bearings in there. And imagine having that with a bunch of bushings that have a high static friction and so on, it just doesn't work, never mind the high rolling efficiency of our wheels and bottom brackets and all these things. So let's go back to bearings. You alluded to how Enduro got started and you were doing forklift bearings so let's continue on that Bain. [00:22:31] Matt Harvey: all right. So we were making bearings for forklifts that you couldn't get anymore because forklifts last their electric vehicles, or, you know, you can put a new engine on 'em. So the, the car that you of the forklift keeps going, so, or the truck. So, yeah, we were making specifically the bearings that go up and down in the mast that hold the forks. So those have to be. They carry extremely high loads and they don't spin very fast. They're max bearings. And that's [00:23:01] Randall Jacobs: What, what defines a max bearing? [00:23:04] Matt Harvey: maximum fill of balls. So not a retainer bearing. You can put, if you take the retainer out and just fill it full of balls on max maximum fill, you can put about 35% more balls into the bearing and then your, yeah. Your load capacity increases. By that amount, 35% [00:23:27] Randall Jacobs: Mm-hmm so you can either have a bigger bearing or you can have one of these max bearings to fit the same amount of load capacity into a smaller form factor. [00:23:36] Matt Harvey: Exactly. And as long as the rolling element, isn't spinning really fast. Like, you know, it's not an electric motor going 10,000 RPM. It's, it's going maybe I don't know, 20 or 80 RPM, pretty, pretty slow. Even on a bicycle, you know, cranks and wheels. They're hundreds of RPM, not thousands. So, well in a suspension pivot, it's just swiveling back and forth. Maybe 15 degrees. So max bearing makes sense, cuz it's not spinning. You're not looking at a lot of friction from the fill slot or whatever. So we started making we were making those forklift bearings and ironic white industries was actually making 'em for us up in Nevada, those early ones. We made some at the shop. We were turning at the shop, but when we got into larger numbers, white industries was doing it. And. So I was working with them and then we ended up making some hub bearings which are retainer bearings, which for hubs, hubs need to have higher precision to spin smoothly because in a, in a back hub you have four or five bearings that you're stacking up and you need a higher level of precision. That's why we do ABAC five bearings at Enduro for, for hubs specifically, because you need a higher level of tolerance. Now, ABAC ratings are significant in that they give you a level of the precision. However, all of the Abe parameters are not really applicable to bicycle application, cuz it's really a lot about noise ratings and spinning at 10 20,000 RPM, which bicycle bearings never do. So we do. Abe grading, Abe bearings for the ID OD with tolerance to make the alignment. Correct. But we do very deep groove to take higher loads than most high spinning bearings. [00:25:31] Randall Jacobs: Got it. That makes sense. So you have a bigger surface area where the bearings are contacting those races and thus you have less deformation of the balls, less deformation of those races as the, you know, as that as it's spinning. And that load is, you know, coming on and off of each ball. [00:25:47] Matt Harvey: right. And so a lot of high Abbe rated bearings may not be good for bicycles because to reach the noise level testing you want it's easier to make an Abbe, a high Abbe rated bearing with shallower grooves. And less surface contact, but that's not good for a bicycle because you have pretty high axial loads and everybody who makes hubs and bicycle components in general, they're always trying to save weight. So they try and use the lightest weight bearings possible. So you need that bearing to be as robust as possible to resist the the the loads of, of the you know, axial loads, radial loads that, that small bearing has to put up with [00:26:35] Randall Jacobs: And just to clarify terms for those in the audience who don't have an engineering background, radio loads, being those in plane with the bearings. So in, in, in the same plane as the bearings, so if it's a wheel it's like a load that's coming, straight up perpendicular the ground through the center of the bearing essentially versus an axial load is, would be like a twisting load on that same bearing. So if you have a lateral force on that wheel or something like that, which you can have, presumably you have somewhat significant axial loads in especially in like mountain bike linkages and rear wheels and things like that. [00:27:09] Matt Harvey: oh yeah. Or even road wheels, like a rear hub. When you're going up a hill, like a really strong rider out of the saddle, going back and forth. There's significant axial loads and twisting between the cassette mechanism, the, where the Sprockets are and the hub shell. It's, you're literally trying to pull the thing apart because it's not a motor running it on a chain, like sitting stationary, you know, like a you know, a generator motor or something, you know, the human is just, doesn't put out constant power. So that's why you see elliptical. Sprockets and stuff, but you you're basically putting on a, a as you're going up a steep hill, let's say you're, you're twisting everything apart. So there's high axial loads on the rear bearings, and even the front bearing, you know, when you're sprinting the front wheel bearing it's, it's moving side to side when people are throwing their bike and you have now dis brakes too, which puts on unequal loads, cuz it's one side of the hub onto the bearings. So you're pulling the bearings over again with dis brakes and that's brought a whole new well for me, I like it cuz it's a challenge, but that's another new challenge of conundrum of of problems to address with front wheel loading cuz front wheels were just mostly along for the ride with rim breaks. But with dis brakes, you gotta, you gotta look at it closer. They're asymmetric forces on the front wheel now too. Uneven [00:28:37] Randall Jacobs: Yeah. And it's on the hub, it's also on the fork itself. And fork legs had to be redesigned a primary driver of the creation and adoption of through axles was also because the torque loads were so great. And in fact, if that quick release was not tightened fully, you could actually have a wheel eject itself. So yeah, just massive forces in those areas that people don't really consider when they throw on a 1300 gram wheel set and say, okay, this is gonna support my entire weight and keep me safe at 30 miles an hour on a steep mountainous descent. [00:29:09] Matt Harvey: exactly. And, and a lot of times the bearings are even by the designers, surprisingly, sometimes they're the last thing thought about, and they say, oh, we need a bearing to fit in this. You know, it's gotta fit under the disc and over the through axle and it become. Extremely thin. And then you gotta look at other ways to make a solution for that. So it holds up and doesn't burn out. I mean, early in disc breaks that you'd see hubs that the disc would get so hot. You could burn out the, the the disc side bearing in one downhill run, [00:29:43] Randall Jacobs: Oh, wow. [00:29:44] Matt Harvey: and some [00:29:45] Randall Jacobs: I didn't realize that. [00:29:46] Matt Harvey: Oh yeah. And some riders were buying like full tubes of the, this side, front wheel bearings for certain hubs, because they would knock it out after every run and put a new bearing in. It got so hot, it would like boil the grease out of it and just toast the thing. It would practically set the weeds on fire, you know, cuz , it got so hot. I mean the dis brakes have improved and cooling and some other things and people have gotten smarter about the hub bearings on that side. But like about eight years ago we were selling a lot of certain sizes of bearings cuz for downhill guys. [00:30:20] Randall Jacobs: Well, and disc diameters have gotten much bigger. You have aluminum spiders with venting that can help to shed some of that transfer it to the air versus early disc breaks were I mean, a lot of it was what, 140 millimeters [00:30:34] Matt Harvey: yeah, small ones. [00:30:35] Randall Jacobs: lot of, [00:30:36] Matt Harvey: when we start, there was no dis when we started with that RS one with Mert Lawwell we needed a disc break. There were none around. We used to fill disc break from back then. That was a all fiber disk. I don't know if you remember that one, but there weren't any discs that would that, you know, and they faded, you know, faded miserably. That was really hard thing to slow that bike down. [00:30:57] Randall Jacobs: yeah, again, I can't impress upon our audience enough of just how good we have it right now, in terms of how, you can have an extraordinarily lightweight breaking system that will stop you plus your bike, plus whatever gear you have reliably and consistently for long periods of time and everything just works. And it's actually, I, I mean, I remember my first bikes, you know, I'm only, I'm only turning 40, my first bikes didn't just work. There was a lot of service. There was a lot of parts failures and so on, and now things just seemed to be engineered and manufactured to a much higher standard such that it's increasingly surprising when things don't just work. And bearings are a big part of that. [00:31:39] Matt Harvey: And so, what if you don't mind, like the there's one development that I worked on A long from a long time ago, I had heard about this metal that air Airbus had developed and for their, for making bearings in the planes. And I read about it and I immediately wanted it. And there's only a couple foundries that make this particular steel in the world, but I knew it was gonna be perfect for ceramic bearings. And but you know, it was frustrating because the amount of steel that I needed even though it was a lot of money for me who they, they would never be interested in. I, I got my business partner, speaks Germany called the Foundry in Germany and they basically hung up on him, you know, or they didn't hang up on him, but, you know, I was like, yeah, thanks kids. See you later. And I was at a show and I met this guy who. To you know, I, people sign trying to sell me metal all the time. Cuz we make bearings, but this guy, I heard the word nitrogen steel and I said, wait a minute, you can get nitrogen steel. And he's like, oh yeah, you know, I represent the company. So the long and shorts of the story is he's a mountain biker who worked for the Foundry in France. There's only two foundries. So he got me in there and was able to get me some steel. And, and so we'd been making XD 15 bearings now for over 10 years, I think maybe 12 or something. But that material cuz ceramic bearings, they're when you think about ceramic bearings, they're kind of fragile, right? They they're really great because they do spin really well. Cuz you have a super hard ball. It's seven times harder than steel. It won't flex or, or push out of the way deform and but it wears the races out. If there's no grease or. They can rust and all these things, and here's this material XD 15, it won't rust it won't corrode and you can run a ceramic ball in it with dirt, whatever you want and it won't wear out. [00:33:33] Randall Jacobs: It'll just Ize it, whatever gets in there. [00:33:35] Matt Harvey: it, yeah, it burnishes the races it'll like Polish and so you don't get Goling or pitting. So what usually happens with a bearing when it wears out, it'll just, you know, you get dirt or no grease in there and what happens. You get a pothole, essentially. If you're in the race and it's a little pit in the race, and then as the ball rolls over that the P like a car running over a pothole gets bigger and bigger until you feel that it's rough. So that's what happens when a bearing wears out. Well, that doesn't happen with XD 15, nor does it corrode. So, me and this guy, you know, we're, we're, we're still buddies and he he still rides his mountain bikes and he gets me the steel. Still we're still friends, but you know, the bike industry is so small. We're probably 20 minutes of, or not even 10 minutes of production out of this Foundry for all we buy in a. Because Airbus soaks that stuff up by the, you know, it's just aviation uses so much more material than, you know, any sports industry thing. So, I'm just lucky to be able to get it. But it's it's an interesting material to work with. We have to get raw, we can't get tubing, you gotta drill it. There there's a lot of it's hard to make these bearings, but I'm kind of proud of it. I mean, it's my favorite thing that we make because it answers the question when somebody calls and says, I want something to put in my bike and then I never wanna work on it again, which is kind of my goal too. Cause I never have time to work on my bike. And it's just like, I want to, you know, you can put these bearings in your bike and never think about 'em again. So that's why I like them. [00:35:12] Randall Jacobs: well, and this is a great segue into a topic that I think a number of our more performance or competition oriented listeners will be curious about, which is the ceramic bearing landscape, right? There are a few options out there. Maybe they're included on a very premium wheel set. Maybe it's some bearing kit that you can press into your existing hubs, but the perception that these are better or even necessarily faster or more efficient is not really backed up. And there's a phenomenon where, you know, you end up and, and I made this mistake. I. Ceramic bearings early on trying to get every little edge. And the science simply says that, well, it may give you a slight, maybe imperceptible benefit for a few hundred miles and then, the performance is going to a degree rather quickly because they're a significant part of that performance benefit has less to do with the bearing and more to do with say the thinner grease that's being used or the lighter seals that are being used. And then you have contamination, you have the Goling and, and pitting that you just described and so on. So maybe help us to understand the ceramic bearing landscape generally. And what's true and not true about ceramic bearings. How do you make a good one? How do you make a bad one? [00:36:21] Matt Harvey: right. Well, what you just said is, is all true. You know, friction and bearings has more to do usually with the seals and the grease at first grease dissipates. And, you know, after you've ridden it, a couple of rides, it dissipates and it's less of a factor, but right. Brand new out of the box, there's some grease not friction, but resistance [00:36:43] Randall Jacobs: to the viscosity of the grease, the thicker, the grease, the more resistance it applies. It's simply just within the friction of the material within itself. [00:36:52] Matt Harvey: Exactly. And, you know, first of all, the reason you don't see a lot of data about what actual test data about what that is, is because it's really small and hard to measure what that wattage difference is. So the drive train is your drive train is about seven Watts of suck, or if you will, or, you know, the and five of the Watts are the chain because it's basically a chain is 110 plane bearings rolling around on your Sprockets. So that's, that's, [00:37:24] Randall Jacobs: Plain bearings, meaning not having a ball bearing. It's just a metal on metal interface. [00:37:29] Matt Harvey: Rolling element. So it's a, it's a metal, a steel ring that rolls over your chain rings and there chain is extremely efficient. It's great. That's why everybody we use 'em but so that leaves two Watts for all the bearings in your bike. So if you do the math, you know, there's at least 12 bearings. [00:37:44] Randall Jacobs: So two in the front wheel, four or five in the rear wheel. Two in the bottom bracket and then [00:37:51] Matt Harvey: couple in the pedals [00:37:53] Randall Jacobs: Oh, in [00:37:53] Matt Harvey: and the pedals [00:37:55] Randall Jacobs: Yep. Yep. Can't forget that. Usually it's a cartridge ball bearing and then maybe a needle bearing [00:38:00] Matt Harvey: needle bearing. Yeah, [00:38:01] Randall Jacobs: has to fit in that really tight form factor. [00:38:04] Matt Harvey: exactly. So. [00:38:07] Randall Jacobs: for all of that. [00:38:08] Matt Harvey: Yeah. So you're talking under a wat it's it's it's per, per bearing. So it's really hard to measure because not very many people have equipment that can measure under a wat, you know, and even a bad bearing is still under a wat, you know, we're talking 0.2 0.2, five Watts per bearing, something like that. So, but so there are some efficiencies of ceramic what that is, you know, I'll let you leave it to your imagination, but it's not, it's not like, full Watts. Let's say it's you know, and my interest, so ceramic bearings in general are always best as you just pointed out right out of the box, and then they go downhill. From, if you will, from there, they, they deteriorate and you have to keep up with servicing XD 15. The reason I really like it, it's, it's more of a longevity story than a wattage story. Well, it is a wad story because they actually get better over time. The balls burnish, the races and they get smoother, but what's nice about 'em is they don't wear out. And if you don't wanna service 'em, you don't have to. So, you can never open 'em up and put grease on 'em. You can just keep riding 'em and they won't get loose or they won't get rough. They might get rough when you get some dirt in them, but the rough, the dirt will dissipate get ground up or come out and it they're fine again. So that's what I like about 'em. They're if you're talking about wattage there's yeah, they're a little bit better, but it's. Almost immeasurable. So right now we're doing some wattage testing on bearings, but how we're able to do it and see the differences is we have to amplify the tests. So we're, overtraining the bearings so that we get out of one bearing. We can get 10 Watts. Actually it's less than that's seven Watts of resistance, but we're over straining this bearing and we'll publish this next year. You'll see it. But in a way to amplify the results. And then we do comparison tests, [00:40:20] Randall Jacobs: and there's some assumptions that need to be made as to whether the relationship between the, load applied and the change in wattage, is it linear? Is it exponential? That's interesting. And I appreciate how transparent you are about this, because it's, it's a question that we looked into when we were developing our wheel line, which use your bearings by the [00:40:40] Matt Harvey: mm-hmm . Oh, [00:40:41] Randall Jacobs: and I had, I had a great conversation. No, thank you. One, you make a great bearing and two you had product available when we needed it, which at that time was, was a big challenge. I had a long conversation with one of your either support people or engineers. I suspect if it was a support person, they have an engineering background cuz they really knew their stuff and talked about the, the different ceramic options and the only one that. That really resonated with me as a potential offering in the future was this XD 15 because of the purported benefits you cite. But listeners should not lose sight of the fact that this is a marginal gain at best in terms of performance. A lot of it is probably coming from the ability to use less restrictive seals and a lighter lubricant in there as opposed to bearings for themselves. But, the, the benefit is there, but if you are unless you are, you know, either riding to the ends of the earth for years on end and want something ultra durable, or you are a high level competitive athlete with a sponsorship and a team car and a mechanic who works on your stuff, ceramic bearings it's not the lowest lying fruit in terms of improving your performance. But at the bleeding edge, if you're going to do it. You would want to do it with something that maintains its performance advantage over time. And that is not true of a lot of ceramic bearings out there. And in fact, quite a few of them are manufactured to a standard such that they're actually worse out of the box than even a traditional steel bearing. [00:42:11] Matt Harvey: Yeah, it, it depends on, so there's a lot of different balls out there. There's only really there's very few factories in the world that make really good ceramic balls, San GOBA, or Panasonic or Toshiba in Japan. And then there's, you, you, there's a lot of balls you don't wanna put in there that are worse than steel balls. So, you know, that's another reason for the price, because if they're really cheap, ceramic bearings, they're probably really cheap for a reason. Cause I know what the price of the balls good balls are, cuz we buy 'em all the time. But that's the first thing is good. Good ceramic balls. You do on sta if you use, so what we're talking about, the other steel, so there's XD 15 steel that we've been talking about, which is called a nitrogen stainless steel. And the other steel that is used almost across the board is called 52, 100 chromium steel. So that's the, it's a that's the steel that everybody pretty much uses in ceramic bearings and it can rust. It's extremely hard. Get it up to like 60 Rockwell, which is really hard. That's why people, that's why factories use it for bearings it's industry standard. But with a ceramic ball, it can wear it out unless you keep up with the maintenance. So that means when the grease is gone, you probably got about two weeks left before that bearing. If you keep riding, if you're running, riding a couple hundred miles a week, you probably. Couple weeks left and then it's gonna be rough. So you gotta keep up with cleaning it and greasing it. And you know, if you clean 'em and grease, 'em ceramic bearings on a regular basis. They, they last a long time and they work. But that's the reality of ceramic bearings with that [00:44:00] Randall Jacobs: Yeah. I look forward to getting some data sets from you because the XD fifteens are actually something that I'm quite interested in for a future offering for us. They're not cheap, but if you, if you actually want to have the benefits both upfront and over time, it is what it costs. Otherwise unless you have a mechanic constantly taking care of your bearings, popping seals and repacking grease, and so on. You're better off with a high quality steel bearing. [00:44:24] Matt Harvey: Yeah, I think so. But you know, I tell people the story. They still buy the regular ceramic bearings all the time. Cuz I, I just can't I come from engineering background, not marketing. So I just kind of tell it like it is, I'll get 'em anyway and they put 'em in and say, you know what, you're wrong. They, they roll better. I can feel it, but you know, that's, I, I get it all the time and it's like, well, it's okay. You know? It's you know, there is a lot of in the mind, especially with bike racers, it is psychological thing, you know, like, if you, if you're on the best bike you think you have, then you probably are faster too. [00:45:00] Randall Jacobs: yeah. There's that? I'll tell you too though. I was friends with the European pro who I was talking. Because I was just coming up and I was never at his level, but asking does it matter all that much? What you're riding and so on. He's like, you honestly, yeah. I wanna win. I wanna have the best equipment, but there's a lot of parody between what's out there and if you pay me enough, I'll ride a shopping cart. [00:45:20] Matt Harvey: Yeah. Yeah. Yeah. If you're strong, you're strong you'll you are gonna win the race. [00:45:26] Randall Jacobs: Yeah. [00:45:27] Matt Harvey: no, it's, that's very true. I agree. [00:45:30] Randall Jacobs: well, I think ceramic bearings, they have a lot of bling factor. So if you say that your product has ceramic bearings in there, it doesn't really matter. If the bearings are better than a non ceramic bearing, it just matters that you can say ceramic bearings. And now you just marked your product. In the case of a wheel set, it's anywhere from several hundred to a thousand or more that you're able to mark that product up because it is perceived as having the best of the best, even if it's not necessarily the case. [00:45:58] Matt Harvey: Yeah. And in, in the case of XD 15 so it, the ceramic ball is perfect for that material. Number one, when we started, there were no XD 15 balls available. So you would have to use chromium steel or four 40 C stainless balls, which is another bearing steel that's out there. But the problem with four 40 C or an unmatched steel ball in XD 15 is at micro weld. And then you do have problems. So with X micro weld is the ball actually under pressure welds itself to the race in certain situations. So for XD 15, you have to run ceramic balls. And the benefits also are that they won't corrode like the XD 15 material. So. They're they're kind of made for each other in, in this instance. [00:46:49] Randall Jacobs: Interesting. It reminds me of a phenomenon with the doors of the space station, where they were finding that the door could seal shut because you had raw aluminum surfaces that had no oxidization on them. And so that it basically would bond and, and weld in that vacuum. [00:47:04] Matt Harvey: oh my God. And then right when alien shows up, you can't get you can't jettison out of the, your [00:47:11] Randall Jacobs: Yeah. So, so thank you for this dive on ceramics. I find it really fascinating and it was no less. So when I was talking to one of your teammates, so let's talk about the bearings that most of us are riding, which is a steel bearing, typically a stainless steel bearing, what goes into a good bearing for all the different applications on the bicycle so this is everything from headsets to bottom brackets and radio bearings versus angular, contact bearings, and so on. What makes the kind of the best bearing for each one of those applications? [00:47:42] Matt Harvey: so it's a really good question. Let's just go to the com most common bearings. The most common bearing in the bike industry is this number 6, 9 0 2. And so that's an industry standard of a bearing in just briefly 6, 9 0 2. The six refers to radio nine is the series. And then, oh two is the internal diameter. That's if anybody's interested, that's how that works. So 6, 9 0 2 though. So it gives you some specificity about the bearing, because that gives you the ID, the OD and the width. However, what's inside the bearing can vary greatly. You can have different size balls, you can have different. So there's no standard on the 6, 9 0 2 as to what it looks like on the inside, but that's the important part, right? So you can buy a 6, 9 0 2 that works in a printing machine. It's very common in big printers and it's going back and forth, or you can put a 6, 9 0 2 and a turbo charger, and now it's going 50,000 RPM. And now you can put it in a hub and it's going 200 RPM. And it has a lot of axial loads that we talked about earlier. So you'd have a different 6, 9 0 2, even though it's a standard bearing in each of those applications. For instance, if you put a bunch of grease, like we do 85% grease fill in a bicycle 6, 9 0 2, because it's only going 200 RPM and you want it full of grease. If you put that in a turbo charger, bearing, going. 40,000 RPM, that grease is gonna fly out and set the car on fire, [00:49:19] Randall Jacobs: I was gonna say, yeah, I was expecting a flammable situation. [00:49:22] Matt Harvey: Yeah. So, for bicycle application, we or I started by designing the inside of the bearing for the bicycle application. So number one, it's got the biggest ball possible, cuz that's your biggest load bearing capabilities to start with that [00:49:41] Randall Jacobs: okay. [00:49:41] Matt Harvey: second you use the deepest grooves possible that you can design around cuz some of 'em are shallow grooves and you have loads side to side loads, axial loads, and you need to support the ball once the ball rolls past the groove and it's on the edge, you're either like doing some damage or it's not supporting how it can. So deepest grooves, largest balls. And then we look at the seals and we do groove type seals. A lot of, so two RS, 6, 9 0 2, 2 RS, two RS litter means two rubber seals. That's but it doesn't tell you what kind of seal. So we do these seals called LL B and L L U. And those are, we actually machine a groove into the seal at that point. And there's two lips that run inside that groove [00:50:33] Randall Jacobs: Machine into the the races, right? [00:50:36] Matt Harvey: yeah. [00:50:36] Randall Jacobs: Where the seal is interfacing with the race? [00:50:39] Matt Harvey: Exactly. And there's always an external groove to hold the seal, but on the ID, there's often just a flat surface that one lip, a two RS seal just rubs against, but it's not very, and sometimes they don't even make contact on cheaper bearings. You know, you can hold them up to the light and see the light shine [00:50:57] Randall Jacobs: oh, wow. [00:50:57] Matt Harvey: well, it's, it's not even making contact. [00:51:01] Randall Jacobs: which means that all sorts of grime and dirt and dust and water is getting in there in a bike application. [00:51:07] Matt Harvey: Right. And so, like our, so our dual lip LL B L O use one lip, keeps the grease in and then the other is kind of a sweeper seal that keeps the dust out from the outside. And then in between the seals, you get some, when you start turning it, the reason for the full grease fill is some grease comes out and that makes an extra grease seal, if you will, on the, on the idea of the bearing. So, that, [00:51:33] Randall Jacobs: inner inner diameter of the bearing. [00:51:35] Matt Harvey: exactly helps keep the moisture from crawling in, or, you know, [00:51:40] Randall Jacobs: The seal is static relative to the outer race, but the inner race is turning be presumably because it's a smaller surface area. So you have less friction [00:51:48] Matt Harvey: Exactly. Oh, [00:51:50] Randall Jacobs: Yeah. [00:51:50] Matt Harvey: engineering mine there. Yeah. So less friction on the [00:51:53] Randall Jacobs: physics, physics nerd. [00:51:55] Matt Harvey: No, that's good. Yeah. And so yeah, and, and the grease so that's the dynamic lip on the inside and the grease. You got kind of a grease barrier there. So on Enduro bearings, you'll have some grease come out and that's a good thing cuz grease is another barrier that catches dust and holds it back from getting inside. So, that's, that's the basics of how we design the bearing. Of course you have to start out with good balls good material, good steel. It's like making bread or you know, food. You, you gotta start out with good ingredients to have good end results. [00:52:30] Randall Jacobs: And when you say good ingredients, you're talking high precision in the formulation, the right heat treatments, really tight tolerances, high hardness that is also consistent across the entire material. And there's all sorts of technologies that make that possible too. There's a lot that goes into a bearing, even if it looks the same as a cheap bearing. [00:52:51] Matt Harvey: exactly. You gotta get the steel from a good Foundry. It's gotta be clean without pollutants in it. And we're lucky cuz we have the industrial side that we, we buy a lot of steel every year. And so we're able to buy from the bigger foundries that supply, the big boys, you know, the big bearing companies, cuz we're a little teeny bearing company, you know, in this, in the universe of bearing companies, but very niche, you know, area. But we do enough that we can buy good steel because of both sides. But yeah, so you start out with really good, 52, 100 or four 40 C or well, XD 15, obviously you have to start out with really good steel and good steel balls and then heat treatment. So for XD 15, that stuff has to be heat treated on ceramic tables in a you have to pull a atmosphere you know, it it's of gas. So to, to do it properly, it's, it's not just in [00:53:50] Randall Jacobs: an atmosphere of gas. Do you mean like you're doing this in a vacuum? [00:53:53] Matt Harvey: yeah. In an inner gas to to keep it stable. [00:53:56] Randall Jacobs: have oxidization or something like this. [00:53:59] Matt Harvey: we do the same with four 40 C and then we do tri cryogenic treatment as well. So you bring it down to almost absolute zero and that normalizes. The steel, so it lasts longer. So these are the things people don't really know about. With four 40 C and XD 15 it's similar heat treatment. Not exactly the same, but it does go from those ceramic table induction heat treatment to cryogenic treatment. And other bearings can be heat treated in like a gas environment without that atmosphere and so forth. That's why they cost less. But you know, there's different processes for different levels of, of bearings. They're not just all the going through the same process says. [00:54:43] Randall Jacobs: yeah. And it's the sort of stuff where even if you have the technical expertise to be able to understand the nuances of this conversation that we've just had. I think the thing to really make clear is that again, two things that look very similar can have very, very different properties in terms of how they perform out the gate and how they perform over time and to make a quality product. Well, when you buy a product, you're essentially trusting that company and that product manager and, and the decision makers on that product to, to really focus on those details. And it's not just the company, it's not just the product manager. It's also, the team at all of vendors. [00:55:18] Matt Harvey: Yeah, there's a lot of things. You know, I obviously go deep here, one other, we do a lot of things that people just don't know about. Cuz you buy it and you see it. And it's like, well, what's the difference between this one and this other one. And we do for the For the suspension, bearings, the pivot bearings, we do a black oxide treatment. And when we do it, it turns the bearing black and people like it, cuz it looks cool, but it's people like black things and it you know, it, there is an advantage to it because it actually does a second heat treatment to the metal besides making it corrosion resistant. But we gotta take those and we gotta grind it off where the ball rolls because you can't have the black oxide treatment where the ball rolls. Well, there's similar products out there and they're black and they're max bearings, but it's almost like a paint that they do, or sometimes it's black oxide treatment, but that they don't take it off the inside of the, where the balls roll. And what happens is if you do black oxide treatment and you leave it on where the balls roll, that stuff rubs off mixes with the grease and makes a nice paste that wears the bearing out faster than if you just didn't do it at. [00:56:29] Randall Jacobs: Yeah, and there's so much of that in our industry. I think that that's something across the board, but we are a highly technical industry. The bicycle is a highly technical product, and there's so much to know in order to do things right, that you can't really expect a rider to know all of this stuff. And so they're like, oh, ceramic, great. Oh, this black coating. Well, it looks like the other one and it's cheaper. Okay, great. I have the, the latest and greatest but I've seen so many examples, so many examples across the industry, including on projects that I have been involved with and didn't have authority over where decisions are made purely for marketing purposes, purely to get you to think that it's a better thing and to spend more money on something that oftentimes at best it's neutral. And oftentimes it actually makes the bike worse in ways that you will experience over its lifetime. [00:57:21] Matt Harvey: Yeah. And it's, it's hard to get, you know, it's hard to get people interested in say bearings sometimes, cuz you don't see 'em on the bikes now they're all buried. Like, you know, new carbon bikes, you, oh, there's bearings inside that thing you, I mean there's not, you know, used to be, you could see a headset, you know? [00:57:39] Randall Jacobs: We used to press them directly into the carbon frame. cuz that was a good idea. There's there's one other thing that I wanted to call out, which I thought was interesting when I was looking through your bearing catalog, which is using different seals on one side of the bearing versus the other and because the, the risk of contamination is always much greater on the exterior facing seal, but the one on the inside. Well there's not much to contaminate there for example, facing the inside of the hub. So you can run a, a seal that keeps the grease in, but doesn't need to be as as tight for water ingress and dust and dust can be lower friction. So even like those little micro optimizations matter. [00:58:17] Matt Harvey: Yeah. And so, you know, if you roll back like 10 or 15 years ago, everybody wanted bearings in their wheels to spin, like, you know, like a metal roller skate wheel, you know, where you spin it and it won't stop or you see those videos, people doing [00:58:33] Randall Jacobs: The YouTube videos look at how efficient my bike is because when, when there's no rider on it and it's up on a stand, it just spins for a long time. And somehow that is a good proxy for how it performs in the wild [00:58:44] Matt Harvey: Yeah. And so if you take the seals out and put sewing machine oil in there, yeah. You can get it. The spin, like CRA you know, old track bikes used to do that. They'd do that. And but it's on a track, you know, but if you're riding out in the rain and stuff so we used to do getting back to your question. We used to do just LL B seals, both sides on the ABAC five bearings, which was real popular wheel bearing. And, you know, in certain environments especially like Vancouver, wet environments, you know, Vancouver, different places where there's a lot more rain. People say, Hey, you know, we're just the water's the grease is getting washed out too quick. We're getting dirt ingression. So we, we always had L L U seals, but L L U if you use a factory, sorry, industry standard, LLL U seal, it's really tight. And [00:59:32] Randall Jacobs: In L L B versus L L U L L U is the, the tighter, [00:59:38] Matt Harvey: medium contact. Yeah. [00:59:39] Randall Jacobs: okay. Yep. [00:59:41] Matt Harvey: Or, [00:59:41] Randall Jacobs: Versus the LLL B, which is [00:59:44] Matt Harvey: light contact. Yeah. LL B light contact, but LL U in the industry is pretty tight contact. So we make it medium contact. So we had to, we reengineered L L U for bicycle industry, basically. So ours is, is medium contact. So it's an acceptable amount of seal friction. If you do it too much, people just don't like the way their wheels spin and it's really sealed. Right. But it just, you know, you spin it and it goes once around and stops. Like if you had a really tight seal in there, so there's compromises [01:00:19] Randall Jacobs: it's kinda like, you want a bike that lasts forever, but are you willing to add that half pound of weight across the entire bike to make it more durable? You know, that's a half pound that I'll add every day, but if you wanna be in the magazine listed at some headline weight, well some people are only looking at that number. [01:00:37] Matt Harvey: Right. Right. And you know, when you, and, and that's a good point if I could just touch on this, like really super lightweight hubs, which people were going crazy, you know, again, 10 years ago with extremely lightweight hubs with really small bearings. And one of my customers did some tests on those hubs, like versus his hubs, cuz they were heavier and he used a thicker axle and so forth. And in some of those hubs, when you're going up a hill, the bearings, the thin bearings, cuz they're so thin, they're only a millimeter. Thickness of the race. They [01:01:15] Randall Jacobs: Oh, they're distorting. Yeah. [01:01:17] Matt Harvey: they're, they're twisting so much that they're actually locking up and skidding. So you, if you're going up a hill, you essentially have a drag break that you're working against and sure. They're light, you know, you just shaved some weight off your bike. But you're working against yourself because that's, that's like the worst case scenario. Now you got a drag break going uphill. [01:01:40] Randall Jacobs: So I think at this point anyone who's made it this far into the conversation should have an appreciation of just how much goes into not just bearings, but the bike generally to make it function as well as it does. And, kind of a sense of the depth of innovation and all the layers of innovation that have to happen at every level, from the steel maker to how it's heat treated to new coatings to how it's assembled. And so on that go into making a product like a 20 pound bike that can go over single track at high speeds, under a heavy rider and do so day in, day out for years on end. I hope also that folks get a sense of. What you compromise when you push up against the limits of that, because technology and material science and so on can take you so far in, in pushing the envelope in terms of performance and weight and strength and so on. But there is a point at which you're compromising something. And so I want to acknowledge how cool it is to hear and detail the innovation that you and your team have done in order to enable the sorts of highly reliable, high performance bicycles that we have today. And then also the transparency on how that process works and the trade offs and so on. And being able to unpack that with you today has been a lot of fun and hopefully has been informative to some of our listeners here. Is there anything else that you think listeners should know about bearings and, and how to think about them and what to look for? [01:03

Our Season One finale is here! Before we get too emo, let's celebrate with 412 Vintage founder, allie xcx! She is known for her eclectic style, and her nine lives on the internet. Pojo asks allie about everything we need to know about having your own shop, developing a healthy relationship with the internet, and just getting excited about expressing yourself through clothes. Shop allie xcx's closet on Galaxy: https://www.shopgalaxy.com/allie-xcx Follow allie xcx: Instagram: https://www.instagram.com/allie.xcx Tiktok: https://www.tiktok.com/@allie_xcx Finding Fashion, powered by Galaxy is an eco fashion podcast that isn't clinically depressing! Finding Fashion is a new podcast that profiles fashion creators and their unique approaches to reversing the damage caused by fast fashion. Each episode celebrates a fashion change maker that is leading the shift by inspiring Gen Z to embrace sustainability in style. Galaxy is a new sustainable way to shop vintage, pre-loved and handmade fashion powered by live video. Visit https://www.shopgalaxy.com/ today! Subscribe now to catch our weekly episodes! Apple: https://podcasts.apple.com/us/podcast/finding-fashion/id1620544734 Spotify: https://open.spotify.com/show/6ULvmf9aHMuNLvmFRYPgXV?si=RLwnNlaYT_C4Y41qB0vXJg Follow, Listen, Watch and SHOP on Galaxy! Instagram: https://www.instagram.com/buyongalaxy/ YouTube: https://www.youtube.com/channel/UC4QI... Tiktok: https://www.tiktok.com/@buyongalaxy Shop: https://www.shopgalaxy.com/ Watch: https://www.findingfashion.com/ Closet Cleanout: https://www.closetcleanout.com/ Follow Pojo: https://www.instagram.com/pojo/ About our host: Pojo is a model and sustainability advocate based in NYC. She grew up in the fashion industry, going to class and then running to castings or runway shows after school. After a decade of modeling, Pojo's perspective shifted – and a passion for sustainability grew out of ethical dilemmas within her career. She wondered, how can a model be a part of the solution, with a history of being an advertisement for the problem? With each episode of Finding Fashion Pojo guides our journey, discussing a more sustainable fashion future with our special guests. Produced by Phoebe “Pojo” Joseph & Perry Landesberg Recorded at Gotham Podcast Studios NYC Videography Geoff Haggray Sound & Video Edited by Patrick Steward

She's cool. She's effortless. She's dressed your favorite singers, and created that knitted hat you saved on Pinterest. Behold, Molly Hayward: founder of NotJustTrash. Pojo sits down with the icon herself, all the way from England, to chat about her personal style journey, growing up with a big family, hand-me-down culture, and more. Molly also discusses growing up online, and how her passion for sustainability resulted in a community of like-minded fashion enthusiasts. This is certainly not just trash! Shop NotJustTrash on Galaxy: https://www.shopgalaxy.com/notjusttrash Follow Molly & NotJustTrash Instagram: https://www.instagram.com/notjusttrash Tiktok: https://www.tiktok.com/@notjusttrash Finding Fashion, powered by Galaxy is an eco fashion podcast that isn't clinically depressing! Finding Fashion is a new podcast that profiles fashion creators and their unique approaches to reversing the damage caused by fast fashion. Each episode celebrates a fashion change maker that is leading the shift by inspiring Gen Z to embrace sustainability in style. Galaxy is a new sustainable way to shop vintage, pre-loved and handmade fashion powered by live video. Visit https://www.shopgalaxy.com/ today! Subscribe now to catch our weekly episodes! Apple: https://podcasts.apple.com/us/podcast/finding-fashion/id1620544734 Spotify: https://open.spotify.com/show/6ULvmf9aHMuNLvmFRYPgXV?si=RLwnNlaYT_C4Y41qB0vXJg Follow, Listen, Watch and SHOP on Galaxy! Instagram: https://www.instagram.com/buyongalaxy/ YouTube: https://www.youtube.com/channel/UC4QI... Tiktok: https://www.tiktok.com/@buyongalaxy Shop: https://www.shopgalaxy.com/ Watch: https://www.findingfashion.com/ Closet Cleanout: https://www.closetcleanout.com/ Follow Pojo: https://www.instagram.com/pojo/ About our host: Pojo is a model and sustainability advocate based in NYC. She grew up in the fashion industry, going to class and then running to castings or runway shows after school. After a decade of modeling, Pojo's perspective shifted – and a passion for sustainability grew out of ethical dilemmas within her career. She wondered, how can a model be a part of the solution, with a history of being an advertisement for the problem? With each episode of Finding Fashion Pojo guides our journey, discussing a more sustainable fashion future with our special guests. Produced by Phoebe “Pojo” Joseph & Perry Landesberg Recorded at Gotham Podcast Studios NYC Videography Geoff Haggray Sound & Video Edited by Patrick Steward

On this episode of Finding Fashion, Pojo gets schooled by Mandy Lee, the trend analyst behind “Old Loser In Brooklyn”. Her TikTok and IG are best described as an Encyclopedia of Fashion, covering everything from emerging trends to brand origin stories and even red carpet analysis videos. She dives into her experience entering the fashion industry, and how she emerged in a space that has always fed on nepotism and exploitation. Mandy also discusses her journey of personal expression through clothes, her own style's definition, and how the death of nuance online jeopardizes the immense need for change in the industry. Follow Mandy Lee: Tiktok: https://www.tiktok.com/@oldloserinbrooklyn Instagram: https://www.instagram.com/oldloserinbrooklyn Finding Fashion, powered by Galaxy is an eco fashion podcast that isn't clinically depressing! Finding Fashion is a new podcast that profiles fashion creators and their unique approaches to reversing the damage caused by fast fashion. Each episode celebrates a fashion change maker that is leading the shift by inspiring Gen Z to embrace sustainability in style. Galaxy is a new sustainable way to shop vintage, pre-loved and handmade fashion powered by live video. Visit https://www.shopgalaxy.com/ today! Subscribe now to catch our weekly episodes! Apple: https://podcasts.apple.com/us/podcast/finding-fashion/id1620544734 Spotify: https://open.spotify.com/show/6ULvmf9aHMuNLvmFRYPgXV?si=RLwnNlaYT_C4Y41qB0vXJg Follow, Listen, Watch and SHOP on Galaxy! Instagram: https://www.instagram.com/buyongalaxy/ YouTube: https://www.youtube.com/channel/UC4QI... Tiktok: https://www.tiktok.com/@buyongalaxy Shop: https://www.shopgalaxy.com/ Watch: https://www.findingfashion.com/ Closet Cleanout: https://www.closetcleanout.com/ Follow Pojo: https://www.instagram.com/pojo/ About our host: Pojo is a model and sustainability advocate based in NYC. She grew up in the fashion industry, going to class and then running to castings or runway shows after school. After a decade of modeling, Pojo's perspective shifted – and a passion for sustainability grew out of ethical dilemmas within her career. She wondered, how can a model be a part of the solution, with a history of being an advertisement for the problem? With each episode of Finding Fashion Pojo guides our journey, discussing a more sustainable fashion future with our special guests. Produced by Phoebe “Pojo” Joseph & Perry Landesberg Recorded at Gotham Podcast Studios NYC Videography Geoff Haggray Sound & Video Edited by Patrick Steward

When you think of secondhand shopping, what comes to mind? Chances are, not $3 YSL shirts and porn star estate sales. Welcome to the magical world of Macy Eleni – aka, the powerhouse behind “Blazed and Glazed!” Macy sits down with Pojo to discuss the in's and out's of full time thrifting, sustainable clothing, and her journey as a fashion influencer. She also opens up about her mental health, and how she shows up every day to live a healthier and happier life. Follow Macy: Instagram: https://www.instagram.com/macyeleni Tiktok: https://www.tiktok.com/@blazedandglazed Youtube: https://www.youtube.com/c/BlazedAndGlazed Finding Fashion, powered by Galaxy is an eco fashion podcast that isn't clinically depressing! Finding Fashion is a new podcast that profiles fashion creators and their unique approaches to reversing the damage caused by fast fashion. Each episode celebrates a fashion change maker that is leading the shift by inspiring Gen Z to embrace sustainability in style. Galaxy is a new sustainable way to shop vintage, pre-loved and handmade fashion powered by live video. Visit https://www.shopgalaxy.com/ today! Subscribe now to catch our weekly episodes dropping in May! Apple: https://podcasts.apple.com/us/podcast/finding-fashion/id1620544734 Spotify: https://open.spotify.com/show/6ULvmf9aHMuNLvmFRYPgXV?si=RLwnNlaYT_C4Y41qB0vXJg Follow, Listen, Watch and SHOP on Galaxy! Instagram: https://www.instagram.com/buyongalaxy/ YouTube: https://www.youtube.com/channel/UC4QI... Tiktok: https://www.tiktok.com/@buyongalaxy Shop: https://www.shopgalaxy.com/ Watch: https://www.findingfashion.com/ Closet Cleanout: https://www.closetcleanout.com/ Follow Pojo: https://www.instagram.com/pojo/ About our host: Pojo is a model and sustainability advocate based in NYC. She grew up in the fashion industry, going to class and then running to castings or runway shows after school. After a decade of modeling, Pojo's perspective shifted – and a passion for sustainability grew out of ethical dilemmas within her career. She wondered, how can a model be a part of the solution, with a history of being an advertisement for the problem? With each episode of Finding Fashion Pojo guides our journey, discussing a more sustainable fashion future with our special guests. Produced by Phoebe “Pojo” Joseph & Perry Landesberg Recorded at Gotham Podcast Studios NYC Videography Geoff Haggray Sound & Video Edited by Patrick Steward

Let's get sh!tty... and crafty! On this episode of Finding Fashion, Pojo sits down with Sam Reece – comedy writer, actress, and creator of Sh!tty Craft Club! Sam chats about her journey as a creative in NYC, and how she found her fashion sense...all while hot gluing rhinestones to any item that needed a little love. Now that, friends, is art! Follow Sam Reece and Sh!tty Craft Club: Website: https://shittycraft.club/ Instagram: https://www.instagram.com/shittycraftclub/ Tiktok: https://www.tiktok.com/@shittycraftclub Youtube: https://www.youtube.com/channel/UCOOl... Finding Fashion, powered by Galaxy is an eco fashion podcast that isn't clinically depressing! Finding Fashion is a new podcast that profiles fashion creators and their unique approaches to reversing the damage caused by fast fashion. Each episode celebrates a fashion change maker that is leading the shift by inspiring Gen Z to embrace sustainability in style. Galaxy is a new sustainable way to shop vintage, pre-loved and handmade fashion powered by live video. Visit https://www.shopgalaxy.com/ today! Subscribe now to catch our weekly episodes dropping in May! Apple: https://podcasts.apple.com/us/podcast/finding-fashion/id1620544734 Spotify: https://open.spotify.com/show/6ULvmf9aHMuNLvmFRYPgXV?si=RLwnNlaYT_C4Y41qB0vXJg Follow, Listen, Watch and SHOP on Galaxy! Instagram: https://www.instagram.com/buyongalaxy/ YouTube: https://www.youtube.com/channel/UC4QI... Tiktok: https://www.tiktok.com/@buyongalaxy Shop: https://www.shopgalaxy.com/ Watch: https://www.findingfashion.com/ Closet Cleanout: https://www.closetcleanout.com/ Follow Pojo: https://www.instagram.com/pojo/ About our host: Pojo is a model and sustainability advocate based in NYC. She grew up in the fashion industry, going to class and then running to castings or runway shows after school. After a decade of modeling, Pojo's perspective shifted – and a passion for sustainability grew out of ethical dilemmas within her career. She wondered, how can a model be a part of the solution, with a history of being an advertisement for the problem? With each episode of Finding Fashion Pojo guides our journey, discussing a more sustainable fashion future with our special guests. Produced by Phoebe “Pojo” Joseph & Perry Landesberg Recorded at Gotham Podcast Studios NYC Videography Geoff Haggray Sound & Video Edited by Patrick Steward

Have you ever had 2 million people commenting on your outfit? On this episode of Finding Fashion, Pojo sits down with model and content creator Maddie White to discuss all things fashion, influence, and up-cycling! Maddie sheds light on what it's like blowing up on TikTok, and how her personal style has progressed over the years. One thing is for sure: you don't need a Celine bag to put together a killer look – maybe just a thrifted blazer, a sewing machine, and a dream.Shop Maddie's closet: https://shopgalaxy.com/maddiewhiteFollow Maddie:Instagram: https://www.instagram.com/madeleinecwhiteTiktok: https://www.tiktok.com/@madeleinecwhiteYoutube: https://www.youtube.com/channel/UCOOlawtxwYTq1MZ0Umoy6fAFinding Fashion, powered by Galaxy is an eco fashion podcast that isn't clinically depressing! Finding Fashion is a new podcast that profiles fashion creators and their unique approaches to reversing the damage caused by fast fashion. Each episode celebrates a fashion change maker that is leading the shift by inspiring Gen Z to embrace sustainability in style. Galaxy is a new  sustainable way to shop vintage, pre-loved and handmade fashion powered by live video. Visit https://www.shopgalaxy.com/ today!Subscribe now to catch our weekly episodes!Apple: https://podcasts.apple.com/us/podcast/finding-fashion/id1620544734Spotify: https://open.spotify.com/show/6ULvmf9aHMuNLvmFRYPgXVFollow, Listen, Watch and SHOP on Galaxy!Instagram: https://www.instagram.com/buyongalaxy/YouTube: https://www.youtube.com/channel/UC4QIZ827i9Qh46FzgmONnSgTiktok: https://www.tiktok.com/@buyongalaxyShop: https://www.shopgalaxy.com/Watch: https://www.findingfashion.com/Closet Cleanout: https://www.closetcleanout.com/Follow Pojo: https://www.instagram.com/pojo/About our host: Pojo is a model and sustainability advocate based in NYC. She grew up in the fashion industry, going to class and then running to castings or runway shows after school. After a decade of modeling, Pojo's perspective shifted – and a passion for sustainability grew out of ethical dilemmas within her career. She wondered, how can a model be a part of the solution, with a history of being an advertisement for the problem? With each episode of Finding Fashion Pojo guides our journey, discussing a more sustainable fashion future with our special guests.Produced by Phoebe “Pojo” Joseph & Perry LandesbergRecorded at Gotham Podcast Studios NYCVideography Geoff HaggraySound & Video Edited by Gelatin Labs

What is sustainability? That's the question on everyone's mind. On this episode of Finding Fashion, we take a deep dive with Isaias Hernandez, the founder of Queer Brown Vegan. He covers everything from intersectional sustainability and climate doomism, to what REALLY goes into making vegan leather and fast fashion popping up in thrift stores. Isaias breaks it all down, and explains how he's cultivated a community of like-minded people who all want to learn more about environmentalism.Follow Isaias of Queen Brown Vegan:Instagram: https://www.instagram.com/queerbrownvegan/Tiktok: https://www.tiktok.com/@queerbrownveganTwitter: https://twitter.com/queerbrownvegan Website: https://queerbrownvegan.com/Finding Fashion, powered by Galaxy is an eco fashion podcast that isn't clinically depressing! Finding Fashion is a new podcast that profiles fashion creators and their unique approaches to reversing the damage caused by fast fashion. Each episode celebrates a fashion change maker that is leading the shift by inspiring Gen Z to embrace sustainability in style. Galaxy is a new  sustainable way to shop vintage, pre-loved and handmade fashion powered by live video. Visit https://www.shopgalaxy.com/ today!Subscribe now to catch our weekly episodes dropping in May!Apple: https://podcasts.apple.com/us/podcast/finding-fashion/id1620544734Spotify: https://open.spotify.com/show/6ULvmf9aHMuNLvmFRYPgXVFollow, Listen, Watch and SHOP on Galaxy!Instagram: https://www.instagram.com/buyongalaxy/YouTube: https://www.youtube.com/channel/UC4QIZ827i9Qh46FzgmONnSgTiktok: https://www.tiktok.com/@buyongalaxyShop: https://www.shopgalaxy.com/Watch: https://www.findingfashion.com/Closet Cleanout: https://www.closetcleanout.com/Follow Pojo: https://www.instagram.com/pojo/About our host: Pojo is a model and sustainability advocate based in NYC. She grew up in the fashion industry, going to class and then running to castings or runway shows after school. After a decade of modeling, Pojo's perspective shifted – and a passion for sustainability grew out of ethical dilemmas within her career. She wondered, how can a model be a part of the solution, with a history of being an advertisement for the problem? With each episode of Finding Fashion Pojo guides our journey, discussing a more sustainable fashion future with our special guests.Produced by Phoebe “Pojo” Joseph & Perry LandesbergRecorded at Gotham Podcast Studios NYCVideography Geoff HaggraySound & Video Edited by Gelatin Labs

Happy Earth Day, and welcome to FINDING FASHION – a new eco fashion podcast hosted by Pojo! On this week's premier podcast episode, we are celebrating the planet and  the efforts of NYC sustainable fashion change makers: Thrift2Death, Green Acre Exchange and Bookie Vintage. They share some epic stories about their favorite thrift hauls, and how they launched successful sustainable fashion businesses. They also spill the tea on what's really happening behind the scenes within the fast fashion industry.Subscribe now to catch our weekly episodes dropping in May!This show is brought to you by Galaxy – a new sustainable way to shop vintage, pre-loved and handmade fashion powered by live video. Visit www.shopgalaxy.com today!About our host: Pojo is a model and sustainability advocate based in NYC. She grew up in the fashion industry, going to class and then running to castings or runway shows after school. After a decade of modeling, Pojo's perspective shifted – and a passion for sustainability grew out of ethical dilemmas within her career. She wondered, how can a model be a part of the solution, with a history of being an advertisement for the problem? With each episode of Finding Fashion Pojo guides our journey, discussing a more sustainable fashion future with our special guests. Follow our guests: Thrift2Death: https://www.instagram.com/thrift2death/Green Acre Exchange: https://www.instagram.com/greenacre.exchange/Booki Vintage: https://www.instagram.com/bookivintage/Follow Pojo: https://www.instagram.com/pojo/Follow, Listen, Watch and SHOP on Galaxy!Instagram:https://www.instagram.com/buyongalaxy/YouTube: https://www.youtube.com/channel/UC4QIZ827i9Qh46FzgmONnSgTiktok: https://www.tiktok.com/@buyongalaxyShop: https://shopgalaxy.com/Watch: https://www.findingfashion.com/Closet Cleanout: https://www.closetcleanout.com/

Liz has been in the fitness industry for over 16 years. She has a bachelors degree in Health Science along with many other fitness certifications. She has worked in all areas of the fitness field- she was the director of corporate wellness at American Express Salt Lake, is a certified pre and natal fitness specialist, has filmed several workout videos for fitness on demand companies, is certified a group fitness instructor and nutrition coach. Liz owns POJO Fitness which is a fitness company that is online and in Arizona. She has her own POJO Fitness app with daily workout programs to purchase, does online macro coaching and is the creator of POJO Power Camp. Power Camp is a high intensity strength & conditioning boot camp. Classes are held in Gilbert and Mesa, Arizona. Liz has been married for 15 years and is a mom of 3. Thru her experiences, Liz has developed training methods and programs that are challenging, unique and fun to help clients break barriers, love working out again and build healthy effective lifelong lifestyle habits to make them better, faster and stronger in all aspects of life. Visit pojofitness.com or on instagram to learn more about Liz's online workout programs, macro coaching and Arizona Power Camp programs.

Pojo and Tippy fangirl over the iconic film, Top Gun.

Shawn is a Vocalist from the Twin Cities based, Derechö. Check them out at https://www.derechoband.com and follow him at https://www.facebook.com/shawn.pohjola.1   Support the Podcast by clicking SUBSCRIBE OR Join the Patreon at https://www.patreon.com/jaredsingerlive Sponsor(s): https://www.MarcoVcigars.com https://www.tone-vault.com/JSE Promo Code: 15SINGER https://www.shooterlube.com Promo Code: SINGER https://www.wehost.wernerelements.com Promo Code: SINGER

In this episode we talk The Batman, military memories, and cinematography with our special guest, Pojo! Be sure to check out Pojo's Indiegogo to support their film project: https://www.indiegogo.com/projects/indictus-short-film-a-senior-thesis-project

In this episode, Brooklyn, Pojo, Taco, and Landry give their individual takes on which tourist destinations across the United States are underrated or overrated.

In this episode, Pojo, Brooklyn, and Taco look at different internet trends such as devious licks, planking, and the milk crate challenge then they try to understand why people get involved with these trends and the consequences for getting involved in said challenges.

In this episode, Brooklyn, Landry, Pojo and special guest Alex Young look into what makes a good national anthem and compare different anthem from different countries.  

In this episode, Brooklyn, Pojo, Landry, and special guest Alex Young look into masculinity good and bad (toxic), and how it is reflected in today's society.

Join Brooklyn, Pojo, and guest Connor to take a look at the U.S education system with some of the flaws and ideas on how to reform them. Music Credit: cali- 1171

In this episode, Brooklyn, Taco, and Pojo with guest Connor Sycuro discuss what the future would be like with space exploration and Mars colonization.

In this episode, Pojo, Taco, and Brooklyn discuss different state slogans and what value they have, in particular, the Nebraska tourism slogan, "It's not for everyone". Then the hosts guess what slogan belongs to which state.

In this episode, Brooklyn, Pojo, and Taco discuss the history of the United Nations. In addition, the podcast discusses problems with the United Nations, like the constant vetoing in the United Nations Security Council and possible solutions. Music Credit: Cali - 1171

In this side chat, Brooklyn, Pojo, and featured guest Landry discuss how some television shows get stale after being on air after numerous seasons. The hosts look into ways to revive these shows and ask the question "would it be better if certain shows ended a lot earlier than be dragged out".

In this side episode, Pojo and Brooklyn with special guest Matt Vescio discuss the flaws with movies inspired by video games. They also explore the director's creativity liberties and discuss the common phrase "the book is better than the movie".

In this episode Brooklyn, Pojo, and featured guest Landry discuss what makes a villian iconic as well as how can a villian be iconic in a movie.

In this episode Pojo, Taco, and Brooklyn discuss different odd criminal organizations and why people commit crime.

In this episode, Pojo and Brooklyn talk about whether or not Omaha, Nebraska should have a major league team in a major league franchise (NHL, MLB, NFL, NBA, and MLS). In addition, they talk about which league Omaha would likely be in. Finally, the podcast debates what potential team names Omaha could have.

As season one of Models That Eat: The Podcast comes to a close, MaKayla McRae (aka the Starry Eyed Mystic) sits down with Pojo to sip some oat milk, chow down on some classic Dough donuts, and discuss her modeling-gone-astrology career! She talks about her journey growing into her intuitive practice, creating energetic boundaries online, and her relationship with food. It is a pleasure to wrap the season up with such an insightful and pure soul. Enjoy!watch this episode + more on YouTube: https://www.youtube.com/channel/UCNx3ENkOieKfOebVAMkK5KAjoin us on Patreon for more bonus clips from the podcast! ~ https://www.patreon.com/modelsthateatmodels that ate:MaKayla ~ https://www.instagram.com/thestarryeyedmystic/Pojo ~ https://www.instagram.com/pojo/recorded at Gotham Podcast Studiobrand partner curation by Amy Maziuspodcast artwork by Eden Redpath ~ https://www.edenredpath.comanimation + motion design by Grace Wiehl ~ https://www.gracewiehl.commusic by Mia Gladstone ~ https://www.instagram.com/miagladstone/NEDA resources:Hotline information ~ https://www.nationaleatingdisorders.org/help-support/contact-helplineHelp and Support resources ~ https://www.nationaleatingdisorders.org/help-supportsocials:models that eat ~ https://www.instagram.com/models.that.eat/Pojo ~ https://www.instagram.com/pojo/general inquiries: pojo@modelsthateat.compartnership opportunities: amy@modelsthateat.com

Introduction to the Brookside Chats with Brooklyn, Surpeme Taco, and Pojo.

Pojo sits down with international sensation Abdulaye "AB" Niang over Ramune sodas and Japanese snacks in a tell-all about his relationship with the modeling industry. AB discusses his travels, passion for creativity, and how he has pivoted his career to design a profitable community – and even gives us some insider details on what's to come from his brand!watch this episode + more on YouTube: https://www.youtube.com/channel/UCNx3ENkOieKfOebVAMkK5KAjoin us on Patreon for more bonus clips from the podcast! ~ https://www.patreon.com/modelsthateatmodels that ate:AB ~ https://www.instagram.com/abdulayeniang/Kill Complacency ~ https://www.instagram.com/killcomplacency/Pojo ~ https://www.instagram.com/pojo/filmed by Camille Opprecorded at Gotham Podcast Studiobrand partner curation by Amy Maziuspodcast artwork by Eden Redpath ~ https://www.edenredpath.comanimation + motion design by Grace Wiehl ~ https://www.gracewiehl.commusic by Mia Gladstone ~ https://www.instagram.com/miagladstone/NEDA resources:Hotline information ~ https://www.nationaleatingdisorders.org/help-support/contact-helplineHelp and Support resources ~ https://www.nationaleatingdisorders.org/help-supportsocials:models that eat ~ https://www.instagram.com/models.that.eat/Pojo ~ https://www.instagram.com/pojo/general inquiries: pojo@modelsthateat.compartnership opportunities: amy@modelsthateat.com

Pojo sits down for a solo episode to eat some Gigantic vegan candy bars, try some new Just Water flavors, and talk about what the modeling industry taught her about herself. From a scouting horror story in Paris to facing rejection in NYC, she chats about the importance in knowing who you are from the jump, and not taking others' comments so seriously (warning: some tears may be shed in the process...)watch this episode + more on YouTube: https://www.youtube.com/channel/UCNx3ENkOieKfOebVAMkK5KAjoin us on Patreon for more bonus clips from the podcast! ~ https://www.patreon.com/modelsthateatmodels that ate:Pojo ~ https://www.instagram.com/pojo/filmed by Bianca Castellar Calvanirecorded at Gotham Podcast Studiobrand partner curation by Amy Maziuspodcast artwork by Eden Redpath ~ https://www.edenredpath.comanimation + motion design by Grace Wiehl ~ https://www.gracewiehl.commusic by Mia Gladstone ~ https://www.instagram.com/miagladstone/NEDA resources:Hotline information ~ https://www.nationaleatingdisorders.org/help-support/contact-helplineHelp and Support resources ~ https://www.nationaleatingdisorders.org/help-supportsocials:models that eat ~ https://www.instagram.com/models.that.eat/Pojo ~ https://www.instagram.com/pojo/general inquiries: pojo@modelsthateat.compartnership opportunities: amy@modelsthateat.com

Joe Bartnick of PuckOff Podcast returns for another Soft Dump to recap an eventful week of Penguins hockey heading into the final regular season home stand with Geno Machino back in the lineup and Tristan Jarry coming into his own, much better than Casey DeSmith's glove to say the least. Plus - Bring back PoJo for the playoffs, and the reign of Terrible Tom Wilson continues.

Quadruple threat Tiff Baira (model, singer, dating coach and Tik Tok star!) joins Pojo for some Cafe Aroma espresso, pineapple pizza, and a refreshingly honest chat. Tiff touches on having a platform online, learning to navigate the internet, self care when dating and her personal journey to wellness.Shoutout to Cafe Aroma for sponsoring this episode of Models That Eat: The Podcast! Check out their Instagram and site to snag some of their coffee essentials (Pojo recommends the espresso cup and saucer set, for all your caffeine needs;)Check it out! Cafe Aroma on Instagram: https://www.instagram.com/thecafearoma/shop Cafe Aroma: https://www.cafearoma.com/watch this episode + more on YouTube: https://www.youtube.com/channel/UCNx3ENkOieKfOebVAMkK5KAjoin us on Patreon for an extra 30 minutes of this conversation with Tiff, and many more bonus clips from the podcast! ~ https://www.patreon.com/modelsthateatmodels that ate:Tiff ~ https://www.instagram.com/tiffbaira/Tik Tok ~ https://www.tiktok.com/@tiffbairaPojo ~ https://www.instagram.com/pojo/filmed by Bianca Castellar Calvanirecorded at Gotham Podcast Studiobrand partner curation by Amy Maziuspodcast artwork by Eden Redpath ~ https://www.edenredpath.comanimation + motion design by Grace Wiehl ~ https://www.gracewiehl.commusic by Mia Gladstone ~ https://www.instagram.com/miagladstone/NEDA resources:Hotline information ~ https://www.nationaleatingdisorders.org/help-support/contact-helplineHelp and Support resources ~ https://www.nationaleatingdisorders.org/help-supportsocials:models that eat ~ https://www.instagram.com/models.that.eat/Pojo ~ https://www.instagram.com/pojo/general inquiries: pojo@modelsthateat.compartnership opportunities: amy@modelsthateat.com

Natalia Castellar Calvani joins us on Models That Eat: The Podcast to try mochi ice cream for the first time, taste test wine, and discuss all things modeling! She dives into her upbringing as a Puerto Rican woman, navigating the internet after going viral, industry highlights/horror stories and so much more. watch this episode + more on YouTube: https://www.youtube.com/channel/UCNx3ENkOieKfOebVAMkK5KAjoin us on Patreon for an extra 30 minutes of this conversation with Natalia, and many more bonus clips from the podcast! ~ https://www.patreon.com/modelsthateatmodels that ate:Natalia ~ https://www.instagram.com/nataliacastellarcalvani/Pojo ~ https://www.instagram.com/pojo/filmed by Bianca Castellar Calvanirecorded at Gotham Podcast Studiobrand partner curation by Amy Maziuspodcast artwork by Eden Redpath ~ https://www.edenredpath.comanimation + motion design by Grace Wiehl ~ https://www.gracewiehl.commusic by Mia Gladstone ~ https://www.instagram.com/miagladstone/NEDA resources:Hotline information ~ https://www.nationaleatingdisorders.org/help-support/contact-helplineHelp and Support resources ~ https://www.nationaleatingdisorders.org/help-supportsocials:models that eat ~ https://www.instagram.com/models.that.eat/Pojo ~ https://www.instagram.com/pojo/general inquiries: pojo@modelsthateat.compartnership opportunities: amy@modelsthateat.com

Camille Opp joins Pojo as the first guest on Models That Eat: The Podcast! She eats potato chips, sips Recesss, and talks about her modeling career that brought her to New York City. Camille touches on how coming out affected her life experiences, and how she balances her physical and mental health in a tumultuous industry.Get 15% off of your order of Recess CBD beverages with code "MODELSTHATEAT" :http://bit.ly/3kJGoiBwatch this episode + more on YouTube: https://www.youtube.com/channel/UCNx3ENkOieKfOebVAMkK5KAjoin us on Patreon for extended podcast clips, community conversations, and so much more! ~ https://www.patreon.com/modelsthateatmodels that ate:Camille ~ https://www.instagram.com/camilleopp/Pojo ~ https://www.instagram.com/pojo/filmed by Mimi Joseph and Lauren Lakerecorded at Gotham Podcast Studiobrand partner curation by Amy Maziuspodcast artwork by Eden Redpath ~ https://www.edenredpath.comanimation + motion design by Grace Wiehl ~ https://www.gracewiehl.commusic by Mia Gladstone ~ https://www.instagram.com/miagladstone/NEDA resources:Hotline information ~ https://www.nationaleatingdisorders.org/help-support/contact-helplineHelp and Support resources ~ https://www.nationaleatingdisorders.org/help-supportsocials:models that eat ~ https://www.instagram.com/models.that.eat/Pojo ~ https://www.instagram.com/pojo/general inquiries: pojo@modelsthateat.compartnership opportunities: amy@modelsthateat.com

Pojo pops a bottle of 2008 Saint Chamant champagne to celebrate the first episode of Models That Eat: The Podcast! She discusses her 10-year journey in the modeling industry, the realizations along the way, and what Models That Eat is all about. Cheers to the beginning of an exciting journey together!watch this episode + more on YouTube: https://www.youtube.com/channel/UCNx3ENkOieKfOebVAMkK5KAjoin us on Patreon for extended podcast clips, community conversations, and so much more! ~ https://www.patreon.com/modelsthateatmodels that ate:Pojo ~ https://www.instagram.com/pojo/filmed by Mimi Joseph and Lauren Lakerecorded at Gotham Podcast Studiobrand partner curation by Amy Maziuspodcast artwork by Eden Redpath ~ https://www.edenredpath.comanimation + motion design by Grace Wiehl ~ https://www.gracewiehl.commusic by Mia Gladstone ~ https://www.instagram.com/miagladstone/NEDA resources:Hotline information ~ https://www.nationaleatingdisorders.org/help-support/contact-helplineHelp and Support resources ~ https://www.nationaleatingdisorders.org/help-supportsocials:models that eat ~ https://www.instagram.com/models.that.eat/Pojo ~ https://www.instagram.com/pojo/general inquiries: pojo@modelsthateat.compartnership opportunities: amy@modelsthateat.com

Pojo walks us through her career as a model and how she’s navigated growing her own brand, Models that Eat, as a safe space for models dealing with eating disorders, body image issues, and other social dilemmas within the modeling industry.

Shawn is a Vocalist from Minneapolis, MN and one of two Vocalists from the Twin Cities based, Derechö.  Check them out at https://www.derechoband.com and follow him at https://www.facebook.com/shawn.pohjola.1 #ExtravaganzaFullEpisodes #JaredSingerExtravaganza Support the Podcast by clicking SUBSCRIBE  OR Join the Patreon at https://www.patreon.com/jaredsingerlive Sponsors: https://www.shooterlube.com Promo Code: SINGER

It was a weird week off for the Pens who fell victim to the NHL's COVID-19 protocols due to an outbreak within the Devils organization, but it gave the Pens blue line some much needed time to rest up and get healthy. Comedian and host of Puck Off podcast Joe Bartnick sings PoJo's praises, gives a final stick tap to GMJR, and looks ahead to the new Penguin regime under Patrik Allvin in the interim and maybe beyond.

V prvem letošnjem Avtomatu sem še pred prazniki ujel enega od glavnih akterjev slovenske ledene pravljice. Žiga Pavlin mi še potoži, kako se mu je Jaromir Jagr za polomljena rebra in počeno ledvično ovojnico opravičil po sms-u. Pohvali ženino petje, debatirava o masažnih sedežih v avtomobilih in sprehodih po švedskih peščenih plažah.

Tiff and Phoebe “Pojo” Joseph, creator of Models That Eat and 2020 Dazed 100er, give you a behind the scenes look into the modeling industry — all the good, the bad and the toxic. Speaking from opposite sides of the spectrum (Pojo as a veteran model and Tiff as a fresh face), they discuss the prevalence of eating disorders in the industry, the bravery it takes to say no in bad situations and the strength needed to dismantle preconceived notions. They also delve into the importance of self-care, the stigma that comes with age-gap relationships, their aversions to Twitter, the body hair debate and the power of creating your own identity independent of your past, your work and your relationships.

Den 1 juni 1919 trädde förbudslagen i kraft i Finland. Nu skulle finländarna överge spriten för en trygg arbetsmiljö och ett lugnt familjeliv. Men de nya bestämmelserna fick motsatt effekt då alkoholbruket istället nästan tredubblades. Myndigheterna såg hjälplöst på då skärgården förvandlades till arenor för massiva smugglingsoperationer och gängkriminalitet. Följ med Veronica & Anna till 1920-talets Finland som vi vid sidan om växande ekonomi och sociala reformer också minns som förbudstiden. I avsnittet medverkar historieläraren Jimmy Holmberg. Källor Jimmy Holmberg: Lokalt och lagom nyktert: Aktörer, popularitet och målsättning i nykterhetsföreningar i Pojo 1887–1919. (2017) K. Kilpiö, H. Kuusi, M. Peltonen: Alkoholin vuosisata : suomalaisten alkoholiolojen vaiheita 1900-luvulla. (2006) Aija Kaartinen: Kansan raittiudeksi ja kotien onneksi : naisten kieltolakimielipiteet ja toiminta kieltolain puolesta ja sitä vastaan 1919-1932. (2011) Kustaa Vilkuna: Juomareiden valtakunta: suomalaisten känni ja kulttuuri 1500-1850. (2015)

In today's episode, I talk to Pojo of Models That Eat about the dangers of the "model diet", systematic oppression of fashion models, and social conditioning that shapes our media. Connect with POJO: Website: www.modelsthateat.com Pojo's Instagram: www.instagram.com/pojo Models That Eat Instagram: www.instagram.com/models.that.eat Models That Eat on YouTube: https://www.youtube.com/channel/UCNx3ENkOieKfOebVAMkK5KA FOLLOW ME ON INSTAGRAM FOR UPDATES - www.instagram.com/katenoel__

Zboru, ki je bil ustanovljen 20. aprila 1944 v vasici nad Semičem, so rekli tudi Pojoča četa. Njen naslednik je Partizanski pevski zbor, ki letos praznuje 75-letnico. Spoznajmo dirigenta Iztoka Kocena, predsednika Jožefa Roškarja, tajnika Dušana Kulovca, harmonikarja Branka Sladiča in pevce, ki sta se jim v zadnjih tednih na vajah in koncertih pridružila novinarka Tatjana Pirc in tonski mojster Vjekoslav Mikez.

In the last episode, we spoke a lot about the "why?" behind microstates. This time we wanted to cover how ideas in Microstates map to different patterns used to build JavaScript applications using frameworks like React, Ember, Vue and Angular. We discussed what you need to know about Microstates if you prefer component state architecture or global store architecture like Redux, as well as how setState in React can be refactored to use Microstates. We closed off with the comments about the trade offs that component heavy frameworks make by overemphasizing the view layer at expense of other aspects of the MVC pattern. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Upcoming Conference Talks: Manhattan.js - August 8th (Taras) ReactJS Austin August 6th (Charles) Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode #107. My name is Charles Lowell and we are going to be following up with our Episode 106 with the exciting conclusion of 'Microstates, the Podcast.' With me today to wrap this subject up, at least for the near term, obviously we're going to be talking about it a lot in the days and months to come, are David and Taras, also co-developers here at Frontside. Hello guys. TARAS: Hello, hello. DAVID: Hi everyone. CHARLES: Before we get into that, we'll just make a few quick announcements. First off is here at Frontside, we are going to be having some availability at the end of August. If you or anyone on your team is looking to level up in the area of testing, especially testing single page applications, acceptance testing single page applications or if you need React or general JavaScript consulting, please get in touch. We would love to work with you and love to do some of the great things together. Second, we finally released this and this is germane to the topic at hand. We released a major version of microstates this week that's based on a new and simpler architecture. That's really exciting. It doesn't really change the content of the conversation because the API hasn't changed that much. It just means that the library, which was already very small is even smaller. I think we shaved almost 40% of the size off and it's just much simpler and it's much more harmonious with the underlying JavaScript runtime. It's even more just simple JavaScript objects. Unless there's any other news that you want to cover, we'll jump right into it. TARAS: All right. Let's do it then. Let's do microstates. CHARLES: I Love to talk about microstates. This is obviously the second podcast that we're doing on microstates, just because we ended up, I think it was two weeks ago and we'd been speaking for almost an hour and really, we're just laying out the problems that microstates solve -- the problems of state management and why you often run up against complexity when you have a single state management tool that doesn't account for a bunch of different use cases. We got into microstates a little bit but we left it as kind of a cliffhanger. We talked about transactionality and laziness and immutability, ease of composition, simplicity of API, performance, memory footprint, things like this. Those were all the problems and then we're like, "Yeah, microstates. It's awesome." We're going to talk a little bit more about actual microstates proper and what is involved like the adjustments in mindset that you need to make or don't need to make when adopting a tool like microstates. TARAS: Actually, it's been really interesting for me because I just gave a talk at Toronto JS on microstates and it was pretty cool to see. There was a panel at the end. I think the people that are representing just using component state as a way of architect implication. It was managing state and application and it's representing redux. It's really interesting to see, first of all, like how curious people were. Most of questions were directed to the discussion around microstate, simply because it is a new tool but it was also just interesting to see how curious people who really loves redux, he was like, "I really love redux but I really like that fact that you guys have types," so I was like, "Oh, that's cool." Even though you really liked your solution, you actually found something in microstates interesting but at the same time, I think he was kind of missing that what aspects of Microstates overlap with redux. I think one of the things that we can do today is talk about what microstates has and what API does microstates provides and how similar they are to what people already know. I think that's one of the things that I was thinking about this conversation is that there are some things around microstates API like how to use microstates but the architectural concepts that power a microstates, they are already part of the development process and development architectures for most people that building single page applications. I think we can do is try to map these ideas not what people really know and patterns that they use to ideas in microstates, just to show how close we actually are. I think that's a good way for us to go. CHARLES: I guess we can start with, maybe one particular mode of managing state and then, how that maps to uses with microstates. TARAS: Let's start with components state because that was kind of our starting point. One of the original starting points for microstates because so much of our work was in Ember and component state is where most of Ember development happens. I think that's a good place to start. If you're someone who uses components state, if you're using Ember or Vue without something that is redux-ish which is pretty common these days, if you use components state, then one of the features of -- CHARLES: And also, if you're using React, right? Ember, Vue and React pretty much are all the same in this regard. TARAS: Yeah. Well, Ember and Vue are a little bit different in that behalf. Their particular pattern is you have data coming into the component, then you're doing some work with the data so that in Ember and Vue, you might use computed properties to derive state on that and then you might pass that state further down into other components. In React, you would do something a little bit different because there is no memorized computed properties by default, so you, a lot of times, write your computations that you pass into other computers that are written as expressions in JSX. If you're using this pattern, then one of the challenges around using this pattern is the process of lifting state becomes quite complicated. Because if you have like a bunch of state that lives in the component, it's attached to your derivation of state and the properties that you can invoke are attached to a component object. In React world, it's called lifting state. In Ember world, it'd be essential refactoring it into the parent component and passing that state in. in microstates, you're essentially moving this state into the microstate and now, what you have is this object that instead of having the state live on the component, the state now lives on the microstate object and in all frameworks, when you do that in microstates, you can use the getters to get the memorized computed properties behavior on the microstate. If you use your computed properties, computed properties are available for you on the microstate. You can do it the same way. CHARLES: It's kind of like a wrap up of that idea, not a wrap up but a summary of that idea is that the microstate essentially is a substitute for your component properties. If you're working with a component, a component has state associated with it, so you're setting properties on a component and then using the computed properties of that component. Microstates is you have all those benefits where you can set properties directly. You can define methods that like set properties as part of a transaction and you can then have simple JavaScript getters, which are just like computed properties except there's no enumeration of dependent keys. It's just, that's all they do for you. TARAS: Then the next question that arises is like, "Do I make like one huge microstate or a bunch of smaller microstates?" I think the question is really depends on the role of your component and what's nice thing about microstate is in microstates, there's two things that are kind of cool. One is when you represent your status in microstate, it makes it very easy. If you need to lift that state from the component up into the parent, you can lift that type. You can take that type and you can compose that type into the parent's microstate, if you have to and in that case, you would pass this new object that's created from that type. You'd pass the state for that component to the component that would otherwise have its own state. Essentially now, the parent has the state that would otherwise be in a child component and now, the parent is passing a state from the parent to the child. There's two kind of benefits to that. One is it gives a parent a way to control the state of the child and it also gives you a really easy way to serialize and deserialize state. You start off with having ability to serialize state for a particular component and all of his children, now you can represent that serialized state as part of the components state, so you have an easy way to restore the state of the component tree at the parent component. CHARLES: Right and that's possible because a microstate is really just encapsulating a value within a type but the value is just a simple serializable plain old JavaScript object, right? TARAS: Yeah. CHARLES: I'm just not trying to say like this is the feature that microstate provide, so when you're creating a microstate, you just pass it a POJO and it off to the races with that POJO and you can access that POJO at any single point. TARAS: Yeah. This is part of the architecture that I think are helpful for people that are using components. Is there anything else for people who are using components state that we think would be helpful? CHARLES: I think we're just realizing that you get the benefit of the laziness and immutability and the transactionality and all kind of things that we talked about last time but actually, the mental model is very similar. I think the thing to realize is that if that's the way that you used to working with state, the bridge is not too far. It's actually quite a short one. TARAS: Yeah, that's good. CHARLES: It feels very natural. It's not a huge mental shift. It's just more about a very small mental shift, a very small shift in mechanics for a very large payoff. DAVID: For instance, say you're in an Ember application using component state, what I'm used to is you're going to be passing actions around between components. Whenever you're trading that out for microstates, is it more that these actions are just bundle in with the microstate as the transition? TARAS: Yeah. One nice thing with the microstate, because the transitions that you can perform on any data type are intrinsic to the actual data type, the part of the data type, when you instantiate a microstate, you get these transitions for free. When you pass the object into a component, you can now invoke transitions on that object, that are part of that object's type. It's hard to imagine how awesome that really is because the closest pattern that you would see for that would be like, for example, if you're using Ember, you have Ember object or Ember model that you pass into a component and then, you can work a transition and because it goes through the Ember data store, your component is going to update. With microstates, there's no observation of any kind but what you're doing is when you are invoking the transition, transitions going up to the top of the root and gives you the next microstate, which updates your component tree. You get that functionality of 'data-down, actions-up'' built into the entire system of the microstates and all of that is hooked into these transitions that you can invoke on the objects that you pass into your components. CHARLES: Right, maybe David and Taras, you all could provide a concrete example of what that looks like. Because I think it is something that when I was giving talks on microstates at Ember meetups, one of the first things I like to show is you've got all these actions that you're writing either on your router or your controller but they're really actions manipulating the same type of data. It really comes down to like you're pushing and popping things off of arrays, you're toggling Booleans, you're incrementing counters, you're setting this property on this object. These are actions that we're writing and in the kind of microstates world, that's boilerplate. Because the transitions are intrinsic to the data type of the microstate that you're working with, maybe we could provide an example, like what's an action that you describe that you would pass around. TARAS: I think an easier one would be like if you have a model for example, you're composing a model into your application state or you're compose a model into your components state, so you have this model type that gets instantiated and you pass it into component that represents a model. Off that model, you might have open status like is it open or not that gets consumed by the model component, to know whether the model should be visible. Then along with that is model is open state, there is a toggle transition that you can find inside your component that is going to automatically flip the visibility of open. What will happen when you bind that transition to some kind of action handler that you invoke inside your component, when you invoke that action, it will then trigger transition at the top of that microstates and then, it will create the next state, push it through which will cause your model to change the visibility. David, that does answer the question? DAVID: Yeah, it does and that's actually the example that I have come up with whenever asked. A very simple sort of Boolean toggle. CHARLES: In a couple of my earlier demos, I should dust off that talk that I gave to the Austin Ember meetup where I was able to create an input with a dropdown menu with basically, some pretty advanced mouse behavior, all without having any component state or like storing it all in microstates and a lot of pushback was, "Aren't you putting logic in the template?" and the answer is, "Absolutely not." The logic is in the models but what I'm doing is I'm composing the actions that operate on those models inside the templates but at the template level, the action is data. If you're thinking about, we always want to have, we always want to lift state and then push that state down to the application, what this is really saying is that the actions are part of the data. It is implicit to the value that you've got. TARAS: I think that's really powerful because we do think about actions as being something that you can invoke. Like with closures, it's an action that you can invoke but considering that operation, that piece of data that invokes a transition in microstates and is derived from the type of the data, I think it's a cool concept. That's probably, one of the things that is kind of new for microstates but how you use it in your application should feel pretty much the same as you would if you were creating action handlers on your components. CHARLES: Yeah, just like kind of bundled action handlers for free. TARAS: Right. CHARLES: Maybe the way that you wrap up on this one when talking about kind of what microstates has to offer for the Ember developer, the Vue developer is really, I would say someone who's used to working with like MobX. Would be another good example is when I first started using Ember back in 2012, Ember Object solved a whole lot of issues in a really profound fundamental way and I really, really was drawn to that as the best API to be working with state. What kind of became apparent was perhaps not the best implementation. This is not like bag on Ember Object. I think it was actually amazing technology for seven years ago when most of it was written and probably, even came from before like SproutCore. It's almost 10 years old, which is incredible but it's still under heavy use in 2018 and it speaks well of how well it was constructed. I actually don't have much of a problem with Ember Object API. I just think that the way in which it's implemented that API means that there are some problems that require a different paradigm, so very much I kind of see microstates as heavily inspired by those types of APIs but with, I want to say a modern implementation but an implementation that is designed to solve the problems that have come to light over the last five years of developing single page JavaScript application. TARAS: I want to add that, when you describe with Ember Object, it exists in every framework that uses immutability. In MobX, the observation introduces the necessity to wait for a bunch of things to resolve. In Angular zones, I saw a similar purpose to ensure that if there are kind of cascading or streams or all of that stuff gets settled in into kind of restful state before you can start to assert on what's going on and with Vue, their computed properties has something similar. I think because of the complexity of having to track lots of objects and then recomputing things based on the result, that complexity in microstates is simplified by the fact that you describe you transitions. When you write them, you describe exactly what changes, so we don't need to wait for things to settle down. When you invoke a transition, that transition is explicit and based on the path of where that transition is invoked, we know exactly what needs to change, so we need to only perform one operation to compute the next state. There is no other things that we need to wait. There's no other side effects that we need to resolve before we know what the final status. I think that simplicity can be applied to all the frameworks that are using immutable APIs and derived computations from those immutable APIs. CHARLES: Uhm-mm [affirmative]. TARAS: Should we jump into talking about what microstates has to offer for people familiar with redux? CHARLES: Yeah, okay. Let's jump right into it. For folks who are familiar with immutable APIs like Ember, like Vue, like other ecosystem using MobX, a shift to microstates might feel like what you can expect. What about people who are just using often React-land and they're just using like set state. TARAS: Set state is a little bit tricky because it does get complicated over time and then you get this kind of funky things going on after a while where you start seeing things like, "I'm going to set state on this component and then once the change happens, I'm going to change some states some other state," so this kind of cascading state changes. The other part that I find particularly more challenging in set state world than it is in, I think in regular components state, like what you have with Vue and Ember. I feel like the way that the transitions, the state change handlers become part of the component, I find that part particularly kind of fragile. When you start doing refactoring, when you need to lift up state, it's like -- CHARLES: What's an example of this? TARAS: When you start off and your component owned old state and now, you need to have that state being controlled by the parent, we get into a situation where like, "What am I going to do? Am I going to do something with props as they're coming into the component or I should probably just flip that state from the child to the parent?" and now, you're refactoring the internals of a component to lift up that state so you can then combined those operation with the parent's state transitions. But then, you have this kind of added complexity of the fact that you're working with immutable data in that place. You've got these three things going on: you're refactoring your child component, you are moving these things into the parent components, you modify a parent component and now, you're also managing the complexity of forming immutable objects. I think the fact that people make it work is kind of a testament to human resilience. The people are able to solve such challenging problems and this is not a super hard one but when a component is complex enough and when stakes are high enough, these changes can become fragile. This is what I think microstates simplifies is that by taking care of the model, it makes components much simpler and makes it possible for you to just render a lot of components that are functional components without their own state. CHARLES: It actually reminds me and like I said, we're talking about what it's like to use them, not so much the implementation but that's the exact same sentiment that the author expressed in his book that was very helpful in writing microstates, which is Brian Marick. He has this book called 'Lenses for Mere Mortals' and he's talking about the practical use cases of using lenses, which microstates leans very heavily on. What he says right in the introduction is it gives you by abstracting the location and compose it the way in which your data structures are composed, it makes them very refactorable. You can say, "I want to change where the state lives. I want to change the structure of this object and I want to move it somewhere else," and it's sounds weird to say this, because the structure of the object is not coupled to the structure of the object, it means that it's very malleable, so you can move and you can say, "You know what? I don't want this address to be embedded in this person. I want this address to be inside this address book and then my person has an address book entry." Being able to make those refactors make those changes is very easy because your method of accessing the data is abstracted. It's something that applies beyond even user interface as a component state but it's something that this is a problem that's very salient when you are authoring complex UIs and compose components. It's something that you can benefit very greatly from. DAVID: Taras, you were telling us earlier about a friend of yours who is learning React for the first time over the past few months and he's mainly been using set state as you would just starting out in this world. You said that he didn't really get why you might have to go and learn some other way to manage your state and I think Charles said it, whenever your application starts to get more complex and you've got a lot of different moving parts, that's really where microstates will come out and shine for you. TARAS: Yeah. My friend kind of feel bad because he's spent the last three months learning how to work with React and how to use set state, "And now, you're telling me, I need to learn something else? Like I'm going to start from scratch?" I kind of reassured him that especially when you're a beginner, when you're learning, you learn how to address very specific challenges but you don't know how complicated these things can get when your UI gets really intricate. In those intricate scenarios is when you have to leverage your experience and you'll be able to solve these problems but if you're learning, you encounter these challenges head on and your tool does not really, like set state. Although it can be used to build really complex UIs very effectively but the complexity that over time increases as you start to manage the state, increases much more later on than does early in the beginning. Basically, with microstates, even if you have some basic proficiency with set state, when you start working with microstate, the things that you can do with microstates, you will be able to do more sophisticated things easier when you need to use them than you might realize when you start. Because microstates API is so consistent, there are a very few concepts to actually learn and they cover a broader range of use cases so when you actually starts using it, you'll encounter these challenges. What you already know it will just work for you and always just continue to work for you. That was part of kind of fundamental design on what Charles and I have spent, a lot of time putting into place from a point when we started two years ago. CHARLES: I think, and you touched on this and this is kind of what I was speaking to earlier is that when you're working with a simple system, it's simple, it's easy to work with and then the complexity starts to grow, it's never a good thing when you have to reach for a more complex tool to manage the complexity. It's a hallmark of a good system and that it can scale with you from a very simple and easy use cases to actually being able to handle very large and complex use cases but your API doesn't have to change and your usage doesn't have to change. If you have a tool that can actually scale with you from a one liner to a hundred thousand liner, that reflects very well on the design of the tool. I think you see that with things like Ruby, you see it with things like Clojure. You see it with, I would say there's even people writing like Haskell, shell scripts now but not so much with like C++. I think the analogy is very similar with microstates in the sense that when I'm looking for evaluating a language, it's not the only thing I look for but I really am looking like how is this going to work for me as a one liner? How's it going to work for me as a hundred thousand liner? If the answer is pretty consistently, then that's something that is going to get a lot of bang for your buck, so to speak. If I invest the time in learning it, I'm actually able to reap the reward of having a tool that's got my back on a whole bunch of different use cases. We talked about, in React, if I'm using set state and that's kind of a sub case of component state because I would say that in the previous systems we talked about -- Ember, Vue -- they have components state but the component state is a little bit more rich in the sense that you've got computed properties and what have you. But if we look at a system that externalize a state like redux, where you have a global state atom in your application, at least that's the way most of the redux applications that I've encountered behave, what does it look like for you? TARAS: I think it's a little bit challenging when talking about redux is redux conflate a few different things together. I think it's helpful to split those things up, so we can talk about them separately. One of the parts is how the state is delivered to components. The way that redux does is the instance is this created so every time you use connect, you essentially wired together. You can connect through the context or... I'm not sure. I think they have an observation mechanism that's internal to redux as well but they essentially connect components to the store and then they view that to deliver the state. It's kind of worth pointing out that for that like microstates bindings for React actually give you something similar out of the box through context. For those who really like the ergonomics of connect, I think it would be pretty easy to make that available for microstates. Usually, we don't even know why they wouldn't be available. CHARLES: But I do think that connect can be problematic like you can encourage you to not make components that are reusable and have isolated state. It's very easy to hitch yourself to the redux store and now, you don't have components that are shareable. TARAS: I think I would personally prefer to pass microstates instances through props because of the stability that's built into microstates and structural sharing, you can get some free optimizations and allow it to use functional components in more cases like out of the box but some people who are really like redux, they really like connect. Although it might be my personal preference, there's no reason why that wouldn't work if somebody wants me to connect function and make it available for people. CHARLES: Right and I think, there's a happy medium there too, right? TARAS: Yeah, I think -- CHARLES: -- You can connect components and then fan out that state to a set of functional components that are not connected. TARAS: There are some places where microstates and redux are very similar. When you're using in redux, you have this dispatch mechanism, where you essential saying, "I'm going to dispatch this action and your action creator is going to create an action for you with the payload," and then you're going to match that action to a reducer. One of the things that I kind of hear redux people really enjoy about redux is the one with data flow that dispatch the action and then, it reduces this next state and pushes that through and you have this kind of ingress point where everything is going through this one point. I think what's really interesting with microstates is you essentially get that. That's exactly how microstates works, in a way. The only difference is that the API is different. Any action that you invoke is going to go through a single entry point, which is going for you. Because we know the structure of the data, we know how to transition that state for you, so you don't need to reducers, so you're just defining your transitions or use the built-in transitions and then when you invoke them, we know the path. We're essentially forming for you. The path where you invoke the transition, conceptually, it kind of forms the name of the action that you are invoking. The path refers to a place where the state is going to be transitioned, then you have your transition, which is the actual reducer for that part but it's contextualize, so you don't have to think about how you need to transition that state in a great, global redux state. CHARLES: There's no matching. The matching is automatic. TARAS: Yeah, the matching is automatic, so you get that same single ingress and one directional dataflow. You get those mechanics except the APIs that you use, instead of writing the actions yourself. Instead of writing, we just use yourself. You get to use microstate types. I've heard some people who use redux who are like, "I really love the fact that microstates has types," but other people don't like types for whatever reason. Microstates comes with 'from,' which allows you to take a POJO and from that POJO, it creates a microstate and then you can invoke transitions the same way as if you had a type microstate. The only thing you don't get is you don't get to create your own transitions. You have to use the transitions that are provided for the primitive types. CHARLES: I think that there's a couple of benefits that you'll realize for free. There's laziness, reducers by default, or eager. When you dispatch an action, it will run against every reducer in the store. If the reducer matches, you're going to run the computation that's associated with that reducer. Microstates by contrast is lazy. Basically, until you try and read the property that is affected by that reducer, the reducer won't run. There's some ways that you can get around this. When you're using redux and first of all, you can actually have your reducers return objects that have getters on them. You can realize some of that laziness but again, it's work that you have to explicitly put in. I think, didn't you actually say that there is a package of plugins? There are plugins. There's basically a set of libraries that you could bundle together, which would give us an experience similar to using microstates. TARAS: Yeah. If you wanted to combine redux and reselect and immutable JS together, you can get some of the benefits, except this benefits are not integrated that well because they're still separate systems that you are essentially using together. Also, like microstates, it's four times smaller than redux and reselect and immutable JS combined together. If size matters to you and ergonomics matter to you, you actually can get a lot of ease out of using microstates while still maintaining the benefits of having redux. CHARLES: But if those things, those packages, like reselect and immutable JS, are things that are familiar and you naturally gravitate for it, then you'll probably absolutely love microstates. Because honestly, one of the ways that I think about microstates is like, what if you could have immutable JS, if there was no cost for composing the types like list and record. Immutable JS has come a long way since I've last used it or it's evolved since I've last used it but I think there's still only about four or five basic types and actually, making your own new immutable structure, your own custom type with its own custom methods that still get the benefits of structural sharing and laziness that you have on immutable JS is not something that you can do. But you could think one way to think about microstates is an immutable JS where you can make any type that you want. You're not just constrained to the record types and to their list types and set types or map types. TARAS: It's worth pointing out that at the moment, microstates doesn't map perfectly to immutable JS simply because immutable JS has certain optimizations for managing lists that kind of a great value of immutable JS and microstates doesn't have some of those pieces but -- CHARLES: They're definitely on the road map. TARAS: Yeah. Because microstates is abstracted high enough, that we can actually change internals and some people who are using microstates now, they will get benefits of ergonomics and there's already performance benefits from the stability that microstates offers but there will be a time when by upgrading to newer versions, you will not basically, need to change anything in your op but you will get the benefit of improvements to performance that we will introduce over time. Some of those improvements might come from what we will learn from immutable JS. CHARLES: Right. I have a couple of thoughts before we wrap up. What are the ramifications no matter who you are? What kind of development background, some of the benefits that you'll experience with microstates that might be a pain point or something you hadn't thought about where you are currently? A couple of things that I have jotted down is first, and this is what brought it to mind is talking about stability. Something that you see in a bunch of frameworks is having to manually track the keys that are associated with data. If I've got a list or I've got an object, being able to say, if that object changes, then I need to actually have some sort of key object, which effectively amounts to a hashing function to say, "Did it really change?" Because no matter what system you're in, you need to know how you're going to re-render. If the reference to this object changes, then the default thing needs to be, "I need to re-render it," right? You see this in Ember, in Vue. In React, there's this ability to pass a key or ask the question, "Should this component actually update?" and with microstates, that's much less of an issue because basically, it keeps the key tracking instability for you. If you are using a model with microstates, if you think of an object as a graph of nodes, no node in the graph will change unless it absolutely has to, at least that's the goal. We still actually have some work to do when you're running queries against the state of a microstate. We can cover that later but that's most largely the way it is now and definitely, the way it's going to be going forward is you don't have to do any extra work as a programmer to figure out what has actually changed. TARAS: That opens up some interesting opportunities. Imagine if you had a rendering engine that did not expect side effects to be significant and you could just say, "If I know whence they'd changes, I will then re-render that." That will be really interesting exercise, seeing like what would that look like for a performance perspective, if you have a very clear picture of what has actually changed and what part of the DOM as a result, need to be updated without having to do diffing. The [inaudible] you could actually do a diffing at much higher up. Actually, [inaudible] to diffing because you know what's changed but you can push a lot of assumptions higher up on the architecture stack. CHARLES: Right. That's actually one of my favorite thing about microstates and one of the unwritten values is like triple equals used to work everywhere and by and large, it does. It's usually simplifying but when you don't have to manually tell the computer what equivalence looks like, you can just say, "Look, are they the same object? They're not the same. If not, then they're not," and keeping that consistent is huge. TARAS: I think this is a good segue for us to kind of bring this conversation to a close and also, kind of set up potentially a third full-on conversation, which we could talk about actual architecture of microstates and design decisions because for people who just want to use microstates, they don't need to know all these details but for people who are curious, they might actually want to understand what are the considerations that remain when we were designing microstates, so maybe in a next conversation about microstates, it could be about architecture and the pieces in microstates today and then where we are going with microstates and what it could give us long term. CHARLES: Yeah, I like that idea. It is a plannable subject that we've been talking about internally for the past two years, so it makes sense that there would be plenty to speak about on the podcast. There is one other thing that I did want to bring up and that is, I think enabling to have a state solution that is composable because it allows you to think about your state first. Because really, if you do have a functional UI, where your view is a pure function of the model, that your view follows the model and so, if the view follows the model, then really, the thing that you should be thinking about first is the model that's going to be required to drive your view. I shouldn't drive. I should say derive your view because that's the primary artifact of which the view is nothing more than a function. It's a reflection onto a surface. I don't think that we have a state management solution yet, that enables that mode of thought, where I'm thinking about my prime artifact first and working forward rather than thinking about my secondary artifact and trying to kind of wishy-washy way, work backwards and reconstruct the primary artifact. I think that we've talked about all the development ergonomics and I think there's a mechanic of thought there that's enabled by this that I hope to see in more and more applications. TARAS: I think that's a really well put. I think that's something that I've been thinking about as well, as how do you convey this shift that microstates allows in terms of how we're thinking about architects and the application. For some people that value, the model, like they'll find that shift easier but regardless, I think that making that shift has a potential of simplifying your view dramatically and I'm very excited about exploring this further and having more conversations about this. CHARLES: Yeah, that's where we really kind of open up the conversation about state machines, which is also central to the conceit of microstates and using state machines as an incredible design tool but anyway, we can all get into that later. You heard it here folks, Episode 3 is coming out, although probably not for a while. We're going to be mixing up and we will be talking about microstates at least for a while. I understand that next time, we actually teased it but we based on how much material there was on microstates, we ended up packing in a second episode. We teased it last time, we're going to be talking next time about running an online conference with Twitch, so definitely look for that. Thank you, Taras. Thank you, David. TARAS: Thank you. DAVID: Yeah, it's been great. CHARLES: This is a wonderful conversation and as always, we are Frontside. As I mentioned at the top of the show, we have availability coming in August, so if working with us is something that you would like to do, we have a range of services, please get in touch. You can get in touch with us at @TheFrontside on Twitter or Contact@Frontside.io. That's it for now. I guess we should also mention that Taras that you are going to be giving a talk on microstates at ManhattanJS. When is that? TARAS: On August 8th. CHARLES: I will be giving a talk on microstates at ReactJS Austin on Monday, the 6th, so that is right around the corner. I'm excited about both of those talks, especially following so closely on the heels of the TorontoJS meetup talk, which I understand is... Is that posted online yet? TARAS: It's recorded but it should be coming out soon. We'll definitely tweet it out. CHARLES: Okay. All right. Look for that and we will see you next time.

In part I of The Frontside's microstates series, Charles Lowell, Taras Mankovski, and David Keathley talk about state management that's easy and fun and transactionality. This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Upcoming Conference Talks: Toronto.js - July 30th (Taras) Manhattan.js - August 8th (Taras) ReactJS Austin August 6th (Charles) Transcript: CHARLES: Hello, everybody and welcome to The Frontside Podcast, Episode 106. My name is Charles Lowell, a developer here at Frontside and I'm going to be hosting today's episode and we're going to be talking about microstates with fellow Frontside developers, David Keathley and Taras Mankovski. Welcome you all. DAVID: Hello. TARAS: Hello, hello. CHARLES: I'm really, really excited that we finally get to talk about this but before we jump into this, just wanted to let everybody know that last week, we published our roadmap for Big Test, which is a JavaScript acceptance testing framework that we've been building right here, in-house at Frontside, which can work with both Ember applications and React applications, Vue applications. It's in alpha phase and we're looking for feedback but we're really excited about it, so we're going to leave a link to that in the show notes and please go check it out. All right. Finally, the moment has come that we actually get to talk about this publicly. We've been publishing things about microstates for a while now but we feel that it's ready to share with the world and that's really, really exciting. We should probably like wind the clock back a few years because that's about how long we've been working on this and talk about, kind of the why and the what of what microstates are. It's kind of a weird word. What are we doing here? TARAS: Yes. That's interesting question because we were working for so long and after all this time, what is this specifically we're working on. I can speak personally from my personal motivations because we have conversations over the last two years to why we were doing this and I think for me personally, it's always been that I've been mentoring building complex applications for almost five years now and one of the things that I find consistently is that there are patterns for how to build complex stateful UIs that the required solutions, that are fairly reliably consistent. I can teach people certain patterns and then they can use patterns to build complex applications and those patterns scale really well, the challenge is that, there's not an easy way to express them and it's different for every framework. The way that I would teach somebody how to do it, for example in Ember versus how they would do it in React, even though the pattern itself is the same but the implementation of the pattern is different but it's different in such a way that it's very difficult to see where the consistency is, what is the same about these two patterns. It shows me that there is room for improvement. In the same way that if there is an opportunity that in the future, components will get unified under one umbrella or what component spec. The fact that we do states differently across every implementation, across every opinion, it suggests that what we might be missing is something that would unify across frameworks, how we actually do statement management. CHARLES: Yeah, that makes sense because as much as people try to buck the trend of MVC, it can't keep coming back in the rear view. Hopefully, not like a horror villain but like a caring friend, like a reliable pattern. I remember when I was in writing Java applications back in the day, the most important thing when you were writing a swing application was making sure that you had your models right. If you were modeling either a form or a dialogue or a set of pages, the most important thing was to have those models. Back in the day, we modeled those things with event listeners, very similar to where the way like a Backbone application used to work or if you're familiar with Ember Object, the way that it worked basically, adding observers to some model so that when that model change, you were able to react to that. Your representation was able to be 100% dependent on this model. That was like a Java Swing Application, which was then inherited from this pattern from Smalltalk but we keep on seeing this again and again and again. There is this piece, this state, that if you're going to be representing something, then you need to be able to get at the meat of it. That's ultimately what the model is in the MVC pattern. I remember when React first came out, everybody was like, "Oh, MVC is dead," but now in terms of state management and all of the state management solutions that we see, what that really is, is the model trying to reassert itself. Because it's such an important piece of your application, it's going to rear its head and you cannot escape it. I make it sound like a problem. I guess, it is a problem but there's a proliferation of solutions out there that are attacking the problem in order to represent something you have to know what that something is. DAVID: I think when you only work with the one framework, your perspective might be very much shaded by your experience. If you're really good at building React applications and you have subscribed to POJO is king and you don't need anything beyond that, then you're going to get good at handling POJOs and you might not realize that there is actually limitations to what you're doing. I think the same applies to people who use Ember and they're using Ember Object and they have computer properties and now, in Angular, there is observables and subscribing to streams. What was really interesting with the work that we've been doing with microstates is that and one of things that have notice with other state management solutions is that a lot of them emerge as, "Oh, I had this insight. I spend a couple of days working on it. Here's my proposal, in a way, for managing state." I think that's great because insight and understanding is really important but sometimes, taking the time to design something can be really helpful. I think that one of the things that are really interesting with microstates is that because we've been iterating on it for so long, they've been testing it for so long, we've been able to do something in microstates that's really difficult to do when you have a production application that you're like, "I want something different. Something is not enough but I don't have the time to really make it better," or, "I have an idea. I want to release this thing but I don't have any other collaborators that I can talk to and really flush out these ideas," so what you get is a solution but it doesn't always touch on a lot of the angles that you want to touch on. It's really interesting when you think about -- CHARLES: I'd say, we should talk about those angles, like what are some of those angles? DAVID: Yes. You could think about this from a few different perspectives. I would say, from Ember perspective because that's been my personal starting point. For anyone who was listening. Ember and Vue, for all intents and purposes, in this scenario are very similar because they have the same primitive, which is the computer property. The computer property in Ember, the computer property in Vue is almost identical from the way that you actually consume. In Ember, you would use computer properties and in Vue, it's just computer properties to create derived state from data that's passed into the component and then, you would use is derived state to basically, decorate information that comes with the props, so you could present it in your component. This pattern is very nice. This pattern is being used to build LinkedIn, to build applications at Apple. There are huge implications being built by Ember community using this patterns and I'm sure something similar has happening now with Vue but this pattern doesn't really exist in React in the same way. You might opt in to start using this pattern if you start using [inaudible] but it's not quite the same. Writing computer properties in Ember and in Vue is essentially free because it's so effortless, where in React, if you're using [inaudible] to create cache computer properties and memorize computer properties, you are really opting into doing a particular way of computing this properties and writing selectors that's not trivial. I think that's one thing that is available in Vue and Ember and it's a really effective pattern and you can do it in React but it's actually not possible in Angular, unless you're using, I'm guessing something like ngrx, where you can do similar things to what you would do if with redux in React. Creating derived state that you can consume in your component is one of the things that is possible but it's not possible consistently across all frameworks. That's just one of the things. CHARLES: I agree. I think that was one of the things that drew me to Ember at first coming from Backbone as I did and honestly, from the models in Java was that, in order to compute anything, you had to install a listener and then eagerly make that computation and store it somewhere, where as those frameworks, it made you feel effortless where you can just decorate some state and derive it and the information is there, the computation is there when you need to reach for it but you don't have to do expend any extra effort aside from say, "This state is derived off this other state." I think another case that I came across was immutability. Immutability is a means but the end is to have consistency inside your application. I first really started running up against this when I was working with forms and since then, I've realized that actually, a lot of the pain that I was feeling was because things were not being immutable but this is where the fact that things weren't immutable ended up causing me a lot of pain and headaches and I was having the code into being a lot more complex. Essentially, when I wanted to make something transactional if you're editing a form or something like that, then you need to essentially store off a copy of your current state. If you're editing some object, I want to say, open up a dialogue and I'm going to edit it and then I'm going to commit the changes back to that dialogue. What I'm modeling there is a transaction so I kind of need to shave off a copy or make a Xerox copy of the object and then make the changes inside to that object and then somehow, try and merge those changes upstream and then, get them back into the main lines. Really, like a very Git-like operation. It wasn't just at the object level. When you're doing things like dirty checking, you need to make what is the original value of a field versus what does the input currently have. I might be doing any number of transformations in between the actual physical representation of the field, maybe it's a date but the user interacts with it in as a string, so there has to be this kind of parsing serialize thing sitting in between that value and you need to basically, keep a copy of that field as a mini transaction within your macro transaction because you want to say like, "Is it dirty? is it really the same object?" because if you can just do an object comparison, you have to get into all that hairy like equality checking and it gets really complex really fast but it turns out that a very clean solution to this is if you just never actually make the changes in place and whenever you are making changes, you're generating new information without destroying the old information because when a form is the case where we really come up against this, where we're modeling the same object over time, so a form explicitly models the change of an object. Change is part of what it is and so, the definition of change is being able to compare something in its prior state to be able to compare it to its current state. If you're making that change by destroying the prior state, then you're going to run into a lot of trouble. It just turns out that when you're working with forms and it turns out there are a lot of use cases like this but this was the one where I first really just couldn't even... Without immutability, you want to model your change as always rolling forward and not ever destroying prior states but being able to pick and choose and can always be able to look back to where you were and compare where you are now to where you were. That's where immutability comes when you're modeling change. It's actually much easier to model change when you have explicit states that represents what was and what is. But when you start doing that, then things get a little bit messy. You have to do the compromise. There's a tradeoff, like when I say, "Set this property on this object," that is easy and that's something that I think that we can all understand. We're not idiots. That's why immutable models are very conceptually easy to grasp, to wrap your head around. If I'm modeling myself and I'm saying, "Set hand position two feet up in the air and now I'm raising my hand." That's easy to understand and it turns out that when you're changing a data structure immutably, then you have to, for example model a simple set operation as duplicate and swap. Or if say like you're swapping out one property in an array, you actually model that as a map, where you swap out the one element at that index, rather than just saying, "Just set the thing at that index," or if I'm changing a property of an object, I want to copy over all the fields except for that one which I'm going to change. If you start to do that then, you realize the benefit of always being able to look backwards but you've now introduced overhead and complexity in your code, so you've made a tradeoff. I think that's a lot of people look at saying, "I want this to be immutable," then they actually have to come to the grips with the complexity that's going to introduce. There are libraries like Immutable.js that do make that a lot better but even they have the problems. I can talk about those but one of the cases is like being able to reason about a series of states for your object, rather than just only having one copy of it ever and being stuck with having to deal with it as it is. DAVID: Yeah and I think that really important too is being able to mentally track where you've been because in my experience on other large Ember applications, I've run into so many different bugs that I could really track down to people or rather, places in the code where things are just reaching in and mutating your model, where it wouldn't make sense, so as you're writing your code, you're in a completely different state than you might have expected. CHARLES: Yes and it's easy, right? But essentially, when you have some model, you've basically got a global object. There's a lot of recomputations that needs to happen when those things change. As a result, if you look at the actual code that supports computer properties in Ember and I'm sure other frameworks as well, some of the most hairy and complex. If you look at the chain watchers and the chain nodes and all the stuff that's required to support things like computer properties, it's amazing that it works as well as it does. I've tried to actually open that up and understand that code on a number of occasions and every single time, I had to walk away in defeat. TARAS: This problem exists in React applications and Angular applications because if you think of the challenges of working with set state, I think one of the problems with working with set state in React is that your complexity increases very quickly. It starts off kind of simple when you're using immutability with set state in React. They're kind of very light and then, as you start to add features, your complexity starts to grow very quickly in a way that you really start to run into limitations. You start to confront your personal limitations of your abilities to work with immutability, so you're limited to doing immutable structures that only a few levels deep because your ability to use destructuring to create new immutable object is limited by expressiveness of JavaScript. It's gotten a lot better with the destructuring but if you do it a few levels deep, I think everybody's familiar with what happens. It starts to get really hairy. You kind of loose track of where you are. CHARLES: Yeah. The signal-to-noise ratio increases because after probably, two or three levels, the majority of your code has to do with destructuring and restructuring and very little of the actual change that you want to make. TARAS: And this is kind of interesting because people talk about declarativeness versus imperativeness but at certain point when you have a complex immutable state change, if you're doing with destructuring your code, even though it looks declarative but there is so much processing that you're doing, it's actually kind of losing the benefit of its declarativeness. It's actually starts to look more like imperative code than it does what you would expect a declarative system to look like. I think this touches on the other aspect. It kind of compromise that when you work immutably, when it compromises, you make a serialization. Your ability to represent your state as a POJO becomes restricted by the fact that you have this complex system that's wired together and you have systems like zones in Angular and in Ember Object that are able to keep track of changes in these objects but you don't have a way to restore those objects. You don't have a way to do more sophisticated things that you might want to do, especially in situations where if a service feeding you, what do UIs going to look like. In that situation, it's really helpful to be able to say, "Here's a POJO that I got from the server. I'm going to use this POJO to build this component tree that the user is going to interact with and then, as the user interacts with it, I'm going to then, capture that state, serialize it and put it back in the server." When you're using something like Ember Object or if you're doing this kind of stuff in Angular or even if you're doing this stuff with React but without using something like redux, you essentially end up doing so much wiring to accomplish that. By the time you finished writing your application, you've written a ton of code just to handle this particular use case and if you have to do this again in another application, you just rewritten that kind of code in a new application as well. CHARLES: It reminds me of the concept of a Smalltalk image, like there's no way to really get at the state of a Smalltalk thing. It's almost like you're dealing in docker containers and not actually being able to write that state down into JSON or something like that. I'm trying to casting about for an appropriate analogy. Maybe that's not a good one but what's actually happening cannot be made orthogonal. It can only exist in that one run time that you're currently running. If something wrong manifests itself, reproducing it can be extraordinarily difficult, right? TARAS: Yeah. CHARLES: Imagine if there's some render cycle that's making a bunch of mutations and there's this process that you stood up and it runs in completion, some signal comes in and those effects are like ripple through the system, there's no way at any point to have any other representation of that system than the running system itself. TARAS: There's another element to this, which I find really interesting. When you're thinking about how to architect complex UIs, it's actually helpful to get really clear about what kind of changes are happening. A lot of times when I want to see beginners are writing, especially if you task someone who is a fairly junior at building a single page applications, a lot of times what will happen is because they don't have a clear mental model of what is going on in regards to state. They end up setting a lot of properties. Every operation, every time you have an event handler because they don't have a clear model of what's going on, they end up setting like five or six or seven properties. That kind of signals that they don't have a clear picture but what that also does is a lot of times, they usually comes together with cascading state changes. Usually they're not representing a single operation as a single state change because there might actually be a bunch of things that are happening because what they're doing is they're massaging the system into submission. Not like they're not in control of the state transitions, so they use, essentially time and their dedication to kind of sort it out and make it work and eventually, would that ends up looking like that if it works for most of the cases that they are able to test for or that they able to manually see. But then they AR, not accounting for problems that they're not able to understand right now, they become discovered by users when users start to interact with the system and with the components or with that application and the application is there to get into some funky states. The tools that we have, they don't prevent that from happening. They just -- CHARLES: Right. They don't force you. I think what you're saying is that ideally, you want to model your UI as a set of transactions on your state, that you want transactionality to your state so that I basically am saying, "I'm not going around and setting seven properties in reaction to this one event." I'm saying, "This event triggers this transaction and that transaction clearly bundles up every single operation that needs to happen and the tools don't enforce that." Is that a fair --? TARAS: Yeah and then, the problem is we're working with component trees. You start off with having a set of requirements and over time, the requirements change. As the business unit understands your application better, they give you more direction of how accounting should work and then you find out that there's more interconnect at stake but then what's happening now is that the cost of refactoring those state that spread throughout the components, whether that be with set state, whether that be with the actions in Ember or even in Angular. What you end up doing is you start to change the system but change is not trivial because the actual process of changing where that state lives is not linear. It depends on the complexity of the code that you wrote and it just gets really hairy very quickly. That's where companies end up losing a lot of time. A developer could start off with a requirement, you build something and then a new requirement comes in and instead of it being a simple change, it turns into a week or two weeks refactor because you now understand the state ownership should be different. The state that you have should be in a different place. You have to manually make that change. You have no obstruction to help you express that in an easy way. CHARLES: Another thing, because we are doing a kind of a roundup of all the things that you need to account for when you actually embark on managing your state. Another is actually constraining the amount of computation that happens. If your system is based on listeners and large chain reactions of things where it's like, "This property changes so I need to notify these other 10 dependent properties that change." You can do a lot of unnecessary computation, especially if nobody is going to render. That's kind of the thing that you have to do if you're going to be immutable. You have to eagerly walk those change to see which objects are affected so that you can then invalidate those caches. A system like Ember Object, I don't know exactly how Vue works, it mitigates this somewhat by the fact that the computer properties are lazy but you still have to walk all of those chains. That can actually get out of hand. They're eager, not lazy. Then the other concern that you have, where you normally have to make a trade off around is around composability. One of the things that's really nice about immutable systems is they're very composable. If I've got some object that does one thing, I can then just set that object onto another object just by mutating one of its properties and I've effectively composed them. I can then install listeners onto that thing or I can compute properties off of that property and they can post pretty well. That's something that you get but then of course, you're losing all of the benefits of immutability, so things like Immutable.js don't really compose very well or redux doesn't really compose very well. The concept of taking a redux store and embedding it into another redux store, you just don't see that. I would never distribute and I think ultimately, the litmus test there is would I be able to share it on something like npm. Nobody shares an npm package that's just a redux store that you can dispatch actions to and observe and use it with your other redux stores. When it comes to a system like Immutable.js, that does make transitions a little bit easier over lists and arrays and maps but you still run into the exact same set of problems that you have when you have lists of maps of records and you don't really get any help there, so you have to make this tradeoff between immutability and composability, whereas a system like MobX or Ember object actually quite composable. Before we start talking about microstates, I want to say that you just throw those in there because there is just a lot of concerns out there, a lot of edge cases that actually build up but through the course of a real application, you will encounter them all. You might be making tradeoffs at the beginning that you're not realizing that you're going to need or are going to get you into trouble later on. DAVID: This actually happens in the Angular community as well because there's something really great that's happening with observables in the Angular community. I think everyone's embracing them wholeheartedly and I think that's really been pretty great to see but observable streams of composable, but objects that have on them observable stream providers of some kind, like if you have something that you can subscribe to and that is part of a property in a class, composing multiple classes together and consuming properties from those classes, there is no mechanism for composing that. That kind of composition has to be done manually. Again, you're kind of manually wiring together a bunch of objects and the big challenge is that you are manually subscribing to all those streams and unlike what you have with components. Components have lifecycle hooks. When your components is being torn down, you know you can perform some operations. If you need to remove an event listener, you have a hook where you can do that when you have a class instances like JavaScript class instances that have on them properties that have observables that you subscribe to. There are no tear down hooks for class instances, so there are no obstructions from managing unsubscribing from those streams. You essentially end up having the foundation that you can use to build complex reactive systems and you can subscribe in there really fast but wiring those things together at a bigger scale is simply not there. It's something that you have to create and enforce yourself. CHARLES: Right and I think that's probably a perfect segue into talking about microstates, which is the project that we've been alluding to for the past 30 minutes, that is I think in attempts to solve these problems and make sure that you don't actually have to compromise on those things, so you can reason about things locally but have those things be composed into a greater state. But also have them be immutable so that you can look at past states and reason over a data structure over time as opposed to just in one instance. Also, have an intuitive interface that when you're making these changes, doesn't look like half of your code is unpacking some data structure, flipping some bit in it and then repackaging it back up again. That's the context. Should we start talking about what microstates is and how it addresses those? TARAS: That's a good next step and when I start working in the ReadMe, I end up actually, I think I wrote about 40 pages. One thing that's interesting about microstates is that and this was part of the design of microstates from the work that we've done is that we intentionally wanted to make the number of ideas that you haven't microstates very little, so when you use microstates, the number of concepts that you need to remember in your mind is very few. It is a conceptually a different way of thinking about organizing your state in the same way that shifting from managing DOM elements directly to having an obstruction like component that declaratively applies changes to your DOM tree. In a same way, microstates is kind of an abstraction that allows you to declaratively describe how your state will change and it will manage the transitions for you and allows you to give the state transitions names and it allows you to give your states names as well, so you can actually name things. You don't get a POJO that has a shape but has no name. You actually get to give things names. CHARLES: So, why don't we start? I have a list in my mind. I should probably write it down of the things that we just talked about but I think the things that we talked about are ease of representation, like conceptually easy, transactional, basically serializable and immutable, lazy and composable. Those are like five or six things. But I think there are kind of aligning principle around which we gathers that the state management should feel easy. It should feel fun. One of the things that is awesome about working with components, whether you're using web components or React components or Ember components is when you get it right, you're just snapping these things to feel together and it feels great. It's like I'm just passing properties and render blocks down the tree and the framework is just doing all of the grunt work for me and I'm just operating at a very high level. That's what organizing principle with microstates as it needs to feel easy. Maybe we should start there and just say, how does that easy and fun line up with each one of those kind of unique problems around which we typically have to make tradeoffs? We could start with the interface of making a change. TARAS: I'll go back to the starting point. I remember what got me first interested in microstates is Charles, when you said that, when you have a number, there are certain operations that a number can do. We really don't need to be writing an increment operation for every... Like if you a have a number, you can increment it and decrement it. CHARLES: Honestly, every time I see state management tutorial and they tell you how to increment and decrement a number with it and you write the increment code and you track the thing and you store it back into the store, at this point I'm still annoyed with those tutorials because I'm like, "It's a number. We know we can increment it. Just show me where to plug in the code. I should not have to be writing an increment method." TARAS: Yes. And that's the kind of starting point. There are certain operations that you can perform with the primitive types. If you need to add a number or if you increment a number, we already know how to increment the number. It's part of microstates. But that in itself is nice but that's not that important. I think what's really important is that when you need to put a number into another data structure, let's say you have a nap and you're like, "I need to..." I don't know -- CHARLES: Let's say, like a click tracker that has a number of clicks. TARAS: Right. By itself, you can increment the click tracker but if you need to put a quick tracker into another app, essentially you can compose it in and you don't need to figure out how to wire the actual mechanism of how to make sure that you can update the property, like it's part of another class, for example, you don't need the way you would increment the number. When it's a part of another class versus how you would do it when you're working with it by itself is an approximately the same. The amount of work that you need to do to actually perform that operation is the same. Your complexity doesn't increase as you compose one data structure into another. CHARLES: Right. You can just say, "This is an app. It's got a click tracker and this property is a click tracker and I have to do nothing else. I can register clicks on that thing. It doesn't increase the complexity of application at all." TARAS: There's no wiring. Now, you added some new state, that state is very explicit and it's really clear that it is not impacting other parts of the state. You can operate with this thing. If you change it, it's going to work properly with all the other things that are in the type that you are adding this counter to. Those things are just going to fit well together and it's not going to break if you need to transition one more thing. All of the other transitions will work the same way. I think that kind of consistency is really meaningful, over time especially when you start to increase the amount of state that you manage in your application. CHARLES: Just the ability to work with types and just have kind of those implicit operations and have those things compose, kind of indefinitely. Moving down, we talked about easy and the other thing I would put on that is that the way in which you express those transitions, for example if microstates comes bundled with numbers and Booleans and strings and arrays and objects and kind of the stable of types that you would expect in any JavaScript application but those types are expressed using this way for expressing types, essentially. When you actually do make a transition, it feels very object-oriented, I would say, even though it's not. It feels like you're mutating but you're actually doing a transition. Does that make sense? TARAS: I think for anyone who is familiar with what it's like to write queries for GraphQL, if you're not familiar with it, it's fine. You can get a sense of that from microstates but if you're familiar with the ease of just writing a query and if your backend knows how to retrieve the data, then your queries will just give you the data that you want. That feeling is really powerful and just being able to write the query and just gives you what you want. Microstates is kind of like that. Actually, the inspiration came from experiences with GraphQL, which is that sense of ease is what we wanted to have in microstates and so you get that seems sense of like, "I can just do what I want and it just going to work and with this other thing and it just going to work," and you're just like flying through, like adding states to your application and it's just working for you and working for you and working for you and you don't have to do monkey work like gluing things together. It'll change how you are working before because you have a way of opt working with these things at a higher level. CHARLES: Right. Let's talk about transactionally or should we talk about immutability? How does this make immutability easy and fun? TARAS: I think one thing is that you don't have to write reducers and you don't have to do destructuring by hand. I think you have a way of expressing. Thinking about this, if you have a component tree and let's say you have redux and then a bunch of components like your parent component, your root component has some state using sets date and then components further down the tree also have state. You could actually express that as a microstate. What you would do is, essentially the parent component state would be the root and then the children's component states would be composed into it. The nice things about doing that is that at the root level, you have access to transition state of the children declaratively. You know where the states for those children is on the route type and you can write transitions that are going to declaratively perform multiple operations on the children state and I suppose it'll restructure to what happens with components but if you don't use this, you might have multiple sets date operations. The process of wiring data from the root down to the children is kind of complicated, where here, you have a way to represent that and perform a lot of transitions in the way that is going to be just easy at whatever level you need to operate at. CHARLES: Right. I think, for people familiar with redux, in redux you act globally and then you react locally, if that makes sense, so you dispatch an action to the entire store and every single reducer can see that action. There's ways to manage that but effectively, you have this one atom and then you have the reducers that kind of act on local state, whereas with microstates, you're basically acting locally. You're reacting locally but the effect is global. TARAS: You're participating globally. CHARLES: Yeah, participating globally but you never have to consider the context that is above your own, so you never have to be mindful or cognizant of the context in which you're enclosed because from your perspective, it just doesn't exist. DAVID: Every microstate has a set transition which is the basic transition that you can invoke, essentially in any type, so what's interesting is that it's amazing how powerful -- CHARLES: So, we should break it down really simple. Basically, when you create a microstate, with a type, you say like, "I want to create a number with the value five," and then I can just say, "That returns a microstate," and I can say, "microstate.set 10," and that will return a new microstate who's also a number but the value is 10 and that's available on all microstates. DAVID: Yes. If you have a tree of components and your state is presented by a microstate at the root level, then what you can do is you can invoke the transitions on any part of the microstate and it will just know how to properly create the next microstate for you. The example that Charles you gave of one number so that number can be inside of a class that represents state for a particular component and then that can be a part of another class or represents a state for another component but then, when you invoke a transition on one of the leaf nodes, an equal sets state on one of the leaf nodes or equal set on one leaf nodes, it will respond locally but it will actually reflect the changes globally. At the root level you're going to get a new object that causes the components to update. CHARLES: You know what? I have another concern that actually just popped into my head, which is something that I've certainly struggled with in every single application of notable complexity is stability of value. We should put that on the list. We're almost out of time to talk about this. We spend too much time... Well, not too much time, of the issues of state management, which I think you can't spend enough time talking about but I did want to pile one more on there is when you're making that transition, where you're acting locally but you're participating globally. For things that are unaffected by your action, remain unchanged. That is a super power. It's actually very hard to do with a lot of state management, especially when you're cloning a bunch of stuff, being very judicious about what you don't want to clone. Where this really comes into play is if I want to re-render something. A lot of times you have to jump through a bunch of hoops to tell, did my model really change or did only referentially change? With microstates, when you make that local change, if you're embedded in a very large graph of objects, obviously all of the objects above you are going to be changed but what about things that are off to the side of your siblings. They're outside of that scope of that change. They shouldn't be cloned. They shouldn't be copied over. They should remain the same. If you're doing a re-rendering based on the changes that are happening, that's going to be a key feature because you're not going to have to write, basically any hooks to say, should I have to re-render my component. You can always rely on triple equals. DAVID: This quality is going to describe the structural sharing and some of the other tools that are available but I think that's how it's accomplished. I think one thing that's a little bit different with microstates is that when it comes to structural sharing, it's not that difficult to do if you just do structural sharing and value. Meaning that you can do structural sharing on a value using something like lenses and not a lot of people are familiar with lenses in JavaScript but it's actually only three functions that you can use and it can give structural sharing on complex POJOs. It's pretty easy to use relative to how little people know about it but what that doesn't do is it doesn't allow you to graph of objects that have their own operation that you can invoke and that will perform structural sharing. That part, I know that is not available in any solution, I think at the level of completeness and luxury that microstate provides when you write things. CHARLES: Right because every piece of the tree kind of comes bundled with its own things that you can do with it. DAVID: I don't think you should jam everything into this podcast because there's a lot to talk about it. I think one of the things and we've talked about this a lot, which what we want to do is create an implementation for an idea of what it would look like. What would it be like if we had a composable state primitive that we could use to describe state and share state solutions in the same way that we share components like react-virtualized or whatever your particular frameworks or popular component may be. What it would look like if we had solutions to state problems that we could share and we could -- CHARLES: I think the litmus test of an awesome solution is like you look at this current crop of MVC frameworks and what's so awesome about it is they're sharing. That can happen, right? If I'm writing a React component, I can publish it on npm and other people can use it. If I have an Ember add-on, I can publish it and people can use it. They can consume those components. That's awesome and I think it's the hallmark of a great system. What would it look like if I wrote just the state piece of a file upload and I could publish it npm and then anybody, in any framework, could actually use it with their framework without paying any penalty. What would it look like if there was some transactional data store that could be built and shared and the hooks into any framework were minimal. The possibilities are really exciting around that idea, whether it is realizes microstates or not. But clearly, we feel this is something you should be able to do. DAVID: I'll add one more use kind of use case that I personally find really motivating is that there's a lot of companies that are investing into building single page applications and a lot of times, what you see happening is they're building a very similar application to what they had before because their business hasn't changed. The technology has moved on so solutions have improved. The demands for better user experience have increased but the actual business and how the things that people have to do on day to day within their company hasn't changed. What we're seeing right now is we're seeing the same, like whatever was written before in jQuery or an AngularJS is now being rewritten in React or Angular or whatever you might Choose. But whatever you like to see is it has a situation where the domain specific logic of your business is represented as a data structure that knows how to, potentially, in the future talk to the server and retrieve data from the API because that's likely not going to change. But you can use that like that's been tested and published as an npm module within your enterprise and then you can then consumed that in any framework and it's actually easier to do it this way, than to implement it in a framework-specific version of their state management. That's the part that I find the most exciting. I think one of the things, just to connect to the goal is that, we would like to keep this conversation going. If you're interested and I think this is a kind of a call to our audience that if you're interested in this, we would love to have in our podcast to talk about these things because I think there's a lot of things that microstates really is a beginning of a conversation. It's not meant to be a statement. It's meant to be a proposal that we can just talk about this. CHARLES: I agree and that's one of the reasons we're keeping it very small at this point. The core library of microstates is not setting out to accomplish too much. In the core library, there aren't even any side effects. It's actually impossible to have side effects. It means that it cannot be used for anything except for the model but that's very liberating and it let us focus on what would a system like this actually look like. DAVID: It's really exciting because this has been the biggest metric but we have microstates in the JavaScript weekly and that was great and then it got circled around when people know and it's like 800 stars now, which is not a really big deal. It's funny because somebody commented like, "How can you put something in production that only had 100 stars?" CHARLES: I think it's just important to realize that this really is the beginning of a conversation. There's a really exciting set of things to come. We haven't even talked about how we're going to model side effects, although we're going to use microstates to do it. We haven't even talked about what the various framework integrations will look like and what are the best practices for using this to organize state in your application. We've had some lively discussions internally about what that looks like. There's still a lot of questions but it's going to be a really, really exciting and edifying experience to get to answer them. DAVID: Yeah, it's pretty exciting. I'm excited too. There's been a lot of interest from people in microstates, so it's going to really great. I'm looking forward to meeting people and having conversations about how we can use microstates because I'd love to have someone create a really great solution that I could just take off the shelf and just use and not have to implement them myself. CHARLES: All right. Well, I think we could talk about microstates for at least the next three hours but we have to give everybody an opportunity to, at least like go to the bathroom or something. Microstates will return but if you're interested in learning more about microstates and you happen to be in one of the many places on which we're going to be presenting on microstates in the future, who knows? Maybe you can come in and join the conversation in person. Taras is going to be speaking at Toronto.js on July 30th. He's also going to be presenting at Manhattan.js on August 8th and then, yours truly will be presenting on microstates at React.js Austin on the 6th of August. Come out and see us. We'll drop those in the show notes and it's guaranteed to be a good time and we'll have that conversation. Until then, we are the Frontside. We lead with the why, the how and then the what, if you're interested in working with us and that helps us that we guarantee the lowest total cost of ownership for your application. We're always looking for feedback. If you have news items that you'd like to see at the head of the show or just any feedback or questions, we would be happy to answer them. Thanks today to Mandy Moore for producing our show and next time, we'll be talking with Kristian Freeman about what it's like to run an online conference with Twitch, so I'll be looking forward to that. Bye David. Bye Taras. DAVID: Yeah, thanks for having us. TARAS: Bye. CHARLES: Yup, and bye everybody. See you next time. Next Time: Running An Online-Only, Free Conference on Twitch with Kristian Freeman

After coding live at Lean+Agile DC 2018, Ben Scott of Ippon Technologies joins Bob Payne to talk code craftsmanship and getting proper feedback from the business side.  Ben explains a way to quickly build a quality demo from scratch – creating the first demonstrable piece of value.  Bob and Scott walk through their opinions on (shudder) best practices, living in ambiguity in agile methods, and bridging the gap between IT and business. Bob Payne: [00:00:03] Hi I'm your host Bob Payne. I'm here at Lean+Agile D.C.. I'm here with Ben Scott and we're listening to "Stand in the Place Where You are" by RBM played on the music fiddle version which is really disconcerting for me. It's like Fugazi. You know elevator music which is definitely elevator music. But country elevator music. So Ben we were talking earlier about lots and lots of things but you were talking about sort of your experience here trying to do live coding and talk. What was your what was the gist of your talk? What were you talking about with. Ben Scott: [00:00:56] So, let's start with the problem statement: Whenever you start a project from scratch mainly it's really hard to get good business demos and keep the business interactive with getting proper feedback. You'll see a lot of demos with terminals. Hey let's see what my code can do and you have to look at log statements or use post postman to demonstrate APIs. And then the business kind of glazes over it. And I think a lot of issues stem from developers trying to recreate everything internally. Someone has to provide a demo that even started a presentation with zero code I could provide a business level demo with a front end application backend with database usage deployed to the cloud. All within the same presentation within 45 minutes. So that was kind of the gist, some people really liked the felt it really demonstrated well what could be done now. They're probably unsure how to adopt down to their own organization but it's mostly a show that it is able to do that and you don't have to buy it. It's FREE.  Ben Scott: [00:02:14] It's opensource a tool that I use is called J Hipster and I think overall great.  Bob Payne: [00:02:23] Yeah I mean for those of us who've been familiar with play or Rails or any of the generative frameworks you know that it was not should not have been surprising but I realized how how painful it is for most organizations to get to that first demonstrable piece of value.  Ben Scott: [00:02:50] Yes.  Bob Payne: [00:02:51] It is a little a little insane.  Ben Scott: [00:02:53] It is. The key differences are with J hipster is it really tries to adopt the enterprise level technology. Bob Payne: [00:03:00] You see the full stack you've got full size containerized deployments.  Ben Scott: [00:03:05] You can you don't have to but it sure does generate Docker containers. I use the docker file to let you generate a Docker container from your code. It will generate your CD pipeline script. It supports multiple privacy circles C.I. Jenkins obviously and a few other really really kind of handhold you through the whole process of getting a code from scratch all the way to diploid and ready. It can't do anything about your business level code that's on you right. But all the bootstrapping and plumbing it generates according to best practices of the time with us.  Bob Payne: [00:03:45] I winced on the inside. I don't like the phrase best practices but best that I'm okay with. Ben Scott: [00:03:54] Yes well it's always a big debate. What is best practice. Like for depending on where you are which technology you're using and your opinion because it's a hotly debated topic Your Domain Driven Design or you don't. Some people really love it some people hate it. Yeah that type of thing.  Bob Payne: [00:04:12] Yeah I try to stay away because people always ask us for as consultants are always asking for the answer and there really only is know fee here given your situation. Here are a few options that we've seen people be successful. Yes you know and you know I always sort of try to steer people away from that. Like calling people resources. There's a few you like hot button words that I can't make can move resources around us our projects exactly rituals and scroll to find that I hate things that that pull it out of the somewhat grey world that we actually live in.  Ben Scott: [00:05:05] Yes I actually like to prefer I prefer to live in this ambiguity. I don't like to define what scrum is definitely. I don't like too dear to a Agile philosophy per se or implementation whenever somebody dresses. Hey what is ads out to you. To me it's you delivered a piece of software that was correct at the right time and how you got there might differ based on the people working in your company. Yes we might use Scrum or not. It depends if it's a good fit with that place and sometimes it's now or sometimes they just decide as long as we do what scrum says we are agile and we just get away from what they really mean.  Bob Payne: [00:05:50] Yeah. Defer to authority. There is a good strategy.  Ben Scott: [00:05:55] So I don't like to prescribe things.  Bob Payne:[00:05:57] Yeah.  Ben Scott: [00:05:58] When we hire Scrum Masters always ask me what's your process. What tool to use. You know you use Jira. I don't prescribe - you use what you like to use right.  Ben Scott: [00:06:07] Well your client will let you use yes whatever you is best for your situation which will change.  Bob Payne: [00:06:15] So how do you so I know you've been doing a lot of technical coaching coaching. What do you what do you find most rewarding. Because sometimes it's it's you know it's it's a tough slog sometimes and there are always those little nuggets that just say yeah you know that will keep me going for a few months banging my head against this team or this wall or whatever. Ben Scott: [00:06:43] So I really enjoy bringing upskilling developers on where they lack and I'm not a awesome developer. I'm a very niche developer who understand the agile practices so I can do their job testing frameworks Cucumber, or perform sensing as a Gatling I know how to do them and the basic forms right and the tools to know how to use them. Eventually it clicks at first like I don't want it. It is what QA is for but eventually it clicks and it's really fun to see a click. Likewise I work a lot with the business side on bridging the gap between developers and the business we actually start working together instead of the whole campus. This is the business that we need to take to go on like what we need is. Of course we do to this refactoring. We need to adopt this technology or just trying to bring them together so they actually work as a team and we'll stack clicks which is much harder than it was going developers. Bob Payne: [00:07:40] Yeah. Ben Scott: [00:07:41] That's that's really fun.  Bob Payne: [00:07:42] Yeah that is. Yeah. We like speed we have that sort of mission of making people's lives more valued fulfilling and productive. It's kind of our or our mission if we can do that on an individual basis or you know we health and organization so that it helps the folks. But it all fundamentally comes down to you know people people in interactions and you know hopefully making a you know a decent world for them to sort of grind away at the code code is an unforgiving.  Ben Scott: [00:08:21] Yes we'll spend days looking for that tiny little mistake.  Bob Payne: [00:08:27] Yeah yeah. So what's the other big dogmatic thing you're railing against. I don't know that you're actually railing against any big dogmatic things but you seem like the sort of person that might. Ben Scott: [00:08:41] There are some things I'm very strict on and it's is code craftsmanship to the detriment of sometimes I'm actually delivering value and I understand that. But there are times to be fast and dirty. You have a production bug.  Bob Payne: [00:08:55] Yep. Ben Scott: [00:08:56] There's a feature that needs to go to the market right away. OK we can do that fast and dirty. But if that's every time there's a problem.  Bob Payne: [00:09:06] Right.  Ben Scott: [00:09:06] And at that point I don't have any issues slowing everything down and I guess focus on craftsmanship. Let's focus on actually teaching what solid principles mean because over time you're going into being faster more maintainable code. The sustainable pace and that takes time to learn. It might take six months a year to really get there. It's a huge investment and it's the responsibility of the entire organization to to foster that. So just like we have the Center for agile excellence or you go to an agile coach organization talk about processes.  Ben Scott: [00:09:39] You should have a software craftsmanship as well a new way to mentor the developers. And that practice that's probably where I'm the most strict on.  Bob Payne: [00:09:51] OK yeah no that's ... Yeah. That's a good place to be strict I think. I often think of the three things that can make a great team. It's discipline, continuous improvement, and play the long game you know not the short term gain necessarily but product delivery is is not project right now. Ben Scott: [00:10:16] And I completely understand there's times we have to go really fast for whatever reason it is. Maybe there's a bug that's costing thousands of dollars. When it's in production.  Bob Payne: [00:10:23] Yeah. Ben Scott: [00:10:24] And yes. Quick and dirty fix but then think about it and fix it again the right way. Bob Payne: [00:10:30] Yeah. Well everybody. It's interesting because that the current understanding where the current sort of popular understanding of technical debt is that it is a bad thing and you know when they first started talking about it Ward Cunningham and and you know some of the folks on the first XP team actually used it in more the financial term debt. Sometimes you do take down. You know you go fast to be quick and you might incur some debt. You got to pay it down. Always cost a little bit more to pay it down. But sometimes that's the right decision. But when you're paying off the credit card with another credit card you're in drips.  Ben Scott: [00:11:20] That compounds quickly. Bob Payne: [00:11:21] Then You need to re platform the whole thing. Ben Scott: [00:11:26] And then it just never ends.  Bob Payne: [00:11:27] Yeah. Bob Payne: [00:11:28] And that's what the craftsmanship comes in play because if you instill those values when you build a new software and maybe you'll be a little bit better and last longer.  Bob Payne: [00:11:36] Yeah. So is IPPON primarily you know do you or most of the folks steeped in XP stream programming and.  Ben Scott: [00:11:47] So I would say most of us are what I would consider like Premier consultants as far as developers. Most of us are developers. So in that sense we're a bit different from most agile consulting companies. We focus a lot on the engineering aspect of agile versus the process and most of our developers don't always subscribe to Agile values. They like to get their stuff done and they're like good code and beautiful aspects that don't always adhere to delivering to agile way which is fine. But you couple that wish people would truly understand agile and you've just multiplied yet the actual value of it. It's like the cross-functional needed agile deep expertise to guide the ship but you still need a technical deep expertise on what good coding practices look like. Yeah and we also like to embed with our clients. We don't always like to take the whole project and then deliver at the end. We like to develop right and while we could develop we'll pair with them or we'll teach developed practices how to test and how to automate the whole thing and the whole the whole package. I think that's where our values will be different than other places. Bob Payne: [00:13:07] Yes. And we've you know at LitheSpeed we've been happy to be able to partner with the guys periodically because we focus primarily on the people in the process and you guys can focus on the technical chops.  Ben Scott: [00:13:25] Yes. Bob Payne: [00:13:25] Yeah. I'm primarily a PowerPoint engineer and there is no PPT unit.  Ben Scott: [00:13:34] No I'm really bad at PowerPoint.  Bob Payne: [00:13:39] I wouldn't say I'm good. But the reason I'm not very good is because there's no there's no unit test framework to how to get good. I was talking to somebody earlier because I I was when I was developing you know I got immediately test infected like TTD like real TDD not the ATDD or BDD. Not that those things are bad but that thinking and design process of TDD was an amazing force multiplier for me as not a terribly great developer. It allowed me to focus know where I was know that I hadn't broken something else because I couldn't keep every esoteric detail from the entire system. Ben Scott: [00:14:38] Yes.  Bob Payne: [00:14:39] In my head some people love that they loved the challenge of I've got every single detail in my head. But that doesn't scale. It does and test.  Ben Scott: [00:14:52] It's a good thing you brought TDD like I have my own opinions about it. And you're right. Some people love us some people hate it. And to me there's a lot of focus from the process scores to do TDD when developers aren't ready for it. Bob Payne: [00:15:06] Yeah yeah yeah.  Ben Scott: [00:15:07] Just like everything will be fine if you just do TDD.  Bob Payne: [00:15:11] Yeah I don't believe that to be true. Everything will be fine if you have engineers that are that are that really you know there I sort of look at the code and you can see the thought process of the developer in the code and that is much easier for me to read to read tested code than it is to to create an elegant you know you start throwing in some Lambda's there and we're we're we're parked. I mean because I struck part of my psychosis if you will. And I think it's reasonable to call it that around TDD as I started in Lisp and I don't know if you've ever tried to debug lisp or scala. It's probably easier now and in scala but there's just the interpreter. Back when I was doing this so you had a command line and you read in a file and something pops out and it is the most amazing black box in the world because it's just it's interpreted. It's a functional language and 42 is the answer, right? I forgot the question we asked in end. So unless you knew that those little pieces worked. Yes pull that out throw it into an interpreter and see if it give it some some values in and see if it makes sense because all it takes is a misplaced pen. It could be anywhere and it will usually evolve out to something that still works.  Ben Scott: [00:17:04] And I guess where I differ what it is like or I'm strict on tests in the same commit as the code.  Bob Payne: [00:17:11] Yeah.  Ben Scott: [00:17:12] I don't prescribe to. You must write a test first. Bob Payne: [00:17:15] Sure.  Ben Scott: [00:17:16] But it must be in the same commit. Yeah that's that's kind of where I differ. And some people are really good at writing tests first. Some are not. Bob Payne: [00:17:24] Yeah. Ben Scott: [00:17:24] But everybody should be able to write before or after, there's not. Never does ..That's Not allowed. Bob Payne: [00:17:31] Yeah I think it's a reasonable place to be strict. I think for me just I. Bob Payne: [00:17:39] I loved Arlo Belshee. I think it was our Arlo Belshee that coined the term test infected because some people either are or are not. And it's like you know that zombie strain virus. And I don't know which side is the zombie in which is the not here but I think the TTD folks are probably the zombies. But if you were when you find yourself on one side of that divide I think that the folks that actually like TTD and I know it is not universal. It's it's one of the more powerful and least used agile engineering practices.  Ben Scott: [00:18:15] Yes. Bob Payne: [00:18:16] I mean Pairing, people say they pair, but nobody pairs. I mean not like. Ben Scott: [00:18:21] Well not like extreme program where you must pair. Right. We like to pair for occasions like right. Here's a difficult piece of code. Let's work on it together or for mentoring. We'll pair for code reviews the type of thing we'll do some pairing for writing prose not so much right. How hard is it to write Pojos. You know it's so many people go down this rabbit hole to we test the setters and getters like I don't care. Like ok. Probably not. I'm OK. But really how long would it take you to actually do it if you said if everybody said we need to.  Ben Scott: [00:19:09] So. So interesting thing. So the debate by just writing a piece of code using reflection finds a perjures sets the value gets the value a certain done. So all my pages are tested automatically. Bob Payne: [00:19:25] Yeah. and now with generative frameworks it is it is relatively easy. I was cured of that debate because I'm not a great programmer. When I misformatted the way I created a Java date. And so when I made and I always know how to make your assertion not against the same constructor that you used. So I use distracted at this other date class add some other stuff in and misuse the constructor and when I assert it against the string format it value, i'm like "Well that's not right." And I don't know that I would have found that regular regular test or I would have I would have found like f'd up dates in the database or in the persistence layer or in the front end and I'm like I might not know. Then I've got a whole different problem but because I knew it I found out early that it didn't work like the debugging. For me it was just so much so much easier. Ben Scott: [00:20:36] And eventually you have to use common sense. You look at your POJO like well maybe I don't need to test every single one of them. But if you're serializing a date you should test that because for whatever reason it's so strict that the date format it will kill you application is different for might just use a whole AI behind it to be able to extract data and decide what date it is.  Bob Payne: [00:21:00] You guys likes you know you guys like screw up the order of the month and the day like what is this? Ben Scott: [00:21:05] It has Slashes no slashes. Bob Payne: [00:21:07] Dashes no dashes, dots..  Ben Scott: [00:21:10] Or you add milliseconds and you expect no milliseconds and it still won't truncate it'll just die right there. Bob Payne: [00:21:17] Yeah. Ben Scott: [00:21:17] So testing that. That's a good test. Typically also have a serialization test if it's data layer i'll serialize or deserialize back to the object, validate, but I might not validate.  Bob Payne: [00:21:30] You know that was that it was more important when he had to write her own serializer. Ben Scott: [00:21:37] Well I don't write my own serializer but I do write my own test for the annotations like for date format for example did you do the right format right. Does the precision matter or those type of things you have and I'm working on a project right now that for whatever reason the order matters. The order should not matter but whoever was sending it to they got that code where the order of your serialization matters and they can't just construct the object they actually validate it in its raw format first.  Bob Payne: [00:22:05] Okay. Ben Scott: [00:22:06] So then we have to validate that we send in the right Json format but in the right order each field. It shouldn't matter. At least in my opinion it should not matter.  Bob Payne: [00:22:15] No. But yeah well unless you want strong coupling in implementations which I'm shocked at how many are organizations really like strong coupling. Ben Scott: [00:22:33] I'm not sure they like it or just live with it. Bob Payne: [00:22:36] Yeah it's Like oh my god. It's like it's like the old Korbo or SOAP. Oh man. Ben Scott: [00:22:42] This is how we've always done it so we will continue. Bob Payne: [00:22:44] Yeah. Yep. So what else would do you. What's interesting to you in what hobbies do you have besides like? Ben Scott: [00:22:56] Kids.. Does that count as Hobbies? Bob Payne: [00:22:58] Yeah. Ben Scott: [00:22:59] It takes a lot of my time - it's fun time, it's really interesting and enjoyable to watch and grow. But I did find my most of my hobbies dropped away little by little. Bob Payne: [00:23:10] Yeah. Ben Scott: [00:23:13] When I did become a parent. Bob Payne: [00:23:16] I picked up new hobbies like I had never watched soccer before because I didn't like sports because those were the people that beat up the geeks. And now I'm doing like Magic the Gathering which I avoided in college like the plague. Ben Scott: [00:23:43] I never got into that. Bob Payne: [00:23:43] Because I was more of a punk than a D&D. There's a reasonable Venn diagram there. But but. Now I'm going to Friday Night Magic with my son. Ben Scott: [00:23:55] So that's a very fun but very expensive game. Bob Payne: [00:23:59] It is. Like you know a lot of people like do sports gambling. I think that's even worse. You know. Ben Scott: [00:24:06] Yes. Bob Payne: [00:24:07] Liaisons in a Russian hotel. Let it get very expensive very quickly depending on what you're doing. Ben Scott: [00:24:17] And I also do gaming video games typically do single player story type games. Bob Payne: [00:24:23] Oh really? given your military background. You've had enough First Person Shooter.. Ben Scott: [00:24:31] We'll it's more that to play online takes dedicated time whereas a single player. I can stop anytime. Pause and walk away. Bob Payne: [00:24:39] Yeah. Ben Scott: [00:24:40] I find that sometimes as a parent it's really hard to get an hour dedicated time. Bob Payne: [00:24:43] Oh yeah yeah. Ben Scott: [00:24:44] straight to play, it's like no I cannot help you to do anything because I'm in my game. If I'm doing single player I can quickly pause and do something else. That's how I mostly got into it. Ben Scott: [00:24:54] Before kids I was mostly into Dota. Bob Payne: [00:24:59] sorry? Ben Scott: [00:24:59] Dota Which is a different type of game. Bob Payne: [00:25:02] OK. Ben Scott: [00:25:03] League of Legends. Very similar as the birth of League of Legends. Was one of the first of those types of games.  Bob Payne: [00:25:11] Okay. But that's when I decided it would be hard for me to play because it requires 1 hour blocks.  Bob Payne: [00:25:19] Oh yeah. Yeah. Ben Scott: [00:25:22] Couldn't dedicate that anymore.  Bob Payne: [00:25:23] I know, yeah. So there's there's probably a game waiting for me this evening when I go home. So let's see. But. Ben Scott: [00:25:35] Let's see what else now spend time with family. Every Wednesday we have. Bob Payne: [00:25:42] Long walks on the beach and. Ben Scott: [00:25:43] Ah.. Not that, Just cook and eat and and drink and be merry. Revolves around food, and every Wednesday we have big family dinner.  Bob Payne: [00:25:55] Wednesday? Ben Scott:[00:25:55] Yeah Wednesday just because weekends are crazy. We also do on weekends. But we found that doing it in the middle of the week it kind of cuts the week and half. Bob Payne: [00:26:04] Yeah. You talk about work a little bit the stress and excuse to escape the daily grind of get up go to work. Come back do homework or other things. It's another event middle of the week that's a bit unusual but yeah it works for us. Bob Payne: [00:26:22] Yeah Wednesdays are not that exciting, it's dessert day. So. Ben Scott: [00:26:26] I like family Wednesdays. It's fun. Bob Payne: [00:26:29] Ok cool. We'll have to we'll have to do dessert/Dota/. Ben Scott: [00:26:37] Well I haven't played that game in so long i'd probably be terrible at it now. Bob Payne: [00:26:41] It's ok. You're better than I am  Ben Scott: [00:26:44] Probably. Bob Payne: [00:26:48] Thanks a lot, Ben Really appreciate it.  

Aaron and FLASH discover the secret of PRIME's mysterious past hidden deep in a Triassic jungle. View full episode show notes at www.MyDogRocket.com

Today my great friend Phoebe (Pojo) joins me in talking about the youth and how we grow. We'll also discuss social media, Will Smith and much more!

Vi pratar om allt mellan Andreas nya jobb och feedback från förra avsnittet till programmeringsspel och mobbprogrammering. Vad tjänar man egentligen på att sitta flera personer och skriva kod tillsammans? Vi som driver Still in beta är Anton Gunnarsson, Amanda Sjöström och Andreas Lundgren. Har du kommentarer, frågor eller tips? Hör gärna av dig till oss på @stillinbetapodd eller info@stillinbeta.se. Om du tycker om det vi gör blir vi väldigt glada om du recenserar och prenumererar på oss i iTunes. Länkar Leetspeak Kidspeak Justin Nel DevSum ZType TIS-100 Hanselminutes Scott Hanselman Vimium Advent of Code

Alex Matchneer: @machty | FutureProof Retail Show Notes: Charles and Alex Matchneer have a great discussion that centers around routing in Ember.js: what they want to see in a router, what problems it solves, what's wrong with the routing solutions we currently have, and what the ideal future looks like in respect to routing. Resources: Episode 067: ember-concurrency with Alex Matchneer Cordova ember-rideshare react-router Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast, Episode #86. My name is Charles Lowell, your developer here at the Frontside and podcast host-in-training. I'm flying solo today. It's been a while but that's okay because I've got a really fantastic guest on. Actually, we debated this at the beginning of the show, whether this was the third or the fourth time he's actually been on but no times are too many so hello, Alex Matchneer. Welcome back to the podcast. ALEX: Thank you. It's great to be back. CHARLES: You're still at the same place that you were the last time. ALEX: Yeah. Still working at FutureProof Retail. I'm still working on bunch of mobile ember-cordova apps and that's definitely occupying on my time. CHARLES: Nice. Because FutureProof Retail has a large hardware component and we were doing a series on IoT, we were originally going to have you on the show to actually talk about that experience of what it's like to be a part of a startup and develop software that's going to be running on a bunch of devices and the unique set of problems that poses. But in the pre-show, we decided to scrap that because there's actually a topic that we're both very interested in and you've been heavily involved in lately and might be a really interesting preview as to what's coming in the Ember community and at large. Today we're actually going to go back to talking about the same subject that we talked about in our first podcast, which is routing: what we want to see in a router, what problems does it solve, what's wrong with the routing solutions that we have today. Talk about what that beautiful, ideal future that we want to live in looks like with respect to routing. You've been thinking about this a lot lately. What have you been thinking? ALEX: I'm an Ember core team emeritus and back when I was on it and I'm a lot more active, I did a lot of work on the router, particularly with how it handles asynchronously loading data when you click on links and go to different sections of your app. I spend a lot of time over the last three or four years figuring out the nice patterns for what you actually want to use if you're building out lots of Ember apps. Then kind of around that time, right after landing some cool stuff and some not cool such us query params, which has been a challenging aspect, I start working at this company FutureProof Retail that is like 90% of the Ember work that I do there is in mobile apps. We use Cordova so we're basically running these apps inside a web view, inside either iOS or Android so that we can stay with the technologies we are most familiar with, such as JavaScript and CSS and HTML and build apps using that. We can use Ember to do that. What I found was that I couldn't really apply a lot of the same patterns, all these nice conventions that Ember router gives you. I couldn't really find a way to map that onto what I need to build in mobile apps and there's a few different reasons. I got really busy with the startup, just trying to build these things and kind of went off the happy path where I really just couldn't find a way to make it look like an Ember app. One of the nice things about the whole points of convention over configuration as this sort of Ember and Rails philosophy is that, one of the benefits is that if you know Ember and know Rails, you can drop into someone else's apps as long they're following these basic conventions and immediately know how to be productive and know how it's structured, know how to make a change to it and have it maintain a convention and not just have everybody who's using some framework build these totally different apps from each other that have no shared conventions and whatnot. Everyone is supposed to be able to learn from each other, grow with each other as long as they stay with these conventions. I couldn't really find out how to stay within Ember conventions and build this mobile apps. For a long time, I just didn't really contribute too much to the Ember router at all. I kind of fell out of touch with how most people are using it because most people are building these desktop-centric apps and here I am working on these mobile apps after three years. CHARLES: What are some of the specific use cases that were just impossible to, or not impossible but presented a challenge? ALEX: The first one is which is I think is actually one of the easier problems to solve but still some challenging is that you want something that's called stack routing or stack navigation in a mobile app, which is if you're actually building a native iOS app or an Android app, they both have different names for how they provide you this. But you're thinking of things in terms of stacks. In Android, you might open another activity, which is a full frame of a page in your app and you can push it and then when you press the back button, which is built in in Android phones, it'll pop that off the stack and take you back to where you were. In iOS, they give you a UI navigation controller and let you push and pop view controllers and that is how they want you to think about these applications. That is contrasting to what Ember makes you think about, which is go and define your static hierarchy of all the different places that you can be in an app. But with stack-based navigation, you don't necessarily know upfront all the different orderings of which frames are going to be pushed onto what and you might have situations where you want to be able to dynamically push, say an 'Add a Credit Card' page to where you are and maybe it depends on some data that's been loaded at some lower level in the stack and you can't model that as nested routes in the way that you might think about it in classic Ember apps. It's a different structure -- CHARLES: Now, when you say lower in the stack, I'm curious, if you're entered in aren't you... Oh, you mean... I see, previously in the stack. Okay, so lower in the stack so you're thinking like your current position is at the top of the stack. ALEX: Right, yeah. CHARLES: I see. Now, let me just clarify this in my own head. Your Ember routing structure is ultimately realizes a static tree but at any moment, you are entered into one path through that tree so you do have something resembling a stack. It's just is it the pathways that the ways that you can actually get nodes onto the top of the stack is you're limited because that can't be dynamic. ALEX: Yeah, but even then, it's hard to describe what the difference is but the kind of stack that you're thinking of in terms of the classic Ember router map is more like you're in these different substates than you are different frames that you've pushed onto your -- CHARLES: There's a finite and fully enumerated set of next states. ALEX: Right. To be very concrete, if you have a post route and then a post show route and then a comments route under that and these are all nested in a row, then if you're in the comments route, you are in a kind of hierarchical stack that might have loaded the post that you're looking at and maybe the post call-to-action above that and the comments for that but you're still in one thing. You've just expressed that one thing in terms of these substates so that every other state that's in the parent state can share the same data loading. That's different from saying, "I'm on this page and now, I want to push another page on it and maybe tap some of the data that has been loaded on previous pages." That's more of a navigation stack in a hierarchical substates stack. CHARLES: Is the difference then, the data dependency? Because if you think of the Ember classic where you got the static tree, at least theoretically all of the data in the leaf nodes depends on the data that's above. It's not just being able to dynamically push stuff onto the new stack but it's also saying, you want to be able to push stuff that might have no dependency on the stuff further up and it doesn't need to be re-rendered if stuff further up the stack changes. ALEX: Correct. CHARLES: But sometimes it might. ALEX: Right so there are a lot of corner cases that come out if you try to model this new way that a lot of corner cases have been thought out of if everything matched nicely to this hierarchical substate classic Ember stack but not for navigation. If you want to do something that's stacked routing-based, I've had a few different approaches. At our company, we maintain a suite of different apps that are sort of retailer or grocery-centric and the first one we did, which is more popular flagship one is Mobile Checkout, which is an app that lets you going to stores, scan items with your phone and checkout and skip the cashier line, which is great if there's huge lines and you just want to buy a little handful of things or maybe in your shopping cart. But that is like any other mobile app is really conducive to this step navigation approach. Then we had to make a few apps after that such as like another app that is [inaudible] do a manual check then ordering app and other of handful things that you can imagine is might be used on a grocery store. I took the opportunity to like, "I don't really like how the routing turn out the main mobile checkout shopper apps so let's try different things." If you approaches, at least have their pros and cons without really feeling you're solving the problem and one is to maintain your own in-memory stack of where you were, every link to you, you might recall where you were and then use that logic in addition to what's in a URL to decide what transitions to make, which to use Liquid Fire for that. But already, there's these weird growing questions like, "Why are you even using the URL? Is it helping you at all?" That was the main issue with the main app that we did. The other approach was to try and not even use any of the 'router.map' stuff at all. I use the router.map to basically just create one wildcard route. You can use normal Ember to use it like '*half' and that basically collects the rest of the URL as a param that you can use to do whatever you want with. I was using that to basically pass to another, which is internally used by Ember to do the stack-based parsing like grab a little bit of the URL and then parse the param for that then grab another. Every time you could see your stack in the URL. That has its benefits but the worst part about it is that it's getting further away from Ember so any add on that you might want to use at Internet of Things in terms of which route you're in and has conventions like that you just can't use. I can't think of a good example at the top my head but it's like the further you get away from those norms, the less the Ember system can help you and on your own building your own framework. This is all to say that I think I have enough experience at this point to bring home some of the things to Ember and I'm excited to get back into contributing to Ember with this one particular thing that I'm focusing on now, which is... I don't even know what to call it. It's like -- CHARLES: What does it do? The route stuff? ALEX: It's route stuff. Actually, let me get into the other... That's what is tricky about stack routing and tricky to sort of, if you already have to go through a mental hurdle with thinking of the Ember router and as a stack of states or substates and you train your brain to think that way, it's really hard to take yourself out of it and realize that what you're trying to build with like a classic mobile navigation is almost looks like the same thing but it's really different. The other challenging problem, which is specific to our particular app is that you wouldn't think of it as a very heavily server-driven app but if you're writing an application that at any point can get a message from the server like, "Hey, your status has changed," and that state is heavily coupled to navigation of where you're allowed to be in your apps for the state of some certain model, then you're going to have a really hard time, I'd say in modeling an Ember. I have a really hard time convincing people of this until they've actually tried to do it themselves, which is why I'm going off and just building things showing people. CHARLES: You don't have to convince me because I think one of the biggest problems is the router is like the one non-reactive piece of Ember, which is unfortunate because it's essentially, what is the equivalent of the Redux store in a Redux application, where it's the state that drives literally the entire application and yet, any type of non-hash change driven updates, you have to manually manage. Every time that we've done it, it's been a problem and depends on what data, at that point you have to be very thoughtful because, at least from the highest level, if there's damage to a piece of the tree higher up, you need to realize those effects of that damage or that change all the way down the tree. ALEX: Exactly. That is a great way of putting it. This is maybe a good time to mention this thing called ember-rideshare. I've had a really hard time describing these problems to people so I figured what I would do is write this blog a few months back, a little article called ember-rideshare. It's just a given name to the kind of app that still really hard to write in Ember. It's a mobile app. It involves stack routing but the other part is really difficult about it is this problem of the router being in a silo. It is reactive but it's only reactive to that URL. Other things changes, they need to, like you said come in and patch up something else about the router in case you add some URL that is no longer able to present some model of whose status changed. That's an article on a blog that I can probably link to in show notes or something. When I talk about ember-rideshare, imagine using Ember to build Uber or Lyft and it's got just the slightest bit of the whole thing. The whole point of the app is to coordinate your client-side request of I want to ride with the server going off and doing a bunch of things and finding a nearby driver, displaying you bunch of driver locations and it'll show up. Then finally, find you a driver. It's a constant communication. Throughout that point, you can sort of imagine modeling all the different screens as routes but the routes that are actually allowed to see at any given time are heavily dependent on what is the current state of the user's current ride. But you shouldn't be able to go to a route that says like 'cancel ride request,' if you haven't requested a ride in a million of these other things. If you're an Ember developer and you think that's an easy problem to solve, you're probably thinking, "I would use before model hook when I'm entering that route to check the state of the model," and if it doesn't make sense for the route of entering, I want to transition elsewhere. That's fine. That's good if you're doing an app if the user is the one deciding where to navigate to. But then when you're on a route like that and then the server tells you that your ride is done, you can't still be on that route so you've got to have some kind of validations that is like, "This is no longer a valid route to be in. Is the user still in this route?" CHARLES: "Where am I going?" ALEX: Yeah. Before model doesn't really help you. It's this one-shot discrete event and you just can't capture all the different things. The ember-rideshare describes some of these problems a little bit more detail but that's the main issue with it. Like you said, what is actually missing about the router? Maybe it's reactive but it's only reactive to the URL, what about all these other things that are happening into your app? I think there's a handful of APIs in Ember that they're great but they're kind of siloed off in a way. If you want to make two different kinds of worlds meet, you've got to write a bunch of your own code yourself or you just have to do mentally going back and forth and being like, "I did this, so I can't use this kind of API." I did a lot of work on the Named Blocks RFC, which previously there is silos between if you're passing blocks to a component versus data, you've got to think about them differently and all the ways that you might forward that data to a different internal component, if you want to build these composable, reasonable internals, you got to be kind of split-brain about it. I feel the same way about how the Ember router works. It's only good at dealing with stuff that has to do with the URL and you're on your own, if you needed to react to data changing. That's what I'm trying to fix. Does that correlate with your experience of working on Ember stuff as well? CHARLES: Absolutely. I think that's a great way to put it. I think we've come to a consensus of the problem statement. I am curious to see a big separate query params. I'm going to throw that wildcard out there or maybe we should save it for later. ALEX: Yeah, I definitely going to come back to it. If I say all this cool stuff and I still don't have a solution to that, then what am I talking about? CHARLES: Right. ALEX: Which to be honest, I haven't thought of every single possible thing. I'm doing the thing where I talk about it on a podcast that everyone can guilt me into really finishing it. I actually really think that I'm going to finish it. I'm very confident in stuff I'm working on. I'm very excited to bring it to people but it is not all 100% fleshed out and I definitely appreciate anyone's help to those interested, understands the nature of the problem and wants to help me work on some of this stuff and like that, in Ember community Slack or wherever. CHARLES: Yeah, I'm really excited to hear it and see in what ways we might be able to contribute. ALEX: Basically, the goal is to find some underlying primitives that can model the current behavior without mistake because obviously, we can introduce something that's going to break into Ember apps. Basically, to recognize that the URL is something that goes through multiple passes of transformation, to eventually become the thing that displays stuff on your screen, from the very foundation of it, and this is the actual mini-course of what Ember router does internally because it involves a few different libraries and maybe this is a re-hash from the podcast that I did with you guys but -- CHARLES: Can I just say that there are some things that the Ember router really does right, that are fantastic? One of those things is it baked in to every single piece of data. It doesn't do the stack but in that tree that it models, every single node in that tree abstracts away the asynchrony of that node. I think that's absolutely huge so you get both the dependency enumerated like these are the things that I need to marshal the data to render myself and it's implicit that it might take some time. I might need to draw on a couple of different things to actually assemble this data so the asynchronous nature is modeled up front and it's implicit and it's there every single time, which turns out to be the right thing. The sampling that I've missed has been an excruciating void in all the other routing solutions that I've tried outside of the Ember community is that they just punt over asynchrony to you. You deal with it, not our problem and it's like, "Actually, that is the problem." Anyway... ALEX: That's a great point because if the router doesn't help you with any of this stuff at all, then it basically means that every one of your pages that you might want to render after the fact, probably has to have some loading logic like if data is loading, show us spinner. Otherwise, here's all the data -- CHARLES: Yeah, if something happen wrong. ALEX: Right and sometimes that is actually what you want to do. Sometimes you want to do these skeletal in UIs that looked like the page that's about to display but the date isn't there yet so everything is, regardless going to be wrapped in these 'if' statements, 'else' statements. I worked in ember-concurrency and some people are using that to basically move more of that loading into controllers, that's fine. If that's what you're actually trying to do and that's what you're opting into, that's a perfectly reasonable solution but most of times, chances are you're entering a route and you don't want to have to teach the entire template tree underneath it that has to handle all these different states. There's these nice ideas that work in some cases and I'd like to make them work in more cases than Ember helps with and a whole loading all the promises and the model hooks and absolutely going into the loading state are really cool primitives that Ember is going to do for you. The other frameworks, they don't try to be opinionated. They won't do any of that for you. Sounds like you ran into that with some of your React stuff? CHARLES: Yeah. I definitely did. There's just not much help when you actually want to model asynchrony. You can do it. It's pretty easy. You just implement the right hooks or model a series of actions, either with a Saga or Epic, if you're using redux-observable. But again, you have to assemble it by hand and you have to generate those abstractions by hand and you just want to have them at hand already and not have to worry about that. But the advantage, though is that generally those ones that you do have at hand or that you generate are fully reactive. If new information comes that's germane to that particular leaf in the tree or that particular note in the tree, there's no difference between the initial state and the update state. Whereas, in Ember, you got your first shot and then that data is now at rest. ALEX: Right. I definitely have been looking at React router, in particularly v4. I think it's all contentious for people to see it at first but being able to put things like in your render function, you can say, "If this data is present, something that's going to be past and be a prop or something," then show a loading spinner or otherwise, start matching these subroutes. That's really cool. That's expense that you can't look at essential map of all the states of your router can be in but that's also a real problem and if you can demonstrates that the state world is not in a separate silo than the routing world. CHARLES: With great power comes a lot of bugs. You do run into a lot of things where you have rogue matching. You have random things that are inside your view tree that are matching against the route and they just render and you have to be very careful because it's almost the difference between blacklisting and whitelisting. I see what you're saying. It could be confusing. ALEX: Yeah. I think it's definitely a tradeoff. I think if I had something like a match, I might have been able to maybe arrive at a stack routing solution a little earlier. I'm not sure about that. It's definitely something that could be handled by React router. I think one of things that React and React routers better at in general is that everything is, more or less a component that is more easily swappable or something else here. You're not going to have as many of those silos and I really do think, it went through a lot of churn and maybe, some people had trouble, maybe a lot of people, I don't know had trouble kind of following all the major versions. But I think React router Version 4 is pretty damn cool. I think there's a fullest realization of that kind of modular mindset. CHARLES: I think the biggest problem I have with it, though is it requires the view tree to model your routing structure. That bothers me. I feel like you could do the exact same thing. You could have a way to express your routes, not necessarily with a separate routing file. I supposed you could do it with JSX or something but actually have it be kind of orthogonal to your view tree. The way you can model this dynamically updating thing that can match against anything and maybe, even express it all in one place. Although once you get a big tree, it could be hard to control that. The part that I've come into most conflict and maybe who knows, maybe I just haven't used it enough, we've only got one application that we're using the router V4 on. But the fact that it's actually in the view tree, it bothers me. It's in the state objects. It's hard to adapt to Redux because that state is opaque. It's the routers controlling it and I would it to be not have to pass through React components but just be like, give me the firehose of the router state. ALEX: Right. I love what you're saying. If I'm going to bring this stuff to Ember, I can't suddenly make it work like matching within the view tree. That's not what I'm working at or proposing here. All the stuff is basically to empower that firehose to respond to more things that can drives views and respond to them in a live way, not like a one-shot async validation, only when you enter. CHARLES: Maybe this is what the problem that you're trying to solve and one of the things it's really nice to be able to match against anything inside the view tree is that Ember's rendering process of a route is very opaque. The process, by which an outlet gets connected, that's not something that you really have much visibility into. Is that a good statement of the problem? ALEX: That's definitely part of it. You definitely have to go to the documents. I think it's telling that -- CHARLES: I've never done it. I don't really know how that works and I've written a lot of Ember code. ALEX: How what works? CHARLES: How the route gets rendered, like the mechanics around, which I understand how the route object actually, you makes the decision to render its template and do all that stuff. I know it as a user but I don't know the mechanics and I wouldn't know how to extend it. ALEX: I'm not sure if the stuff I'd work on but it immediately make some of that stuff more clear. One of the goal or constraints is to really try and break down the silos. Whatever I'm about to propose bringing to Ember, I want it also be something that would be useful, possibly at the component or template or controller level, rather than just being this thing that lives only in the router's weird black box of logic that occasionally calls hooks that everyone knows about. CHARLES: Right. In a sense, I'd say that they both suffer from that same problem. I'm curious to hear about the firehose. ALEX: To actually get into what I think you're building here, we can dance around it all day and then we -- CHARLES: Just save it for the last 30 seconds of the podcast. That way there could be no -- ALEX: We're swapping JS for React router V4. Bye! It's basically this. What's happening today is that you have a URL, it's going to be parsed in a way that you've tied it to via the router map file, which every Ember app has the place to go to see all the different places that you can navigate to an Ember app, which is great. You basically taught Ember how to break your long URL string into these usable bits and that's going to give you an array of these things that internally who cares what they're called but they're called handler infos and they basically say, "The first element of this array is named application. Every Ember app has one. It doesn't have any params." The next one, it starts getting into what your URL actually is. Maybe it corresponds to the '/post' portion of the URL so that's going to be named 'post,' and that doesn't have any extra params either. Then there's this thing that is post show or something like that. That has a dynamic param because that's the part of the URL as like the '/123' and that corresponds to the post ID. It's basically, if you like thinking of things in terms of transformations or observables or mapping and functional transformations, that's taking a URL and turning it into an array of these useful POJOs of information. The goal is to keep transforming that into something eventually has enough data to display and templates and whatnot. In this giant black box of the Ember router, it's going through those transformations and then it's going to go through this long series of using these params and this useful array of POJO information, start hitting hooks on people's routes to load data. Hit before model after model, redirect all these things to give tasteful names to all the tons of validations and checks that you might want to do. You do cool things in your before model hooks, check if the current user is actually an admin to prevent them from going into any '/admin' subroute. That's a really cool place to go and it's also a great convention. If you're new in Ember app, you realize you can't go on this route. It should sort of click in your head and that sounds like they've got one of these redirect hooks to ensure that you're not going anywhere you're not supposed to go. All these things are really still to this day, extremely strong, well-designed, it went through many passes of review before it landed. I think they cater to a certain kinds of user-driven clicking around apps but they are extremely strong to this day. I think the only thing that's missing is the smell. That example I gave like checking if the user is an admin, it's a bit of a smell that is not reactive. It's a hook. If it passes, great. You're in the route. It's not going to keep on checking that. What I want to do is basically, either in addition to or as an alternative to specifying these one-off model hooks or these hooks that you, not only really just fire one time, have essentially what is an async computed property or an async validation that is upfront about things it depends on. Ember is going to be smart enough to constantly reevaluate these things as stuff changes. It can depend on not just URLs or URL parameters but it can also depend on data. If you're thinking about ember-rideshare, which again is the imaginary Ember app that it's essentially Lyft or Uber, if you have a current ride model loaded somewhere, maybe by a parent route or maybe it's some sort of service, you should be able to specify it like an async property or validation that says, "I depend on ride.state," and for all these subroutes, you would want to say that, either upon entry or any point in the future, if the state ever changes to something that I don't know how to handle that go to some default route. That would be already, particularly in my app, which is a subset of a different kind of ember-rideshare app, that would be a huge help because the only other alternative is to build a sibling-central coordinator to the router that isn't the router but has to sort of agree with it and then, every one of these frames that you might push onto the navigation stack, they have to do some little chunk of code and then invoke this logic and be like, "Did the state change? Go where you're supposed to go," and they have to do that logic. It would be, I think a great win for conventions as it has if it's a benefit to make people shout out their states in advance to empower them to shout out also their data constraints in advance so that you get things like automatic redirects and things change, I think that would be huge. I know that would immediately benefit off of it and I think it would fall in the same kind of problem solving that they worked on like Ember-related stuff which people don't realize how big a problem is until they see there's a better way of doing stuff. I think with that being there -- CHARLES: As an example, let's say that you're an admin and then all of a sudden, you got fired and there's an event that comes from a server that's this person is no longer an admin and it wipes out the Ember data store and then redirect you outside of the admin route or something like that. ALEX: Yeah, that's a perfect example. To be pedantic, I think a lot of people do hard refreshes between login/sign-off stuff but if you have it all in your Ember app, that would just happen automatically. You'd still want the ability to have more graceful transitions because one of the tricky things about having stuff driven by data is that you have this giant matrix of like, "If I'm in this state and this event happens, how do I handle it? How do I make it look well-designed to the user?" But you're not going to be able to hit every one of those constraints so to just have some basic logic that's just like, "Oops, something happened," you're not an admin so we move you to the sign-in page. For in those cases, we haven't fully filled in all those leaks. I think it would be a huge win and you can just progressively decorate things according to the common flows that people take through your app. CHARLES: You know, I'm just imagining this. Model promise, for example would be some computed property, then how would you enumerate your dependencies? Just do the mechanism that we have now? Or are you imagining something entirely new? ALEX: I don't have a strong opinion on it because the moment I start saying what that specific syntax is, more people will agree on what's missing and what we need to have, regardless and be like, "I don't like it." I'm leaning toward something inspired by a lot of my learnings from observables, which is actually we talked about last time. The whole thing about observables is that there's almost limitless flexibility as to if you're in observable, it can take that event. It has been another observable based on that thing. If a URL changes and you're listening to that via observable description, inside that, you could kick off another observable of Ajax request based on that URL and it doesn't make you enumerate all these things upfront. I think there is going to be a compromise between that. I think when you get into these kinds of problems, you run into stuff like Relay, which is familiar with -- CHARLES: I haven't used Relay. ALEX: Just the idea of dynamically collecting all of your dependencies upfront before hitting the server and asking for specific chunks of data that you need, it's a very promising idea. There's cases of just dynamicism where the data comes back from the server, then you realized that you need this other piece of data and there's no way you could have collected upfront, unless you statically wrote it upfront. I expect to find that with this approach that there's going to be some stuff where you just have to be more upfront about it. But I had a cool little strike the other day on auto-computed properties and I'll also link to that. It's a different way of running computer properties where you don't have to specify your depending keys upfront but your getter function gets passed a getter function itself. CHARLES: It's past the dependencies? ALEX: Not even that. Imagine writing a computer property and the first [inaudible] is a function that you can call to get a property off of this but also track that you've got that property. If it ever changes, it'll invalidate again. That means if you're implementing a [inaudible] in computer property, you don't have to write first name twice, both in your dependent keys and in the actual getter in your function, which I think is kind of cool. I'm trying to make that pattern work for this data loading thing so that you don't have to have this huge verbose thing. You just lift this stuff in one place. I've sensed that the magic will probably break down in some complicated cases but that's what I'm trying to run with because I think it's pretty cool and succinct and sort of the natural evolution of what people think of as computer properties. The other major constraint and this is also what we're talking about because it's one of the best kept secrets about the router or it's one of these things that everyone's benefiting from without realizing it, is that if a transition occurs in the router, everything in the router is going to be a possibly long asynchronous chain of operations that it collects all the data that it needs for the new routes to display. In that time, if something happens, if some hook comes along and has an exception, it can load data from the servers. If something happens then it just says 'transition.abort,' that's going to stop whatever transition is in place and you're going to stay exactly where you were and if you're not stuck in a partial transition state, that's pretty awesome. That's basically database atomic transaction semantics that people have been benefiting from if they've been using Ember for years at this point. But again, it suffers a problem being locked away in the router. That is a cool concept. You should be able to specify like I intend this change of the state this way and if I gave you something that is logically inconsistent or can't be fulfilled, don't leave me in a weird half-assed state that I need to somehow fix and know how to fix all the different places, where I might be kicking off this transaction. I'm trying desperately to preserve those semantics when data comes into it. One of the hardest things to do is and honestly, can be one of the hardest sells for people who are used to thinking about Ember is there's an issue of if you imagine whatever API we're talking about, it's probably going to live on the route. Some kind of hook that might be called resolve or something else, like what is the value of this context object that every function has? Is it a route? It's tempting to want to do that and maybe, that will end up winning but winning out is the best API to get people to use. The thing to realize is that there is no consistent value of this. This implies that there's a state of the world and you're looking at it and currently, these things have these values. But in the transaction phase, there is no stable 'this object' and you can wind up with some weird surprises. I know because, not actually these days but particularly, when a lot of the stuff landed and people started trying to do weird things and these transaction hooks, there's just like, "Why can't I grab the controller? The property isn't what I expected?" Honestly, all the stuff that is gross about query params because of this fundamental violation. You have something that pretends to be a property that is there today but is still driving this asynchronous thing that could fail. CHARLES: I kind of viewed this as playing an off-note in the jazz thing like you only want to reserve using this, unless you're the Miles Davis of JavaScript, don't use this. ALEX: And by Miles Davis, you just mean like the god of concurrency that's incorrect race-condition-y code. CHARLES: Right, so it's just like you've got the right reason and you can spot the one-in-a-million case, where it's appropriate. You can spot it in an instant. ALEX: Exactly. I'm not that person and I don't know too many people who are and that's not the API you want to land. I'm trying to, maybe wean people off on dependency on this because the way we've gotten around it in the past is to use again, is more discrete, get the value functions called 'get model' and 'get params.' These are all very in-depth stuff if you're pretty experience Ember developer but it's a way of getting a value from one of these parent routes when you're inside a transition and the rest the world can't see it but you can because you call this hook at the right time. It's super gross because it's just a method on a route that anyone can call in any given time, whether you're inside this transaction or not. The branching logic of, "Should I look up the data from the transaction object?" because once valid, I should have get the current value of a loaded route. It's really gross to me and it causes real problems that confuse people and causes them to write issues because they've given an API that makes them feel good about treating these things as stable objects. CHARLES: I'm trying to imagine now, just like a spike in my head. I know you don't want to get too into syntax but essentially, modeling the route tree as a set of observables, where essentially, instead of returning a promise from your model, you're just mapping an observable off of some combination of the URL state or what are the other streams of state you want to merge to realize that route. But what I'm not seeing, which I'm sure you also have the answer is the original problem, which was stack routing. What we've been talking about is making the router fully reactive like this fully reactive tree that's always on. But that problem seems almost orthogonal to the stock routing problem. ALEX: It is. It's been very tempting to combine them. Why it is such a hard problem? Because you've got navigation stack, which almost to this route hierarchy stack that [inaudible] about but they're separate so you can't really apply the same lessons. Then you've got stack routing, which is you want the ability for routes to while they're loading, reference data that is dynamically available to them. I don't have a solid answer but I would say, the one thing that I think is going to help is that you have a few options for what you want to stash how you want to represent a URL or where you want to stash your hierarchy. Actually just track it in-memory and if you refresh the page, it'd be like, "I depend on some data that I expected to be there but it's not. It transition elsewhere," which is not a great developer experience. You could want to be able to make changes and refresh the page and continue where you left off. Otherwise, URLs aren't actually used by mobile app users. But the other place that you could possibly put the navigation where event stack is in a query param because that can be fully dynamic and you can just sort of manage every single page. The most current page you've pop is just some top-level route but you're tracking the state on the side. I think if you solve the problem of being able to depend on things that aren't the URL or go through a more complex transition than what the router gives you by default, I think it would be possible to treat that query param or that thing you're stashing in in-memory as another source of data. The other thing that I want to try and make sure that this new API has is really treated dependency injection where you specify all the things that you need and you don't really care from a route's perspective where they come from. I think if you had that, that would solve a lot of problems with stack routing and where it gets data from. To be very specific, today if you were in that post '1, 2, 3' comments route and you needed to access the post model from within the comments route, you would probably do this model for post. Basically you're naming not just the model that you need. You're naming the route that you know provides it upfront, which I think is that. Actually, the real reason it's kind of the smell is that, if you ever need to change the nesting, maybe you need to introduce another level or you want to nest all that under an admin route. Then suddenly, you're asking for the wrong route name. You're not really sure all the different things you need to update if you ever change the nesting of your router. There's solutions like relative URLs that a lot of people thrown around but I think -- CHARLES: To go back in the observable world and specifically, the redux-observable world, it's like a simple map. You're just mapping down off of a global prop, you've got some tree of state and you're just mapping off... What was that like? A model hook and you're just mapping down off of that? Wherever that state lives, you're mapping to it and now you kind of slicing off your little garden hose off of the firehose. But still one huge -- ALEX: I've tried to apply observables to this problem. I don't think I've never seen the observable analogue of is this idea of dependency and injection. To model something as a stream that transforms over time, that's proven to be very useful but to sort of say, "I am an observable that expects these objects given to me," I'm not really sure what that API would look. CHARLES: I would say, just as a straw man perhaps, you have this dependency that it's a well-known location. It's a well-known name. With dependency [inaudible] in classic, it's like, "I depend on the off service. This thing called 'service:off' or whatever. Imagine that you have some pool of state and there's some key called ‘service.off' there and as long as I'm just basically basing my stream, the first thing I do is map off of this and maybe map off of another key and then combined those into a single stream, then I can be sure that I have those things at all times. If they change, my mapping function or my transformation function is going to get evaluated again. Does that make sense? ALEX: Yes, I think we should [inaudible] C without code or something. CHARLES: And maybe I'm thinking about it wrongheadedly but that would be a simple mechanism. ALEX: Could you run by me one more time --? CHARLES: Yeah. Let's say that we've got some authentication service that you want to depend on like you want to inject on it. You want to inject that dependency so why can't you base your stream off of that key? You have observable map, for example. The list of transformations that you would have to do to peel off multiple keys, I'm sure you could write helpers for it. But basically, probably if you're going to be wanting to inject multiple dependencies will -- ALEX: The problem is this. Basically, if you want to write your resolved observable, if this thing based on observables, remember that there is no this in a route because of the transactional reasons of what we've talked about earlier, what are you getting that from? You need to have something passed into you, to be like 'context.get observable blah.' CHARLES: I would just assume that it's implicit. I was thinking a bit basically, the simplest case would just be an observable that was basically taken off of the entire global state or whatever of the router or what have you. The way the redux-observable works is every single epic is what they call them is just a transformation on the global stream. Usually, the first thing that happens is they map down to the local context so the -- ALEX: Like a path? CHARLES: They have a helper like action of type, blah. You only see a subset of the actions that get maps to the Redux store. I think it's redux independent but at least in theory, every single epic is basically going off of the entire global state but the first in reality, what the first thing that happens is you're like, "I am only interested in this subset of the state," so you do a map off of the global state down to your local scope and then you work from there. In fact if you had the convention around that, you could even make that part implicit. It's like I return an observable that it's only seeing the stream of local states. ALEX: That makes sense if there's sort of canonical state of the world but what you're doing when you're transitioning into a route is trying to feel out another state in an asynchronous manner. Redux is the action causes state to change, now the state is this. But the action for type thing, I think that makes sense if you are subscribing to the world global action on this one store when you're constructing this new tentative, may not actually become the store, you're depending on values. What we need in our API is something that depends on values that are from a tentative store. CHARLES: It's similar so in redux-observable, you're mapping actions to actions and you're not necessarily mapping actions here. You want to get state into the equation. ALEX: Yeah and it's so almost observables. It's just this twist of transaction dependency injection. It sounds really over-engineered but the thing is it exists in Ember today and if it exists in a less siloed way, I would certainly benefit on it. I think everyone else would too. CHARLES: Okay. With that hand wave... ALEX: Oh, I didn't mean for that to come as a hand wave. CHARLES: No, no, no. I'm kidding because I think we actually have a lot more to talk about here and we're running out of time. One of the thing that I want to ask is, talking about redux-observable, talking about redux and stuff, have you given any thought as to what this might look as a library that everybody could use? ALEX: I basically have something that's using Ember CLI only because it's so easy to just use it as a sketch pad and get test passing but everything I'm building so far is just ES6 class syntax that can be transpiled in it to whatever. I'm actually realizing, there's a lot of overlap between some of the primitives that are involved and Glimmer so it may or may not have a pass that uses references for tracking when things change until no one to invalidate and refire these async hooks. But either way, I'm going to make sure it lives in the JS usable world and not just Ember's special object model end. CHARLES: Right. Those interfaces are pretty narrow. The things that implement those interfaces are huge and complex but the way, at least I understand it, isn't the reference interfaces themselves -- ALEX: They're really simple, yeah. CHARLES: -- Really simple. It could almost be copied and pasted and not have much maintenance overhead in there. Here's a question and this is probably getting too far into the weeds. Can you not model a transaction as an observable? Essentially, with a flatMap, you would merge in some observable into the chain that was basically a transaction of all the other observables from which it is composed. ALEX: You know, a transaction as it builds up all the new state over time could be part of the main tree and if there is an active transition, then that's future potential state that the world might become and it could be modeled as a leg of the Redux state. I think you could theoretically do that. Definitely worth a try. I don't think I would benefit too much from doing it now and I think this could be a premature optimization but I think there would be just quite a bit of intermediate object collection to express that. I think theoretically it works but how it's going to physically map to Ember in the near future, it would be harder [inaudible] in a way. There's actually a lot of stuff that is very redux-y that again, a lot of Ember people don't maybe know about because it's internal but the way that Ember [inaudible], I think since Edward brought some of his learnings of Liquid Fire back to core Ember, there's this concept of outlet state, which describes -- I'm not an expert on it -- what's rendered where and then each outlet gets a chunk. Like you said, a little piece of the firehose or garden hose, pulled off the main thing so it can just focus on the one piece of state. Those are simple objects that produce this part of this transformation process. That's kind of redux-y in the way that everything just gets a new POJO and stuff changes but it's not strictly redux, obviously and probably won't become that just because it's already good enough on its own. CHARLES: Yeah. I think it's actually good at this point to be hand wavy because the most important thing is to be non-committal about the syntax, like you said because that's when the bikeshedding begins and now it's not the phase. The phase is to come to some agreement about what is that we would love to see. ALEX: Basically, the thing is this. I think people need to realize that Ember won the bet that the URL is an important thing to build apps around and if you have a state that's representable in URL, that state should go in the URL so you can send links around and not break the web and have an app that works that's built on half-assed routing. The only thing I'm proposing is going to make that go away. It's just that there is already this giant world of stuff that's not expressible in Ember today because it is driven by state. If you make that as easy to express and as upfront to express, I think you can have shared conventions versus what everyone is building these apps that I have to do, which is to make a sort of separate router of state-aware stuff and not have to make those two things agree with each other because it's really hard. CHARLES: Right. At that point, you're writing your own framework. Maybe this is the next big thing because I feel like Ember usually has the best stuff way, way, way, way before. Now, we're finally getting to a point where everybody seems to realize that having a CLI is absolutely critical to the developer's experience and most frameworks aren't taken seriously until they've achieved that. It was the same thing with a router back in the day. I'm wondering what that next thing is. ALEX: I don't know. I don't think this is going to be it. I just think it's a good progression. I think a way forward that progress is still a pretty legit central structure to build apps around and just would be welcomed. CHARLES: When are you going to be done? ALEX: About two or three days. I don't know. I think I'm basically going to be continuing to get feedback like the way that a lot of that original router stuff came back or it's just like constantly hit people with real examples, Ember twiddles, things are just like, "Oh, yeah. That thing. That's a cool pattern. That sucks in my app. I didn't realize that until I saw this example." These things that really teach people why this is necessary because that's going to get people's urge to be like, "Well, you could just do..." Oh, you can't because the thing that's hard to explain. It's going to be a lot of that regardless and I hope that will kick off in the next few weeks. CHARLES: And the focus of that is going to be the ember-rideshare application. ALEX: I think that's a good one. This is one that everyone's familiar with. CHARLES: Have you already kind of implemented in it, like this kind of Frankenstein-ish, like this is the kind of histrionics that you have to go through in order to implement the style of routing or the style of application using today's Ember? Or have you started to begin experimentation with these new concepts and try to build out better ways of doing it? ALEX: I'm not strictly extracting it from one app. It's sort of combined. Like I said, the few different apps that we had were an opportunity to be like, "This sporadic stuff is hard." The main route recognizer approach was an example to try different stack routing pattern. But the thing that sort of working on is drawing from three different apps and slightly different takes on it. Basically, I have something that is close to being testable in one of my main apps that will be a great chance to validate if all the stuff is as nice as I think it is going to be. CHARLES: Okay. If the people want to get in touch with you, to help to contribute to the conversation or just publicly guilt you into moving faster towards it, how would they get in touch with you? ALEX: I'm at @Machty on Twitter and GitHub and also, the Ember community Slack. I think I'm going to try to get people to talk about this on channel called Dev Dx Router where it's focused on development stuff all around the router. This is kind of funny because I'm talking about this thing that I've only had maybe, 12 people take a look at and comment on and begins these conversations. I think maybe some people are going to hear this and be like, "What are you talking about?" but if it gets people -- CHARLES: No, no, no. You know, the best conversations seemed to be organized around you, man. I'm just trying to think of some of the best development conversations that I've had in 2017 and you were definitely, I would say the one who fomented them. It starts with 12 people but then, if enough people take interest and be like, "Wow, yeah. Oh, man. I didn't even know that was a problem. This would be a cool way of doing it." They have a tendency to balloon and some fizzle out and some end up with real results. Anyway, I'm looking forward to it. ALEX: I appreciate it and likewise, you're definitely one of the best people to talk about this stuff with. CHARLES: Well, I hope other people will love listening to our conversation. With that, we'll head on out. Thank you everybody if you've made it this far. As always, you can get in touch with us at @TheFrontside on Twitter or just send an email to Contact@Frontside.io. We will talk to you next week.

Robert Jackson: @rwjblue | rwjblue.com Show Notes: 01:00 - Build Tooling in JavaScript 02:19 - Ember and Babel 07:14 - Deciding on Features 11:46 - Class 13:29 - Workflow 14:39 - Payload Size 15:24 - Config Targets 17:18 - Source Maps 25:05 - Ember Decorators, Objects and ES6 Classes 36:07 - What's next and when can we get it?! Resources: Babel.js esperanto Ember CLI Targets

Elementor Page Builder is fantastic! Yep... another front-end visual page builder for WordPress has joined the scene (even though it seems like these tools are coming out overnight, I can assure you these take a lot of time to build and test). Personally, I couldn't be happier. Maybe that's because I'm not a developer... many developers are anti-page builders. That's fine. They're not for them. Page builders have been built for users and people who want to get things to market quicker (and more efficiently). Asking a developer to endorse a page builder is like asking a vegetarian to endorse a hamburger. It's an argument that is irrelevant. And now that we got that out of the way, let's jump into Elementor. When I first saw Elementor I was really impressed with it. It has a really smooth UI, tons of features in the free version and is really easy to work with. Needless to say I was excited to have Ben Pines on the show. I'll definitely be doing a full post, review and video on it... but I didn't want to hold up the interview any longer (I have a list of 7 posts to write, so it will be coming soon). Elementor is created by the team at Pojo.me and Ben Pines is the CMO. Questions I asked Ben Fill us in on how you connected with the team at Pojo? Why did you decide to join the team? Visual builders for WordPress are getting much more popular. What made you decide to create Elementor? What makes this different from other visual builders? I'm sure you have this question before, but Elementor is free. How are you guys going to monetize this awesome tool? Where do you see page builders heading? Features of Elementor You're Going to Love Where to find Elementor & Connect with the Team Website | Twitter  | YouTube

Jan in Uroš se vračata s počitnic in v 63. epizodi povzameta novosti, ki jih je predstavil Apple: Apple Watch series 2, iPhone 7 in iPhone 7 Plus. Na oddajo se lahko naročite preko iTunes ali RSS. Jan je na Twitterju @th0r, Uroš je @uros_m, Apgrejd pa je preprosto @Apgrejd. Mrežo Apparatus lahko podprete tudi osebno. Zapiski: Posnetek predstavitve Apple Watch […]

V šesti epizodi izbiramo genetsko in vedenjsko kompatibilne partnerje, spoznamo, zakaj samci mačk in pajkov poškodujejo samičina spolovila, in ugotovimo, kako poteka vrtinčarsko sabljanje...

Manraj Bath, DMD discusses lip augmentation, dental implants, and why his office hardly ever gets dry sockets.     Dr. Bath spent his childhood years in Warren, Pennsylvania before completing his studies in chemistry and biology at Erie's Gannon University. Dr. Bath earned his DMD degree from Case Western Reserve University in Cleveland where he received the AAOMS excellence award in oral surgery. He then completed his Oral & Maxillofacial Surgery (OMS) residency at University Hospitals of Cleveland and Mt. Sinai Medical Center where he received extensive training in facial cosmetic and reconstructive surgery and laser-assisted procedures and was Chief Resident. He is certified by the Ohio State Dental Board to provide training to other doctors and surgeons in the field of OMS and lectures frequently on both the local and national levels.   Dr. Bath maintains three OMS offices in the Columbus, Ohio area where he practices a full range of OMS procedures with emphasis in oral reconstruction through bone grafting and dental implants. Worth noting, Dr. Bath has accumulated experience with more than twenty distinct dental implant systems. In addition, Dr. Bath maintains a cosmetic practice, Bella Cosmedica, in Pickerington. A published author in the fields of OMS and aesthetics, Dr. Bath travels extensively to further his training. He's an active member of numerous professional organizations including:   •American Association of Oral and Maxillofacial Surgeons (AAOMS)  •Ohio Society of Oral and Maxillofacial Surgeons (OSOMS)  •American Society for Laser Medicine and Surgery (ASLMS •American Academy of Cosmetic Surgery (AACS)  •International Congress of Oral Implantologists (ICOI) •American Academy of Cosmetic Physicians (AAOCP)  •American Academy of Aesthetic Medicine (AAAM)   Dr. Bath is an avid movie fan and enjoys photography along with playing the electric guitar. He lives in the Pickerington area with his wife, daughters and African grey parrot Pojo.     2015 Columbus CEO magazine Healthcare Awards Finalist for Volunteerism     Dr. Bath was the 2013 recipient of the Doug Barr Award that is presented by the Pickerington Area Chamber of Commerce. The award is given to an organization within the Pickerington area who has demonstrated continued commitment to the Pickerington/Violet Township area in terms of time, financial and personal or corporate support to community projects that enrich the community by going above and beyond the call of service.   In April of 2012 Dr. Bath was nominated for an Agent of Change Award presented by HandsOn Central Ohio. The award is designed to celebrate outstanding volunteers. Dr. Bath was nominated for his participation with the Dental OPTIONS program, who's mission is to assist Ohioans with special health care needs and/or financial barriers to obtain dental care.      PMJFS.com

Je žival in je priimek, a žival je pogostejša od priimka. Čeprav so pri nas invazije kobilic redke, pa so znani primeri iz začetka 20. stoletja, ko so na kraških pašnikih otroci skupaj z učitelji v organiziranih akcijah pobirali kobilice in teh je bilo za nekaj vagonov. Vrst na naših travnikih je približno 175, na svetu približno 30 000. 97 vrst in dve podvrsti sta v objektiv in v zvočno napravo ujela Stanislav Gomboc in Blaž Šegula, avtorja knjige Pojoče kobilice Slovenije. In če je za vas kobilica le tista skakajoča žival na travniku, boste v knjigi prebrali, da med kobilice sodijo tudi muren, čriček in celo bramor. Morda jih ne marate, ko priskakljajo v vašo bližino, dejstvo pa je, da če bi človek lahko skočil tako daleč in visoko, kot skoči kobilica, bi lahko preskočil hišo.