Podcasts about ASDF

The search continued overnight through Thursday for the two missing crew members of an Air Self-Defense Force training plane that crashed in central Japan the previous day.

航空自衛隊のＴ４練習機１４日午後３時すぎ、航空自衛隊小牧基地を離陸した練習機「Ｔ４」１機が、同県犬山市の入鹿池に墜落した。 A Japanese Air Self-Defense Force training plane boarded by two ASDF members crashed into Lake Iruka in central Japan on Wednesday.

A Japanese Air Self-Defense Force training plane boarded by two ASDF members crashed into Lake Iruka in central Japan on Wednesday.

In this episode, Chris and Andrew start out talking about personal milestones and upcoming birthdays.  The conversation then moves to technical issues faced with PostgreSQL configurations on Hatchbox. They delve into the functionality and challenges of different tools such as Asdf and its alternatives like Mise, a tool for managing programming environments, and the evolving role of AI in coding environments. They also explore Warp's new terminal features and Chris's work on the ‘Learning Hotwire' course. Hit download now to hear more! HoneybadgerHoneybadger is an application health monitoring tool built by developers for developers.Disclaimer: This post contains affiliate links. If you make a purchase, I may receive a commission at no extra cost to you. Chris Oliver X/Twitter Andrew Mason X/Twitter Jason Charnes X/Twitter

News includes Erlang/OTP achieving OpenChain ISO certification for open source license compliance, the release of the new "Elixir Patterns" book by Hugo Barauna and Alex Koutmos, a security audit of Oban Web and Pro by Paraxial.io showing excellent results, upcoming Alchemy Conf in Portugal, and a major rewrite of the asdf version manager to Go, and more! Show Notes online - http://podcast.thinkingelixir.com/240 (http://podcast.thinkingelixir.com/240) Elixir Community News https://bsky.app/profile/theerlef.bsky.social/post/3lhc5552djc24 (https://bsky.app/profile/theerlef.bsky.social/post/3lhc5552djc24?utm_source=thinkingelixir&utm_medium=shownotes) – Erlang/OTP team announces compliance with OpenChain ISO/IEC 5230 standard for open source license compliance. https://openchainproject.org/featured/2025/02/01/erlang-otp-iso5230 (https://openchainproject.org/featured/2025/02/01/erlang-otp-iso5230?utm_source=thinkingelixir&utm_medium=shownotes) – Details about OpenChain certification and its importance for Erlang/OTP's 2025 goals for enhancing community infrastructure. https://podcast.thinkingelixir.com/220 (https://podcast.thinkingelixir.com/220?utm_source=thinkingelixir&utm_medium=shownotes) – Reference to Allistair Woodman episode providing additional context about Erlang/OTP. https://www.elixirpatterns.dev/#pricing (https://www.elixirpatterns.dev/#pricing?utm_source=thinkingelixir&utm_medium=shownotes) – New book "Elixir Patterns" by Hugo Barauna and Alex Koutmos has been released. https://bsky.app/profile/hugobarauna.com/post/3lgv5yfw5o22q (https://bsky.app/profile/hugobarauna.com/post/3lgv5yfw5o22q?utm_source=thinkingelixir&utm_medium=shownotes) – Author's announcement about the Elixir Patterns book release. https://www.elixirpatterns.dev/#free-chapters (https://www.elixirpatterns.dev/#free-chapters?utm_source=thinkingelixir&utm_medium=shownotes) – Free sample chapters of Elixir Patterns book available with accompanying Livebooks. https://www.youtube.com/watch?v=AZZvljvgKy8 (https://www.youtube.com/watch?v=AZZvljvgKy8?utm_source=thinkingelixir&utm_medium=shownotes) – Launch livestream recording for the Elixir Patterns book. https://paraxial.io/blog/oban-pentest (https://paraxial.io/blog/oban-pentest?utm_source=thinkingelixir&utm_medium=shownotes) – Security audit results for Oban Web and Oban Pro by Paraxial.io, showing no critical vulnerabilities. https://alchemyconf.com/ (https://alchemyconf.com/?utm_source=thinkingelixir&utm_medium=shownotes) – Announcement for Alchemy Conf happening April 2-3 in Braga Portugal. https://x.com/hugobarauna/status/1886766098411909420 (https://x.com/hugobarauna/status/1886766098411909420?utm_source=thinkingelixir&utm_medium=shownotes) – Hugo Barauna announces he'll be speaking about Livebook and Livebook Teams internals at Alchemy Conf. https://stratus3d.com/blog/2025/02/03/asdf-has-been-rewritten-in-go/ (https://stratus3d.com/blog/2025/02/03/asdf-has-been-rewritten-in-go/?utm_source=thinkingelixir&utm_medium=shownotes) – Announcement about asdf v0.16 major update and rewrite in Go. https://asdf-vm.com/guide/upgrading-to-v0-16.html#installation (https://asdf-vm.com/guide/upgrading-to-v0-16.html#installation?utm_source=thinkingelixir&utm_medium=shownotes) – Installation guide for the new asdf v0.16 with breaking changes. Do you have some Elixir news to share? Tell us at @ThinkingElixir (https://twitter.com/ThinkingElixir) or email at show@thinkingelixir.com (mailto:show@thinkingelixir.com) Find us online - Message the show - Bluesky (https://bsky.app/profile/thinkingelixir.com) - Message the show - X (https://x.com/ThinkingElixir) - Message the show on Fediverse - @ThinkingElixir@genserver.social (https://genserver.social/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen on X - @brainlid (https://x.com/brainlid) - Mark Ericksen on Bluesky - @brainlid.bsky.social (https://bsky.app/profile/brainlid.bsky.social) - Mark Ericksen on Fediverse - @brainlid@genserver.social (https://genserver.social/brainlid) - David Bernheisel on Bluesky - @david.bernheisel.com (https://bsky.app/profile/david.bernheisel.com) - David Bernheisel on Fediverse - @dbern@genserver.social (https://genserver.social/dbern)

Construction of a Japanese Air Self-Defense Force base on Mageshima, an island in the southwestern Japan prefecture of Kagoshima, is likely to be delayed by three years.

Fredrik snackar om långdistansmjukvaruutveckling - att bygga saker över längre tid på ett bra sätt, och hur och varför han tänker väldigt mycket på löpning i sammanhanget. Det blir rutiner, löpning, agil utveckling, tidsuppskattning, deadlines, och varför sprint är ett värdelöst ord när man snackar mjukvaruutveckling. Avsnittet är på sätt och vis en deluxeförlängd regissörsversion av Fredriks lucka i Asdfs julkalender. Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @thieta, @krig, och @bjoreman på Mastodon, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik. Länkar Asdfs julkalender Fredriks lucka i Asdf-kalendern Stöd oss på Ko-fi Göteborgsvarvet Den gamla webbplatsen där Fredrik skrev om sitt första Göteborgsvarv finns inte åtkomlig på nätet för tillfället Ultramaraton Lejonbragden Rune Larsson Martin och Magnus Agil mjukvaruutveckling Woody Zuill Mobbprogrammering Turn up the good (och undertiteln “a lifetime of tiny steps” är om möjligt ännu mer på samma spår Move fast and break things Mörk materia-utvecklare - ett begrepp myntat av Scott Hanselman Lyssnarundersökningen Titlar Vår eviga tacksamhet och klistermärken Långdistansmjukvaruutveckling Sammansatta ord är ju trevligt Hur man undviker att sluta utveckla mjukvara Min väg, eller en av mina vägar Efter att ha börjat skriva kod Öka hastigheten, öka sträckan I omloppsbana runt ett fikabord Kortare och kortare bitar Inte ta in helheten Delmål hela tiden Tänk bara på ett steg Vi låtsas att det är bråttom En bra insats över tid Vi ska springa hela tiden Det sista vi ska göra Vad som helst utom sprint

共同記者会見後、握手する航空自衛隊の鈴木康彦航空総隊司令官と独空軍のゲルハルツ総監、２３日午後、北海道千歳市日本に派遣中のドイツ空軍機と航空自衛隊の共同訓練「ニッポンスカイズ２４」が始まり、空自千歳基地で２３日、日独の共同記者会見が開かれた。 A senior official of Japan's Air Self-Defense Force stressed the strong unity between the ASDF and the German Air Force on Tuesday.

A senior official of Japan's Air Self-Defense Force stressed the strong unity between the ASDF and the German Air Force on Tuesday.

The village of Kitadaito, Okinawa Prefecture, southernmost Japan, will accept the planned deployment of a mobile radar of the Air Self-Defense Force, its mayor, Mitsunori Onizuka, said Monday.

航空自衛隊などとの共同訓練のため、初飛来したスペイン空軍の戦闘機ユーロファイター、１９日午前、空自千歳基地スペインとドイツの空軍の戦闘機「ユーロファイター」が１９日、航空自衛隊との共同訓練のため、北海道千歳市の空自千歳基地に到着した。 Eurofighter jets from the Spanish and German air forces arrived at the Japanese Air Self-Defense Force's Chitose base in Hokkaido, northernmost Japan, on Friday to participate in joint training with the ASDF.

Eurofighter jets from the Spanish and German air forces arrived at the Japanese Air Self-Defense Force's Chitose base in Hokkaido, northernmost Japan, on Friday to participate in joint training with the ASDF.

Internal information from Japan's Air Self-Defense Force, including a photo of a model of what is likely a missile currently under development, has been posted on social media, ASDF officials said Thursday.

Bộ trưởng Quốc phòng Nhật Bản Kihara Minoruan tuyên bố trong cuộc họp báo ngày 25/6 rằng lần đầu tiên Lực lượng Không quân Nhật Bản (ASDF) sẽ tiến hành một loạt cuộc tập trận chung với lực lượng không quân của Đức, Pháp và Tây Ban Nha tại Nhật Bản vào tháng 7.

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/

Vi är äntligen tillbaka med en klassiskt låg energi! I det perfekta avsnittet att somna till snackar vi bland annat trafikkaos på E4an, att skriva in en konferens i sitt anställningsavtal, ett gäng gäspningar, hippa entreprenörskvinnor, att inte orka åka utomlands, en tillplattad dröm, single track-sammanhållningen, gratulationer på kvinnodagen, att bara läsa saker med färg och mycket mycket annat. Hör av er till oss på vår röstbrevlåda! Berätta ett skämt, ställ en fråga eller vad som: 0766 86 05 07 Om du gillar podden blir vi väldigt glada för en liten recension i iTunes eller en prenumeration på Spotify. Följ oss och säg hej på @asdfpodden på Instagram

Stephanie shares her task of retiring a small, internally-used link-shortening app. She describes the process as both celebratory and a bit mournful. Meanwhile, Joël discusses his deep dive into ActiveRecord, particularly in the context of debugging. He explores the complexities of ActiveRecord querying schemas and the additional latency this introduces. Together, the hosts discuss the nuances of package management systems and their implications for developers. They touch upon the differences between system packages and language packages, sharing personal experiences with tools like Homebrew, RubyGems, and Docker. Transcript: JOËL: Hello and welcome to another episode of The Bike Shed, a weekly podcast from your friends at thoughtbot about developing great software. I'm Joël Quenneville. STEPHANIE: And I'm Stephanie Minn. And together, we're here to share a bit of what we've learned along the way. JOËL: So, Stephanie, what's new in your world? STEPHANIE: So, this week, I got to have some fun working on some internal thoughtbot work. And what I focused on was retiring one of our just, like, small internal self-hosted on Heroku apps in favor of going with a third-party service for this functionality. We basically had a tiny, little app that we used as a link-shortening service. So, if you've ever seen a tbot.io short link out in the world, we were using our just, like, an in-house app to do that, you know, but for various reasons, we wanted to...just it wasn't worth maintaining anymore. So, we wanted to just use a purchased service. But today, I got to just, like, do the little bit of, like, tidying up, you know, in preparation to archive a repo and kind of delete the app from Heroku, and I hadn't done that before. So, it felt a little bit celebratory and a little bit mournful even [laughs] to, you know, retire something like that. And I was pairing with another thoughtbot developer, and we used a pairing app called Tuple. And you can just send, like, fun reactions to each other. Like, you could send, like, a fire emoji [laughs] or something if that's what you're feeling. And so, I sent some, like, confetti when we clicked the, "I understand what deleting this app means on GitHub." But I joked that "Actually, I feel like what I really needed was a, like, a salute kind of like thank you for your service [laughs] type of reaction." JOËL: I love those moments when you're kind of you're hitting those kind of milestone-y moments, and then you get to send a reaction. I should do that more often in Tuple. Those are fun. STEPHANIE: They are fun. There's also a, like, table flip reaction, too, is one that I really enjoy [laughs], you know, you just have to manifest that energy somehow. And then, after we kind of sent out an email to the company saying like, "Oh yeah, we're not using our app anymore for link shortening," someone had a great suggestion to make our archived repo public instead of private. I kind of liked it as a way of, like, memorializing this application and let community members see, you know, real code in a real...the application that we used here at thoughtbot. So, hopefully, if not me, then someone else will be able to do that and maybe publish a little blog post about that. JOËL: That's exciting. So, it's not currently public, the repo, but it might be at some point in the future. STEPHANIE: Yeah, that's right. JOËL: We'll definitely have to mention it on a future episode if that happens so that people following along with the story can go check out the code. STEPHANIE: So, Joël, what's new in your world? JOËL: I've been doing a deep dive into how ActiveRecord works. Particularly, I am debugging some pretty significant slowdowns in querying ActiveRecord models that are backed not by a regular Postgres database but instead a Snowflake data warehouse via an ODBC connection. So, there's a bunch of moving pieces going on here, and it would just take forever to make any queries. And sure, the actual reported query time is longer than for a local Postgres database, but then there's this sort of mystery extra waiting time, and I couldn't figure out why is it taking so much longer than the actual sort of recorded query time. And I started digging into all of this, and it turns out that in addition to executing queries to pull actual data in, ActiveRecord needs to, at various points, query the schema of your data store to pull things like names of tables and what are the indexes and primary keys and things like that. STEPHANIE: Wow. That sounds really cool and something that I have never needed to do before. I'm curious if you noticed...you said that it takes, I guess, longer to query Snowflake than it would a more common Postgres database. Were you noticing this performance slowness locally or on production? JOËL: Both places. So, the nice thing is I can reproduce it locally, and locally, I mean running the Rails app locally. I'm still talking to a remote Snowflake data warehouse, which is fine. I can reproduce that slowness locally, which has made it much easier to experiment and try things. And so, from there, it's really just been a bit of a detective case trying to, I guess, narrow the possibility space and try to understand what are the parts that trigger slowness. So, I'm printing timestamps in different places. I've got different things that get measured. I've not done, like, a profiling tool to generate a flame graph or anything like that. That might have been something cool to try. I just did old-school print statements in a couple of places where I, like, time before, time after, print the delta, and that's gotten me pretty far. STEPHANIE: That's pretty cool. What do you think will be an outcome of this? Because I remember you saying you're digging a little bit into ActiveRecord internals. So, based on, like, what you're exploring, what do you think you could do as a developer to increase some of the performance there? JOËL: I think probably what this ends up being is finding that the Snowflake adapter that I'm using for ActiveRecord maybe has some sort of small bug in it or some implementation that's a little bit too naive that needs to be fine-tuned. And so, probably what ends up happening here is that this finishes as, like, an open-source pull request to the Snowflake Adapter gem. STEPHANIE: Yeah, that's where I thought maybe that might go. And that's pretty cool, too, and to, you know, just be investigating something on your app and being able to make a contribution that it benefits the community. JOËL: And that's what's so great about open source because not only am I able to get the source to go source diving through all of this, because I absolutely need to do that, but also, then if I make a fix, I can push that fix back out to the community, and everybody gets to benefit. STEPHANIE: Cool. Well, that's another thing that I look forward to hearing more on the development of [laughs] later if it pans out that way. JOËL: One thing that has been interesting with this Snowflake work is that there are a lot of moving parts and multiple different packages that I need to install to get this all to work. So, I mentioned that I might be doing a pull request against the Snowflake Adapter for ActiveRecord, but all of this talks through a sort of lower-level technology protocol called ODBC, which is a sort of generic protocol for speaking to data stores, and that actually has two different pieces. I had to install two different packages. There is a sort of low-level executable that I had to install on my local dev machine and that I have to install on our servers. And on my Mac, I'm installing that via Homebrew, which is a system package. And then to get Ruby bindings for that, there is a Ruby gem that I install that allows Ruby code to talk to ODBC, and that's installed via RubyGems or Bundler. And that got me thinking about sort of these two separate ecosystems that I tend to work with every day. We've got sort of the system packages and the, I don't know what you want to call them, language packages maybe, things like RubyGems, but that could also be NPM or whatever your language of choice is, and realizing that we kind of have things split into two different zones, and sometimes we need both and wondering a little bit about why is that difference necessary. STEPHANIE: Yeah, I don't have an answer to that [laughs] question right now, but I can say that that was an area that really tripped me up, I think, when I was first a fledgling developer. And I was really confused about where all of these dependencies were coming from and going through, you know, setting up my first project and being, like, asked to install Postgres on my machine but then also Bundler, which then also installs more dependencies [laughs]. The lines between those ecosystems were not super clear to me. And, you know, even now, like, I find myself really just kind of, like, learning what I need to know to get by [laughs] with my day-to-day work. But I do like what you said about these are kind of the two main layers that you're working with in terms of package management. And it's really helpful to have that knowledge so you can troubleshoot when there is an issue at one or the other. JOËL: And you mentioned Postgres. That's another one that's interesting because there are components in both of those ecosystems. Postgres itself is typically installed via a system package manager, so something like Homebrew on a Mac or apt-get on a Linux machine. But then, if you're interacting with Postgres in a Ruby app, you're probably also installing the pg gem, which are Ruby's bindings for Postgres to allow Ruby to talk to Postgres, and that lives in the package ecosystem on RubyGems. STEPHANIE: Yeah, I've certainly been in the position of, you know, again, as consultants, we oftentimes are also setting up new laptops entirely [laughs] like client laptops and such and bundling and the pg gem is installed. And then at least I have, you know, I have to give thanks to the very clear error message that [laughs] tells me that I don't have Postgres installed on my machine. Because when I mentioned, you know, troubleshooting earlier, I've certainly been in positions where it was really unclear what was going on in terms of the interaction between what I guess we're calling the Ruby package ecosystem and our system level one. JOËL: Especially for things like the pg gem, which need to compile against some existing libraries, those always get interesting where sometimes they'll fail to compile because there's a path to some C compiler that's not set correctly or something like that. For me, typically, that means I need to update the macOS command line tools or the Xcode command line tools; I forget what the name of that package is. And, usually, that does the trick. That might happen if I've upgraded my OS version recently and haven't downloaded the latest version of the command line tools. STEPHANIE: Yeah. Speaking of OS versions, I have a bit of a story to share about using...I've never said this name out loud, but I am pretty sure that it would just be pronounced as wkhtmltopdf [laughs]. For some reason, whenever I see words like that in my brain, I want to, like, make it into a pronounceable thing [laughs]. JOËL: Right, just insert some vowels in there. STEPHANIE: Yeah, wkhtmltopdf [laughs]. Anyway, that was being used in an app to generate PDF invoices or something. It's a pretty old tool. It's a CLI tool, and it's, as far as I can tell, it's been around for a long time but was recently no longer maintained. And so, as I was working on this app, I was running into a bug where that library was causing some issues with the PDF that was generated. So, I had to go down this route of actually finding a Ruby gem that would figure out which package binary to use, you know, based off of my system. And that worked great locally, and I was like, okay, cool, I fixed the issue. And then, once I pushed my change, it turns out that it did not work on CI because CI was running on Ubuntu. And I guess the binary didn't work with the latest version of Ubuntu that was running on CI, so there was just so many incompatibilities there. And I was wanting to fix this bug. But the next step I took was looking into community-provided packages because there just simply weren't any, like, up-to-date binaries that would likely work with these new operating systems. And I kind of stopped at that point because I just wasn't really sure, like, how trustworthy were these community packages. That was an ecosystem I didn't know enough about. In particular, I was having to install some using apt from, you know, just, like, some Linux community. But yeah, I think I normally have a little bit more experience and confidence in terms of the Ruby package ecosystem and can tell, like, what gems are popular, which ones are trustworthy. There are different heuristics I have for evaluating what dependency to pull in. But here I ended up just kind of bailing out of that endeavor because I just didn't have enough time to go down that rabbit hole. JOËL: It is interesting that learning how to evaluate packages is a skill you have to learn that varies from package community to package community. I know that when I used to be very involved with Elm, we would often have people who would come to the Elm community from the JavaScript community who were used to evaluating NPM packages. And one of the metrics that was very popular in the JavaScript community is just stars on GitHub. That's a really important metric. And that wasn't really much of a thing in the Elm community. And so, people would come and be like, "Wait, how do I know which package is good? I don't see any stars on GitHub." And then, it turns out that there are other metrics that people would use. And similarly, you know, in Ruby, there are different ways that you might use to evaluate Ruby gems that may or may not involve stars on GitHub. It might be something entirely different. STEPHANIE: Yeah. Speaking of that, I wanted to plug a website that I have used before called the Ruby Toolbox, and that gives some suggestions for open-source Ruby libraries of various categories. So, if you're looking for, like, a JSON parser, it has some of the more popular ones. If you're looking for, you know, it stores them by category, and I think it is also based on things like stars and forks like that, so that's a good one to know. JOËL: You could probably also look at something like download numbers to see what's popular, although sometimes it's sort of, like, an emergent gem that's more popular. Some of that almost you just need to be a little bit in the community, like, hearing, you know, maybe listening to podcasts like this one, subscribing to Ruby newsletters, going to conferences, things like that, and to realize, okay, maybe, you know, we had sort of an old staple for JSON parsing, but there's a new thing that's twice as fast. And this is sort of becoming the new standard, and the community is shifting towards that. You might not know that just by looking at raw stats. So, there's a human component to it as well. STEPHANIE: Yeah, absolutely. I think an extension of knowing how to evaluate different package systems is this question of like, how much does an average developer need to know about package management? [laughs] JOËL: Yeah, a little bit to a medium amount, and then if you're writing your own packages, you probably need to know a little bit more. But there are some things that are really maybe best left to the maintainers of package managers. Package managers are actually pretty complex pieces of software in terms of all of the dependency management and making sure that when you say, "Oh, I've got Rails, and this other gem, and this other gem, and it's going to find the exact versions of all those gems that play nicely together," that's non-trivial. As a sort of working developer, you don't need to know all of the algorithms or the graph theory or any of that that underlies a package manager to be able to be productive in your career. And even as a package developer, you probably don't need to really know a whole lot of that. STEPHANIE: Yeah, that makes sense. I actually had referred to our internal at thoughtbot here, our kind of, like, expectations for skill levels for developers. And I would say for an average developer, we kind of just expect a basic understanding of these more complex parts of our toolchain, I think, specifically, like, command line tools and package management. And I think I'd mentioned earlier that, for me, it is a very need-to-know basis. And so, yeah, when I was going down that little bit of exploration around why wkhtmltopdf [chuckles] wasn't working [chuckles], it was a bit of a twisty and turning journey where I, you know, wasn't really sure where to go. I was getting very obtuse error messages, and, you know, I had to dive deep into all these forums [laughs] for all the various platforms [laughs] about why libraries weren't working. And I think what I did come away with was that like, oh, like, even though I'm mostly working on my local machine for development, there was some amount of knowledge I needed to have about the systems that my CI and, you know, production servers are running on. The project I was working on happened to have, like, a Docker file for those environments, and, you know, kind of knowing how to configure them to install the packages I needed to install and just knowing a little bit about the different ways of doing that on systems outside of my usual daily workflows. JOËL: And I think that gets back to some of the interesting distinctions between what we might call language packages versus system packages is that language packages more or less work the same across all operating systems. They might have a build step that's slightly different or something like that, but system packages might be pretty different between different operating systems. So, development, for me, is a Mac, and I'm probably installing system packages via something like Homebrew. If I then want that Rails app to run on CI or some Linux server somewhere, I can't use Homebrew to install things there. It's going to be a slightly different package ecosystem. And so, now I need to find something that will install Postgres for Linux, something that will install, I guess, wkhtmltopdf [laughs] for Linux. And so, when I'm building that Docker file, that might be a little bit different for Mac versus for...or I guess when you run a Docker file, you're running a containerized system. So, the goal there is to make this system the same everywhere for everyone. But when you're setting that up, typically, it's more of a Linux-like system. And so running inside the Docker container versus outside on the native Mac might involve a totally different set of packages and a different package tool. As opposed to something like Bundler, you've got your gem file; you bundle install. It doesn't matter if you're on Linux or macOS. STEPHANIE: Yes, I think you're right. I think we kind of answered our own question at the top of the show [laughs] about differences and what do you need to know about them. And I also like how you pointed out, oh yeah, like, Docker is supposed to [laughs], you know, make sure that we're all developing in the same system, essentially. But, you know, sometimes you have different use cases for it. And, yeah, when you were talking about installing an application on your native Mac and using Homebrew, but even, you know, not everyone even uses Homebrew, right? You can install manually [laughs] through whatever official installer that application might provide. So, there's just so many different ways of doing something. And I had the thought that it's too bad that we both [chuckles] develop on Mac because it could be really interesting to get a Linux user's perspective in here. JOËL: You mentioned not installing via Homebrew. A kind of glaring example of that in my personal setup is that I use Postgres.app to manage Postgres on my machine rather than using Homebrew. I've just...over the years, the Homebrew version every time I upgrade my operating system or something, it's just such a pain to update, and I've lost too many hours to it, and Postgres.app just works, and so I've switched to that. Most other things, I'll use the Homebrew version, but Postgres it's now Postgres.app. It's not even a command line install, and it works fine for me. STEPHANIE: Nice. Yeah. That's interesting. That's a good tip. I'll have to look into that next time because I have also certainly had to just install so many [laughs] various versions of Postgres and figure out what's going on with them every time I upgrade my OS. I'm with you, though, in terms of the packages world I'm looking for, it works [laughs]. JOËL: So, you'd mentioned earlier that packages is sort of an area that's a bit of a need-to-know basis for you. Are there, like, particular moments in your career that you remember like, oh, that's the moment where I needed to, like, take some time and learn a little bit of the next level of packages? STEPHANIE: That's a great question. I think the very beginnings of understanding how package versions work when you have multiple projects on your machine; I just remember that being really confusing for me. When I started out, like, you know, as soon as I cloned my second repo [laughs], and was very confused about, like, I'm sure I went through the process of not installing gems using Bundler, and then just having so much chaos [laughs] wrecked in my development environment and, you know, having to ask someone, "I don't understand how this works. Like, why is it saying I have multiple versions of this library or whatever?" JOËL: Have you ever sudo gem installed a gem? STEPHANIE: Oh yeah, I definitely have. I can't [laughs], like, even give a good reason for why I have done it, but I probably was just, like, pulling my hair out, and that's what Stack Overflow told me to do. I don't know if I can recommend that, but it is [chuckles] one thing to do when you just are kind of totally stuck. JOËL: There was a time where I think that that was in the READMEs for most projects. STEPHANIE: Yeah, that's a really good point. JOËL: So, that's probably why a lot of people end up doing that, but then it tends to install it for your system Ruby rather than for...because if you're using something like Rbenv or RVM or ASDF to manage multiple Ruby versions, those end up being what's using or even Homebrew to manage your Ruby. It wouldn't be installing it for those versions of Ruby. It would be installing it for the one that shipped with your Mac. I actually...you know what? I don't even know if Mac still ships with Ruby. It used to. It used to ship with a really old version of Ruby, and so the advice was like, "Hey, every repo tells you to install it with sudo; don't do that. It will mess you up." STEPHANIE: Huh. I think Mac still does ship with Ruby, but don't quote me on that [laughter]. And I think that's really funny that, like, yeah, people were just writing those instructions in READMEs. And I'm glad that we've collectively [laughs] figured out that difference and want to, hopefully, not let other developers fall into that trap [laughs]. Do you have a particular memory or experience when you had to kind of level up your knowledge about the package ecosystem? JOËL: I think one sort of moment where I really had to level up is when I started really needing to understand how install paths worked, especially when you have, let's say, multiple versions of a gem installed because you have different projects. And you want to know, like, how does it know which one it's using? And then you see, oh, there are different paths that point to different directories with the installs. Or when you might have an executable you've installed via Homebrew, and it's like, oh yeah, so I've got this, like, command that I run on my shell, but actually that points to a very particular path, you know, in my Homebrew directory. But maybe it could also point to some, like, pre-installed system binaries or some other custom things I've done. So, there was a time where I had to really learn about how the path shell variable worked on a machine in order to really understand how the packages I installed were sometimes showing up when I invoked a binary and sometimes not. STEPHANIE: Yeah, that is another really great example that I have memories of [laughs] being really frustrated by, especially if...because, you know, we had talked earlier about all the different ways that you can install applications on your system, and you don't always know where they end up [laughs]. JOËL: And this particular memory is tied to debugging Postgres because, you know, you're installing Postgres, and some paths aren't working. Or maybe you try to update Postgres and now it's like, oh, but, like, I'm still loading the wrong one. And why does PSQL not do the thing that I think it does? And so, that forced me to learn a little bit about, like, under the hood, what happens when I type brew install PostgreSQL? And how does that mesh with the way my shell interprets commands and things like that? So, it was maybe a little bit of a painful experience but eye-opening and definitely then led to me, I think, being able to debug my setup much more effectively in the future. STEPHANIE: Yeah. I like that you also pointed out how it was interacting with your shell because that's, like, another can of worms, right? [laughs] In terms of just the complexity of how these things are talking to each other. JOËL: And for those of our listeners who are not familiar with this, there is a shell command that you can use called which, W-H-I-C-H. And you can prefix that in front of another command, and it will tell you the path that it's using for that binary. So, in my case, if I'm looking like, why is this PSQL behaving weirdly or seems to be using the old version, I can type 'which space psql', and it'll say, "Oh, it's going to this path." And I can look at it and be like, oh, it's using my system install of Postgres. It's not using the Homebrew one. Or, oh, maybe it's using the Homebrew install, not my Postgres.app version. I need to, like, tinker with the paths a little bit. So, that has definitely helped me debug my package system more than once. STEPHANIE: Yeah, that's a really good tip. I can recall just totally uninstalling everything [laughs] and reinstalling and fingers crossed it would figure out a route to the right thing [laughs]. JOËL: You know what? That works. It's not the, like, most precise solution but resetting your environment when all else fails it's not a bad solution. So, we've been talking a lot about what it's like to interact with a package ecosystem as developers, as users of packages, but what if you're a package developer? Sometimes, there's a very clear-cut place where to publish, and sometimes it's a little bit grayer. So, I could see, you know, I'm developing a database, and I want that to be on operating systems, probably should be a system-level package rather than a Ruby gem. But what if I'm building some kind of command line tool, and I write it in Ruby because I like writing Ruby? Should I publish that as a gem, or should I publish that as some kind of system package that's installed via Homebrew? Any opinions or heuristics that you would use to choose where to publish on one side or the other? STEPHANIE: As not a package developer [laughs], I can only answer from that point of view. That is interesting because if you publish on a, you know, like, a system repository, then yeah, like, you might get a lot more people using your tool out there because you're not just targeting a specific language's community. But I don't know if I have always enjoyed downloading various things to my system's OS. I think that actually, like, is a bit complicated for me or, like, I try to avoid it if I can because if something can be categorized or, like, containerized in a way that, like, feels right for my mental model, you know, if it's written in Ruby or something really related to things I use Ruby in, it could be nice to have that installed in my, like, systems RubyGems. But I would be really interested to hear if other people have opinions about where they might want to publish a package and what kind of developers they're hoping to find to use their tool. JOËL: I like the heuristic that you mentioned here, the idea of who the audience is because, yeah, as a Ruby developer who already has a Ruby setup, it might be easier for me to install something via a gem. But if I'm not a Ruby developer who wants to use the packages maybe a little bit more generic, you know, let's say, I don't know, it's some sort of command line tool for interacting with GitHub or something like that. And, like, it happens to be written in Ruby, but you don't particularly care about that as a user of this. Maybe you don't have Ruby installed and now you've got to, like, juggle, like, oh, what is RubyGems, and Bundler, and all this stuff? And I've definitely felt that occasionally downloading packages sort of like, oh, this is a Python package. And you're going to need to, like, set up all this stuff. And it's maybe designed for a Python audience. And so, it's like, oh, you're going to set up a virtual environment and all these things. I'm like, I just want your command line tools. I don't want to install a whole language. And so, sometimes there can be some frustration there. STEPHANIE: Yeah, that is very true. Before you even said that, I was like, oh, I've definitely wanted to download a command line tool and be like, first install [laughs] Python. And I'm like, nope, I'm bailing out of this. JOËL: On the other hand, as a developer, it can be a lot harder to write something that's a bit more cross-platform and managing all that. And I've had to deal a little bit with this for thoughtbot's Parity tool, which is a command-line tool for working with Heroku. It allows you to basically run commands on either staging or production by giving you a staging command and a production command for common Heroku CLI tasks, which makes it really nice if you're working and you're having to do some local, some development, some staging, and some production things all from your command line. It initially started as a gem, and we thought, you know what? This is mostly command line, and it's not just Rubyists who use Heroku. Let's try to put this on Homebrew. But then it depends on Ruby because it's written in Ruby. And now we had to make sure that we marked Ruby as a dependency in Homebrew, which meant that Homebrew would then also pull in Ruby as a dependency. And that got a little bit messy. For a while, we even experimented with sort of briefly available technology called Traveling Ruby that allowed you to embed Ruby in your binary, and you could compile against that. That had some drawbacks. So, we ended up rolling that back as well. And eventually, just for maintenance ease, we went back to making this a Ruby gem and saying, "Look, you install it via RubyGems." It does mean that we're targeting more of the Ruby community. It's going to be a little bit harder for other people to install, but it is easier for us to maintain. STEPHANIE: That's really interesting. I didn't know that history about Parity. It's a tool that I have used recently and really enjoyed. But yeah, I think I remember someone having some issues between installing it as a gem and installing it via Homebrew and some conflicts there as well. So, I can also see how trying to decide or maybe going down one path and then realizing, oh, like, maybe we want to try something else is certainly not trivial. JOËL: I think, in me, I have a little bit of the idealist and the pragmatist that fight. The idealist says, "Hey, if it's not, like, aimed for Ruby developers as a, like, you can pull this into your codebase, if it's just command line tools and the fact that it's written in Ruby is an implementation detail, that should be a system package. Do not distribute binaries via RubyGems." That's the idealist in me. The pragmatist says, "Oh, that's a lot of work and not always worth it for both the maintainers and sometimes for the users, and so it's totally okay to ship binaries as RubyGems." STEPHANIE: I was totally thinking that I'm sure that you've been in that position of being a user and trying to download a system package and then seeing it start to download, like, another language. And you're like, wait, what? [laughter] That's not what I want. JOËL: So, you and I have shared some of our heuristics in the way we approach this problem. Now, I'm curious to hear from the audience. What are some heuristics that you use to decide whether your package is better shipped on RubyGems versus, let's say, Homebrew? Or maybe as a user, what do you prefer to consume? STEPHANIE: Yes. And speaking of getting listener feedback, we're also looking for some listener questions. We're hoping to do a bit of a grab-bag episode where we answer your questions. So, if you have anything that you're wanting to hear me and Joël's thoughts on, write us at hosts@bikeshed.fm. JOËL: On that note, shall we wrap up? STEPHANIE: Let's wrap up. Show notes for this episode can be found at bikeshed.fm. JOËL: This show has been produced and edited by Mandy Moore. STEPHANIE: If you enjoyed listening, one really easy way to support the show is to leave us a quick rating or even a review in iTunes. It really helps other folks find the show. JOËL: If you have any feedback for this or any of our other episodes, you can reach us @_bikeshed, or you can reach me @joelquen on Twitter. STEPHANIE: Or reach both of us at hosts@bikeshed.fm via email. JOËL: Thanks so much for listening to The Bike Shed, and we'll see you next week. ALL: Byeeeeeeee!!!!!!! AD: Did you know thoughtbot has a referral program? If you introduce us to someone looking for a design or development partner, we will compensate you if they decide to work with us. More info on our website at: tbot.io/referral. Or you can email us at referrals@thoughtbot.com with any questions.

Ep. 621: Pickles! Book talk begins @ 18:20 Royal intrigue escalates with the King's investigation and Madame Bonacieux's quest. , , (and my fave TomSka sketch (—it's the bees that got me + - which I heard from the kids' a lot) Etsy channel and the PICKLES!—Bread & Butter Pickles - I combined and - I didn't heat the cukes up - just packed the jars. Watermelon pickles - I combined these two (mostly leaning on the ) CraftLit's socials: Find everything here: Join the newsletter:   Podcast site: Twitter: @CraftLit Facebook: Facebook group:  Pinterest: Youtube:   Support the show links: Subscribe to the Premium feed (on the app) here: or on Patreon: (same price, $5/month) Feedback: You can ask your questions, make comments, and let us know what you do when you listen to CraftLit! Let your voice be heard. • Download the FREE CraftLit App for or (you can call or email feedback straight from within the app) • Call 1-206-350-1642 • Email: heather@craftlit.com • Use our ! FOR FB EVENT TUES Please Register here to get the meeting link for the FREE weekly chat: FOR FB EVENT THURS Please Register here to get the meeting link for the FREE ongoing weekly chat:

Therése Komstadius och Anton Gunnarsson - kända från podden Asdf - gästar Bartek och diskuterar till att börja med svårigheterna med att både lyssna på poddar och delta i dem (och att motstå frestelsen att avbryta sin TV).Sedan får Bartek äntligen chans att prova på Asdf:s klassiska öppning innan vi dyker in i huvudämnet: tankar och reaktioner på att webbutveckla som en boomer. Anton och Therése diskuterar hur det var att först komma in i frontendramverkens .NET - React, och hur Ract själv har förändrats över tiden till den best det är idag. Bartek lägger fram sin teori om utvecklingstrenderna på 2010-talet: hade de kanske inte så mycket alls att göra med vilka behov man som utvecklare och användare faktiskt har?Gör webbramverken att man tappar det webbläsarnära? Och är vi kanske, förhoppningsvis, på väg bort från ramverkskrigen mot en bättre balans, där man kan välja olika verktyg för olika behov?Arc-invitesEtt stort tack till Anton som har donerat 5 Arc-invites. Först till kvarn gäller!Hämta dom här: https://arc.net/gift/5df94bf5LänkarTheréseAntonAsdfADSLStill in beta - Antons "förra podd" - gästade Kodsnack i avsnitt 194Patrik SvenssonWebbutveckla som en boomerSSR - server-side renderingServer componentsAngularJSVueReactBackboneJqueryMixinsNext.jsCargo cultArcRemixHTMXDanssjukaCitatPodd-globetrotterDet ska göra lite ont för allaJag är ofta ute och vevarInnan stora ramverkskrigenFrontendramverkens .NETEn tankemodell att användaDeveloper-driven developmentAnvändare är ju kassa på att vara användareAnti-boomer, det är jagFör gamla backend-boomersSPA-sjukanLanda på den gyllene medelvägenAlltid trevligt med lite vevning

Therése Komstadius och Anton Gunnarsson - kända från podden Asdf - gästar Bartek och diskuterar till att börja med svårigheterna med att både lyssna på poddar och delta i dem (och att motstå frestelsen att avbryta sin TV).Sedan får Bartek äntligen chans att prova på Asdf:s klassiska öppning innan vi dyker in i huvudämnet: tankar och reaktioner på att webbutveckla som en boomer. Anton och Therése diskuterar hur det var att först komma in i frontendramverkens .NET - React, och hur Ract själv har förändrats över tiden till den best det är idag. Bartek lägger fram sin teori om utvecklingstrenderna på 2010-talet: hade de kanske inte så mycket alls att göra med vilka behov man som utvecklare och användare faktiskt har?Gör webbramverken att man tappar det webbläsarnära? Och är vi kanske, förhoppningsvis, på väg bort från ramverkskrigen mot en bättre balans, där man kan välja olika verktyg för olika behov?Arc-invitesEtt stort tack till Anton som har donerat 5 Arc-invites. Först till kvarn gäller!Hämta dom här: https://arc.net/gift/5df94bf5LänkarTheréseAntonAsdfADSLStill in beta - Antons "förra podd" - gästade Kodsnack i avsnitt 194Patrik SvenssonWebbutveckla som en boomerSSR - server-side renderingServer componentsAngularJSVueReactBackboneJqueryMixinsNext.jsCargo cultArcRemixHTMXDanssjukaCitatPodd-globetrotterDet ska göra lite ont för allaJag är ofta ute och vevarInnan stora ramverkskrigenFrontendramverkens .NETEn tankemodell att användaDeveloper-driven developmentAnvändare är ju kassa på att vara användareAnti-boomer, det är jagFör gamla backend-boomersSPA-sjukanLanda på den gyllene medelvägenAlltid trevligt med lite vevning

Fredrik och Kristoffer snackar tangentbord, AI-undringar, och att ta hand om sin röst. Uppvärmning: Fredrik har varit förkyld, och följde upp med att tappa rösten. Borde man lära sig vårda sin röst? Kristoffer tänkte spela in någonting själv, men blev självmedveten och skrev för mycket manus. Kristoffer håller gradvis på att samla ihop en roman av material om vad problemen är med Clean code. Sedan blir det tangentbordssnack! Kristoffer fascineras av små tangentbord, funderar över home row mods, och har skaffat alla tangentbord för att prova vad han egentligen trivs bäst med. Fredrik undrar om det är på grund av Apple han alls blev intresserad av mekaniska tangentbord. Därefter diskuteras AI igen. Kristoffer har - precis som alla andra - fortsatt fundera på AI, speciellt efter snacket vi hade med Bartek. Är redan namnet eller etiketten AI en stor del av problemet? Har Copilot någon mer medvetenhet om kod än vad “rena” GPT-4 har? Chatdbg - ett roligt sätt att koppla in Chatgpt i en process som kanske inte alls behövde en språkmodell inblandad? Hur många saker som idag får en språkmodell inkopplad kommer att ha det om, säg, ett år eller två? Att bygga förståelse är något som pågår inom en person. Fredrik har testat Whisper - en språkmodell som ingen anklagar för att tänka eller läser intelligens i, men som faktiskt utför ett jobb rätt bra. Och lastar ens dator på ett tillfredsställande sätt. Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @oferlund, och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik. Länkar Clean code Avsnitt 490 - Med Daniel Grenehed Home row mods Ergodox Planck Preonic Moonlander Kyria Sofle Corne Ferris sweep Dygma defy Monkeytype Colemak Workman Dvorak Norman Asdf är också en väldigt trevlig podd Dygma raise Kombos - flera tangenter samtidigt Pok3r Magnus Avsnitt 519 - “AI-snacket” med Bartek Chatdbg LLDB Papegojor som videochattar blir mindre ensamma Råttor och kokain - har de kompisar är det en helt annan sak Whisper whisper.cpp Neural engine Hej (resten av) internet! - en trevlig podd om roliga saker som gömmer sig ute på nätet SOLID-principerna Titlar Minimalt mer optimalt Skift på höger tumme Händerna rakt framför sig Maximalt jättedåligt (Den norska) Hytteknappen Kurvat efter handens kurva Asdf på vänster hand Den är nästan där den brukar Fickor av muskelminne Tummen mitt i klustret Slarvig med hur jag skriver Räkna matte och dra jätteraka linjer ship: make coffee En papegoja som kan prata

Fredrik snackar med Magnus Therning om att bygga sin egen Emacs-setup, att skala bort och skriva om saker, beroenden, och mycket mer. Som det lugn som kan infinna sig när man nyss avslutat något större och ännu inte påbörjat nästa sak. Kasta bort saker som inte finns med i det mentala destillatet efter något års arbete med någonting. Och utan att bara sätta sig i ett hörn och skriva om vad man redan har på ett nytt sätt. Anpassa koncepten man redan har efter de koncept man tillför. Förmågan att vara precis när man pratar om saker. Rätt namn på rätt saker kan lösa så mycket bara i sig. Man behöver kanske mer tillåtelse att leka? Kod som är lätt att ändra där man behöver göra ändringar ofta. Du behöver inte bry dig - ända tills det går fel. Sedan behöver man bry sig jättemycket. HTTP-bibliotek för servrar - skulle det finnas utrymme för ett som helt struntade i streaming? Loggning är svårt, och nyttigt. Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @oferlund, och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik. Länkar Magnus Therning Zimpler DDD - domändriven design Domain-driven design-boken Asdf om Emacs och små tangentbord och grejer Emacs Neovim Planck Spacemacs Systemcrafters - Youtubekanal MES - Magnus' Emacs setup Tree-sitter Helm Ivy LSP - Language server protocol LSP-klient för Emacs Haskell mode för Emacs Cabal - paketsystem för Haskell DRM - Digital rights management Magnus löste indenteringsproblemen strax efter inspelning Douglas Crockford Javascript: the good parts JSON Refaktorering CORBA COM For each desired change, make the change easy (warning: this may be hard), then make the easy change - Kent Beck Clean code HTTP-streaming Babel Coffeescript Serenityos Ladybird (inte Ladybug som Fredrik fick för sig) - webbläsare för Serenityos Dart Webassembly Create React app Unixsignaler Titlar Icke-jobbrelaterade saker Folk med små tangentbord I princip så outsourcar jag min konfiguration till hela internet Node-varning Bara för att leka lite Den här är väldigt stor Skala bort väldigt mycket Då hoppade jag ner i kaninhålet Väldigt annorlunda för att jag ska skriva den Interaktivt hela tiden Ett visst lugn I download music from the internet Mentalt destillat Smyga in mer omskrivande Förmågan att vara precis Det har i alla fall ett namn Leka Det skiter sig liksom i kanterna Plugins som omvandlar Javascript till Javascript Javascript är binärt Antingen är du expert, eller så är du farlig Ideologi om att inte skapa en massa kod Om den upptäcker att den blir tillsagd Som att läsa andras kod Justera sitt eget beteende

In dieser Folge spricht Katharina Klein, Sprecherin des Vorstandes der Stiftung Energie und Klimaschutz mit Eva-Maria Welskop-Deffaa, der Präsidentin des deutschen Caritasverbandes über die sozioökonomischen Folgen der aktuellen Energiekrise sowie deren Auswirkungen auf die Energiewende.

Fredrik och Tobias snackar om hur språk som C++ omvandlas till maskinkod. Tobias går på djupet om hur man bär sig åt för att kunna felsöka kod när kompilatorn kan bestämma sig för att helt enkelt slänga bort stora delar av den. Det känns lite som ett under att man över huvud taget kan sätta brytpunkter i sin kod när man felsöker. Som uppvärmning: Advent är här igen. Tobias portionerar ut Lego och funderar över varför han sällan deltar i Advent of code. Avsnittet sponsras av Grebban - en e-handelsbyrå som söker fler utvecklare inom bland annat backend och fullstack. Söker du och får ett jobb och nämner Kodsnack i din ansökan så får du en sign-on-bonus på 20000 kronor. Surfa in på grebban.com/kodsnack för mer information och ansökan! Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @oferlund, och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik. Länkar Advent of code Kodsnacks Advent of code-repo - bidra med din kod! Dependabot Unga programmerares kodkalender Asdf - kalenderavsnitten syns inte (än?) på webbsidan, men de finns i poddflödet Lowering LLVM-IR Godbolt.org Första exemplet GCC:s olika intermediärrepresentationer DAG - Directed acyclic graph DWARF - Unix debugformat Codeview - Microsofts och Windows debugformat Andra exemplet Register Minnespekare Grebban - veckans sponsor söker utvecklare Laravel grebban.com/kodsnack - läs mer eller ansök Anvil Tredje exemplet Fjärde exemplet Inlining i C och C++ Lambda i C++ Femte exemplet - med lambda Const i C++ Kodgranskningen i LLVM - sök på CodeViewDebug.cpp och hoppa några gånger för att komma till den faktiska koden Titlar På det mest komplicerade sättet Ett lätt ämne Hur debugging faktiskt funkar Sänkning Det ultimata lågnivåspråket När vi sänker C-kod Högnivåassembler Tre lager av översättning Hur representeras det i assemblerlagret Med debuginformation och utan optimering Jag behöver inte deklarera en variabel Lägg till en variabel som är borta Rakt in i returregistret Då låtsas vi att det är en constant Konstant nog

About AmyAmy Tobey has worked in tech for more than 20 years at companies of every size, working with everything from kernel code to user interfaces. These days she spends her time building an innovative Site Reliability Engineering program at Equinix, where she is a principal engineer. When she's not working, she can be found with her nose in a book, watching anime with her son, making noise with electronics, or doing yoga poses in the sun.Links Referenced: Equinix Metal: https://metal.equinix.com Personal Twitter: https://twitter.com/MissAmyTobey Personal Blog: https://tobert.github.io/ TranscriptAnnouncer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.Corey: This episode is sponsored in part by our friends at Vultr. Optimized cloud compute plans have landed at Vultr to deliver lightning-fast processing power, courtesy of third-gen AMD EPYC processors without the IO or hardware limitations of a traditional multi-tenant cloud server. Starting at just 28 bucks a month, users can deploy general-purpose, CPU, memory, or storage optimized cloud instances in more than 20 locations across five continents. Without looking, I know that once again, Antarctica has gotten the short end of the stick. Launch your Vultr optimized compute instance in 60 seconds or less on your choice of included operating systems, or bring your own. It's time to ditch convoluted and unpredictable giant tech company billing practices and say goodbye to noisy neighbors and egregious egress forever. Vultr delivers the power of the cloud with none of the bloat. “Screaming in the Cloud” listeners can try Vultr for free today with a $150 in credit when they visit getvultr.com/screaming. That's G-E-T-V-U-L-T-R dot com slash screaming. My thanks to them for sponsoring this ridiculous podcast.Corey: Finding skilled DevOps engineers is a pain in the neck! And if you need to deploy a secure and compliant application to AWS, forgettaboutit! But that's where DuploCloud can help. Their comprehensive no-code/low-code software platform guarantees a secure and compliant infrastructure in as little as two weeks, while automating the full DevSecOps lifestyle. Get started with DevOps-as-a-Service from DuploCloud so that your cloud configurations are done right the first time. Tell them I sent you and your first two months are free. To learn more visit: snark.cloud/duplo. Thats's snark.cloud/D-U-P-L-O-C-L-O-U-D.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. Every once in a while I catch up with someone that it feels like I've known for ages, and I realize somehow I have never been able to line up getting them on this show as a guest. Today is just one of those days. And my guest is Amy Tobey who has been someone I've been talking to for ages, even in the before-times, if you can remember such a thing. Today, she's a Senior Principal Engineer at Equinix. Amy, thank you for finally giving in to my endless wheedling.Amy: Thanks for having me. You mentioned the before-times. Like, I remember it was, like, right before the pandemic we had beers in San Francisco wasn't it? There was Ian there—Corey: Yeah, I—Amy: —and a couple other people. It was a really great time. And then—Corey: I vaguely remember beer. Yeah. And then—Amy: And then the world ended.Corey: Oh, my God. Yes. It's still March of 2020, right?Amy: As far as I know. Like, I haven't checked in a couple years.Corey: So, you do an awful lot. And it's always a difficult question to ask someone, so can you encapsulate your entire existence in a paragraph? It's—Amy: [sigh].Corey: —awful, so I'd like to give a bit more structure to it. Let's start with the introduction: You are a Senior Principal Engineer. We know it's high level because of all the adjectives that get put in there, and none of those adjectives are ‘associate' or ‘beginner' or ‘junior,' or all the other diminutives that companies like to play games with to justify paying people less. And you're at Equinix, which is a company that is a bit unlike most of the, shall we say, traditional cloud providers. What do you do over there and both as a company, as a person?Amy: So, as a company Equinix, what most people know about is that we have a whole bunch of data centers all over the world. I think we have the most of any company. And what we do is we lease out space in that data center, and then we have a number of other products that people don't know as well, which one is Equinix Metal, which is what I specifically work on, where we rent you bare-metal servers. None of that fancy stuff that you get any other clouds on top of it, there's things you can get that are… partner things that you can add-on, like, you know, storage and other things like that, but we just deliver you bare-metal servers with really great networking. So, what I work on is the reliability of that whole system. All of the things that go into provisioning the servers, making them come up, making sure that they get delivered to the server, make sure the API works right, all of that stuff.Corey: So, you're on the Equinix cloud side of the world more so than you are on the building data centers by the sweat of your brow, as they say?Amy: Correct. Yeah, yeah. Software side.Corey: Excellent. I spent some time in data centers in the early part of my career before cloud ate that. That was sort of cotemporaneous with the discovery that I'm the hardware destruction bunny, and I should go to great pains to keep my aura from anything expensive and important, like, you know, the SAN. So—Amy: Right, yeah.Corey: Companies moving out of data centers, and me getting out was a great thing.Amy: But the thing about SANs though, is, like, it might not be you. They're just kind of cursed from the start, right? They just always were kind of fussy and easy to break.Corey: Oh, yeah. I used to think—and I kid you not—that I had a limited upside to my career in tech because I sometimes got sloppy and I was fairly slow at crimping ethernet cables.Amy: [laugh].Corey: That is very similar to growing up in third grade when it became apparent that I was going to have problems in my career because my handwriting was sloppy. Yeah, it turns out the future doesn't look like we predicted it would.Amy: Oh, gosh. Are we going to talk about, like, neurological development now or… [laugh] okay, that's a thing I struggle with, too right, is I started typing as soon as they would let—in fact, before they would let me. I remember in high school, I had teachers who would grade me down for typing a paper out. They want me to handwrite it and I would go, “Cool. Go ahead and take a grade off because if I handwrite it, you're going to take two grades off my handwriting, so I'm cool with this deal.”Corey: Yeah, it was pretty easy early on. I don't know when the actual shift was, but it became more and more apparent that more and more things are moving towards a world where you could type. And I was almost five when I started working on that stuff, and that really wound up changing a lot of aspects of how I started seeing things. One thing I think you're probably fairly well known for is incidents. I want to be clear when I say that you are not the root cause as—“So, why are things broken?” “It's Amy again. What's she gotten into this time?” Great.Amy: [laugh]. But it does happen, but not all the time.Corey: Exa—it's a learning experience.Amy: Right.Corey: You've also been deeply involved with SREcon and a number of—a lot of aspects of what I will term—and please don't yell at me for this—SRE culture—Amy: Yeah.Corey: Which is sometimes a challenging thing to wind up describing or putting a definition around. The one that I've always been somewhat partial to is, “SRE is DevOps, except you worked at Google for a while.” I don't know how necessarily accurate that is, but it does rile people up.Amy: Yeah, it does. Dave Stanke actually did a really great talk at SREcon San Francisco just a couple weeks ago, about the DORA report. And the new DORA report, they split SRE out into its own function and kind of is pushing against that old model, which actually comes from Liz Fong-Jones—I think it's from her, or older—about, like, class SRE implements DevOps, which is kind of this idea that, like, SREs make DevOps happen. Things have evolved, right, since then. Things have evolved since Google released those books, and we're all just figured out what works and what doesn't a little bit.And so, it's not that we're implementing DevOps so much. In fact, it's that ops stuff that kind of holds us back from the really high impact work that SREs, I think, should be doing, that aren't just, like, fixing the problems, the symptoms down at the bottom layer, right? Like what we did as sysadmins 20 years ago. You know, we'd go and a lot of people are SREs that came out of the sysadmin world and still think in that mode, where it's like, “Well, I set up the systems, and when things break, I go and I fix them.” And, “Why did the developers keep writing crappy code? Why do I have to always getting up in the middle of the night because this thing crashed?”And it turns out that the work we need to do to make things more reliable, there's a ceiling to how far away the platform can take us, right? Like, we can have the best platform in the world with redundancy, and, you know, nine-way replicated data storage and all this crazy stuff, and still if we put crappy software on top, it's going to be unreliable. So, how do we make less crappy software? And for most of my career, people would be, like, “Well, you should test it.” And so, we started doing that, and we still have crappy software, so what's going on here? We still have incidents.So, we write more tests, and we still have incidents. We had a QA group, we still have incidents. We send the developers to training, and we still have incidents. So like, what is the thing we need to do to make things more reliable? And it turns out, most of it is culture work.Corey: My perspective on this stems from being a grumpy old sysadmin. And at some point, I started calling myself a systems engineer or DevOps or production engineer, or SRE. It was all from my point of view, the same job, but you know, if you call yourself a sysadmin, you're just asking for a 40% pay cut off the top.Amy: [laugh].Corey: But I still tended to view the world through that lens. I tended to be very good at Linux systems internals, for example, understanding system calls and the rest, but increasingly, as the DevOps wave or SRE wave, or Google-isation of the internet wound up being more and more of a thing, I found myself increasingly in job interviews, where, “Great, now, can you go wind up implementing a sorting algorithm on the whiteboard?” “What on earth? No.” Like, my lingua franca is shitty Bash, and no one tends to write that without a bunch of tab completions and quick checking with manpages—die.net or whatnot—on the fly as you go down that path.And it was awful, and I felt… like my skill set was increasingly eroding. And it wasn't honestly until I started this place where I really got into writing a fair bit of code to do different things because it felt like an orthogonal skill set, but the fullness of time, it seems like it's not. And it's a reskilling. And it made me wonder, does this mean that the areas of technology that I focused on early in my career, was that all a waste? And the answer is not really. Sometimes, sure, in that I don't spend nearly as much time worrying about inodes—for example—as I once did. But every once in a while, I'll run into something and I looked like a wizard from the future, but instead, I'm a wizard from the past.Amy: Yeah, I find that a lot in my work, now. Sometimes things I did 20 years ago, come back, and it's like, oh, yeah, I remember I did all that threading work in 2002 in Perl, and I learned everything the very, very, very hard way. And then, you know, this January, did some threading work to fix some stability issues, and all of it came flooding back, right? Just that the experiences really, more than the code or the learning or the text and stuff; more just the, like, this feels like threads [BLEEP]-ery. Is a diagnostic thing that sometimes we have to say.And then people are like, “Can you prove it?” And I'm like, “Not really,” because it's literally thread [BLEEP]-ery. Like, the definition of it is that there's weird stuff happening that we can't figure out why it's happening. There's something acting in the system that isn't synchronized, that isn't connected to other things, that's happening out of order from what we expect, and if we had a clear signal, we would just fix it, but we don't. We just have, like, weird stuff happening over here and then over there and over there and over there.And, like, that tells me there's just something happening at that layer and then have to go and dig into that right, and like, just basically charge through. My colleagues are like, “Well, maybe you should look at this, and go look at the database,” the things that they're used to looking at and that their experiences inform, whereas then I bring that ancient toiling through the threading mines experiences back and go, “Oh, yeah. So, let's go find where this is happening, where people are doing dangerous things with threads, and see if we can spot something.” But that came from that experience.Corey: And there's so much that just repeats itself. And history rhymes. The challenge is that, do you have 20 years of experience, or do you have one year of experience repeated 20 times? And as the tide rises, doing the same task by hand, it really is just a matter of time before your full-time job winds up being something a piece of software does. An easy example is, “Oh, what's your job?” “I manually place containers onto specific hosts.” “Well, I've got news for you, and you're not going to like it at all.”Amy: Yeah, yeah. I think that we share a little bit. I'm allergic to repeated work. I don't know if allergic is the right word, but you know, if I sit and I do something once, fine. Like, I'll just crank it out, you know, it's this form, or it's a datafile I got to write and I'll—fine I'll type it in and do the manual labor.The second time, the difficulty goes up by ten, right? Like, just mentally, just to do it, be like, I've already done this once. Doing it again is anathema to everything that I am. And then sometimes I'll get through it, but after that, like, writing a program is so much easier because it's like exponential, almost, growth in difficulty. You know, the third time I have to do the same thing that's like just typing the same stuff—like, look over here, read this thing and type it over here—I'm out; I can't do it. You know, I got to find a way to automate. And I don't know, maybe normal people aren't driven to live this way, but it's kept me from getting stuck in those spots, too.Corey: It was weird because I spent a lot of time as a consultant going from place to place and it led to some weird changes. For example, “Oh, thank God, I don't have to think about that whole messaging queue thing.” Sure enough, next engagement, it's message queue time. Fantastic. I found that repeating myself drove me nuts, but you also have to be very sensitive not to wind up, you know, stealing IP from the people that you're working with.Amy: Right.Corey: But what I loved about the sysadmin side of the world is that the vast majority of stuff that I've taken with me, lives in my shell config. And what I mean by that is I'm not—there's nothing in there is proprietary, but when you have a weird problem with trying to figure out the best way to figure out which Ruby process is stealing all the CPU, great, turns out that you can chain seven or eight different shell commands together through a bunch of pipes. I don't want to remember that forever. So, that's the sort of thing I would wind up committing as I learned it. I don't remember what company I picked that up at, but it was one of those things that was super helpful.I have a sarcastic—it's a one-liner, except no sane editor setting is going to show it in any less than three—of a whole bunch of Perl, piped into du, piped into the rest, that tells you one of the largest consumers of files in a given part of the system. And it rates them with stars and it winds up doing some neat stuff. I would never sit down and reinvent something like that today, but the fact that it's there means that I can do all kinds of neat tricks when I need to. It's making sure that as you move through your career, on some level, you're picking up skills that are repeatable and applicable beyond one company.Amy: Skills and tooling—Corey: Yeah.Amy: —right? Like, you just described the tool. Another SREcon talk was John Allspaw and Dr. Richard Cook talking about above the line; below the line. And they started with these metaphors about tools, right, showing all the different kinds of hammers.And if you're a blacksmith, a lot of times you craft specialized hammers for very specific jobs. And that's one of the properties of a tool that they were trying to get people to think about, right, is that tools get crafted to the job. And what you just described as a bespoke tool that you had created on the fly, that kind of floated under the radar of intellectual property. [laugh].So, let's not tell the security or IP people right? Like, because there's probably billions and billions of dollars of technically, like, made-up IP value—I'm doing air quotes with my fingers—you know, that's just basically people's shell profiles. And my God, the Emacs automation that people have done. If you've ever really seen somebody who's amazing at Emacs and is 10, 20, 30, maybe 40 years of experience encoded in their emacs settings, it's a wonder to behold. Like, I look at it and I go, “Man, I wish I could do that.”It's like listening to a really great guitar player and be like, “Wow, I wish I could play like them.” You see them just flying through stuff. But all that IP in there is both that person's collection of wisdom and experience and working with that code, but also encodes that stuff like you described, right? It's just all these little systems tricks and little fiddly commands and things we don't want to remember and so we encode them into our toolset.Corey: Oh, yeah. Anything I wound up taking, I always would share it with people internally, too. I'd mention, “Yeah, I'm keeping this in my shell files.” Because I disclosed it, which solves a lot of the problem. And also, none of it was even close to proprietary or anything like that. I'm sorry, but the way that you wind up figuring out how much of a disk is being eaten up and where in a more pleasing way, is not a competitive advantage. It just isn't.Amy: It isn't to you or me, but, you know, back in the beginning of our careers, people thought it was worth money and should be proprietary. You know, like, oh, that disk-checking script as a competitive advantage for our company because there are only a few of us doing this work. Like, it was actually being able to, like, manage your—[laugh] actually manage your servers was a competitive advantage. Now, it's kind of commodity.Corey: Let's also be clear that the world has moved on. I wound up buying a DaisyDisk a while back for Mac, which I love. It is a fantastic, pretty effective, “Where's all the stuff on your disk going?” And it does a scan and you can drive and collect things and delete them when trying to clean things out. I was using it the other day, so it's top of mind at the moment.But it's way more polished than that crappy Perl three-liner. And I see both sides, truly I do. The trick also, for those wondering [unintelligible 00:15:45], like, “Where is the line?” It's super easy. Disclose it, what you're doing, in those scenarios in the event someone is no because they believe that finding the right man page section for something is somehow proprietary.Great. When you go home that evening in a completely separate environment, build it yourself from scratch to solve the problem, reimplement it and save that. And you're done. There are lots of ways to do this. Don't steal from your employer, but your employer employs you; they don't own you and the way that you think about these problems.Every person I've met who has had a career that's longer than 20 minutes has a giant doc somewhere on some system of all of the scripts that they wound up putting together, all of the one-liners, the notes on, “Next time you see this, this is the thing to check.”Amy: Yeah, the cheat sheet or the notebook with all the little commands, or again the Emacs config, sometimes for some people, or shell profiles. Yeah.Corey: Here's the awk one-liner that I put that automatically spits out from an Apache log file what—the httpd log file that just tells me what are the most frequent talkers, and what are the—Amy: You should probably let go of that one. You know, like, I think that one's lifetime is kind of past, Corey. Maybe you—Corey: I just have to get it working with Nginx, and we're good to go.Amy: Oh, yeah, there you go. [laugh].Corey: Or S3 access logs. Perish the thought. But yeah, like, what are the five most high-volume talkers, and what are those relative to each other? Huh, that one thing seems super crappy and it's coming from Russia. But that's—hmm, one starts to wonder; maybe it's time to dig back in.So, one of the things that I have found is that a lot of the people talking about SRE seem to have descended from an ivory tower somewhere. And they're talking about how some of the best-in-class companies out there, renowned for their technical cultures—at least externally—are doing these things. But there's a lot more folks who are not there. And honestly, I consider myself one of those people who is not there. I was a competent engineer, but never a terrific one.And looking at the way this was described, I often came away thinking, “Okay, it was the purpose of this conference talk just to reinforce how smart people are, and how I'm not,” and/or, “There are the 18 cultural changes you need to make to your company, and then you can do something kind of like we were just talking about on stage.” It feels like there's a combination of problems here. One is making this stuff more accessible to folks who are not themselves in those environments, and two, how to drive cultural change as an individual contributor if that's even possible. And I'm going to go out on a limb and guess you have thoughts on both aspects of that, and probably some more hit me, please.Amy: So, the ivory tower, right. Let's just be straight up, like, the ivory tower is Google. I mean, that's where it started. And we get it from the other large companies that, you know, want to do conference talks about what this stuff means and what it does. What I've kind of come around to in the last couple of years is that those talks don't really reach the vast majority of engineers, they don't really apply to a large swath of the enterprise especially, which is, like, where a lot of the—the bulk of our industry sits, right? We spend a lot of time talking about the darlings out here on the West Coast in high tech culture and startups and so on.But, like, we were talking about before we started the show, right, like, the interior of even just America, is filled with all these, like, insurance and banks and all of these companies that are cranking out tons of code and servers and stuff, and they're trying to figure out the same problems. But they're structured in companies where their tech arm is still, in most cases, considered a cost center, often is bundled under finance, for—that's a whole show of itself about that historical blunder. And so, the tech culture is tend to be very, very different from what we experience in—what do we call it anymore? Like, I don't even want to say West Coast anymore because we've gone remote, but, like, high tech culture we'll say. And so, like, thinking about how to make SRE and all this stuff more accessible comes down to, like, thinking about who those engineers are that are sitting at the computers, writing all the code that runs our banks, all the code that makes sure that—I'm trying to think of examples that are more enterprise-y right?Or shoot buying clothes online. You go to Macy's for example. They have a whole bunch of servers that run their online store and stuff. They have internal IT-ish people who keep all this stuff running and write that code and probably integrating open-source stuff much like we all do. But when you go to try to put in a reliability program that's based on the current SRE models, like SLOs; you put in SLOs and you start doing, like, this incident management program that's, like, you know, you have a form you fill out after every incident, and then you [unintelligible 00:20:25] retros.And it turns out that those things are very high-level skills, skills and capabilities in an organization. And so, when you have this kind of IT mindset or the enterprise mindset, bringing the culture together to make those things work often doesn't happen. Because, you know, they'll go with the prescriptive model and say, like, okay, we're going to implement SLOs, we're going to start measuring SLIs on all of the services, and we're going to hold you accountable for meeting those targets. If you just do that, right, you're just doing more gatekeeping and policing of your tech environment. My bet is, reliability almost never improves in those cases.And that's been my experience, too, and why I get charged up about this is, if you just go slam in these practices, people end up miserable, the practices then become tarnished because people experienced the worst version of them. And then—Corey: And with the remote explosion as well, it turns out that changing jobs basically means their company sends you a different Mac, and the next Monday, you wind up signing into a different Slack team.Amy: Yeah, so the culture really matters, right? You can't cover it over with foosball tables and great lunch. You actually have to deliver tools that developers want to use and you have to deliver a software engineering culture that brings out the best in developers instead of demanding the best from developers. I think that's a fundamental business shift that's kind of happening. If I'm putting on my wizard hat and looking into the future and dreaming about what might change in the world, right, is that there's kind of a change in how we do leadership and how we do business that's shifting more towards that model where we look at what people are capable of and we trust in our people, and we get more out of them, the knowledge work model.If we want more knowledge work, we need people to be happy and to feel engaged in their community. And suddenly we start to see these kind of generational, bigger-pie kind of things start to happen. But how do we get there? It's not SLOs. It maybe it's a little bit starting with incidents. That's where I've had the most success, and you asked me about that. So, getting practical, incident management is probably—Corey: Right. Well, as I see it, the problem with SLOs across the board is it feels like it's a very insular community so far, and communicating it to engineers seems to be the focus of where the community has been, but from my understanding of it, you absolutely need buy-in at significantly high executive levels, to at the very least by you air cover while you're doing these things and making these changes, but also to help drive that cultural shift. None of this is something I have the slightest clue how to do, let's be very clear. If I knew how to change a company's culture, I'd have a different job.Amy: Yeah. [laugh]. The biggest omission in the Google SRE books was [Ers 00:22:58]. There was a guy at Google named Ers who owns availability for Google, and when anything is, like, in dispute and bubbles up the management team, it goes to Ers, and he says, “Thou shalt…” right? Makes the call. And that's why it works, right?Like, it's not just that one person, but that system of management where the whole leadership team—there's a large, very well-funded team with a lot of power in the organization that can drive availability, and they can say, this is how you're going to do metrics for your service, and this is the system that you're in. And it's kind of, yeah, sure it works for them because they have all the organizational support in place. What I was saying to my team just the other day—because we're in the middle of our SLO rollout—is that really, I think an SLO program isn't [clear throat] about the engineers at all until late in the game. At the beginning of the game, it's really about getting the leadership team on board to say, “Hey, we want to put in SLIs and SLOs to start to understand the functioning of our software system.” But if they don't have that curiosity in the first place, that desire to understand how well their teams are doing, how healthy their teams are, don't do it. It's not going to work. It's just going to make everyone miserable.Corey: It feels like it's one of those difficult to sell problems as well, in that it requires some tooling changes, absolutely. It requires cultural change and buy-in and whatnot, but in order for that to happen, there has to be a painful problem that a company recognizes and is willing to pay to make go away. The problem with stuff like this is that once you pay, there's a lot of extra work that goes on top of it as well, that does not have a perception—rightly or wrongly—of contributing to feature velocity, of hitting the next milestone. It's, “Really? So, we're going to be spending how much money to make engineers happier? They should get paid an awful lot and they're still complaining and never seem happy. Why do I care if they're happy other than the pure mercenary perspective of otherwise they'll quit?” I'm not saying that it's not worth pursuing; it's not a worthy goal. I am saying that it becomes a very difficult thing to wind up selling as a product.Amy: Well, as a product for sure, right? Because—[sigh] gosh, I have friends in the space who work on these tools. And I want to be careful.Corey: Of course. Nothing but love for all of those people, let's be very clear.Amy: But a lot of them, you know, they're pulling metrics from existing monitoring systems, they are doing some interesting math on them, but what you get at the end is a nice service catalog and dashboard, which are things we've been trying to land as products in this industry for as long as I can remember, and—Corey: “We've got it this time, though. This time we'll crack the nut.” Yeah. Get off the island, Gilligan.Amy: And then the other, like, risky thing, right, is the other part that makes me uncomfortable about SLOs, and why I will often tell folks that I talk to out in the industry that are asking me about this, like, one-on-one, “Should I do it here?” And it's like, you can bring the tool in, and if you have a management team that's just looking to have metrics to drive productivity, instead of you know, trying to drive better knowledge work, what you get is just a fancier version of more Taylorism, right, which is basically scientific management, this idea that we can, like, drive workers to maximum efficiency by measuring random things about them and driving those numbers. It turns out, that doesn't really work very well, even in industrial scale, it just happened to work because, you know, we have a bloody enough society that we pushed people into it. But the reality is, if you implement SLOs badly, you get more really bad Taylorism that's bad for you developers. And my suspicion is that you will get worse availability out of it than you would if you just didn't do it at all.Corey: This episode is sponsored by our friends at Revelo. Revelo is the Spanish word of the day, and its spelled R-E-V-E-L-O. It means “I reveal.” Now, have you tried to hire an engineer lately? I assure you it is significantly harder than it sounds. One of the things that Revelo has recognized is something I've been talking about for a while, specifically that while talent is evenly distributed, opportunity is absolutely not. They're exposing a new talent pool to, basically, those of us without a presence in Latin America via their platform. It's the largest tech talent marketplace in Latin America with over a million engineers in their network, which includes—but isn't limited to—talent in Mexico, Costa Rica, Brazil, and Argentina. Now, not only do they wind up spreading all of their talent on English ability, as well as you know, their engineering skills, but they go significantly beyond that. Some of the folks on their platform are hands down the most talented engineers that I've ever spoken to. Let's also not forget that Latin America has high time zone overlap with what we have here in the United States, so you can hire full-time remote engineers who share most of the workday as your team. It's an end-to-end talent service, so you can find and hire engineers in Central and South America without having to worry about, frankly, the colossal pain of cross-border payroll and benefits and compliance because Revelo handles all of it. If you're hiring engineers, check out revelo.io/screaming to get 20% off your first three months. That's R-E-V-E-L-O dot I-O slash screaming.Corey: That is part of the problem is, in some cases, to drive some of these improvements, you have to go backwards to move forwards. And it's one of those, “Great, so we spent all this effort and money in the rest of now things are worse?” No, not necessarily, but suddenly are aware of things that were slipping through the cracks previously.Amy: Yeah. Yeah.Corey: Like, the most realistic thing about first The Phoenix Project and then The Unicorn Project, both by Gene Kim, has been the fact that companies have these problems and actively cared enough to change it. In my experience, that feels a little on the rare side.Amy: Yeah, and I think that's actually the key, right? It's for the culture change, and for, like, if you really looking to be, like, do I want to work at this company? Am I investing my myself in here? Is look at the leadership team and be, like, do these people actually give a crap? Are they looking just to punt another number down the road?That's the real question, right? Like, the technology and stuff, at the point where I'm at in my career, I just don't care that much anymore. [laugh]. Just… fine, use Kubernetes, use Postgres, [unintelligible 00:27:30], I don't care. I just don't. Like, Oracle, I might have to ask, you know, go to finance and be like, “Hey, can we spend 20 million for a database?” But like, nobody really asks for that anymore, so. [laugh].Corey: As one does. I will say that I mostly agree with you, but a technology that I found myself getting excited about, given the time of the recording on this is… fun, I spent a bit of time yesterday—from when we're recording this—teaching myself just enough Go to wind up being together a binary that I needed to do something actively ridiculous for my camera here. And I found myself coming away deeply impressed by a lot of things about it, how prescriptive it was for one, how self-contained for another. And after spending far too many years of my life writing shitty Perl, and shitty Bash, and worse Python, et cetera, et cetera, the prescriptiveness was great. The fact that it wound up giving me something I could just run, I could cross-compile for anything I need to run it on, and it just worked. It's been a while since I found a technology that got me this interested in exploring further.Amy: Go is great for that. You mentioned one of my two favorite features of Go. One is usually when a program compiles—at least the way I code in Go—it usually works. I've been working with Go since about 0.9, like, just a little bit before it was released as 1.0, and that's what I've noticed over the years of working with it is that most of the time, if you have a pretty good data structure design and you get the code to compile, usually it's going to work, unless you're doing weird stuff.The other thing I really love about Go and that maybe you'll discover over time is the malleability of it. And the reason why I think about that more than probably most folks is that I work on other people's code most of the time. And maybe this is something that you probably run into with your business, too, right, where you're working on other people's infrastructure. And the way that we encode business rules and things in the languages, in our programming language or our config syntax and stuff has a huge impact on folks like us and how quickly we can come into a situation, assess, figure out what's going on, figure out where things are laid out, and start making changes with confidence.Corey: Forget other people for a minute they're looking at what I built out three or four years ago here, myself, like, I look at past me, it's like, “What was that rat bastard thinking? This is awful.” And it's—forget other people's code; hell is your own code, on some level, too, once it's slipped out of the mental stack and you have to re-explore it and, “Oh, well thank God I defensively wound up not including any comments whatsoever explaining what the living hell this thing was.” It's terrible. But you're right, the other people's shell scripts are finicky and odd.I started poking around for help when I got stuck on something, by looking at GitHub, and a few bit of searching here and there. Even these large, complex, well-used projects started making sense to me in a way that I very rarely find. It's, “What the hell is that thing?” is my most common refrain when I'm looking at other people's code, and Go for whatever reason avoids that, I think because it is so prescriptive about formatting, about how things should be done, about the vision that it has. Maybe I'm romanticizing it and I'll hate it and a week from now, and I want to go back and remove this recording, but.Amy: The size of the language helps a lot.Corey: Yeah.Amy: But probably my favorite. It's more of a convention, which actually funny the way I'm going to talk about this because the two languages I work on the most right now are Ruby and Go. And I don't feel like two languages could really be more different.Syntax-wise, they share some things, but really, like, the mental models are so very, very different. Ruby is all the way in on object-oriented programming, and, like, the actual real kind of object-oriented with messaging and stuff, and, like, the whole language kind of springs from that. And it kind of requires you to understand all of these concepts very deeply to be effective in large programs. So, what I find is, when I approach Ruby codebase, I have to load all this crap into my head and remember, “Okay, so yeah, there's this convention, when you do this kind of thing in Ruby”—or especially Ruby on Rails is even worse because they go deep into convention over configuration. But what that's code for is, this code is accessible to people who have a lot of free cognitive capacity to load all this convention into their heads and keep it in their heads so that the code looks pretty, right?And so, that's the trade-off as you said, okay, my developers have to be these people with all these spare brain cycles to understand, like, why I would put the code here in this place versus this place? And all these, like, things that are in the code, like, very compact, dense concepts. And then you go to something like Go, which is, like, “Nah, we're not going to do Lambdas. Nah”—[laugh]—“We're not doing all this fancy stuff.” So, everything is there on the page.This drives some people crazy, right, is that there's all this boilerplate, boilerplate, boilerplate. But the reality is, I can read most Go files from top to the bottom and understand what the hell it's doing, whereas I can go sometimes look at, like, a Ruby thing, or sometimes Python and e—Perl is just [unintelligible 00:32:19] all the time, right, it's there's so much indirection. And it just be, like, “What the [BLEEP] is going on? This is so dense. I'm going to have to sit down and write it out in longhand so I can understand what the developer was even doing here.” And—Corey: Well, that's why I got the Mac Studio; for when I'm not doing A/V stuff with it, that means that I'll have one core that I can use for, you know, front-end processing and the rest, and the other 19 cores can be put to work failing to build Nokogiri in Ruby yet again.Amy: [laugh].Corey: I remember the travails of working with Ruby, and the problem—I have similar problems with Python, specifically in that—I don't know if I'm special like this—it feels like it's a SRE DevOps style of working, but I am grabbing random crap off a GitHub constantly and running it, like, small scripts other people have built. And let's be clear, I run them on my test AWS account that has nothing important because I'm not a fool that I read most of it before I run it, but I also—it wants a different version of Python every single time. It wants a whole bunch of other things, too. And okay, so I use ASDF as my version manager for these things, which for whatever reason, does not work for the way that I think about this ergonomically. Okay, great.And I wind up with detritus scattered throughout my system. It's, “Hey, can you make this reproducible on my machine?” “Almost certainly not, but thank you for asking.” It's like ‘Step 17: Master the Wolf' level of instructions.Amy: And I think Docker generally… papers over the worst of it, right, is when we built all this stuff in the aughts, you know, [CPAN 00:33:45]—Corey: Dev containers and VS Code are very nice.Amy: Yeah, yeah. You know, like, we had CPAN back in the day, I was doing chroots, I think in, like, '04 or '05, you know, to solve this problem, right, which is basically I just—screw it; I will compile an entire distro into a directory with a Perl and all of its dependencies so that I can isolate it from the other things I want to run on this machine and not screw up and not have these interactions. And I think that's kind of what you're talking about is, like, the old model, when we deployed servers, there was one of us sitting there and then we'd log into the server and be like, I'm going to install the Perl. You know, I'll compile it into, like, [/app/perl 558 00:34:21] whatever, and then I'll CPAN all this stuff in, and I'll give it over to the developer, tell them to set their shebang to that and everything just works. And now we're in a mode where it's like, okay, you got to set up a thousand of those. “Okay, well, I'll make a tarball.” [laugh]. But it's still like we had to just—Corey: DevOps, but [unintelligible 00:34:37] dev closer to ops. You're interrelating all the time. Yeah, then Docker comes along, and add dev is, like, “Well, here's the container. Good luck, asshole.” And it feels like it's been cast into your yard to worry about.Amy: Yeah, well, I mean, that's just kind of business, or just—Corey: Yeah. Yeah.Amy: I'm not sure if it's business or capitalism or something like that, but just the idea that, you know, if I can hand off the shitty work to some other poor schlub, why wouldn't I? I mean, that's most folks, right? Like, just be like, “Well”—Corey: Which is fair.Amy: —“I got it working. Like, my part is done, I did what I was supposed to do.” And now there's a lot of folks out there, that's how they work, right? “I hit done. I'm done. I shipped it. Sure. It's an old [unintelligible 00:35:16] Ubuntu. Sure, there's a bunch of shell scripts that rip through things. Sure”—you know, like, I've worked on repos where there's hundreds of things that need to be addressed.Corey: And passing to someone else is fine. I'm thrilled to do it. Where I run into problems with it is where people assume that well, my part was the hard part and anything you schlubs do is easy. I don't—Amy: Well, that's the underclass. Yeah. That's—Corey: Forget engineering for a second; I throw things to the people over in the finance group here at The Duckbill Group because those people are wizards at solving for this thing. And it's—Amy: Well, that's how we want to do things.Corey: Yeah, specialization works.Amy: But we have this—it's probably more cultural. I don't want to pick, like, capitalism to beat on because this is really, like, human cultural thing, and it's not even really particularly Western. Is the idea that, like, “If I have an underclass, why would I give a shit what their experience is?” And this is why I say, like, ops teams, like, get out of here because most ops teams, the extant ops teams are still called ops, and a lot of them have been renamed SRE—but they still do the same job—are an underclass. And I don't mean that those people are below us. People are treated as an underclass, and they shouldn't be. Absolutely not.Corey: Yes.Amy: Because the idea is that, like, well, I'm a fancy person who writes code at my ivory tower, and then it all flows down, and those people, just faceless people, do the deployment stuff that's beneath me. That attitude is the most toxic thing, I think, in tech orgs to address. Like, if you're trying to be like, “Well, our liability is bad, we have security problems, people won't fix their code.” And go look around and you will find people that are treated as an underclass that are given codes thrown over the wall at them and then they just have to toil through and make it work. I've worked on that a number of times in my career.And I think just like saying, underclass, right, or caste system, is what I found is the most effective way to get people actually thinking about what the hell is going on here. Because most people are just, like, “Well, that's just the way things are. It's just how we've always done it. The developers write to code, then give it to the sysadmins. The sysadmins deploy the code. Isn't that how it always works?”Corey: You'd really like to hope, wouldn't you?Amy: [laugh]. Not me. [laugh].Corey: Again, the way I see it is, in theory—in theory—sysadmins, ops, or that should not exist. People should theoretically be able to write code as developers that just works, the end. And write it correct the first time and never have to change it again. Yeah. There's a reason that I always like to call staging environments in places I work ‘theory' because it works in theory, but not in production, and that is fundamentally the—like, that entire job role is the difference between theory and practice.Amy: Yeah, yeah. Well, I think that's the problem with it. We're already so disconnected from the physical world, right? Like, you and I right now are talking over multiple strands of glass and digital transcodings and things right now, right? Like, we are detached from the physical reality.You mentioned earlier working in data centers, right? The thing I miss about it is, like, the physicality of it. Like, actually, like, I held a server in my arms and put it in the rack and slid it into the rails. I plugged into power myself; I pushed the power button myself. There's a server there. I physically touched it.Developers who don't work in production, we talked about empathy and stuff, but really, I think the big problem is when they work out in their idea space and just writing code, they write the unit tests, if we're very lucky, they'll write a functional test, and then they hand that wad off to some poor ops group. They're detached from the reality of operations. It's not even about accountability; it's about experience. The ability to see all of the weird crap we deal with, right? You know, like, “Well, we pushed the code to that server, but there were three bit flips, so we had to do it again. And then the other server, the disk failed. And on the other server…” You know? [laugh].It's just, there's all this weird crap that happens, these systems are so complex that they're always doing something weird. And if you're a developer that just spends all day in your IDE, you don't get to see that. And I can't really be mad at those folks, as individuals, for not understanding our world. I figure out how to help them, and the best thing we've come up with so far is, like, well, we start giving this—some responsibility in a production environment so that they can learn that. People do that, again, is another one that can be done wrong, where it turns into kind of a forced empathy.I actually really hate that mode, where it's like, “We're forcing all the developers online whether they like it or not. On-call whether they like it or not because they have to learn this.” And it's like, you know, maybe slow your roll a little buddy because the stuff is actually hard to learn. Again, minimizing how hard ops work is. “Oh, we'll just put the developers on it. They'll figure it out, right? They're software engineers. They're probably smarter than you sysadmins.” Is the unstated thing when we do that, right? When we throw them in the pit and be like, “Yeah, they'll get it.” [laugh].Corey: And that was my problem [unintelligible 00:39:49] the interview stuff. It was in the write code on a whiteboard. It's, “Look, I understood how the system fundamentally worked under the hood.” Being able to power my way through to get to an outcome even in language I don't know, was sort of part and parcel of the job. But this idea of doing it in artificially constrained environment, in a language I'm not super familiar with, off the top of my head, it took me years to get to a point of being able to do it with a Bash script because who ever starts with an empty editor and starts getting to work in a lot of these scenarios? Especially in an ops role where we're not building something from scratch.Amy: That's the interesting thing, right? In the majority of tech work today—maybe 20 years ago, we did it more because we were literally building the internet we have today. But today, most of the engineers out there working—most of us working stiffs—are working on stuff that already exists. We're making small incremental changes, which is great that's what we're doing. And we're dealing with old code.Corey: We're gluing APIs together, and that's fine. Ugh. I really want to thank you for taking so much time to talk to me about how you see all these things. If people want to learn more about what you're up to, where's the best place to find you?Amy: I'm on Twitter every once in a while as @MissAmyTobey, M-I-S-S-A-M-Y-T-O-B-E-Y. I have a blog I don't write on enough. And there's a couple things on the Equinix Metal blog that I've written, so if you're looking for that. Otherwise, mainly Twitter.Corey: And those links will of course be in the [show notes 00:41:08]. Thank you so much for your time. I appreciate it.Amy: I had fun. Thank you.Corey: As did I. Amy Tobey, Senior Principal Engineer at Equinix. I'm Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you've enjoyed this podcast, please leave a five-star review on your podcast platform of choice, or on the YouTubes, smash the like and subscribe buttons, as the kids say. Whereas if you've hated this episode, same thing, five-star review all the platforms, smash the buttons, but also include an angry comment telling me that you're about to wind up subpoenaing a copy of my shell script because you're convinced that your intellectual property and secrets are buried within.Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business and we get to the point. Visit duckbillgroup.com to get started.Announcer: This has been a HumblePod production. Stay humble.

Fredrik och Anton Gunnarsson snackar om Baldur Bjarnasons lista med 136 saker varje webbutvecklare bör veta och vad vi tänker om dem. Eller vad vi tänker om kanske en tiondel av punkterna i alla fall. Vi diskuterar bland annat att utveckling behöver stödja ens organisation, lär oss det intressanta begreppet failure demand, och diskuterar single-page-applikationers vara eller icke vara. Därefter blir det sansat ångrande, varför mobillösningar alltid skaver, besvärliga beroenden, lärande av andras kod, och varför ramverk är mer för organisationer än människor. Med mera. Skit händer, det löser sig! Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @oferlund, och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi, eller handla något i vår butik. Länkar Anton Tidigare avsnitt med Anton Thérese - Antons kollega i grannpodden Asdf 136 facts every web dev should know before they burn out and turn to landscape painting or nude modelling Holier-than-thou Failure demand SPA:er - single-page applications Don't be evil Sturgeon's law Mikrotjänster Code sandbox Code sandbox app för Ipad Förslag att införa typer i Javascript Rich Harris som gör Svelte JSDoc Don't repeat yourself - DRY Dan Abramov The WET codebase Lasagnekod och spaghettikod Just Javascript - Dan Abramovs kurs som ger en bättre mental modell av Javascript När HBO skyllde på praktikanten Matt Mullenweg Automattic Wordpress Notion Notions webclipper extension Drafts Digital gardens-rörelsen Meatloaf om namnet Meatloaf Titlar Rubriken är 5+ Jag vet verkligen vad jag pratar om Få, färre, färst Sansad undo Don't be mean Trycka “Hoppsan” efteråt 90% av allt du gör är skit Browsern som skaver Läs kod En liknelse som flyger Fel mental modell Det gäller att ha samma modell Olika typer av kommunikation Det ska inte få spåra ur Ramverk är för organisationer

The World Domination Treasury increased by $1 this week! But it's not from somewhere you would expect... I'm back in business after a 2-week burnout break, with some big plans for next year. You can get access to Overmind over at www.overmind.wiki And my side-projects (Priority Cubes and ASDF) at www.overmindlabs.com You can also follow my progress towards the Evil Master Plan in our Discord (discord.gg/zV8FFKjD96), Twitter (@overmind_wiki) or on LinkedIn. Logo Opener by Free Music (CC BY 3.0 License, Promoted by Chosic) --- Send in a voice message: https://podcasters.spotify.com/pod/show/evil-master-plan/message Support this podcast: https://podcasters.spotify.com/pod/show/evil-master-plan/support

நாறும்பூநாதனின் "தட்டச்சு கால நினைவுகள் குறுநாவலின் இறுதிபகுதி. For feedback and comments please contact jerrydear10@gmail.com --- Support this podcast: https://anchor.fm/jerry0355/support

நாறும்பூநாதனின் தட்டச்சு கால நினைவுகள் குறுநாவலின் இரண்டாம் பாகம் --- Support this podcast: https://anchor.fm/jerry0355/support

asdf:lkj தட்டச்சு கால நினைவுகள். (குறுநாவல்) For feedback and comments please contact jerrydear10@gmail.com --- Support this podcast: https://anchor.fm/jerry0355/support

Olli ist aufgedreht und Hauke war in Berlin saufen. Mails an allesundlecker@aol.com Themen: Für Olli: Internetklassiker Für Hauke: Lammbock & Lombock (Netflix) Inhalt: 00:19:00 - Hausaufgabe Olli: YouTube-Hits 00:44:50 - Mails (danke Jan!) 00:46:50 - Hausaufgabe Hauke: Lammbock & Lommbock 00:55:00 - Haukes Problem mit Lammbock 01:12:50 - Neue Hausaufgabe Neue Hausaufgaben: Für Hauke: Dave Chapelle - The Closer Für Olli: Mario Barth - Männer sind Schweine, Frauen aber auch Links: Spiegel-Doku: https://www.youtube.com/watch?v=eOz6lip7AWc Ollis Klassiker: https://www.youtube.com/watch?v=uq2OGLUel0M https://www.youtube.com/watch?v=e4FSbGVrLS8 https://www.youtube.com/watch?v=uE-1RPDqJAY https://www.youtube.com/watch?v=EzNhaLUT520 https://www.youtube.com/watch?v=NXYTI0xh6o0 https://www.youtube.com/watch?v=Vryan475_w4 https://www.youtube.com/watch?v=CsGYh8AacgY https://www.youtube.com/watch?v=EIyixC9NsLI https://www.youtube.com/watch?v=fhS9Y3SfuRQ https://www.youtube.com/watch?v=J---aiyznGQ https://www.youtube.com/watch?v=OQSNhk5ICTI

02:01 - Sy's Superpower: Making Complex Topics Digestible * Sy on YouTube: "Computer Science Explained with my Cats" (https://www.youtube.com/SyBrandPlusCats) 06:28 - Approaching Learning to Code: Do Something That Motivates You * Greater Than Code Episode 246: Digital Democracy and Indigenous Storytelling with Rudo Kemper (https://www.greaterthancode.com/digital-democracy-and-indigenous-storytelling) * Ruby For Good (https://rubyforgood.org/) * Terrastories (https://terrastories.io/) 11:25 - Computers Can Hurt Our Bodies! * Logitech M570 Max (https://www.amazon.com/Logitech-M570-Wireless-Trackball-Mouse/dp/B0043T7FXE) * Dvorak Keyboard (https://www.dvorak-keyboard.com/) 13:57 - Motivation (Cont'd) * Weekend Game Jams * The I Do, We Do, You Do Pattern (https://theowlteacher.com/examples-of-i-do-you-do-we-do/) 22:15 - Sy's Content (Cont'd) * Sy on YouTube: "Computer Science Explained with my Cats" (https://www.youtube.com/SyBrandPlusCats) * Content Creation and Choosing Topics 33:58 - Code As Art * code:art (https://code-art.xyz/) / @codeart_journal (https://twitter.com/codeart_journal) * trashheap (https://trashheap.party/) / @trashheapzine (https://twitter.com/trashheapzine) * Submission Guidelines (https://trashheap.party/submit/) * Casey's Viral TikTok! (https://www.tiktok.com/@heycaseywattsup/video/6988571925811367173?lang=en&is_copy_url=1&is_from_webapp=v1) 41:34 - #include ＜C++＞ (https://www.includecpp.org/) * Lessons learned creating an inclusive space in a decades old community (Sy's Talk) (https://developerrelations.com/community/lessons-learned-creating-an-inclusive-space-in-a-decades-old-community) * QueerJS (https://queerjs.com/) * Emscripten (https://emscripten.org/) * Graphiz it! (http://graphviz.it/#/gallery) Reflections: Mandy: Digging into Sy's videos. Casey: Working within content creation constraints. Sy: Make a video on register allocation. This episode was brought to you by @therubyrep (https://twitter.com/therubyrep) of DevReps, LLC (http://www.devreps.com/). To pledge your support and to join our awesome Slack community, visit patreon.com/greaterthancode (https://www.patreon.com/greaterthancode) To make a one-time donation so that we can continue to bring you more content and transcripts like this, please do so at paypal.me/devreps (https://www.paypal.me/devreps). You will also get an invitation to our Slack community this way as well. Transcript: Software is broken, but it can be fixed. Test Double's superpower is improving how the world builds software by building both great software and great teams and you can help. Test Double is looking for empathetic senior software engineers and dev ops engineers. We work in JavaScript, Ruby, Elixir, and a lot more. Test Double trusts developers with autonomy and flexibility at a 100% remote employee-owned software consulting agency. Are you trying to grow? Looking for more challenges? Enjoy lots of variety in projects working with the best teams in tech as a developer consultant at Test Double. Find out more and check out remote openings at link.testdouble.com/join. That's link.testdouble.com/join. MANDY: Hello and welcome to Greater Than Code, Episode 247. My name is Mandy Moore and I'm here with my friend, Casey Watts. CASEY: Hi, I'm Casey, and we're both here with our guest today, Sy Brand. SY: Hey, everyone! CASEY: Sy is Microsoft's C++ Developer Advocate. Their background is in compilers and debuggers for embedded accelerators. They're particularly interested in generic library design, making complex concepts understandable, and making our communities more welcoming and inclusive. They can usually be found on Twitter, playing with their three cats, writing, or watching experimental movies. Hi, Sy! Good to have you. SY: Hey, thanks for having me on. CASEY: The first question we like to ask, I think you're prepared for it, is what is your superpower and how did you acquire it? SY: Yeah, so very topically, I think one of my superpowers is forgetting what topics I want to talk about when recording podcasts and that, I acquired through having ADHD and forgetting to write things down. But I did write things down this time so maybe that won't be too much of a problem. But I think one of my other ones is making complex topics digestible, trying to take computer science topics and distill them down into things which are understandable without necessarily having a lot of the background knowledge, the resources you'd expect. I gained that mostly through my background in computer science and then my interest in public speaking and communication and performance poetry, trying to blend those together to make things easier to understand, lower the barrier for entry. CASEY: I love it. Making complex topics digestible. That's definitely a skill we need more of in the world. MANDY: Absolutely. So Casey told me you are a bit of a teacher and you do a lot of teaching on, is it YouTube? So making things easier to digest. Like I said, during the preshow, I've been trying to learn to code on and off for 12 years, as long as I've had this career, and I've started and stopped, gotten frustrated and stopped, and I've tried different things. I've had mentors and I feel like I've let my mentors down and I've tried this and that. I've tried the code academy and I don't know. So how do you do it? Can you tell us a little bit about how you do that? SY: Sure. So most of the topics that I am interested in teaching is, because I come from a background of compilers and debuggers and very low-level systems, those are the things that I want people to get excited about because I think people look at compilers, or C++, or low-level programming and think, “Oh, this is not very interesting,” or new, or it's too complex, or it requires too much of a degree, or whatever. But none of that is true. You can write a compiler without having to have a lot of the background knowledge you might expect and you can learn C++ without having to – it can be a lot easier than people make art. So I want to make these concepts seem interesting and understandable because they're deeply interesting to me and they've been working on them for a large part of my life and I still love it and find them fascinating. So I want to share that with people. CASEY: What's your motivation when you're working on these? Is it to understand things that are complex, or are you solving problems you have, or other people have, or maybe a blend, or other motivations? I'm wondering what gets you so pumped about it. SY: Yeah, so I think it's a few different things. I make videos on Twitter, or YouTube, things like that of explaining concepts that I'm already familiar with and it's pretty much stuff that I could write an entire video off the top of my head without having to do any research. So I've done videos on explaining what a compiler is and all the stages of compilation, or a video on higher cash performance works, or [in audible 05:48] cash configurancy, garbage collection. These are all things I could just sit down and write something on and don't have to do a lot of research. Then there's the more exploratory stuff. I've been live streaming the development of a Ranges library for C++, which is being able to compose operations, building up a pipeline of operations for your data and then declarative manner so that you don't have to deal with a lot of memory allocations and moving data, or a range yourself. You just say, “Here's all the steps that I want to occur,” and then someone who has written all of these pipeline operations deals with how that actually happens. I've been developing that library live and trying to teach myself hired to do all of these things as while also teaching other people at the same time. MANDY: So is it right to assume that maybe I've been going about learning to code in all the wrong ways and that I've just picked a language and tried to dive in, or did I miss some of the conceptual stuff? And if so, as I suspect, a lot of the conceptual stuff has gone over my head. So where do you suggest, if you were giving me advice, which yes, you are giving me advice. [laughter] Where would you suggest, as a brand-new beginner coder, what kind of software concepts I need to research and understand before actually diving into an actual programming language? SY: Honestly, I don't think that there's a single answer there and I don't think there's a lot of wrong answers there. From my perspective, the best way to learn how to code is doing something that motivates you and that gets you excited because coding is hard and when you hit those bumps and things are going wrong, if you don't have that motivation to keep going, then it's very easy to stop. I know I've done it in trying to learn certain concepts and things like that before, because I felt like, “Oh, I should learn this thing, but I wasn't really interested in it,” and then I find out it was hard and stopped. The best way that I learn is finding something where I'm like, “Hey, I want to build this thing,” or “I want to understand this because I want to solve this problem,” or “because I want to dove on that knowledge with something else.” It's always the motivation, but then I'm coming from if you're someone with ADHD, or something like me, then it's pretty much impossible to do anything without [chuckles] having a strong motivation behind it. So that kind of comes into my way of learning as well. MANDY: That's super interesting. Actually, the last episode we did was with Rudo Kemper and he did a project with Ruby for Good. I went to that and I actually got really excited, intrigued, and wanted to get involved and learn how to code because I was really interested and passionate about the project that he presented, which was Terrastories, which was handing down indigenous knowledge technologically so that stories aren't lost in just having oral traditions, that these stories are actually being recorded and are living somewhere on the internet. So that's really interesting. I went to that and then of course, pandemic happened. It didn't happen again last year, but I'm thinking about going back this year. I'm hoping maybe I can be on a team with somebody that could just shadow and sit there and maybe Casey would let me be that person because rumor has it, Casey is going to be there. Ruby for Good on the East Coast in the fall. CASEY: Yeah, I'll be there. I'd be happy to have you shadow me. Also, my role lately has been a higher level. Last time I was a product manager for the team not coding and this year I'm going to be helping the teams be happy and effective across the board because there's always a team, or two that need some alignment work so that they can be productive the whole weekend. MANDY: That's interesting. Okay. Well, I'm sure I'll find somebody who wouldn't mind me doing a kind of shadow. CASEY: For sure. MANDY: Yeah, cool. CASEY: That's the kind of environment it is. MANDY: Absolutely. CASEY: Yeah. SY: That definitely sounds like the right kind of thing like something where you hear about something, or you look at this project and you think, “Hey, I want to get involved. I want to contribute to this.” That's what can drive a positive learning experience, I think it's that motivation and that motivation could just be, “Hey, I want to get into the tech industry because it pays well and we need money to live because capitalism.” That's like totally legit as well. Whatever you find motivates you to work. MANDY: Yeah, that's why I'm here. I had to find a way for my daughter and I to live. SY: Yeah. MANDY: So I got into tech and podcasts and then I'm working for all these people who I always considered so much smarter than me. I was like, “I could never learn that. I'm not good enough.” But now since joining the podcast as a host and coming on here, I'm feeling more and more like I am smart enough, I could do the thing and so, I'm actually really getting into it more. But it's just that being on the computer for so many hours doing the work stuff makes it hard to also break into the wanting to do the learning outside of my work hours – [overtalk] SY: Right, yeah. MANDY: Because it's so much computering. SY: Yeah, or just split the good screen from bad screen. CASEY: I've been computering so much, I have a tendonitis in my right pinky now from using the arrow keys on the keyboard too much, I think and bad posture, which I've been working on for years. Computers can hurt our bodies. SY: Yeah, definitely. I use the Logitech M570 mouse, which I switched to a number of years ago and was one of the best changes I ever made for using the computer and also, switching to Dvorak for keyboard layout. CASEY: Okay. I use that, too. SY: Nice! CASEY: Dvorak. It's not better, but I learned it. [laughter] It might be more better for my health maybe, but I'm not faster. That's what people always ask. SY: I'm definitely – [overtalk] CASEY: Instead of ASDF, it's a AOEU under your fingers; the common letters right at your fingertips. You don't need the semicolon under your right pinky. [laughter] Why is that there? SY: Yeah. MANDY: Yeah. I was going to ask for us what you were even talking about there. So it's just basically reconfiguring your keyboard to not be QWERTY thing? SY: Yeah, exactly. MANDY: Okay. SY: That means you have to completely relearn how to type, which can take a while. Like when I completely stopped using QWERTY at all and just switched to Dvorak, I didn't even buy a Dvorak keyboard, I just printed out the keyboard layout and stuck it to my monitor and just learned. For the first while, it's excruciating because you're trying to type an email and you're typing 15 words per minute, or something. That's bad. I did definitely did get faster shifting to Dvorak. Before I think I used to type at like 70, 80; I type around a 100 words per minute so it changed my speed a bit. But to be fair, I don't think I typed properly on QWERTY. I switched 10 years ago, though so I can't even remember a whole lot. [chuckles] MANDY: That's interesting, though. That gives me something I want to play around with right there and it's not even really coding. [laughter] It's just I'll be just trying to teach myself to type in a different way. That's really interesting. Thank you. [chuckles] CASEY: Yeah. It was fun for when I learned it, too. I think I learned in middle school and I was I practiced on AIM, AOL Instant Messenger, and RuneScape. SY: Nice. CASEY: I didn't dare practice while I had essays due and I had to write those up. That was too stressful. [laughter] CASEY: Summer was better for me. SY: Yeah, I switched during a summer break at university. CASEY: Low stakes. I needed the low stakes for that to succeed. SY: [laughs] Yeah. CASEY: We were talking about what motivates you to learn programming and I wrote up a story about that for me actually recently. SY: Okay. CASEY: At the highest level, my first programming class, we modeled buoys and boats and it was so boring. I don't know why we were doing it. It didn't have a purpose. There was no end goal, no user, nobody was ever going to use the code. It was fine for learning concepts, I guess, but it wasn't motivated and I hated it and I stopped doing CS for years until I had the opportunity to work on an app that I actually used every day. I was like, “Yeah, I want to edit that.” I just want to add this little checkbox there. Finally, I'll learn programming for that and relearn programming to do useful things for people. Motivation is key. SY: Yeah. I think because I started doing programming when I was quite young, I knew it was definitely the classic video games, wanting to learn how to make video games and then by the time I actually got to university, then I was like, “Yeah, don't want go into the games industry.” So didn't end up doing that. But I still enjoy game jams and things like that. If you're not again. CASEY: That's another thing you might like, Mandy. It's a weekend game jam. MANDY: Hm. CASEY: I don't know how into gaming you are, but it's also fun, lower stakes. People are just partying. Not unlike Ruby for Good. They happen more often and I like how it feels at a game jam, a little better than a hackathon because you're building something fun and creative instead of using a company's API because they told you to. SY: [laughs] Yeah. MANDY: Yeah, I was honestly never exposed to video games as a child. They were a no-no in my household and that's one of the things that I always cursed my parents for is the fact that I am the worst gamer. [laughs] My daughter makes fun of me. I'll sit down and like try to – she's 12 and I'll try to do something. She'll be like, “Wow, this is hurting me to watch you, Mom,” [laughs] and I'm like – [overtalk] CASEY: Ouch. MANDY: No, she called me a try hard and I was like, “Yeah, I'm trying really hard to just go forward.” Like I'm trying really hard to just jump over this object, [chuckles] I was like, “If that makes me a try hard well, then yes, I'm trying very hard. Thank you.” SY: Yeah. My 6-year-old has now got to the point where he can beat me at Super Smash Brothers so I'm not feeling too good about that. [laughs] CASEY: Yeah. My 6-year-old nephew beat us all in Mario Kart a couple weeks. SY: Yeah. [laughs] I can still beat in the Mario Kart. That, I could do. [laughs] MANDY: Yeah. A lot of the games she does looks fun, though so it's something I would be interested in, it's just something that I haven't been exposed to. I'm really excited now that—I don't want to say the pandemic is nearing an end because it seems to be not happening, but I'm excited – [overtalk] CASEY: True. Things are opening up. MANDY: Right now. Until they start closing down again. CASEY: Yeah. MANDY: Because I'm so excited for things like Ruby for Good, driving down to D.C. and seeing some of my friends, and I would be interested in going to one of those game things, as long as people are just like, “Oh yeah, we can be patient with her because she's never done a game before.” [laughs] CASEY: Yeah. My last game jam had eight people on the team and zero had ever done game development before. We figured something out. SY: [chuckles] Yeah. MANDY: Oh, that's fun. SY: Like muddle along. CASEY: Yeah. Somebody did like level design. They did a title map. Someone did sprites. They were like, “I'm going to do a sprite tutorial now.” Sprite is moving like a walking character. We had learned all the terms for it. We didn't know the terms either, but it was a good environment to learn. MANDY: It seems it. It seems like if you have a happy, healthy environment. For me, it was just, I was becoming stressed out. I had a standing meeting once a week with a really, really awesome person and it felt like it was more of like, I was like, “Oh my gosh, I have to work this into my already busy workweek and if I don't, then I'm completely wasting their time,” and I started to feel guilty to the point it brought me down. I was just like, “I don't think this is good for either one of us right now” because I'm feeling too much pressure, especially with the once-a-week thing and it's like to get through this chapter and then get through this chapter, and then I'd have a question and I'm not good at writing things down and then I'd forget. It seems like that might be more of a strategy to learn for me. I think a lot of people, there's different strategies like you have your visual learners, or you have your audio learners and I think for me, it would be cool just like I said, shadowing somebody. Like, if I just like sat there and it wasn't weird for me just to watch it over somebody's shoulder while they're doing this thing, that would a more conducive environment to the way I learn. CASEY: Yeah. I like the pattern, You do, We do, I do. Have you heard of that one? MANDY: No. CASEY: Or I do, We do, You do depending on the perspective. So it's like shadowing first and then doing it together where you're both involved and then you can do it on your own. It's a three-step process to make it a little bit easier to learn things from other people. SY: Yeah, that makes sense. MANDY: Yeah, that sounds like how kids learn. It's how we teach our children like I do, now we're going to do it together, now you do it. Yeah, I definitely have used that with my kid. [chuckles] CASEY: And it's just completely reasonable to do that as adults. That's how human brains work. MANDY: Yeah. No, I don't feel – that's the thing I would have to not almost get over, but just be like, “Oh my gosh, I'm 2 years old. I'm learning like I'm a toddler and that's so embarrassing.” But I think that that is a great way to learn and a great way to approach learning in general. I just started a book on learning more about crystals and it's the beginner's guide and she said, “You read this book and then you can move on to reading this other 700-page book that I've authored, but you should probably read this concise guide first.” I think a lot of people feel the pressure to dive into the super smart, or what they perceive as being the super smart way of diving in like, picking up the Ruby book, or the books that everyone talks about when there's so many other great resources exist that break it into smaller, bite-sized, digestible chunks. I think there's no shame in learning like that and I think a lot of people think that they just need to dive right in and be like, “Oh, this is the hard book, I'm going to go for the hard book first.” Like no, start with the easiest, start small. SY: Yeah. I think as you say, it definitely depends on how you learn what kind of resources you find interesting and engaging. CASEY: I've heard a similar story from a lot of friends, Mandy, where they really want to learn something, maybe programming in general, or a language, and then they psych themselves out, or they don't have the bandwidth in the first place, but they don't realize it and they struggle through that and the guilt because they want to, but they don't have time, or energy, which you also need. It's really common. A lot of people that I know are really motivated to do a lot of stuff; they want to do everything. I know some people who are fine not doing everything and that's great because they're probably more grounded. [chuckles] [laughter] But a lot of people I know really want to learn at all and it's a tension; you don't have infinite time and energy. SY: Yeah. I definitely fall into wanting to learn absolutely everything and right now. MANDY: So what kind of things are you teaching right now, Sy? What kind of content are you putting out there? SY: Yeah. So like I said, a lot of it's to do with low-level programming, like how memory actually works on a computer and how it affects how we program things. Because for a lot of people, if you come from a higher-level programming background, you're used to memory being abstracted away from what you do. You deal with variables, you deal with objects, and the implementation of the programming language deals with how that actually maps onto the underlying hardware. But if you really need to get the most performance you possibly can out of your system and you're using a little bit lower-level language like C, or C++, or Rust, or Swift, or something, then you need to understand how your processor is actually handling the instructions and that is actually handling your memory accesses in order for your performance to actually be good. Some of it is not obvious as well and does not match with how you might think memory works because the processors which we're using today are based in so much history and legacy. A lot of the time, they're essentially trying to mimic behavior of older processors in order to give us a programming model, which we can understand and work with, but then that means that they have to work in certain ways in order to actually get performance for the high-performance modern systems we need. So having an understanding of how our caches work, how instruction pipelines work, and things like that can actually make a really big difference down with the low-level programming. MANDY: Okay. So I'm looking at your Twitter and then looking at your pinned tweet, it says, “I made a YouTube channel for my ‘Computer Science Explained with my Cats' videos.” How do you explain computer science with your cats? Because that's something I could probably get into. SY: Yeah. So I have three cats and – [overtalk] MANDY: I've got you beat by one. SY: Nice. What were your cats called? MANDY: I have four. I have Nicks after Stevie Nicks. I have Sphinx because he looks so regal and I have Chessy and I have Jolie. SY: Cool. Mine are Milkshake, Marshmallow, and Lexical Analysis cat. MANDY: [laughs] Cool. SY: [chuckles] Yeah. So the things explained with my cats, it's mostly I wanted to explain things with my cats and random things, which I find around my house. So I remember I have a Discord server, which I help to moderate called #include , which is a welcoming inclusive organization for the C++ community. We were talking about hash maps and how hash maps are actually implemented, and I realized that there's a lot of different design areas in hash maps, which can be difficult to understand. I wanted to try and explain it using boxes and teddies and my cats so I set up a bunch of boxes. These are all of the buckets, which your items could go into it and then there's some way to map a given teddy to a given box. Let's say, it could be how cute it is. So if it's super cute and it goes in the west most box, and if it's kind of cute, then it goes into the box after that and so on and so forth. That's kind of how hash maps work. They have a bunch of memory, which is allocated somewhere, a bunch of boxes, and they have some way of mapping given items to a given box, which is called a hash function. In this case, it was how cute they are and then you have some way of what happens if two teddies happened to be as cute as each other, how do you deal with that? There's a bunch of different ways that you could handle that and that's called hash collision. Like, what do you do with collisions? Do you stick them in the same box and have a way of dealing with that, or do you just put them in the next box up, or a few boxes up, or something like that? There's whole decades worth of research and designing, which go into these things, but the concepts map quite nicely onto boxes and teddies and how cute they are. [chuckles] MANDY: I love that. SY: They are also explaining how caching works with chocolate, like the intuition with memory access is you ask for some chunk of memory and you get that chunks. You ask for a single chunk of chocolate and you get that chunk of chocolate, but in reality, that's not what happens in most cases. In most cases, you're actually going to get back a whole row of chocolate because it's most likely that if you're going to get a bit of chocolate, you're probably going to be accessing the bits which are right next to it. Like, if you have an array and you're processing all of the elements in that array, then you're just going to be stepping along all of those elements. So it's much faster to bring all of those elements would be right into memory at once. That's what happens in modern processors. Without you having to ask for it, they just bring in that whole row of chocolate. So I tried to – [overtalk] CASEY: That's so polite. [laughs] When your friend asks for a single chip, or a single piece of chocolate, you know what they want more. SY: [laughs] Yeah. CASEY: How generous of you to give them the whole bag. [laughs] Whether they want it, or not though. SY: Yeah. MANDY: So are these videos relatively short, or are they more long-form videos? SY: Yeah, they are 2 minutes long. MANDY: Oh, cool. SY: I try and keep them within the video limit for Twitter videos, which is 2 minutes, 20 seconds. MANDY: Okay, cool. See, that's something I could probably commit to is watching one of those videos not even maybe once a day because sometimes that's a little bit, much pressure every day. So maybe I try to work out three to four times a week. So saying I'm going to do this three to four times a week and I'm going to not stress on I'm going to do this every Monday. Generally three to four times a week, I think that's something I could, could commit to. SY: Yeah. Trying to get them within 2 minutes, 20 seconds can be really tough sometimes. Like it's quite – [overtalk] MANDY: Do you do a lot of editing? SY: Yeah. I would sit down and I'll write the whole episode, or video, or whatever and just get in all of the content that I want, just put it onto a text document and then I'll start filming it in whatever order I want, and then I start editing and then quite often, I realized that I've got 2 minutes, 40 seconds worth of content, or something and I can't quite cut it down and I have to reshoot something and then reedit it. I try to get it all done within a single day because if I don't get it done in a single day, then it ends up taking even longer because I get distracted and things like that. I need to focus just getting this one thing done. MANDY: So you're doing these within hours? SY: Yeah. MANDY: From start to finish, how many hours would you say you invest in these videos? SY: Start to finish, about 5, 6 hours, something like that. Like I said, I don't really have to do a lot of research for them because they're things I know very well, so I can pretty much sit down and just write something and then most of the time is spent in editing and then captioning as well. MANDY: Very cool. CASEY: I've been doing a bit of video editing lately and it takes so long. SY: Yeah, it really does. CASEY: I'm not surprised it takes 5, or 6 hours. [laughter] MANDY: No, I'm not either. I do all the podcasts editing. For those of you listening, who do not know, I edit all these podcasts and it takes roughly even 5 to 6 hours for audio, because I also put other work into that, like doing the show notes and getting the transcripts. Now I have those outsourced because I don't have enough hours in the day, but there's a lot of different parts to editing, podcasting, screen casting, and stuff that I don't think a lot of people know that these 2-minute videos that you do really do take 5 to 6 hours and you're putting these out there for free? SY: Yeah. MANDY: Wow. That's amazing. I assume you have a full-time job on top of that. SY: Yeah. Because my position is a developer advocate, I can count that as is doing work so I don't have to do that in my own time. MANDY: Very cool. Yeah, that's cool. I love DevRel so working in DevRel, I do that, too. I'm a Renaissance woman, basically. Podcast editing, DevRel conference organizing, it's a lot. SY: Yeah. MANDY: So I give you mad props for putting stuff out there and just giving a shout out to people who might not be aware that content creation is not easy and it does take time. So thank you. Thank you for that. Because this seems like the kind of stuff I would be able to ingest. SY: Yeah, thanks. MANDY: And that's cool. CASEY: I'm especially impressed, Sy that you have these interests that are complex would expand and you can explain the well and you find the overlap with what people want to know about. [chuckle] I think maybe in part from the Discord, you hear people asking questions. Can you tell us a little bit about what that's like? How do you decide what's interesting? SY: Yeah. I ask people on Twitter what they would find it interesting, but I also, because right now I'm not really going to conferences, but previously I'd go to a lot of conferences and people would come up to me and if I give a talk on compilers, for example, come and say like, “Oh hey, I never knew how register allocation worked. It was super interesting to know.” So I don't think I've done a video on register allocation yet actually. I should do one of those. MANDY: Write that down. SY: [laughs] Yeah. That's the kind of thing. Just because I spent a lot of time in communities, conferences, Discords, on Twitter, you get a feel for the kind of topics which people find interesting and maybe want to know how they work under the covers and just haven't found a good topic. Even function calls like, how does a function call work in C at the hardware level? If you call a function, what's actually happening? I did a video on that because it feels like such a fundamental thing, calling a function, but there's a lot of magic which goes into it, or it can seem like a lot of magic. It's actually, I want to say very well-defined, sometimes less so, but [laughs] they are real so there is random reason. MANDY: Very cool. I want to talk about the other content creation that you do. So code art journal and trashheap zine, do you want to talk about those a minute? SY: Sure. So code art was an idea that I had. It's a journal of code as art. I'd hear a lot of people saying, “Oh, coding is an art form.” I'd be like, “Okay. Yes. Sometimes, maybe. When is it an art form? When is it not? What's the difference between these?” Like, I spent a lot of time thinking about art because I'm a poet and I spend most of my free time researching and watching movies. Code as art is something which really interested me so I made this journal, which is a collection of things which people send in of code which they think is art and sometimes, it's something you might immediately see and look at it and think, “Okay, right, this is code and it's fulfilling some functional purpose,” and maybe that functional purpose gives it some artistic qualities just by how it achieved something, or if it does something in a very performant manner, or a very interesting manner. Other times, you might look at it and say, “Okay, well, this is code, but it's more aesthetic than functional.” And sometimes it's things which you might look at and think, “Okay, is this even code?” Like there was someone sent in a program written in a language called Folders, which is a esoteric programming language entirely programmed using empty folders on your hard drive, which I absolutely love. I'm super into esoteric programming languages so I absolutely loved that one. [chuckles] But yeah, so the – [overtalk] CASEY: That sounds so cool. Where can people find it? Is it online also? SY: Yes, it's in print and there's also, you can get the issues online for free in PDF form. There is a third issue, which is pretty much fully put together on my machine, I just haven't done the finishing touches and it's been one of those things that's just sat, not doing anything for months and I need to get finished. [chuckles] And then trashheap zine is another thing that I co-edit, which is just utter trash, because as much as I love more explicitly artistic films and writing and things like that, I also have a deep love of utter, utter trash. So this is the trashiest stuff that we could possibly find, even the submission guidelines that I wrote for that is essentially a trash pond, but random submission guidelines. So if you have trash, please send our way. MANDY: Yeah. I was going to say, what you consider trash? What trashiest [laughs] enough to be in these zines? SY: I can read out, where's my submission guidelines? The URL for the zine is trashyheap.party, which I was very, very pleased with and the website looks awful. I spent a lot of time making it as awful as I possibly could. Things like any kind of – [overtalk] CASEY: I love the sparkles. SY: Yes! CASEY: When the mouse moves, it sparkles. SY: Isn't it the best, seriously? Yeah. CASEY: Every website should have that. SY: Yeah, totally. Like texts you sent your crush at 4:00 AM while drunk where you misspelled their name and they never spoke to you again, or draft tweets which you thought better of sending, purely Photoshop pictures of our website. [laughter] A medically inaccurate explanation of the digestive system of raccoon dogs. All good stuff. MANDY: That's amazing. CASEY: I know a lot of people who would be cracking up reading this together. [laughter] CASEY: That sounds great. There's so much treasure in this trash heap. MANDY: Yeah. Don't worry, folks, we'll put links in the show notes. CASEY: Oh, yeah. SY: Yeah. One of my favorite things with it was when we'd get all of the submissions, we would get together and just project them up on a wall and read them together and so much so bad, it's hilarious in the most wonderful way. CASEY: That sounds like a party itself. SY: It is, yes. CASEY: The be trashheap party. SY: Absolutely. CASEY: It's kind of taking me back to early pre-YouTube internet when we watch flash cartoons all the time and a lot of those were terrible, but we loved them. SY: Yes. I made some as well, they were so bad. [laughter] I remember getting a very non legal version of flash and making the worst stick flash renovations I possibly could. CASEY: Oh, speaking of content creation, I've been learning some animation and 3D modeling animation lately. I had my first ever viral TikTok; it had over 9,000 views. SY: Wow! Nice. CASEY: And so when I look at my phone, if it's not the notifications muted, it's annoying. I have to turn it off. [laughter] SY: Yeah – [overtalk] MANDY: Congratulations! [laughs] CASEY: Thank you. So the video is a USB thumb drive that won't insert, even though you flip it over. That's been done before, but what I added was misheard lyrics by the band Maroon 5. Sugar! USB! That's what I hear every time. Mandy, have you done any art? MANDY: Have I done any art? CASEY: Lately? MANDY: Oh. Yeah. Well, actually – [overtalk] CASEY: You've been doing some home stuff, I know. MANDY: Yeah. I've been doing plant stuff, gardening, but this weekend, I actually took my daughter to a workshop. It was called working with resin—epoxy. SY: Oh, cool. MANDY: And we got to make coasters. The teacher brought stickers, feathers, and crystals and it was like a 3-hour workshop and I think my daughter had extra resin. Her birthday is on Thursday this week and I noticed she was making kind of the same ones and I said, “What are you doing?” And she said, “I'm making gifts for my friends that come to my birthday party.” I just thought it was so sweet that I was like – [overtalk] SY: Oh, so sweet. MANDY: Usually birthday parties, you receive gifts, or whatever and she's like, “No, I would like to give them gifts for my birthday,” and I was like, “Oh, that's adorable.” So I've been trying to do more things with my hands and get off the screens more, which has been the major thing keeping me back from being on code. I've made a strict weekend policy where I do not touch my computer from Friday evening to Monday morning, unless it's an absolute dumpster fire, I need to do something, or if a takeout menu looks better on my computer than it does on my phone. [laughter] Then I'll pop it open, but I won't read the email, or do the Slack. And then this Saturday I'm taking a course in astrology. It's all-day workshop so I'm excited to kind of dive into that stuff a little bit more. CASEY: So cool. It's hard to believe we can do these in person again. I'm not over it. MANDY: I know. I'm so afraid to get excited over it and then have it be taken away again. CASEY: Yeah. Sy, tell us a little more about #includes . I've actually heard of it. It's a little bit famous online. It's an inclusive community, I know from the name. SY: Yes. CASEY: Tell us more about it. SY: So it actually started off on Twitter as a half joke; Guy Davidson tweeted being like, “Hey, so why isn't there a diversity and inclusion organization for C++ called #include?” Because #include is it's like a language concept in C and C++ and people were like, “Hahaha yeah, you're right,” and then Kate Gregory was like, “You're right. We should make one.” So we did [chuckles] and we started off with like six of us in a Slack channel and then ended up moving to Discord and starting our own server there and now we are a few thousand members. Back when we had in-person conferences, we would have a booth at pretty much every major C++ conference, we had scholarships, which we would send people on, we got conferences to improve by having live captioning and wheelchair accessible stages and gender-neutral bathrooms instituting and upholding code of conduct, things like that. We started off thinking, “Hey, if we could get some conferences to have a code of conduct or something that would be great,” and then it ended up being way, way, way bigger than any of us thought it would become, which is amazing to see. CASEY: That's so cool. What a success story. SY: Yeah. CASEY: How long has it been going on now? SY: I guess about 3, or 4 years. Yeah, probably closer to 4 years. My sense of time is not good the best of times, but something around 4 years. CASEY: I'm curious if another language community wanted to do something similar if they're inspired. Is there a writeup about what y'all have done? 
SY: I've given talks. CASEY: That we can point people to. We can put that in the show notes. SY: Yeah. I've given a couple of talks, as I said. CASEY: Talks, that would be good. SY: Other people have given talks as well. I gave a slightly longer form talk DevRelCon, London in 2019, I think, which was on the lessons which we learned through trying to build a welcoming and inclusive community. Community which has already been around for decades because C++ was first standardized in 1998 so it's been around for quite a long time and has a lot of history. CASEY: That sounds great. I can't wait to watch it. SY: Yeah. I know that there's other languages. You have JavaScript, QueerJS, which is a really cool community and I'm sure there are other languages which have similar things going as well. CASEY: I had never heard of QueerJS. I'm queer and JS. SY: Yeah. CASEY: I'm glad I had this moment just now. SY: It's cool. They have a Discord and I can't remember how active the Discord is, but they would have meetups across the world, they have one in London and in Berlin and bunch of other places, and talks and community. It seems really cool. CASEY: That's awesome. SY: I wanted to give a talk about C++ and JavaScript because you could link target JavaScript with C++ these days, which is kind of cool. CASEY: I've used Emscripten before. SY: Yeah. CASEY: I didn't use it directly, other people did. It turned Graphviz into a JavaScript. A program that runs in JavaScript instead of normally, it's just CSS. So I could draw circles pointing to other circles in the browser, which is what I always wanted to do. Graphviz.it, that “it” is my favorite Graphviz editor. It's online. SY: Cool. I like Graphviz a lot. Emscripten is really cool, though. Basically a way of compiling C++ plus to JavaScript and then having the interoperation with the browser and the ecosystem that you might want to be able to call JS functions from C++, or other way around, and do things which seem operating systems E, but have to be mapped inside the browser environment. CASEY: That's powerful. I'm also glad I've never had to use it directly. Other people made libraries doing it what I needed. Thank goodness. [chuckles] Abstraction! SY: Yeah. I've not used a whole lot, but I did find it fairly nice to work with when I did. I made a silly esoteric programming language called Enjamb, which is a language where the programs are cones and it runs on a stack-based abstract machine and the interpreter for it is written in C++. I wrote a command line driver for it and also, a version which runs in the browser and that compiles using Emscripten. It was really cool and I picked it all up with CMake, which is the main C++ build systems that you could just say, “Hey, I want to build the combine line version for my platform” like Windows, or Mac, or Linux, or whatever, or “Hey, I want to build it for the web,” and it would build the JavaScript version in HTML page and things like that. It's pretty cool. I recently made another esoteric programming language, which you program using MS Paint. You literally make shapes with MS Paint and you give the compiler an image file, and then it uses OCR and computer vision in order to parse your code and then generate C from that. [laughs] It's pretty ridiculous, but I had so much fun with it. CASEY: OCR is Optical Character Recognition? SY: Yes, exactly. CASEY: So I'm picturing if I wrote a program on a napkin and a computer could maybe OCR that into software. SY: Yeah. So it uses OCR for things like function names because it supports function calls and then uses shapes for most things. It has things like a plus sign, which means increment what it's currently being pointed to, or right, or left, or up, or down arrow is for moving things around. You would actually make an image file with those symbols and then I used OpenCV for working out what the shapes were. It was the first time I've ever done any kind of image recognition stuff. It was a lot easier than I expected it to be; I thought we'd have to write a lot of code in order to get things up and running and to do image detection. But most of the simple things like recognizing hey, this is a triangle, or this is a plus sign, or this is a square, and things like that were pretty, you don't need a lot of code in order to do them. That was mostly when you had to say like, “Okay, this is a triangle, but which direction is it pointing in?” It got a little bit more complicated; I had to do some maths and things like that and I'm terrible at maths. [chuckles] So that was a little bit more difficult, but it was a lot fun to get started with and I had a much lower barrier to entry than I expected. CASEY: Now I want to play with OCR and image recognition. I haven't done that for 10 years. It was not easy when I tried it last time with whatever tool that was. SY: [chuckles] Yeah, I did it – [overtalk] CASEY: For the future! SY: [laughs] Definitely. Yeah. I did it with Python and Python has fairly nice OpenCV bindings and there's a ton of resources out there for predicting most of the basic stuff that you would expect. So there's a lot of learning resources and decent library solutions out there now. CASEY: Cool. All right. We're getting near the end of time. At the end, we like to go through reflections, which is what's something interesting that stood out to you, something you'll take with you going forward from our conversations today. MANDY: I really am excited to dig into Sy's videos. They seem, like I said earlier in the show, something I could commit to a few times a week to watching these videos especially when they are concepts that seem so much fun, like cats, teddy bears, cuteness levels, and things like that. I think that would be a great start for me just to in the morning while I'm still drinking tea just before I even dive into my email, check out one of those videos. So I think I'll do that. SY: Thanks. CASEY: Sy, I liked hearing about your process side with your constraints like 2 minutes, 20 seconds on Twitter, that's such a helpful constraint to make sure it's really polished and dense. It takes you 5 to 6 hours and you make things that people ask about, that they're interested in. That whole process is fascinating to me as I try to make more viral TikToks. [laughter] Or whatever I'm making at the time. SY: Yeah. CASEY: I always wondered how you made such good stuff that got retweeted so often. Cool things of insight. SY: Yeah. Mostly just time. [laughs] I guess, it makes me remember that I definitely want to make a video on register allocation because I love register allocation. It's such a cool thing. For those who don't know, it's like if you have a compiler which takes your code and maps it onto the hardware, your hardware only has a certain number of resources so how do you work out how to use those resources in the best manner? It maps onto some quite nice computer science algorithms like graph coloring, which means it maps quite nicely visually, I could probably make a pretty cool graph coloring visualization with some random things I have strewn around my room. CASEY: I can't imagine this yet, but I will understand that clearly soon I bet. MANDY: That's awesome. Well, I just want to wrap up by saying thank you so much for joining us today, Sy. This has been a really awesome conversation. And to folks who have been listening, thank a content creator. It takes time. It takes energy. It's a lot of work that I don't think a lot of people, unless you've done it, really understand how long and in-depth of a process it is. So thank one of us content creators, especially when we're putting this content out for you for free. To do that for us Greater Than Code, we do a Patreon page and we will invite Sy to join us and we would like you to join us as well. If you are able to donate on a monthly basis, it's awesome. It's patreon.com/greaterthancode. All episodes have show notes and transcripts, and we do a lot of audio editing. So join us if you're able. If you are still a person who is greater than code and cannot afford a monthly commitment, you are still welcome to join us in our Slack community. Simply send a DM to one of the panelists and we will let you in for free. So with that, thank you so much, Casey. Thank you again, Sy. And we'll see you all next week. Special Guest: Sy Brand.

This week Mark and Jonathan share in the excitement of hitting 100 episodes. Warby Parker has a new iOS update to let you update your prescription with just an iPhone. Then they chat about what might come for Apple as right to repair is about to take effect sooner rather than later. Finally they talk about the new iPad mini rumors and how it will be getting its biggest update ever.      Email: mail@everydayrobots.tech   Twitter: @_ everydayrobots @refactoredd @swiftymf    Our Site: Everyday Robots.tech   Links: Bricklink We Bare Bears Warby Parker can now renew prescriptions with new app update  FTC unanimously adopts right to repair policy that will affect Apple and others MKBHD's right to repair video New iPad mini rumors  Canoopsy portable iMac setup Jonathan imagines an iMac G4 like iPad docking station

Fredrik snackar om livet som utvecklare med Therése Komstadius och Anton Gunnarsson, som bland annat gör Asdf - Sveriges kanske skönast avslappnade podd för utvecklare. Vi startar vår diskussion med livet som konsult kontra fast anställd på produktbolag. Vad gör att man går från det ena till det andra, och hur många tidrapporteringssystem vill man egentligen ha? Vi diskuterar också hur det är att jobba på ett bolag som inte har chefer på det sätt de flesta av oss förväntar sig. Fredrik är nyfiken, Therése och Anton berättar. Avsnittet sponsras av Future skill, ett kodcommunity där du kan öva upp dina färdigheter i ett språk, lära dig ett nytt språk, eller skapa utmaningar för andra att lära sig av och med. Future skill är helt gratis att använda, surfa in på futureskill.com och testa! Det är mycket videokonferens nu. Mjukvaror, prylar … och hur känns det med allt hemmajobbande? Vissa av oss ser fram mot att få rita React-komponenter på en whiteboard igen (med andra människor i rummet). Som avslutning lite brädspelstips, och entusiasm för VR-spel. Ett stort tack till Cloudnet som sponsrar vår VPS! Har du kommentarer, frågor eller tips? Vi är @kodsnack, @tobiashieta, @antikristoffer, och @bjoreman på Twitter, har en sida på Facebook och epostas på info@kodsnack.se om du vill skriva längre. Vi läser allt som skickas. Gillar du Kodsnack får du hemskt gärna recensera oss i iTunes! Du kan också stödja podden genom att ge oss en kaffe (eller två!) på Ko-fi. Länkar Anton och webbsida Therése Sist Anton var med i podden - februari 2017, i avsnitt 194 Asdf - podden Still in beta Amanda Swetugg Mpya - konsultbolaget där Therése och Anton jobbar Valve Econtalk om hur det funkade på Valve Artikel om hur det fungerar på Valve lite mer nyss Teal organization - “an emerging organizational paradigm that advocates enabling employee autonomy and to adapt as an organization grows” Evolve Future skill - veckans sponsor Henrik Enström Jitsi Årets julklapp: stormkök?! Dead of winter Catan - artisten tidigare känd som Settlers of Catan Carcassonne Pandemic Pandemic: legacy Beat saber Sidequest Keep talking and nobody explodes Pistol whip Fitxr Eminems Rap god Webvr Titlar En parentes Poddabstinens Startberöringspunkt Och nu har vi podd ihop Den motvillige poddaren Hur mår konsulten Doppa tån i konsultsjön Men ska jag ta beslut? Interna människor som inte är konsulter Turkosa organisationer Alla driver bolag tillsammans Jag vet inte hur de ser ut Jag har aldrig känt mig mer som en IT-konsult Sök på asdf!

Noel, Allison, and Kate finish week 31 Streaming In Place with our wrap-up of The Legend of Korra, Book Four: Balance. We share our thoughts on the season and the series as a whole, looking back on our journey with Korra before turning the floor over to our Zoom listeners. Asdf, asdf, asdf. Tune in for our thoughts, and come back next week as we dive in with the first four episodes of the modern autumnal classic, Over the Garden Wall (available streaming on Hulu).

Noel, Allison, and Kate finish week 31 Streaming In Place with our wrap-up of The Legend of Korra, Book Four: Balance. We share our thoughts on the season and the series as a whole, looking back on our journey with Korra before turning the floor over to our Zoom listeners. Asdf, asdf, asdf. Tune in for our thoughts, and come back next week as we dive in with the first four episodes of the modern autumnal classic, Over the Garden Wall (available streaming on Hulu).

We talk about ASDF movies and more! and I laugh way to much. --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app Support this podcast: https://anchor.fm/lunastory/support

Elixir 1.11 is shaping up to be a huge release with a number of "big deal" features. We are joined by Wojtek Mach to help us understand the significance of some of the new features. These include an improved recompilation process, when alias is preferred over import, improved compiler checks for structs, Erlang help docs in IEx, and more! https://thinkingelixir.com/podcast-episodes/003-elixir-1-11-preview-with-wojtek-mach/ - Show Notes Elixir Community News https://github.com/elixir-lsp/elixir-ls - ElixirLS 0.5.0 released with improved autocomplete https://www.tddphoenix.com/work-in-progress/ - German Velesco published a WIP book on TDD for Elixir https://elixir-lang.org/blog/2020/06/23/growing-with-elixir-at-brex/ - Elixir's website is going to start publishing case studies. The first one is on Brex. https://github.com/aesmail/kaffy - Kaffy provides a quick way of spinning up an admin portal to manage your resources. Works with Phoenix contexts. https://2020.elixirconf.com/ - ElixirConf US 2020 Announced and CFP. Tickets on sale soon. Will be a virtual conference. Interview Resources https://github.com/elixir-lang/elixir/blob/master/CHANGELOG.md https://dashbit.co/blog/speeding-up-re-compilation-of-elixir-projects - Understanding the recompilation problem. https://dashbit.co/blog/rewriting-imports-to-aliases-with-compilation-tracers - Wojtek's blog post on re-writing imports to aliases. https://twitter.com/josevalim/status/1276082352448581635 - Jose sharing compilation improvements. https://www.youtube.com/watch?v=kX6inmSF78c - Changelog podcast testing out LiveDashboard: "Let's take Phoenix LiveDashboard for a spin!" https://github.com/phoenixframework/phoenixlivedashboard/ - Phoenix LiveDashboard https://bytepack.io/ - Where Wojtek has been spending his time recently https://dashbit.co/ - Dashbit https://twitter.com/wojtekmach - Wojtek Mach on Twitter https://github.com/wojtekmach - Wojtek Mach on Github Additional Resources https://thinkingelixir.com/elixir-in-vs-code/ - Elixir in VS Code. Getting your dev environment setup. https://thinkingelixir.com/elixir-in-the-type-system-quadrant/ - Understand what it means that Elixir is a Strong Dynamic language. https://thinkingelixir.com/install-elixir-using-asdf/ - Get started with ASDF. Try out the Elixir master branch! Find us online Message the show - @ThinkingElixir Mark Ericksen - @brainlid David Bernheisel - @bernheisel Cade Ward - Github

We had an AMAZING show. The highlight was a phenomenal call by Roxanne. We also had Eric Kirk, Miltdog, Sinister, and ASDF called in. We talked about the new Police Reform Bill introduced by democrats, HS school president who bashed the police and has been punished harshly. We talked about another young woman on social media who was attacking people regarding black lives matter. She took a beating on social media. We talked about my father who has dementia. I visited him yesterday and he had a really rough day. We talked over cancelled and renewed TV shows. The Amazon movie Becky. Famous peoples mansions and more. This was a really good show. Enjoy! 

I det första trevande premiäravsnittet av Asdf snackar vi bland annat om vilka vi är och vad vi gjort tidigare, strategier för att få klappa hundar, att (inte) hata EpiServer, Sveriges högsta McDonaldsskylt och att drunkna i prestandaträsket. Dessutom hinner vi prata om att övertänka saker, att inte bry sig om andras åsikter och att bry sig för mycket om andras åsikter. Om du gillar podden blir vi väldigt glada för en liten recension i iTunes eller om du säger hej på Twitter (Anton, Therése)

In this episode Michelle is joined by the accomplished lecturer Jill Eversmann, MS CCC-SLP, Academic and Clinical Faculty of Columbia College, and X instructor w/ ASDF. In this hour they challenge all the preconceived notions about incorporating American Sign Language into Early Intervention….in short, they will teach you how “talking with your hands” is an excellent strategy to increase acquisition of functional communication, the differences between Baby Sign and American Sign Language, and the best resources and references behind the beautiful intersection that is ASL and EI. Be sure to stretch before this hour, because it will have you moving!

Office ergonomics is not just about your mouse or your keyboard or your chair.  It’s an integrated look at all the factors; human, environmental, and equipment, which affect how we work at a desk.  For the episode, Ergonomics in the Office, Peter speaks with Maureen Anderson, Certified Professional Ergonomist and Safety Management Consultant with MEMIC.  They talk posture, habits, gravity, focal distance, even lighting.  Maureen brings a wealth of experience to the table, as she discusses the long- and short-term effects of a poorly designed or set up workstation.  Have a great workstation, but still experience aches and pains after a long day in front of the keyboard?  They get into how a well-designed workstation isn’t the lone solution for reducing musculoskeletal injuries in the office.  What to know more about Office Ergonomics?  Check it out at the MEMIC Safety Experts Podcast.   Peter Koch: Hello, listeners, and welcome to the Safety Experts podcast. Does your back hurt by noon or the end of the day? Do you get headaches staring at the screen? Does that chair start to hurt you after a while? Peter Koch: Is the solution to standing workstation or maybe a different chair? Peter Koch: Well, I can tell you if the answer is yes to the first three of those questions, then the answer to the last is no. And today we're going to dig deep into the topic of ergonomics in the office. The Safety Experts podcast is presented by MEMIC, a leading worker's compensation provider based on the East Coast. A new episode of the podcast drops every two weeks featuring interviews with leaders in the field. Top executives MEMIC staff and other industry experts discussing how safety applies to all aspects of our lives. I'm your host, Peter Koch. And for the past 17 years, I've been working for MEMIC as a safety expert within the hospitality and construction industries. What I realized over that time is that safety impacts every part of each position you have or tasks that you do. So, bear with me. I need to exorcise a demon here. So, who would have figured that simply working at a desk would be so bad for you? We've even talked about the hazards of sitting in a previous episode up your need with Al Brown, so check that out on MEMIC.com/podcast. But what the heck happened to us? Sitting down used to be a break, a relief, a reward at the end of the day. But now for many workers, it's a possible vector for musculoskeletal disorders. Get up, drive to work, sit at work, sit at lunch, drive home, sit down, watch TV. A pain in the back, pain in the neck, down the leg, in the wrist that leads to poor sleep, contributes to poor posture, and the cycle just continues. It's not so much the sitting as how much we do it and how we sit and how our workstation is setup. So, on today's episode, the ergonomics in the office episode, I'm speaking with Maureen Anderson, a safety consultant with MEMIC, to better understand what ergonomics is and how it impacts our business. So, Maureen is a certified professional ergonomist and has been helping businesses get a handle on the workplace risk factors for more than 20 years. So, Maureen, welcome to the podcast. Maureen Anderson: Thank you. Peter, it's an honor to be here. Peter Koch: That's awesome. So, we're gonna jump right into it. So, what does it mean to be an Ergonomist? Maureen Anderson: OK, an ergonomist is not a doctor. It's not a physical therapist. When I go out, I am looking at the environment, the environment the person is working. And what I'm trying to do is trying to match that environment to a person and to see what I can change in the environment to optimize the work of the person. So, when I go in someone says, you know, I have carpal tunnel or something like that, I can't fix their wrist. I'm not a doctor, but I can try to see what I can do in that environment to either prevent them from worsening the condition or allowing them to have time to heal. But I do not physically fix them like a doctor would, I can't prescribe, I can't do that. I am all about the environment. Peter Koch: Ok, so really, when we look at your certification as an ergonomist and then looking at ergonomics being that study of the person's efficiency within the work environment, and how to fit work to the person. Maureen Anderson: Yes. Peter Koch: What are some of those short-term effects that you see of a poorly designed or poorly fit workstation? So, what are the short-term effects? Maureen Anderson: Oh, my goodness. Where do you start? So, when I said I'm just looking at the environment, I'm looking at sort of the match between the person and the environment and how the person interacts with the environment. So, when the environment does not fit a person, a person will often adapt what we call awkward postures. Right. They are not working in an optimum way. They're slouching. They're leaning. They're compressing, pressing onto things. So, in the short term, what I'll generally see are aches and pains. Right. That's your body telling you that something is not right. It is a way that your body is complaining to you. And when the problems start to rise, the complaints start out pretty polite. You know, a little bit of discomfort, you know, maybe you're just move your shoulders a little bit. But if you ignore those messages over time, those complaints, those cries for help are going to get louder and louder until you end up with pain. Pain is that scream from the body that you need to do something, and you need to do it quick. Peter Koch: So that the stiffness that you might feel after sitting at the workstation for a little while, your shoulders get little stiff, your eyes might get a little tired, your wrists get a little sore. That's the short-term effect. Maureen Anderson: That is the short term. And that's the easiest time to do something either. I don't know if I'm jumping off topic, but, you know, stiffness, if you just get up and move a little bit and get the blood flowing, that's going to help that. OK, that's going to get the blood flowing and really help you, but if you then go right back to a poorly designed situation, those symptoms are probably going to come back. So, if you can fix the environment at the same time, the person listens to your body. You're going to get a much better result, a much better fit. Peter Koch: Ok. So in that poorly designed workstation, when you have someone who is adapting to that poorly designed workstation and you're looking at the person and you're looking at the environment, what are some of those risk factors that you might be looking for that are going to show up with that complaint later on? Maureen Anderson: Right. Peter Koch: The cause of the stiffness possibly. Maureen Anderson: Probably the first is awkward postures. So, we start out with what is good posture and we usually talk about the neutral posture and that is standing. The ears are in line with the shoulders so that your head is supported. There's no bends in the wrist. OK. So, anything that is away from that becomes an awkward posture. Coupled with that is what our static postures. So even if you had perfect posture and you were standing up and that sort of military upright posture, you know, absolutely wonderful posture, if you do that for a long period of time, that becomes a problem because human beings have evolved to be dynamic, to move. We do not handle being in one position all the time. No changes. So those are probably the two dominant ones, awkward postures and static postures in the office environment. Peter Koch: Ok. That’s good. So, let's think about neutral posture for a minute, and so take me through how you would put somebody into neutral posture. So, if I'm at the workstation and you describe some of those parts, but what do you do first to get into it, to get to feel what neutral posture would be? Maureen Anderson: Ok. So right now, you're talking about. If I go and do an office evaluation. Peter Koch: Well just right now, so let's talk me through. Maureen Anderson: OK. So right now, you would be a closer to a neutral posture than I am because number one, I'm seated. OK. So, seated takes you out of the neutral posture. You lose some curve in your back. That puts a little more pressure on your back. So, a neutral posture would be standing posture. OK. As I said, the very important to have the ears in line with the shoulders, the head upright. OK. In a neutral posture, your arms are by your side. Your palms are facing inward, OK. Or a slight turn, about a quarter turn to the back. Often when someone is seated at a desk, they're seated. So, we have the back issue and then we put a bend in their arms and then we also twist them. Right. Peter Koch: Palms down instead of palms... Maureen Anderson: Yeah, pronate them. Right. We put them pronated. So, we've got a whole bunch of issues going and we talk about the angles and dangles. So now all the muscles, the tendons are all pulling at different angles and that greatly changes the force requirements for doing work. Peter Koch: Oh sure. So, in a neutral posture, we're supporting more of our body weights through our skeletal system than relying on our muscular system. Which will tire over time. Maureen Anderson: Right. We are allowing gravity to do its work on our skeleton, our skeletal system. Right. Peter Koch: Very good. So, in a neutral posture than just thinking about it, if we can kind of take our listeners through this. So, from a standing posture, stand up tall, chin forward, try to keep your fingers and shoulders in line and then shoulders and hips and in line. Maureen Anderson: Yes. So, we do spend some time talking about the neutral posture. But I have not met anyone who works in the neutral posture at this point. Right. Peter Koch: It's hard to stay there. And I think part of that feeling, if you could get into neutral postures and even if you're seated listening to this in the car at the dinner table. Maureen Anderson: Right. Peter Koch: Just try to stay in that neutral posture for a while. It can't be tiring. Maureen Anderson: It's tiring. It is very tiring. And there's things like locking your knees. A lot of experts on say don't lock your knees. But if you ever tried to stand for a long time and not lock your knees? It's exhausting. You wouldn't do it. Everyone locks their knees when they're on their feet for a long period of time. But as I said, no one works in a neutral posture. There's not a lot of call in this world for well-paid jobs, for people just to stand up straight all day. I wish there was. But most people have to perform tasks at work and perform work. And that's OK, because we deal with change really well. So, moving doing tasks like that is great. But the modern office environment, we've done so much now to get people sitting in front of a computer and not moving. And that's where the problem comes up. Peter Koch: So that's the key piece. That's not just awkward or being in neutral posture. And it's not just being an awkward posture, but it's. Maureen Anderson: It's the static statics are a problem combined with the awkward posture. I'd rather see someone sitting at their desk, slouching, crossing our legs, fidgeting, leaning on one elbow, but moving rather than the perfect, rigid, upright person, 90-degree angles like you see all the pictures. Someone doing like this and sitting there all day never moving. I'd bet they would probably have more aches and pains than my fidgeter. Peter Koch: I could see that happening. So, the risk factors that we're looking for in office ergonomics initially are the largest ones for contributors would be static postures or static awkward posture. Maureen Anderson: Yes. Peter Koch: Would be... Maureen Anderson: Yes. Peter Koch: ...the challenges, but then you also have force and pressure. Maureen Anderson:  Yes. My asking people like leaning on hard edges and compressing, cutting off blood flow, potentially compressing nerves. Usually it's leaning on the hard edge of a desk. We see it sometimes in drivers with leaning elbows onto windows, you know, doing this for a long period of time. Backs of a chair that are digging into the back of a knee and potentially cutting off circulation. So that compression would be another risk factor that would cause problems. Temperature, cold temperatures hinder blood supply. So, people working in very cold environments on Hinds will have issues. Not so much in hot environment, it's more the risk of dehydration, but from an ergonomic perspective, we see more problems probably in the cold. Not usually a problem in most offices, though I will tell you when I go into an office, probably that is one of the most common complaints I hear is the temperature of an office. I'll have two people sitting, you know, cubicles or desk next to each other. And one person is telling me it is frying hot in here and they are sweating all day. And the other person is telling me it is so cold. Their fingers are going numb. They can't feel their fingers. It's so cold. So, temperature is one of those risk factors. That interplay is with a whole bunch of other factors. Peter Koch: Sure. Because it changes circulation, which causes issues with static postures, and then on and on. How about lighting in the office? Can that be an issue? Maureen Anderson: That's also another common complaint that I get in the office. The overall trend in office lighting is to less overall light and more task light. You don't need a lot of light to talk to someone. OK, to look someone in the eye, to have a conversation. You really do not need very much light. As many people in the romantic world know. Candlelight is wonderful for that. But to do an office task like if you have to look at small text like a spreadsheet or something. Print out. The finer the task, the lighter you need. So, we try to get offices to put the light where you need it. A lot of people are bothered by really bright lights the whole day long and we are seeing increases in eye fatigue and dry eye. I think the dry eye might be a little bit more complicated. That's a lot newer research coming out about looking at computer screens. We're kind of at the first generation now that has worked in front of a computer screen their whole career. Peter Koch: All the time. Yeah. Yeah. Maureen Anderson: So now people have been working with computers, you know, 40 years staring at a screen and we're seeing a lot more dry eye. You blink a lot less when you look at that. It's direct light into your eye. Some people say the blue light spectrums think there's a lot more research that needs to be done there. But just out in the field, I am hearing that. Peter Koch: Yeah. Yeah. Interesting. And is very two dimensional as well, where if you're doing something at a desk, you have the three-dimensional effect of a pen or a pencil, the paper, and you're constantly changing the... Maureen Anderson: You're changing your focal distance all the time. So, you're looking at close far, you know, small changes. But when people are at a computer screen, you know, it's arm's length away, you know, 20 to 24 inches. And they're looking at that focal distance all day with very little interruption. And that can be very fatiguing to the eyes. And it's interesting because that distance, that arm's length, I would think it's kind of interesting that comes from resting focal distance. If you're to close your eyes in a completely dark room and let your eyes relax and they flick on the lights. That's the distance you would be focused on. No kidding. Yeah. So resting eye accommodation that they think comes from, you know, cavemen, people coming up to attack you. You have to be able to defend yourself at an arm's length. Peter Koch: So interesting. So not even just to learn peace, but over almost an evolutionary part for us, which is... Maureen Anderson: Right. Peter Koch: We are changing, or you know, we've have to think about it. If I'm working at my desk, I'm close to an arm's length if I'm seated in a relaxed posture. Yeah, but if I'm looking at a computer screen, I know I've seen people that are leaning the way in. Maureen Anderson: Yes. They're trying to get their eyes a lot closer. Yeah. And then we also have in the office world, frankly, most people wear some type of glasses these days, too. Right. So, we have the basics and then we have this other tool that sits in between it. So, you have to accommodate for that, too. A lot of people use readers, drugstore readers, which actually are designed for a focal distance of 10 to 12 inches, like you're holding a book and a computer is a little bit further away. So often what I'll see when people are wearing those, you know, the Dollar Store readers is they are leaning forward either like this or like that, trying to get into that 12-inch focal distance. Peter Koch: Sure. Maureen Anderson: They do make computer readers. They're slightly more expensive. You can get them at a lot of dollar stores and drugstores and those have the focal distance of the 22 inches. Peter Koch: I think it is interesting. So, I have progressive lenses that I wear. Yeah, well I have to because otherwise I have to... Yeah. Well that's a whole other story. Maureen Anderson: Yes. Peter Koch: So, for me to work in front of the computer, I actually have a pair of glasses, prescription glasses for my script that is... Maureen Anderson: Yeah. Peter Koch: ...That computer distance away. So that's interesting. I just thought it was I did it because it was the best way for me to be able to see the whole screen instead of looking through the section of my glasses that are there, which caused me to have awkward posture. Maureen Anderson: Yes, it's very common. I got my first progressive lenses this year and I couldn't adapt to them. I don't even use that. That's a terrible thing for an ergonomist to say but had to do with astigmatism that they're correcting for, that every time I turn my head, I felt like the whole world was spinning with me. I need to go back and do something about those. But yes, if you wear a progressive's or bifocals, often the monitor has to be lowered and angled because that tool, those glasses, are assuming you're going to be focusing at something down here. Keep your distance vision is right at eye level. Peter Koch: Excellent. OK. So, we've talked about the risk factors a number of risk factors. So, we have lighting is a risk factor. We have awkward posture, static postures. We have pressure... Maureen Anderson: Force. Peter Koch: ...Force and pressure, reaching. Maureen Anderson: And repetition that often comes up because, gosh, when was it back in the 80s and 90s. Carpal tunnel was a huge thing. And it's interesting that we don't see as much of that anymore, though. It's still out there. People assuming that it was all the repetition in the fingers from typing. Turns out the hands do handle repetition very well. I mean, we can kind of type along fairly well without having problems from repetition. But when you combine it with a bent wrist, increased force deviation like this with the risk, then we don't handle the repetition as much. NIOSH at one point put out some guidelines for repetition that were never really adopted. They kind of died on the vine for political reasons, I think. Saying that, you know, the repetition for hands would be around typing 90 words per minute your hands can handle, it was like, 200 exertions a minute. But when you get into something like your shoulder then it's only like three times per minute before it becomes problematic. Right. So, our shoulders do not handle repetition as much. So, what we're finding often with a computer, sometimes it's not the typing, but sometimes it's that reaching to the mouse. OK, especially, when the mouse is at a distance. So now we're getting some shoulder exertions and elbow exertions that are going on quite frequently, some typing mouse like that. And so, we do see some problems in the elbow and sometimes the shoulder and sometimes even down into the hand. Peter Koch: Now, that makes a lot of sense. OK, so we have awkward postures at our workstation. We have odd reaching postures, pressure, lighting, and our body tells us that we are having an issue, stiffness, a little bit of pain. But if we ignore those and we just keep on going. So, what are the long-term implications of having those risk factor or engaging in those work factors or risk factors within the workstation? Maureen Anderson: Ok. So, the long-term effects can be permanent damage to the nerves. OK, muscles heal fairly quickly. So, stiffness and muscles you usually can do something about. But when you don't address it, sometimes you can lead to damage. In the nerves and in the tendons and in the ligaments, ligaments take an awful long time to heal. Nerves essentially do not heal. OK. Once a nerve is damaged it's kind of done. Fortunately, in the human body, we have a great system with so much redundancy that the nerves of the electrical system, they can reroute usually, but you can get to points where you have done so much damage, it cannot be repaired easily with today's technology, which is always changing. So that's really where you're getting into some of the long-term effects. There's other things like from prolonged sitting and lack of movement, you know, your blood chemistry starts to change and that can lead to increased risks for heart disease, even some stroke and things like that, the DBT, the blood clots in the legs and things like that. So those are all long-term effects that you don't want to deal with. Peter Koch: Yeah. Interesting. So, something as simple as again, sitting at the desk in the office. If we ignore the effects that a poorly designed workstation might have or even if it's a well-designed workstation and we're engaging in it poorly because of our habits. Maureen Anderson: Right. There's always that. You have the environment and you have the person and you have the behavior. So, you can have the perfect environment. You can have the perfect five-thousand-dollar office chair. If you sit there all day and never move, you're going to end up with some problems. Peter Koch: Have you seen that? Have you seen a really well-designed workstation and the person's just still having issues at it because of just the habits, the postural habits that they've learned over time? Maureen Anderson: Yes, I do. I see people with a lot of habits. I'm seeing actually sometimes people don't have the issues yet. And that's always a hard thing for me to deal with. I'll see generally a younger person I'm gonna pick on a young male that I worked with once who tells me he is perfectly comfortable, and he is working what I call kind of the gaming posture. Hard to demonstrate in this chair, slouched back like this as if they are gaming on their computer and they tell me that this is the most comfortable way for them to work. They're not having any issues. And if I try to make them sit up, they say this is uncomfortable. I can't work that way. And that's a really hard thing to do because I feel I work in the prevention business. I want to prevent injuries. So, when you go when you see someone like that, I'm thinking, no, you're not having any problems because you're 22 years old. You do this for another, even 10 years in your early 30s, you're going to be feeling it. Probably the first place is gonna be up on their neck because there, when they're doing that, they have poor head posture. So, yeah, that's the issue. Peter Koch: Let me just describe that that gaming posture that you had there. So, it's not a typical office posture that you might have, but we do see it. We see it all the time in offices now. Yeah. It's become more and more prevalent because of the habits that they have when they're outside of the office, so they are bringing that in. So that gaming posture that you describe as slouched down low in the chair, hips very forward on the seat pan that they have. Maureen Anderson: Arms up high. Peter and Maureen: Arms are up high, neck forward and dense and... Maureen Anderson: Sometimes support and sometimes not. Peter and Maureen: Yeah. Maureen Anderson: I think sometimes people do that not only from gaming, but also because of laptops. And I think in schools, in college, a lot of people are using laptops only. And so, when you have that monitor so low and the keyboard there, they're sort of adapting to it by get either going like this or going like that. Peter Koch: Sure. So, hunching forward or leaning backwards. Maureen Anderson: Yeah. And in an office environment, we like to say we're a little bit more evolved. We have docking stations or external monitors, external keyboards so that we can adjust more to the human body, how it's designed. Peter Koch: And so very interesting, too. So, the habits that people bring with them can really even overcome good workplace design. Maureen Anderson: Yes. Yes. Certainly. Behavior is Huge. And how people choose to use it. Peter Koch: So, I think going back and just considering that in that the first item we discussed was neutral posture. So, understanding neutral, not necessarily being able to work in neutral posture, but understanding what neutral posture looks like and then how far you deviate from neutral posture in your work posture can then help you understand the effects of that work posture over time. Because if neutral posture is going to be the best overall, not from a fatigue standpoint, but actually from a support standpoint. Maureen Anderson: Right. Peter Koch: Using the body dynamics and structure as it was designed, then I can look at it. And so, if I work out of neutral, I need to make sure that I only do that for so long before I change the posture into another posture that could again be neutral. Maureen Anderson: We always say around 20 minutes; you should be changing your posture every 20 minutes. And so often in an office environment I try to set people up to neutral as close to neutral as I can get in a seated posture as the kind of starting posture, so you get people, give the people opportunity to have that posture, and then if they choose to slouch, to go back, to change it, at least in theory, they will come back to that neutral in between those other postures. We often talk about comfort postures, things like people crossing their legs. And, you know, a lot of research will tell you, oh, people shouldn't cross their legs. That's not good for the circulation in the legs. But I can tell you, there's almost no way you were going to change those comfort postures, especially when people are stressed, they revert to them. They're going to cross their legs. You know, they're going to chew on their fingers. They're going to do what they're going to do. So, I would much rather tell people it's OK to do that limit it to 20 minutes and then switch to a different posture. So, if you're gonna cross your leg, that's OK, but you only do it for 20 minutes. The dreaded one is people sitting on one leg, which is more common amongst women. That they'll kind of curl one leg under them and sit on one leg and it's usually always the same leg. So, I tell them again, 20 minutes, then you've got to switch to something else. Peter Koch: Interesting. So, let's think about this. So, before we get into how to change the workstation, let's talk about what someone can do besides changing the workstation. So, if I if my body's telling me that, like I'm stiff and I'm a little sore or I'm tired, I'm fatigued, what can a person do at their workstation to combat some of that besides changing it? Maureen Anderson: Right. So, the movement is probably the biggest one is to change your posture, to probably stand up, perhaps reset your back by going into a slight back extension. I mean, we love it if people do stretch programs, but it almost doesn't matter which stretch you do in a lot of ways. I think it's the fact that you bring that attention back to yourself. You've thought about your posture because that's what you're thinking about when you stretch it almost to sort of just resets the person. So, I also believe in compromise. A lot of times people say we don't have time to stretch. And I'm like, well, you might have time to do five shoulder rolls. You know, that's five seconds. And you can be talking on the phone at the same time. You can be thinking about what you're doing, but you could do five shoulder rolls, and something is infinitely better than nothing. Peter Koch: Yeah, very true. Maureen Anderson: So, to do some kind of movement, it's probably the number one thing that you can do. Peter Koch: Ok, so, yeah shoulder rolls would be a good one, even just standing up if you have to answer the phone instead of staying seated while you answer the phone. Maureen Anderson: Yes. Yes. We used to give that advice. We still do sometimes that, you know, if you can just stand when you answer the phone to say hello. Hello, Maureen. This is Maureen at MEMIC. And then you can sit right back down. Even that couple of seconds can really be good. But also, just standing and sort of gently taking your back into extension, that can be really good for the back. Peter Koch: Excellent. Peter and Maureen: Yeah. Peter Koch: So, any kind of movement and activity at the workstation can help combat, maybe not overcome, but they can combat some of those awkward postures from starting postures. Maureen Anderson: In ergonomics we talk about reengineering as the change. And then what you can't change, then how do you sort of adjust to accommodate it? And that's usually what we're talking about in movement. So, if you can't change your workstation, you know, then you can change your habits, your behaviors. Add a little bit of movement. Stand up. Talk to somebody. You know, I love to see water bottles on people's desks or big coffee mugs because I know they have to get up to get the water in. They have to get up to get the water out. So that's going to promote some motion. There's a movement in the office place just by having that. Peter Koch: And certainly, hydration overall. Maureen Anderson: Yes, hydration is good. Yes. Peter Koch: Very. And even outside the ergonomic part, hydration helps with cognition, helps with focus. Helps you. Helps your brain activity in your body activity. So, hydration and health go hand-in-hand. So... Maureen Anderson: And so, does movement. I mean, they've done research. I think it was on rats navigating mazes. And if they put the rat on a little exercise wheel for, I don't know how long it was, I forget all the details, but like 20 seconds, then they would navigate the maze more than 20 seconds faster. Right. So would make up for that little bit of motion. Peter Koch: Interesting. So... Maureen Anderson: Not that we're rats in mazes, but... Peter Koch: No, but when we think about it. So, brain activity, which is essential for all of our work, no matter how monotonous it is or how high stress that job might be, brain function is critical to all of that. And hydration and nutrition motion, blood flow... Maureen Anderson: Yes. Peter Koch: All help with that. I was listening to or I read a study somewhere that said that the brain consumes somewhere around 50 percent of. The calories taken in during the day just for brain activity. I might be a little off on that, but a lot more than you would think, considering that it is a very small part of the overall body mass. But it consumes a lot of energy. Maureen Anderson: A lot of resources. Peter Koch: A lot of resources. Maureen Anderson: Yeah. Peter Koch: So, if I'm just static sitting there, it's kind of like standing with your legs locked. Maureen Anderson: Yeah. Peter Koch: A neutral posture for a long time. I'm burning a lot of calories to stay in that position, but I don't have a lot of demand for oxygen. So therefore, I'm not as efficient doing it. Maureen Anderson: Yes. Yes. And I was just going to talk about when people talk about dynamic workstations and standing. We do know in the applied world that if you're doing real heavy cognitive lifting, really difficult tasks, most people will prefer to sit because I think their brain needs a little bit. So, I tell people when they're first moving into dynamic workstations, make sure you use it for all those routine tasks. That's why I tell people sometimes leave it in the up position when they go home, because usually when people come to work, the first 15, 20 minutes are, you know, firing up the computer, checking the e-mail, checking the schedules, all those routine tasks. And if you can stand during that, that's usually pretty easy. But if you're doing really tough, difficult tasks and what's difficult for one person, it's not difficult for another person. And when people are starting a job and learning, everything is difficult. So, all those things are going to change over time. Peter Koch: Very good. Hey, we're going to take a quick break. So, we're going to continue with more discussion here with Maureen, but we'll take a short break and we'll be back in just a moment. Maureen Anderson: Ok. Peter Koch: Welcome back to the Safety Experts podcast. Today, we're talking with Maureen Anderson, safety consultant and certified ergonomist at MEMIC. So, let's jump back into more questions, Maureen. So earlier we were discussing how your workstation, or your desk setup can affect you, those short-term effects, some of those risk factors. And we also talked a little bit about what you can do at your workstation to combat some of those risk factors or those early warning signs that your body's providing you with. To tell you, to start moving. But let's talk about what you can do to change your workstation. So, as you come into an office and you're looking at an office setup, what do you look for in the setup itself and how the person's interacting and what things might you change in that workstation? Maureen Anderson: Ok. I'll sort of walk you through how I do a workstation evaluation and everyone or other ergonomists might do it slightly different. So, when I go in, what I like to do is take a picture of their posture. OK. The first thing I'd like to do is I say, show me your how you would send an email. OK. And then I take a picture. Now, a couple of things happen with that, is one, whenever you put a camera on someone. They show you what they think they want to show you. And that may not always be the truth. So, I will generally, though, start with that picture and then I'll ask them what's going on. And the other thing I've learned from people over time is they're going to tell me what they want to tell me, whether I let them or not. So, it's best just to get it out in the open right away. So, someone might say everything in here is fine, but this rug is really bothering me. And if I don't let them get that, we are gonna be stuck on the rug the whole evaluation. So, it's best just to let people have their little free for all. Tell me what's going on. They often do know what's going on better than I can know in a few minutes of watching. So, they will give me a lot of good information. When I first started doing evaluations, I would use a checklist method to do an evaluation. The wonderful thing about a checklist, it makes it very thorough. It reminds you of all those things, so you don't skip a task. Maureen Anderson: So, I would use a checklist and I would go through and would measure the height of their tasks, the distance of their monitor, information like that. Generally, I might note about if height was an issue. For instance, I evaluated a woman who is four foot nine yesterday. So, I would note that in my notes and then I would try to get all the measurements of that person. Maureen Anderson: I might look at their seated elbow height. That's when their feet are flat on the floor. So, I adjust the chair, so their feet are flat on the floor. And then I would measure from the floor to the bottom of their elbow to get that height. I do that without looking at the computer because it may be different than how they are set up when they're at the computer. Peter Koch: So why is that important, that seated elbow? How do you how does that factor in? Maureen Anderson: Because your elbow height should be approximately the same height as your keyboard. OK. So, if I get a seated elbow height, let's say it's 26 inches and then I have them turn and go back to the computer, but I already know their desk is 29 inches. I know that there's a disconnect there, and so then I want to see how they're adjusting for it. It can be either they're hunching their shoulders up to get their elbows higher or it could be that they're pushing things further away. Because when you extend your reach, your elbows come up. So, I like to have that information because I already know that there's a disconnect there between the two heights, but I want to see how they're adjusting to it. Peter Koch: So, you're looking at... initially you're looking at the person and how... Maureen Anderson: They're interacting with their environment. Peter Koch: How they're interacting with their environment before you actually look at the environment to see how it affects them. Maureen Anderson: Yes. Yes. So, I usually start with the person get sort of a basic overview of the person. And then I'm starting to look at their environment, getting the lay of the land, so to speak, and then also the whole time we're sort of talking and sharing information about what they do. For instance, often there's some physical complaint. They may say that, I don't know, their shoulders are really achy. Only on one side, let's say their right side. So, you know, I may ask are you righthanded or lefthanded? You know, what else do you do in your day? They may say that they are scanning documents and feeding pieces of paper into a feeder for three hours a day. And they're doing one every second or something like that. So, I'll try to find out what else they do in their day, because those are also contributing factors. My job is to look at the work environment, but sometimes they will share information about what they do outside of work. Sometimes that's just more of an FYI, if we're looking at something that may be a repetitive issue and they tell me there are into competitive crochet or something like that, that's highly repetitive, I may note that down. But generally, that's not really a concern of mine. What they're doing outside of the job, I'm looking at the workplace. Peter Koch: Sure. But it might even make what they're doing outside of work. My highlight for you to them how important it is for them to move more to keep it set up more correctly, because the risk factors outside of work can challenge the risk factors that work. Maureen Anderson: Yes. Yes. Peter and Maureen: Enhance them or make them worse. Maureen Anderson: I will tell a little amusing anecdote about a gentleman I evaluated once and he had really terrible posture leaning on to his elbows like a 45-degree forward bend, really onto his elbow, everything down low. And I was like, wow, you know, this is interesting. Why do you do this? And he said, well, he was a triathlete and he used aero bars on his bike where he's really hunched forward like that. And he said he's training himself at work to hold that posture for a long time to help his triathlon performance. I was like, well, I really don't think that's going to help. I think it's actually probably going to hurt you to be in that posture for hours and hours a day and then to get on your bike and continue to do that awkward posture all that time. And I said it's different when you're on a bike, you're pedaling, you're moving. You have a lot of other things going on. So, I felt that was a little bit misguided of him. But we had a little chat and I'm not convinced that he's probably still not doing that. But that gets back to behavior. I only can do what I can do. I can make recommendations. I don't have a whip. I don't use a cattle prod to zap people when they are doing things they shouldn't be doing. Peter Koch: Certainly. But in a just a brief Segway, though, you hit on a really important point, that post evaluation, when the recommendations come back and whether it's a change in the workstation or it's a change in behavior that the employer has to hold accountable the employees for doing this, because I mean, it happens often that people will try to do things at work that will, in their mind, help them in personal activities. And that's sort of an extreme example you brought up, but I think it can be applied in other areas. So if the recommendation is to change your posture frequently at your workstation, then the employer's supervision has to be there to help hold those people accountable to do that, because at some point in time, those static postures, regardless of when you do it, will be harmful to you over time. Maureen Anderson: Yes. Yes. I don't know how you could... a lot of this we are talking about people changing behavior, and that is the hardest thing to change. And I don't know from a worker's comp perspective, even how you hold people entirely responsible for behaviors. For instance, someone who does static posture all day and then is convinced that they're so busy that they need to eat lunch at their desk while doing tasks. Right. So, they're not ever taking any breaks. You know, there's a personal side to this. They really do need to take those breaks. Their employer needs to set up an environment, I think, where they're encouraged to take those breaks. But I'm not sure. As an employer, how you would force someone, do you take away their chair from twelve to one every day? Peter Koch: No, but I think you did hit on the three components that are in any performance management formula. Even when you look at it and you start to think in order to have some sort of performance, you have to have motivation, opportunity and ability. So as the employer you can affect motivation by education. Maureen Anderson: Yes. Peter Koch: You can affect opportunity like here at MEMIC inside the office, there's a stretch break that happens. It gets announced. And from a supervision standpoint, I know when I was working more in the office instead of out in the field, that when this the supervisors and the management team got up at the stretch break. Maureen Anderson: Yes. Peter Koch: And we all got up with them. But if they didn't, we didn't all tend to come out of our cubicles. So, it's an interesting piece of there's a little bit of motivation, opportunity provided, an expectation provided by the employer. Peter and Maureen: The expectation that, you know, that they get up in the cafeteria or eat in the break room or don't sit during all day and never take any breaks, because people think that that's going to make them seem like they're working harder. But it's really not a good way to be. Peter Koch: Very good. Peter Koch: So, let's continue on with the workstation evaluations. Maureen Anderson: Yes. Peter Koch: You were looking at the person. You had that seated elbow height measurement. Maureen Anderson: Yes. Peter Koch: Which then is important because it is in how it interacts with... Maureen Anderson: The keyboard. Peter Koch: The keyboard and the desk that they have in the mouse and then everything else that's on it. So, after the seated elbow height measurements and you're starting to get information about what they do, how they do it, how often they do it complaints that they already have. Where else do you look? Maureen Anderson: I look at the monitor height. The top of the monitor should be approximately eye level. OK, unless they are wearing glasses like progressive's or bifocals and then it may be lower. The distance should be about, we say, arm's length. But again, everyone's vision is different. And I have had people who like it a lot closer. I've had people who have it to me what seems freakishly far away. But they insist that that is the distance that works best for them. And they want what they are showing me is basic good head posture. So, I have to, you know, believe them. Peter Koch: And they're not having complaints that would associate distance... Maureen Anderson: Yes. Peter Koch: For that complaint as being one of those factors that would cause something. Maureen Anderson: Right. I look at their wrists. I'm trying to get as close as I can to sort of a straight wrist. No bends up or down or deviating off to the sides. Then, I look at the mouse use. The mouse is one of the evilest devices ever invented by people, I think, as it causes so many problems. I'm looking at the mouse placement, the mouse over time and often will walk further away. I don't know why that is, but I'll see people with a very long reach to their mouse. So, I'm trying to keep that mouse kind of in close. What we're trying to do is most frequent tasks go to sort of the windshield wiper zone in front of them, about 10 to 12 inches away from their torso. Trying... Peter Koch: So, if you think about that, if I am standing at my desk from the sort of the center of my torso, I should come out 10 to 12 inches in an arc... Maureen Anderson:  In an arc, right. Maureen Anderson: So, it allows you to do your motion while keeping your upper arms kind of close to your body. Peter Koch: And so that would that 10 or 12 inches would be where with my elbow right down on my side. Maureen Anderson: Yes. Peter Koch: Reaching out to my desk. And then if I move my hands to the side, that's that arc that we're looking at. Maureen Anderson: Yeah, the windshield wiper. Now, I will say there are some slight changes for that. I do see for women with large chests often that 10 to 12 inches is too close. So, they may need to be a little bit further. It's just the way they're built... Peter Koch: Or men with large torsos as well, women with large torsos depending on stature. Maureen Anderson: Yup. Differences in stature, that may not work. That is a rough guideline. You know, in rough guidelines that are always meant to be adapted or changed a little bit. So I'm looking sort of for the hand posture and I'm looking at the shoulders distance, the reach distances, I'm looking at head posture a lot and really trying to keep people to keep their head in a good posture because that causes such havoc up and to the neck and shoulders. Often when I see people using the telephone and they do what we call cradling, they're trying to hold the telephone between the ear and the shoulder to use both hands on the computer. That, if you do that for more than two minutes at a time, that's considered a risk factor for neck and shoulder pain. Peter Koch: How come? Maureen Anderson: Well, you have the mass of your head that 12 to 14 pounds, which is tilted off its axis, and that's a problem. You're hitching your shoulder up, which takes a lot of muscle activity, and then you have a hard piece of plastic pressing into the soft tissue of your shoulders. So, it's just kind of wrong, wrong, wrong. Usually it causes problems on that side of the shoulder, but sometimes on the neck, on the opposite side can be affected. Peter Koch: And then you're trying to do fine motions either with keyboard or pencil at the same time. Maureen Anderson: Yes, at the same time. And so that can carry all the way down through your hand, down into your hand and into your fingers. So, yeah, it can cause a lot of problems. Peter Koch: And of course, if you do it once, not a huge issue, but it's doing it multiple times throughout the day. Maureen Anderson: And I will have people tell me, oh, I do that for, you know, an hour when I'm on the phone for an hour. And basically, I can tell you there's no way you could hold that posture in a static way for an hour. I don't think a human is capable of that. So, what they're doing is they're doing that and then they're having either to switch it to the other side or they're going to have to take it out. But that is a big risk factor. So, when people do that, I tell them you need to use the telephone headset. And some people are very adverse to a telephone headset because of the quality of sound. And I will tell people the quality of sound has improved, or they're just not used to the whole, I don't even know how to explain it.  With a telephone headset sometimes, people can't tell and they're talking on the phone, and they're dealing with a lot of other people interrupting, and they haven't developed sort of the body language to I tell people I'm on the phone, please don't interrupt.  Though, they do make little, you know, light up tools to alert people. So, I tell people to use a telephone headset or use speaker phone or just use the phone and hold it in their hand. Peter Koch: So that's interesting. I know one of the, well the local automotive shop that we use the receptionist as you walk in the door, the receptionist is right to the right and she has a little light on the counter and there's a sign that says if the light is lit, I'm on the phone. Maureen Anderson: Right. Peter Koch: And it helps her because she's got a headset and five or six years ago, she was one of those that would cradle the phone between her shoulder and her head and then they ended up getting her the headset and she's much happier. Maureen Anderson: Yes. Peter Koch: But it was a habit changing piece and the reason that she struggled with it was just what you said was there is that demand between productivity and the quality of service that she wants to provide both to the customer on the phone and the customers in there. Maureen Anderson: Yeah, and the other issue often is whether they're wireless or not, whether they're tethered, because some people are just so used to jumping out of their desk and running over to here, and if you've got that leash on you, that can take a while to get used to. But even at MEMIC, you know, not receptionists, a lot of people where telephone headsets. And when you walk up behind them, depending on how, you're never sure if they're on the phone or not. Right? So, you're always it makes you very tentative, you know, are you on the phone, you know, trying to figure it out. But most people master, you know, putting their hand up in some signal to say, you know, please don't interrupt me. Peter Koch: Yeah, interesting. Maureen Anderson: So, it takes a little while to get used to. But that's a great, great office tool. And certainly, with cell phones, we're going that way that people should be using headsets or hand free for everything. Peter Koch: For everything, for sure. Talk to me a little bit more about how evil the mouse is. Maureen Anderson: Evil mouse. Well, I already talked about neutral posture. So, when you bring your hand up to use the mouse and you pronate it down to use the mouse... Peter Koch: Palm down. Maureen Anderson: Palm down, right. A lot of mice, some of them are very small and people use a lot of grip to hold them. They will often grip it between their thumb and their pinky, which can be a very fatiguing grip for the hands. And then also couple that with the external rotation in the shoulder. So, they're kind of reaching off to the side and trying to use their mouse. So, it's almost as if their arm is held way out to the side to use their mouse. Ideally, that mouse is used as a straight line from your shoulder, okay? It's partially it's the design of the keyboard. We have those, the ASDF keys, all the alphabetic keys, which are right in front of you, and if you took high school typing, those central keys should be lined up with your belly button. But the design of the modern keyboard, you have the keyboard, then you have a numeric keypad and then you have your mouse. So that mouse ends up being way off to the side. So sometimes we'll recommend people using their non dominant hand, usually they're use the mouse with their left hand, and most people find that very difficult unless they're in pain. Pain is an incredible motivator for people to change. I myself have tried to left mouse and I could never stick with it. It interrupts your whole cognitive flow. It takes so much attention to use the mouse. It's like I can't think about what I'm trying to mouse to. So, I have a keyboard where the numeric keypad is on the other side. It's called a mouse friendly keyboard. And that allows me to have the keys directly in front of me and my mouse a lot closer. It was easy for myself to train myself to use the numbers with my left hand, already type with my left hand. I can type, touch, type with my left hand. It's a task I can do. So that's one way to approach it. Or some of the keyboards have a detachable numeric keypad and then you can put the mouse and then the numbers way off out at a reach. If you don't use the numbers that often or you can move the numbers either away, if you don't use numeric keypad, or off to the left. Peter Koch: Sure, sure. Maureen Anderson: So, there's ways to do it. Or there is a bar device that goes in front of the keyboard called the Contour RollerMouse, which replaces the mouse. And we've had a lot of great success stories with that task. It's pricey, though, so a lot of companies don't like to go there. They only go there as a last resort. Peter Koch: And with anything else, that change takes time to incorporate into your workflow. Maureen Anderson: Yes. Peter Koch: So, the mouse being challenging because it causes you have to use… or many people will use increase pressure because of the side, which puts that static posture again. Maureen Anderson: They'll hover a finger sometimes over the top button, so they'll be hovering, and so they're sort of holding that finger in contraction for long periods of time. They don't realize it. If you're not doing something with the mouse, you really don't need to be hovering your fingers, you know, at full attention. Peter Koch: I was in an office setting at one time walking in for a meeting, and it was silent in the office space. Everyone was pretty focused and all you could hear were the keyboard actuations and then mouse clicks and the volume of the mouse click, I thought it just struck me as being very loud - louder than I thought it should be because and if I think about it, even my own, as I get focused on my own task, many times I'm clicking that mouse button pretty forcefully. Maureen Anderson: Well, people like to have feedback when they do a task. And there's actually an interesting trend going on in keyboards right now. Back towards mechanical keyboards are digital keyboards they're making smaller and the height of the keys is less and they're very quiet, and sometimes you can't even tell when you hit a key. So, there's been a movement. It's actually come from the gaming community back towards mechanical keyboards, which are rather old fashioned, and they have a real clicky feel. But people like that. Peter Koch: Yeah there's a lot of tactile feedback. Maureen Anderson: Lot of tactile feedback as they're working along, they know what they've done. Peter Koch: And I find that, too, when I'm typing. So, I have a keyboard for my iPad, which is electronic. So, it's just a button actuate and it's not a mechanical actuation and then I have a mechanical keyboard at home that I use with my desktop and I type much harder, the keystrokes are much more forceful on my iPad because of that physical feedback. Maureen Anderson: Yes, and they've done a lot of work, like with an iPad. If you're using the on screen keyboard to make like a little sound or a little bloop to give you to give you some feedback, because without the feedback it's you have to keep checking like did I, did I do it? You know what happened here. Peter Koch: Do it right. Maureen Anderson: Yeah. Peter Koch: Interesting. OK, so let's go through and recap. If I were to have a workstation set up appropriately, what would it look like? Maureen Anderson: Ok. So as an ergonomist, I like things to be highly adjustable. I love the new dynamic workstations. You know, electric desks that can go up and down. The converters on top are OK for some people, not for other people. We haven't even talked about dynamic workstations. So much to talk about today! But I like to see people that are working their elbow height is about the same as their keyboard height, the monitor is about eye level, arm's length. These are all sort of just your basic starting points. If what you do needs to be different, then we can, you can adapt to that. But that should really be it. So, elbow height, good head posture, the ears over the shoulder. Generally, we say some back support. It's good to have some back support because it is difficult to sit all day without any back support. Peter Koch: So generally, whether it's standing or seated for a workstation. My elbows should be at my keyboard height. Maureen Anderson: Yes. Peter Koch: The monitor top of the text should be about I height for the monitor. Maureen Anderson: Yes. Peter Koch: So, I shouldn't look up or down. But is it dependent upon glasses? Maureen Anderson: Glasses are often a big factor. Yes. Peter Koch: It should be approximately an arm's length away. And then my mouse should be on the same plane as the keyboard? Maureen Anderson: Same plain as the keyboard, right. So, we're not doing any excessive reaching as it should be as close to you as possible to reduce the reaches. Again, to get a little off track. What I see in the real world, often, is when I go into an office, people have pushed their keyboard and mouse far away in order to have papers close to them. Peter Koch: And so, the important part there is we really want to switch that around. We want to have the keyboard closer or whatever you're using closer. Maureen Anderson: Yes. We try to get the keyboard and the mouse closer and then we get like an inline copy holder to get the papers a little bit further away. Peter Koch: That's a good key point right there. Maureen Anderson: It really depends, though, on what you're doing when it comes to handwriting, that's really the issue because people say, well, I need the papers close because I do a lot of handwriting. And so, then I try to probe. Do they do more handwriting in the day or are they doing more keying? And for most people, it's more keyboard and mouse than it is for writing. Very few people will write long, long parts with a paper and pen. What they're doing is just writing down a phone number. They're just writing down a quick note. They're checking something off. They're not really writing. Peter Koch: Or they might be keying. So that numeric keypad and the mouse so your paper can be here in front of you. The numeric pad that could be separated from the keyboard could be on the left-hand side and your mouse to adjust the cell if you could be on the right. So, but still, everything is within that... Maureen Anderson: Should be close. Peter Koch: Windshield wiper plane, nice and close to you? Maureen Anderson: Yes. Peter Koch: Good. Maureen Anderson: But you have to look at what a person does. And as I said, when I go in, they usually are changing their behavior for me because, right. They're going to sit up straighter. Peter Koch: They want to get a good grade. Maureen Anderson: They want to get a good grade. So sometimes I will look at their co-workers actually not them to see what everyone else is doing, because that's sometimes, you know, we have sort of a herd mentality. So, if I see everyone else has things pushed way far away, then I start to suspect, you know, maybe they do. Or I'll see wear and tear on the desk. I'll see worn spots in their chair. Maybe I'll see really ripped up arms. So, I know that chair is banging into the desk. So, I'm looking for other hints as to where things are. You can you know, you can almost see dust patterns from where their stuff usually is, and I can tell they've moved it just for me. Peter Koch: So, do you have or are there any tips for - because we're seeing this a lot more in the workplace now, for multiple monitors? Maureen Anderson: Oh yeah. Peter Koch: Let's look at like a two-monitor setup. Where should they be in relationship to like the center plane of the person? Maureen Anderson: I did have one person with six monitors once and I was like, that is a lot of information to be looking at. Peter Koch: They win. Maureen Anderson: Right? They won. Right. We take whatever they look at most of the time, that is their dominant monitor. We like to have that front and center. OK. The secondary or tertiary and I don't even know what you call it when it's six your, “sixtiary” one. You can have arrayed around you, trying to minimize a static neck twist. So, you don't want to be looking for an hour with your head twisted off to one side. That's why we say the primary one is directly in front of you. Most common now I see is two monitors. So, if you use them equally, then we would have them sort of centered in front of you. But it's all about head posture, trying to get you in the best head posture. I do see a lot of situations where people have one monitor in front of you, in front of them, and then they'll have a small monitor like on a laptop or an iPad. And so, I really have to you know, if they're just looking over at that because it's their calendar, and that's all they're doing, then it's, you know, I'm OK with it. But if they're looking down and typing on that one, then I'm saying, well, maybe that's your primary monitor and we need to get that in a better location. Peter Koch: So those key points would go back to the multiple monitor setup. So, whatever you're doing primarily should be in that center line. So. Maureen Anderson: Yes. Peter Koch: Your body center line, your keyboard should be in the center. Your primary monitor should be in the center. Maureen Anderson: Should be in the primary. Yep. Peter Koch: The things that you do most frequently should be closer, use most frequently should be closest to your body. Maureen Anderson: Yes. Peter Koch: And then the things that you do intermittently, whether it's like stapling or printing or whatever those are. Move them farther away, so it forces you to actually get up and move. Maureen Anderson: And that's a great point. I'm glad you brought that up. It's somewhat counterintuitive. But like printers, sometimes people try to have that printer in close because they're reaching to it all the time. Really, they're probably not reaching to it all the time. And sometimes we do we say move that further away. That's a technique to get people out of their chairs or if they're in a dynamic workstation and they're standing to take a couple of extra steps to get that movement back in their day. Peter Koch: Awesome. Maureen Anderson: Yeah. Peter Koch: So, as we come to a close here. Think about, are there maybe a couple, three or four key points that you'd like to leave us with from our workstation setup or how to work safely in an office setting? Maureen Anderson: Right. So first of all, I would say everyone is different. So, you have to adjust that workstation for the person. Right. So, if they're very short, their keyboards are going to need to be lower. Their monitors are going to be lower if they're very tall. You know, we're gonna need to change that. Most workstations are designed to hit kind of 90 percent of the population. But having said that, there are plenty of people who are below 5 foot 2 or above 6 foot 2 because that 90 percent is about 5' 2" to 6' 2". So, people at those other ends may not work well with the off the shelf equipment. They may need some special things. Peter Koch: So. Maureen Anderson: So again, yeah. Peter Koch: From an onboarding standpoint, if I'm bringing people in to work in an office, knowing that if I'm going to have workstations that fit these people, I might be hiring somebody that's outside of the design parameters for that workstation. Maureen Anderson: Yes. Peter Koch: I have to look at the person and the workstations. Maureen Anderson: And the workstation. And that. Peter Koch:  So, it should be adjustable. Maureen Anderson: Right. One of the great things I love about the dynamic workstations is even if people aren't using it as much as they should. And I'm always telling them they should be changing. At least I know when a new person comes into that workstation, if they're a lot different stature from the previous person, you know, with a couple of hand cranks or a push of a button, you can adjust it to their needs, which is great. Peter Koch: Workstation adjustability would be key, it helps not only to get the person to move, but it also helps the company to allow the workstation to be adjusted to the stature of a person. Maureen Anderson: Right. And for their changing needs and staff, to make those changes. And the other one is behavior, right? It's to change the workstation, to be adjustable for the person, but to encourage the behavior where people are going to move and change their posture during the day. You talked about giving opportunities, things like there is a place to eat away from their desk. There are plenty of opportunities for people to get up and move. And so, you know, in the culture, sometimes people don't like to see people away from their desks. You know where it may be better if you have an issue to get up and walk down the hall and talk to that person rather tha

Добрый день уважаемые слушатели. Представляем новый выпуск подкаста RWpod. В этом выпуске: Ruby Ruby 2.7.0’s Rails Ruby Bench Speed is Unchanged from 2.6.0, My top five Rails performance tips for performance noobs и Why is Ruby on Rails’ default_scope bad? Down - a utility tool for streaming, flexible and safe downloading of remote files, FStrings - Python-alike fstrings (formatting strings) for Ruby и Rails PG Extras - a rake tasks and Ruby methods can be used to obtain information about a Postgres instance Web Goodbye, Clean Code, Common Javascript Promise mistakes every beginner should know and avoid, The unseen performance costs of modern CSS-in-JS libraries in React apps и Debounce vs Throttle: Definitive Visual Guide Developer Roadmaps, Asdf-vm - manage multiple runtime versions with a single CLI tool, Parse, Validate, Manipulate, and Display Dates and Times in JavaScript with Day.js, IsoCity - an isometric city builder in JavaScript и Peekobot - a simple choice-driven chatbot framework

Welcome to the #IIEX Europe Conference Series 2019. Recorded live in Amsterdam, this series is bringing interviews straight to you from exhibitors and speakers at this year’s event. In this interview, host Jamin Brazil interviews Frank Hayden, COO at Op4G. This Episode’s Sponsor: GreenBook Contact Frank Online:  LinkedIn Op4G [00:01] We are live today. I have got Frank Hayden, the CEO – COO, excuse me, right? For Op4G? [00:12] Op4G. [00:12] Op4G, sorry. Which sounds like a rapper sort of thing. [00:18] It can be to some people. (Laughs.) But in the market research space, we’re a— [00:23] You down with OP— Anyway. [00:24] Yes, Op4G is Opinions 4 Good and we work with nonprofits. From the food bank of San Francisco to American Red Cross to very local charitable groups. We do an outreach for them to have their members, their donors, volunteers and supporters to join our panel and with their participation of surveys, they have to put back a percentage to the nonprofit that brought them to us. We’re here today in Amsterdam rolling out our European business. [01:06] How are you guys different than Research For Good? [01:10] We’re different in the fact that we actually go out and make the relationship with the nonprofit, which means it’s a little bit stickier. They can go into our portal and see how many dollars that their research activities have generated for that nonprofit. Research For Good, you join their panel, and they do more of a river based sampling as well, mixing that in, which we’re different in that fact that we only work with nonprofits exclusively. With them, you can pick and choose who you want to join with. With us, you’re pretty much invited in. There’s no open recruitment. [01:59] That’s super interesting. How long have you been around? Has the business been around? [02:05] Eight years. [02:09] And you were early? A founder? [02:11] I was early in. They asked me to come in. I was with Greenfield, then Toluna, then sat out a year, and then they asked me to pretty much start the business from scratch. [02:22] It’s interesting having an invite-only approach because one of the biggest issues facing market research, in my opinion, is centered around data quality. I’m 22 years in the industry. CPIs continue to go down. We’ve hit the bottom of that, by the way. The actual amount of money or reward that goes to the respondent is relatively small. Again, in aggregate, not picking on any specific brands here or companies. It really is, for me, creating this moment of crisis. I do this exercise, in fact, I’m going to do it tomorrow when I speak here: “How many of you have taken a survey in the last six months for third-party companies?” I’m not talking about satisfaction on the last customer service interaction, I’m talking about outside solicitation of, “I’d like your opinion.” The answer is not very many people ever raise their hand to that question. And yet, there’s an order of, back of the napkin, about 1.4 million surveys that are done in North America every day. There are a lot of surveys that are being done, and I can’t figure out who’s doing all the surveys. You’ve got this inflection point of overall CPIs are really cheap and then you’ve got more demand for people to take surveys. It’s starting to really kind of hit this, in my opinion, I’m calling it a crisis, that’s probably overstating it, but it’s a material concern centered around data quality. How good is the actual data? Just to finish the point, Remesh, I’m very good friends with Andrew, the founder, and Gary, his COO. They now have in their open-ended, moderated, chat-based discussions, they now ask a screening question which is, “What is your favorite color?” Sixty percent of the answers that they get back are, on average, are “I really like that” and “ASDF.” That’s the first question. (Laughs.) Right? That’s kind of the problem that we’re facing and so having an invite-only panel is interesting because, presumably,

Sponsors Sentry use the code "devchat" for $100 credit TripleByte offers $1000 signing bonus Cachefly Panel: Mark Ericksen Josh Adams Special Guest:  Mitchell Hanberg Notes: This episode welcomes guest Mitchell Hanberg, software developer for SEP in Carmel, IN. Currently, he is working with Rails at his job and writes Elixir at home. Mitchell wrote a blog post about how to use Elixir LS with Vim. He is working on integrating ALE and Elixir LS for Vim. The panelists discuss some problems they are having with Elixir LS crashing. The panelists conclude by discussing their favorite features of the Elixir/ALE integration and their favorite features of VIM. Terms: Erlang VS CODE Github Vim ALE (asynchronos linting engine) Visual Studio Code Vim LSP NeoVim OniVim intelliJ ASDF Emacs Picks: Mark https://rg3.github.io/youtube-dl/ Josh https://urbit.org/primer/ https://xi-editor.io/xi-editor/ Mitchell Hanberg http://calnewport.com/books/deep-work/ https://www.amazon.com/All-new-Kindle-Paperwhite-Waterproof-Storage/

Sponsors Sentry use the code "devchat" for $100 credit TripleByte offers $1000 signing bonus Cachefly Panel: Mark Ericksen Josh Adams Special Guest:  Mitchell Hanberg Notes: This episode welcomes guest Mitchell Hanberg, software developer for SEP in Carmel, IN. Currently, he is working with Rails at his job and writes Elixir at home. Mitchell wrote a blog post about how to use Elixir LS with Vim. He is working on integrating ALE and Elixir LS for Vim. The panelists discuss some problems they are having with Elixir LS crashing. The panelists conclude by discussing their favorite features of the Elixir/ALE integration and their favorite features of VIM. Terms: Erlang VS CODE Github Vim ALE (asynchronos linting engine) Visual Studio Code Vim LSP NeoVim OniVim intelliJ ASDF Emacs Picks: Mark https://rg3.github.io/youtube-dl/ Josh https://urbit.org/primer/ https://xi-editor.io/xi-editor/ Mitchell Hanberg http://calnewport.com/books/deep-work/ https://www.amazon.com/All-new-Kindle-Paperwhite-Waterproof-Storage/

This week Hex has no whinge?? But Hex will always be Hex... or Carol Beer.... Naes talks nonsense and we have a secret guest once more.. Join the fun, facts and friction as we talk all things FFXIV:ARR!

I'm so excited about today's article, which has a new format that I am trying out for you guys: It's a podcast (in your RSS readers this shows up as podcast, though no artwork or intro have been created yet)! The first interview features a great guest: Mr Levi Antrim from Learn German with Herr Antrim. Levi is a German teacher in a US high school, but he's doing excellent work with a brand new approach to the classroom.Listen to the interview below: Here's what Levi and I discussedHow this small-town American guy discovered a love and passion for German and started producing creative and entertaining videos for his classesHow the students in his high school classes have changed the way they approach German as a school subjectHerr Antrim's YouTube success and the new series he's working on - teaching with puppets!How quickly you can really experience the full benefit of immersion learning in the countryHow to deal with the eternal problem called "They all speak English to me!"What Levi loves about Germany, and our shared love of the beautiful city of BerlinWhy you shouldn't use "Männer" by Herbert Grönemeyer in classes with under 21sLevi's top picks for bands and videos to use while practicing GermanLinks to what we chatted aboutFluency MC and Mickey Mangan in the Fluent Language InterviewsDöner Kebab - the classic German (Turkish?) fastfoodThe ASDF movies and Charlie the Unicorn in GermanHerr Antrim's YouTube playlist of German songs"Männer" by Herbert GrönemeyerI need your comments - what do you think about a podcast?As you can tell, I'm considering the launch of a whole Fluent Language podcast format featuring interviews, music and other excellent content that you can listen to wherever you are. As you can hear in today's recording, I think the improvements in my own speaking and microphone skills would be significant with regular practice, and I'd like to share the journey with you.  There are so many creative learners and teachers out there, and a lot of fun to be had - and what's better than hearing language as well as reading it?!What do you think about a Fluent Language podcast? Are you as excited as I am? Please leave your reply in the comments today so the project can start with your support!  

Ep67 Got Faded Japan Podcast Johnny returns from "glaucoma" treatment while Shank breaks down the booze events springing up around Tokyo.  Jockey-boxer nabs toddler, two girl's bar employees throw the hammer down on their boss, 2 ASDF members roll drunk salariboy, 75 year-old slashes daughter's face in Elderly of the Corn episode, 9 North Koreans hop a banana boat, man burns down ex's house with her parents in it, and biker gang leader goes from assaulting sumo grand champions to regular ol drunk dudes. The Got Faded Japan Podcast gives listeners a glimpse of the seedy side of Japan's news, culture, politics, parties, and all around mischief and mayhem. Hosted by Johnny and Shank who add their own opinions and otherwise drunken bullshit to the mix.  Send us an email to gotfadedjapan@yahoo.co.jp or go to gotfadedjapan.com to buy a t-shirt and support the show. Or just tell a friend or post a link to keep this shit rolllin' Fader! Kanpai mofos!

ep58 Got Faded Japan Podcast- Johnny assists to the drunken and injured while Shank fails miserably on the booze cruise. Bicycle tipping serial rapist gets 28 years, man attempts to cash out on dead woman, Kaiser Soze finally caught a Narita Airport, elderly driver bolts car into traffic and self into jail for manslaughter, ASDF member's family to get 80mil in damages over suicide, 20 year old mills about after taxi cab murder, and gang of teens clothesline elderly man. The Got Faded Japan Podcast gives listeners a glimpse of the seedy side of Japan's news, culture, politics, parties, and all around mischief and mayhem. Hosted by Johnny and Shank who add their own opinions and otherwise drunken bullshit to the mix. Send us an email to gotfadedjapan@yahoo.co.jp or go to gotfadedjapan.com to buy a t-shirt and support the show. Or just tell a friend or post a link to keep this shit rolllin' Fader! Kanpai motha fuckas!