Podcasts about dialyzer

Play Episode Listen Later Jun 27, 2023 53:37

Dialyzer is something that eventually everyone hears about in the Elixir community. It's a static code analysis tool that has both fans and detractors, and with good reasons on both sides! We talk with Noah Betzen about how he brought Dialyzer to several mature Elixir projects. He wanted the benefits of finding and fixing bugs and to prevent new problems from being added. He shared tools, strategies and other resources for how to get started without stopping everything to fix all the existing problems. If you've ever tried to add Dialyzer to a project and aborted, then this discussion may give you the courage and the tools to try again! Show Notes online - http://podcast.thinkingelixir.com/157 (http://podcast.thinkingelixir.com/157) Elixir Community News - https://elixir-lang.org/blog/2023/06/19/elixir-v1-15-0-released/ (https://elixir-lang.org/blog/2023/06/19/elixir-v1-15-0-released/?utm_source=thinkingelixir&utm_medium=shownotes) – Elixir 1.15 release blog post - https://github.com/elixir-lang/elixir/releases/tag/v1.15.0 (https://github.com/elixir-lang/elixir/releases/tag/v1.15.0?utm_source=thinkingelixir&utm_medium=shownotes) – full release notes - https://twitter.com/josevalim/status/1670879654134050828 (https://twitter.com/josevalim/status/1670879654134050828?utm_source=thinkingelixir&utm_medium=shownotes) – José Valim's tweet about reported compilation time improvements - https://elixirforum.com/t/elixir-v1-15-0-released/56584 (https://elixirforum.com/t/elixir-v1-15-0-released/56584?utm_source=thinkingelixir&utm_medium=shownotes) – ElixirForum.com post about the release with comments, feedback, and workarounds for issues. - https://github.com/phoenixframework/phoenix/blob/v1.7.4/CHANGELOG.md (https://github.com/phoenixframework/phoenix/blob/v1.7.4/CHANGELOG.md?utm_source=thinkingelixir&utm_medium=shownotes) – Phoenix 1.7.4 (then up to 1.7.6) was released with a small, but handy fix around deploying with active websockets - https://survey.stackoverflow.co/2023/ (https://survey.stackoverflow.co/2023/?utm_source=thinkingelixir&utm_medium=shownotes) – StackOverflow Developer Survey results - https://survey.stackoverflow.co/2023/#technology-most-popular-technologies (https://survey.stackoverflow.co/2023/#technology-most-popular-technologies?utm_source=thinkingelixir&utm_medium=shownotes) – Most popular technologies - https://survey.stackoverflow.co/2023/#section-top-paying-technologies-top-paying-technologies (https://survey.stackoverflow.co/2023/#section-top-paying-technologies-top-paying-technologies?utm_source=thinkingelixir&utm_medium=shownotes) – Top paying technologies - https://survey.stackoverflow.co/2023/#section-admired-and-desired-web-frameworks-and-technologies (https://survey.stackoverflow.co/2023/#section-admired-and-desired-web-frameworks-and-technologies?utm_source=thinkingelixir&utm_medium=shownotes) – Phoenix is the most admired web framework and technology - https://twitter.com/bcardarella/status/1669423297518264320 (https://twitter.com/bcardarella/status/1669423297518264320?utm_source=thinkingelixir&utm_medium=shownotes) – LiveView Native got animated charts working in SwiftCharts - https://twitter.com/moomerman/status/1670021284900614144 (https://twitter.com/moomerman/status/1670021284900614144?utm_source=thinkingelixir&utm_medium=shownotes) – Apache ECharts with LiveView - https://huggingface.co/blog/livebook-app-deployment (https://huggingface.co/blog/livebook-app-deployment?utm_source=thinkingelixir&utm_medium=shownotes) – José Valim's has a Livebook blog post on the Hugging Face blog. - https://twitter.com/thibaut_barrere/status/1670789241436028931 (https://twitter.com/thibaut_barrere/status/1670789241436028931?utm_source=thinkingelixir&utm_medium=shownotes) – Using IEx helpers in Livebook cells - import IEx.Helpers - https://twitter.com/germsvel/status/1669669754305404928 (https://twitter.com/germsvel/status/1669669754305404928?utm_source=thinkingelixir&utm_medium=shownotes) – German Velasco has created a number of short tip videos that now have a home on ElixirStreams.com - https://twitter.com/elixirphoenix/status/1670856560480747526 (https://twitter.com/elixirphoenix/status/1670856560480747526?utm_source=thinkingelixir&utm_medium=shownotes) – Adding Bandit to a Phoenix 1.7 project fits in a single tweet - https://erlef.org/events (https://erlef.org/events?utm_source=thinkingelixir&utm_medium=shownotes) – The EEF (Erlang Ecosystem Foundation) has an "events" page.1 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) Discussion Resources - https://fly.io/phoenix-files/adding-dialyzer-without-the-pain/ (https://fly.io/phoenix-files/adding-dialyzer-without-the-pain/?utm_source=thinkingelixir&utm_medium=shownotes) – Blog post with more resources and code - https://www.erlang.org/doc/man/dialyzer.html (https://www.erlang.org/doc/man/dialyzer.html?utm_source=thinkingelixir&utm_medium=shownotes) – Dialyzer docs - https://github.com/jeremyjh/dialyxir (https://github.com/jeremyjh/dialyxir?utm_source=thinkingelixir&utm_medium=shownotes) – Dialyxir project - https://github.com/jeremyjh/dialyxir/pull/493 (https://github.com/jeremyjh/dialyxir/pull/493?utm_source=thinkingelixir&utm_medium=shownotes) – PR to add new format for ignorefilestrict - https://elixirforum.com/t/blog-post-adding-dialyzer-without-the-pain/56461 (https://elixirforum.com/t/blog-post-adding-dialyzer-without-the-pain/56461?utm_source=thinkingelixir&utm_medium=shownotes) – Feedback to blog post that we discuss - https://www.youtube.com/watch?v=4PZE40h13wM (https://www.youtube.com/watch?v=4PZE40h13wM?utm_source=thinkingelixir&utm_medium=shownotes) – Slaying the Type Hydra, or How We Went from 12,000 Dialyzer Errors to None | Jesper Eskilson - Senior Engineer at Klarna - https://github.com/bamorim/typedectoschema (https://github.com/bamorim/typed_ecto_schema?utm_source=thinkingelixir&utm_medium=shownotes) - https://podcast.thinkingelixir.com/72 (https://podcast.thinkingelixir.com/72?utm_source=thinkingelixir&utm_medium=shownotes) – Interview about type_check - https://github.com/Qqwy/elixir-type_check (https://github.com/Qqwy/elixir-type_check?utm_source=thinkingelixir&utm_medium=shownotes) - https://github.com/lexical-lsp/lexical (https://github.com/lexical-lsp/lexical?utm_source=thinkingelixir&utm_medium=shownotes) – Lexical Language Server - https://github.com/elixir-tools/next-ls (https://github.com/elixir-tools/next-ls?utm_source=thinkingelixir&utm_medium=shownotes) – Next-LS Language Server - https://smartlogic.io/podcast/elixir-wizards/s10-e12-jose-guillaume-giuseppe-types-elixir/ (https://smartlogic.io/podcast/elixir-wizards/s10-e12-jose-guillaume-giuseppe-types-elixir/?utm_source=thinkingelixir&utm_medium=shownotes) – José Valim, Guillaume Duboc, and Giuseppe Castagna discussing static types in Elixir Guest Information - https://twitter.com/Nezteb (https://twitter.com/Nezteb?utm_source=thinkingelixir&utm_medium=shownotes) – on Twitter - https://github.com/Nezteb/ (https://github.com/Nezteb/?utm_source=thinkingelixir&utm_medium=shownotes) – on Github - https://genserver.social/Nezteb/ (https://genserver.social/Nezteb/?utm_source=thinkingelixir&utm_medium=shownotes) – on Fediverse - https://nezteb.net (https://nezteb.net?utm_source=thinkingelixir&utm_medium=shownotes) – Blog Find us online - Message the show - @ThinkingElixir (https://twitter.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 - @brainlid (https://twitter.com/brainlid) - Mark Ericksen on Fediverse - @brainlid@genserver.social (https://genserver.social/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - David Bernheisel on Fediverse - @dbern@genserver.social (https://genserver.social/dbern) - Cade Ward - @cadebward (https://twitter.com/cadebward) - Cade Ward on Fediverse - @cadebward@genserver.social (https://genserver.social/cadebward)

game interview pr blog types bugs github slaying helpers elixir klarna changelog liveview iex dialyzer dialyxir

José Valim, Guillaume Duboc, and Giuseppe Castagna on the Future of Types in Elixir

Play Episode Listen Later Jun 8, 2023 48:32

It's the Season 10 finale of the Elixir Wizards podcast! José Valim, Guillaume Duboc, and Giuseppe Castagna join Wizards Owen Bickford and Dan Ivovich to dive into the prospect of types in the Elixir programming language! They break down their research on set-theoretical typing and highlight their goal of creating a type system that supports as many Elixir idioms as possible while balancing simplicity and pragmatism. José, Guillaume, and Giuseppe talk about what initially sparked this project, the challenges in bringing types to Elixir, and the benefits that the Elixir community can expect from this exciting work. Guillaume's formalization and Giuseppe's "cutting-edge research" balance José's pragmatism and "Guardian of Orthodoxy" role. Decades of theory meet the needs of a living language, with open challenges like multi-process typing ahead. They come together with a shared joy of problem-solving that will accelerate Elixir's continued growth. Key Topics Discussed in this Episode: Adding type safety to Elixir through set theoretical typing How the team chose a type system that supports as many Elixir idioms as possible Balancing simplicity and pragmatism in type system design Addressing challenges like typing maps, pattern matching, and guards The tradeoffs between Dialyzer and making types part of the core language Advantages of typing for catching bugs, documentation, and tooling The differences between typing in the Gleam programming language vs. Elixir The possibility of type inference in a set-theoretic type system The history and development of set-theoretic types over 20 years Gradual typing techniques for integrating typed and untyped code How José and Giuseppe initially connected through research papers Using types as a form of "mechanized documentation" The risks and tradeoffs of choosing syntax Cheers to another decade of Elixir! A big thanks to this season's guests and all the listeners! Links and Resources Mentioned in this Episode: Bringing Types to Elixir | Guillaume Duboc & Giuseppe Castagna | ElixirConf EU 2023 (https://youtu.be/gJJH7a2J9O8) Keynote: Celebrating the 10 Years of Elixir | José Valim | ElixirConf EU 2022 (https://youtu.be/Jf5Hsa1KOc8) OCaml industrial-strength functional programming https://ocaml.org/ ℂDuce: a language for transformation of XML documents http://www.cduce.org/ Ballerina coding language https://ballerina.io/ Luau coding language https://luau-lang.org/ Gleam type language https://gleam.run/ "The Design Principles of the Elixir Type System" (https://www.irif.fr/_media/users/gduboc/elixir-types.pdf) by G. Castagna, G. Duboc, and J. Valim "A Gradual Type System for Elixir" (https://dlnext.acm.org/doi/abs/10.1145/3427081.3427084) by M. Cassola, A. Talagorria, A. Pardo, and M. Viera "Programming with union, intersection, and negation types" (https://www.irif.fr/~gc/papers/set-theoretic-types-2022.pdf), by Giuseppe Castagna "Covariance and Contravariance: a fresh look at an old issue (a primer in advanced type systems for learning functional programmers)" (https://www.irif.fr/~gc/papers/covcon-again.pdf) by Giuseppe Castagna "A reckless introduction to Hindley-Milner type inference" (https://www.lesswrong.com/posts/vTS8K4NBSi9iyCrPo/a-reckless-introduction-to-hindley-milner-type-inference) Special Guests: Giuseppe Castagna, Guillaume Duboc, and José Valim.

philosophy balancing cheers types guardian records jos logic casting algorithms decades relations computer science mathematics guillaume compilation methodology functions documentation giuseppe probability orthodoxy elixir ballerina pardo coercion epistemology determinism xml equations tooling debugging duce programming languages thought experiments academic research design principles visual studio code luau gleam functional programming erlang axioms actor model concurrency performance optimization parallelism castagna polymorphism compilers pattern matching live coding theorems static analysis computational linguistics experimental design valim formal verification set theory duboc empirical studies type safety type theory corollaries type inference lambda calculus dialyzer dialyxir gradual typing

152: Rust and Elixir Play Great Together

Play Episode Listen Later May 23, 2023 50:15

Rust is a popular lower level language and the community has created a number of libraries to solve different problems. We talk with Jason Stiebs, a Phoenix Core Team member, about how Elixir and Rust can play well together. Jason wrote an article about how he leveraged an image processing library available in Rust by using the Elixir Rustler package. We talk about how Rustler works through NIFs, and we learn how easy using Rustler has become. It's great to understand that we have a powerful escape hatch like Rustler for those times we need it. We also get Jason's insights into the Phoenix project and talk about the importance of improving the developer experience when a LiveView crashes and more! Show Notes online - http://podcast.thinkingelixir.com/152 (http://podcast.thinkingelixir.com/152) Elixir Community News - https://www.erlang.org/news/164 (https://www.erlang.org/news/164?utm_source=thinkingelixir&utm_medium=shownotes) – Erlang OTP 26 Final was released - https://www.erlang.org/blog/otp-26-highlights/ (https://www.erlang.org/blog/otp-26-highlights/?utm_source=thinkingelixir&utm_medium=shownotes) - https://www.erlang.org/blog/otp-26-highlights/#improvements-of-maps (https://www.erlang.org/blog/otp-26-highlights/#improvements-of-maps?utm_source=thinkingelixir&utm_medium=shownotes) – Improvements to Maps - https://github.com/elixir-lang/elixir/releases/tag/v1.14.4 (https://github.com/elixir-lang/elixir/releases/tag/v1.14.4?utm_source=thinkingelixir&utm_medium=shownotes) – When Elixir 1.14.4 was released, it included the ability to request sorted map keys when inspecting. - https://www.erlang.org/blog/otp-26-highlights/#incremental-mode-for-dialyzer (https://www.erlang.org/blog/otp-26-highlights/#incremental-mode-for-dialyzer?utm_source=thinkingelixir&utm_medium=shownotes) – Incremental mode for Dialyzer - https://erlangforums.com/t/in-erlang-otp-27-0-0-will-no-longer-be-exactly-equal-to-0-0/2586 (https://erlangforums.com/t/in-erlang-otp-27-0-0-will-no-longer-be-exactly-equal-to-0-0/2586?utm_source=thinkingelixir&utm_medium=shownotes) – Erlang OTP 27 where +0.0 will no longer be exactly equal to -0.0. - https://felt.com/blog/startup-and-shutdown-for-phoenix-applications (https://felt.com/blog/startup-and-shutdown-for-phoenix-applications?utm_source=thinkingelixir&utm_medium=shownotes) – Jason Axelson wrote an article about doing a “Graceful Startup and Shutdown for Phoenix Applications” over on the Felt blog. - https://smartlogic.io/podcast/elixir-wizards/s10-e08-jose-valim-future-elixir-ecosystem/ (https://smartlogic.io/podcast/elixir-wizards/s10-e08-jose-valim-future-elixir-ecosystem/?utm_source=thinkingelixir&utm_medium=shownotes) – José Valim was on the Elixir Wizards podcast talking about the future development of Elixir - https://twitter.com/josevalim/status/1658160088354369546 (https://twitter.com/josevalim/status/1658160088354369546?utm_source=thinkingelixir&utm_medium=shownotes) – José Valim was asking for feedback on the "Optional Syntax Sheet" documentation. - https://elixir-lang.org/getting-started/optional-syntax.html (https://elixir-lang.org/getting-started/optional-syntax.html?utm_source=thinkingelixir&utm_medium=shownotes) – Optional syntax sheet in the Elixir Getting Started docs - https://twitter.com/sean_moriarity/status/1648466250828484609 (https://twitter.com/sean_moriarity/status/1648466250828484609?utm_source=thinkingelixir&utm_medium=shownotes) – LLaMa support added to Nx and Bumblebee by Sean Moriarity - https://twitter.com/FrerichRaabe/status/1648696436266004480 (https://twitter.com/FrerichRaabe/status/1648696436266004480?utm_source=thinkingelixir&utm_medium=shownotes) – Nicely summarizing Tweet that frames the LLaMa work - https://www.youtube.com/watch?v=e2fDjl2hoAk (https://www.youtube.com/watch?v=e2fDjl2hoAk?utm_source=thinkingelixir&utm_medium=shownotes) – ElixirConf EU keynote video titled “Using Elixir & Phoenix To Build A City Software Infrastructure” - https://www.empex.co/new-york (https://www.empex.co/new-york?utm_source=thinkingelixir&utm_medium=shownotes) – Empex NYC - use code THINKING to get $100 of your ticket - https://www.lambdadays.org/lambdadays2023 (https://www.lambdadays.org/lambdadays2023?utm_source=thinkingelixir&utm_medium=shownotes) – LambdaDays functional programming conference on 5-6 June 2023 in Kraków Poland - https://twitter.com/josevalim/status/1658159252773453824 (https://twitter.com/josevalim/status/1658159252773453824?utm_source=thinkingelixir&utm_medium=shownotes) – José Valim will speak about meta-programmable functional notebooks with Livebook 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) Discussion Resources - https://fly.io/phoenix-files/elixir-and-rust-is-a-good-mix/ (https://fly.io/phoenix-files/elixir-and-rust-is-a-good-mix/?utm_source=thinkingelixir&utm_medium=shownotes) – Elixir and Rust Is a Good Mix - https://youtu.be/FADQAnq0RpA?t=3636 (https://youtu.be/FADQAnq0RpA?t=3636?utm_source=thinkingelixir&utm_medium=shownotes) – Chris McCord specifically calling out Jason for advocating for a better DX around LiveView errors. - https://github.com/rusterlium/rustler (https://github.com/rusterlium/rustler?utm_source=thinkingelixir&utm_medium=shownotes) - https://discord.com/blog/using-rust-to-scale-elixir-for-11-million-concurrent-users (https://discord.com/blog/using-rust-to-scale-elixir-for-11-million-concurrent-users?utm_source=thinkingelixir&utm_medium=shownotes) - https://news.livebook.dev/label/45764 (https://news.livebook.dev/label/45764?utm_source=thinkingelixir&utm_medium=shownotes) - https://fly.io/phoenix-files/tensors-and-nx-are-not-just-for-machine-learning/ (https://fly.io/phoenix-files/tensors-and-nx-are-not-just-for-machine-learning/?utm_source=thinkingelixir&utm_medium=shownotes) Guest Information - https://twitter.com/peregrine (https://twitter.com/peregrine?utm_source=thinkingelixir&utm_medium=shownotes) – on Twitter - https://github.com/jeregrine/ (https://github.com/jeregrine/?utm_source=thinkingelixir&utm_medium=shownotes) – on Github - https://merveilles.town/@peregrine (https://merveilles.town/@peregrine?utm_source=thinkingelixir&utm_medium=shownotes) – on Fediverse - mailto:jason@fly.io (mailto:jason@fly.io?utm_source=thinkingelixir&utm_medium=shownotes) – Email Find us online - Message the show - @ThinkingElixir (https://twitter.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 - @brainlid (https://twitter.com/brainlid) - Mark Ericksen on Fediverse - @brainlid@genserver.social (https://genserver.social/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - David Bernheisel on Fediverse - @dbern@genserver.social (https://genserver.social/dbern) - Cade Ward - @cadebward (https://twitter.com/cadebward) - Cade Ward on Fediverse - @cadebward@genserver.social (https://genserver.social/cadebward)

thinking poland shutdowns felt maps rust improvements github llama bumblebee optional elixir dx incremental nx krak developer experience nif liveview rustler good mix chris mccord erlang otp nifs dialyzer elixirconf eu

Saša Jurić on The Future of Training & Education in Elixir

Play Episode Listen Later May 4, 2023 46:27

Today on Elixir Wizards, Sundi Myint and Owen Bickford are joined by Saša Jurić, distinguished developer, mentor, and author of Elixir in Action. They discuss the future of training and education in Elixir, challenges faced by new Elixir developers, Phoenix generators, peer mentorship, the emergence of types, and when it's time to close the umbrella. Key Takeaways: The functional programming paradigm, the actor model, and concurrency Adapting to the Elixir syntax and tooling The role of community, mentorship, and continuous learning in Elixir education The pros and cons of Phoenix generators for Elixir development Customizing templates in the Phoenix priv directory to better suit individual needs The importance of understanding and adapting generated code for maintainability and proper abstractions Importance of having a clear separation between core and interface Adapting to different opinions and preferences within a development team Refactoring and restructuring code to improve quality and reduce complexity Static typing for better documentation and the limitations of dynamic code Umbrella apps vs. mix configuration and how to avoid complexity Links Mentioned in this Episode: Enter to win a copy of Elixir in Action: https://smr.tl/2023bookgiveaway Elixir in Action by Saša Jurić https://www.manning.com/books/elixir-in-action 35% discount code for book on manning.com: podexwizards20 Saša's Website/Blog TheErlangelist.com (https://www.theerlangelist.com/) Towards Maintainable Elixir - Saša Jurić's Medium Blog Article Series (https://medium.com/very-big-things/towards-maintainable-elixir-the-core-and-the-interface-c267f0da43) Boundary (https://hex.pm/packages/boundary): Managing cross-module dependencies in Elixir projects Site Encrypt (https://hex.pm/packages/site_encrypt): Integrated Certification via Let's Encrypt for Elixir-powered sites Authentication Generator in Phoenix: https://hexdocs.pm/phoenix/mixphxgen_auth.html Ecto query generator for Elixir https://hexdocs.pm/ecto/Ecto.html GraphQL: Query language for APIs https://graphql.org/ Dialyxir: https://hexdocs.pm/dialyxir/readme.html Nx (Numerical Elixir) GitHub Repository: https://github.com/elixir-nx/nx ElixirLS (Elixir Language Server) GitHub Repository: https://github.com/elixir-lsp/elixir-ls Special Guest: Saša Jurić.

Mike Waud and Tony Winn on the Future of Elixir on the Grid

Play Episode Listen Later Apr 20, 2023 42:41

Elixir Wizards Owen Bickford and Dan Ivovich are joined by Mike Waud, Senior Software Engineer at SparkMeter, and Tony Winn, Lead Software Architect at Generac, to discuss the future of the BEAM in the electric grid, how their companies use Elixir, and the challenges they face in implementing cutting-edge technologies in an environment with a mix of old and new systems. Both guests have backgrounds in various programming languages before turning to Elixir for its functional programming capabilities, concurrency, and reliability. Elixir's portability allows it to be used in various environments, from cloud-based systems to more conservative organizations that prefer running software off the cloud. Key topics discussed in this episode: • Technology sophistication varies across different regions and industries • BEAM's reliability, concurrency, and scaling in electric grid systems • Using Elixir for caching, telemetry, and managing traffic spikes • Elixir fits well for devices due to its fault tolerance and supervision trees • Observability with telemetry hooks for understanding system performance • Traffic patterns in the grid space are often dictated by weather and human activity, requiring efficient handling • The balance between using Elixir/BEAM and other tools depending on use case • Using Elixir tools like Broadway to work with event queues and Nebulex for distributed caching • The future of the electric grid and its evolution over the next 10 years, including a shift towards more distributed energy generation • Global lessons about grid management, solar penetration, regulations, and energy storage • Prioritizing data in IoT systems and processing data at the edge of the network • Gratitude for open-source contributors in the Elixir community Links in this episode: SparkMeter: https://www.sparkmeter.io/ Generac: https://www.generac.com/ SmartLogic - https://smartlogic.io/jobs Gary Bernhardt's talk on functional core and imperative shell: https://www.destroyallsoftware.com/talks/boundaries Joe Armstrong's Erlang book: https://pragprog.com/titles/jaerlang/programming-erlang/ The Nerves podcast and documentation: https://nerves-project.org/ Special Guests: Mike Waud and Tony Winn.

144: Thinking Elixir News

Play Episode Listen Later Mar 28, 2023 13:43

A collection of ML stories, fixing an 8-year old LiveView bug, Docker drama, speeding up Dialyzer in CI, a new Credo release and more! Show Notes online - http://podcast.thinkingelixir.com/144 (http://podcast.thinkingelixir.com/144) Elixir Community News - https://www.phoenixframework.org/blog/whisper-speech-to-text-phoenix (https://www.phoenixframework.org/blog/whisper-speech-to-text-phoenix?utm_source=thinkingelixir&utm_medium=shownotes) – Chris McCord made a video showing how quickly he can add audio transcription to the open-source LiveBeats application. - https://fly.io/blog/livebeats/ (https://fly.io/blog/livebeats/?utm_source=thinkingelixir&utm_medium=shownotes) – LiveBeats blog post with link to the project - https://www.youtube.com/watch?v=OsxGB6MbA8o (https://www.youtube.com/watch?v=OsxGB6MbA8o?utm_source=thinkingelixir&utm_medium=shownotes) – Warsaw meetup was recorded where Hans Josephsen showed using “Object detection in Elixir with Axon” in a Livebook. - https://twitter.com/livebookdev/status/1636780420422418465 (https://twitter.com/livebookdev/status/1636780420422418465?utm_source=thinkingelixir&utm_medium=shownotes) – Conversation models coming soon to Livebook + Bumblebee - https://github.com/nickgnd/programming-machine-learning-livebooks (https://github.com/nickgnd/programming-machine-learning-livebooks?utm_source=thinkingelixir&utm_medium=shownotes) – Gin Lennon converted the Jupyter notebooks for the Python book “Programming Machine Learning” book by P. Perrotta into Elixir Livebooks with Axon. - https://fly.io/phoenix-files/phoenix-dev-blog-sounds-like-a-bug/ (https://fly.io/phoenix-files/phoenix-dev-blog-sounds-like-a-bug/?utm_source=thinkingelixir&utm_medium=shownotes) – Chris McCord wrote a blog post about his journey to diagnose and fix a challenging race condition in LiveView but only when using the long-poll feature. - https://www.docker.com/blog/we-apologize-we-did-a-terrible-job-announcing-the-end-of-docker-free-teams/ (https://www.docker.com/blog/we-apologize-we-did-a-terrible-job-announcing-the-end-of-docker-free-teams/?utm_source=thinkingelixir&utm_medium=shownotes) – The Docker drama update from blog post published on March 16th. - https://twitter.com/hexpm/status/1636337448543301633 (https://twitter.com/hexpm/status/1636337448543301633?utm_source=thinkingelixir&utm_medium=shownotes) – Docker policy update and the impact on Hex "TL;DR - we are not affected by it" - https://hub.docker.com/u/hexpm (https://hub.docker.com/u/hexpm?utm_source=thinkingelixir&utm_medium=shownotes) – The Hexpm organization on Docker Hub - https://twitter.com/whatyouhide/status/1635692248485572622 (https://twitter.com/whatyouhide/status/1635692248485572622?utm_source=thinkingelixir&utm_medium=shownotes) – Andrea Leopardi added module support for the "since" metadata attribute - https://github.com/elixir-lang/ex_doc/pull/1680 (https://github.com/elixir-lang/ex_doc/pull/1680?utm_source=thinkingelixir&utm_medium=shownotes) – PR for the change - https://blog.massdriver.cloud/posts/gha-dialyzer/ (https://blog.massdriver.cloud/posts/gha-dialyzer/?utm_source=thinkingelixir&utm_medium=shownotes) – Massdriver published a blog post on speeding up Dialyzer in CI - https://hexdocs.pm/credo/changelog.html (https://hexdocs.pm/credo/changelog.html?utm_source=thinkingelixir&utm_medium=shownotes) – Credo released a big update 1.7.0 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 - @ThinkingElixir (https://twitter.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 - @brainlid (https://twitter.com/brainlid) - Mark Ericksen on Fediverse - @brainlid@genserver.social (https://genserver.social/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - David Bernheisel on Fediverse - @dbern@genserver.social (https://genserver.social/dbern) - Cade Ward - @cadebward (https://twitter.com/cadebward) - Cade Ward on Fediverse - @cadebward@genserver.social (https://genserver.social/cadebward)

conversations pr thinking machine learning python ml object warsaw credo elixir docker axon jupyter liveview perrotta docker hub chris mccord dialyzer

142: Orion for Distributed Tracing in Production

Play Episode Listen Later Mar 14, 2023 53:49

Orion is an interesting library created by Thomas Depierre that makes it easy to run dynamic distributed tracing in your app on production! It includes a LiveView UI for visualizing the performance and running multiple traces simultaneously. We talk with Thomas to learn more about the history, the inspirations, how it works, why it's safe to run in production, how to get performance insights, and more! Show Notes online - http://podcast.thinkingelixir.com/142 (http://podcast.thinkingelixir.com/142) Elixir Community News - https://github.com/phoenixframework/phoenix/blob/main/CHANGELOG.md#171-2023-03-02 (https://github.com/phoenixframework/phoenix/blob/main/CHANGELOG.md#171-2023-03-02?utm_source=thinkingelixir&utm_medium=shownotes) – Phoenix 1.7.1 released with enhancement to phx.new - https://elixirstream.dev/gendiff/phx_new/EEEFA23CF29B825D3F84B0E3B3978F62 (https://elixirstream.dev/gendiff/phx_new/EEEFA23CF29B825D3F84B0E3B3978F62?utm_source=thinkingelixir&utm_medium=shownotes) – Diff for the sizable project changes as heroicons are added - https://groups.google.com/g/elixir-lang-core/c/cocMcghahs4/m/DdYRNfuYAwAJ (https://groups.google.com/g/elixir-lang-core/c/cocMcghahs4/m/DdYRNfuYAwAJ?utm_source=thinkingelixir&utm_medium=shownotes) – Multi-letter uppercase sigils being added to Elixir - https://github.com/elixir-lang/elixir/pull/12448 (https://github.com/elixir-lang/elixir/pull/12448?utm_source=thinkingelixir&utm_medium=shownotes) – Expanded sigil support already merged in - https://twitter.com/germsvel/status/1630558483102801922 (https://twitter.com/germsvel/status/1630558483102801922?utm_source=thinkingelixir&utm_medium=shownotes) – German Velasco's collection of short videos about Phoenix 1.7 - https://www.youtube.com/playlist?list=PLvQQYdm3-EoiRuwcPQds_msNxiKIvgen8 (https://www.youtube.com/playlist?list=PLvQQYdm3-EoiRuwcPQds_msNxiKIvgen8?utm_source=thinkingelixir&utm_medium=shownotes) – YouTube playlist of the short videos - https://twitter.com/germsvel/status/1631627732261154816 (https://twitter.com/germsvel/status/1631627732261154816?utm_source=thinkingelixir&utm_medium=shownotes) – Tip from German on using phx-mounted binding to do initial animations with JS transitions - https://fullstackphoenix.com/tutorials/mix-task-automatic-convert-to-verified-routes (https://fullstackphoenix.com/tutorials/mix-task-automatic-convert-to-verified-routes?utm_source=thinkingelixir&utm_medium=shownotes) – A mix task was created to help projects migrate to verified routes by the people at Fullstack Phoenix. - https://gist.github.com/andreaseriksson/e454b9244a734310d4ab74d8595f98cd (https://gist.github.com/andreaseriksson/e454b9244a734310d4ab74d8595f98cd?utm_source=thinkingelixir&utm_medium=shownotes) – Gist for mix task converttoverifiedroutes.ex - https://twitter.com/basilenouvellet/status/1628702926318313473 (https://twitter.com/basilenouvellet/status/1628702926318313473?utm_source=thinkingelixir&utm_medium=shownotes) – Quick bash script to launch a LiveBook connected to your Fly instance - https://flowbite.com/docs/getting-started/phoenix/ (https://flowbite.com/docs/getting-started/phoenix/?utm_source=thinkingelixir&utm_medium=shownotes) – Flowbite has TailwindCSS styled components and just added a “getting started with Phoenix” guide. - https://twitter.com/bcardarella/status/1632956603249950722 (https://twitter.com/bcardarella/status/1632956603249950722?utm_source=thinkingelixir&utm_medium=shownotes) – All LiveView Native SwiftUI views are complete. On to Modifiers - https://github.com/liveviewnative/liveview-client-swiftui/issues/42 (https://github.com/liveviewnative/liveview-client-swiftui/issues/42?utm_source=thinkingelixir&utm_medium=shownotes) – Github checklist of SwiftUI views - https://github.com/erlang/otp/releases/tag/OTP-26.0-rc1 (https://github.com/erlang/otp/releases/tag/OTP-26.0-rc1?utm_source=thinkingelixir&utm_medium=shownotes) – OTP 26 RC 1 bring improvements - https://erlangforums.com/t/how-is-the-new-dialyzer-incremental-mode-different/2367 (https://erlangforums.com/t/how-is-the-new-dialyzer-incremental-mode-different/2367?utm_source=thinkingelixir&utm_medium=shownotes) – Dialyzer gets an --incremental - https://gleam.run/news/v0.27-hello-panic-goodbye-try/ (https://gleam.run/news/v0.27-hello-panic-goodbye-try/?utm_source=thinkingelixir&utm_medium=shownotes) – Gleam v0.27 released - https://codebeamstockholm.com/#register (https://codebeamstockholm.com/#register?utm_source=thinkingelixir&utm_medium=shownotes) – CodeBEAM Lite Stockholm on Fri, 12 May 202 - one day conference and early bird tickets are on sale now 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) Discussion Resources - https://github.com/LivewareProblems/Orion (https://github.com/LivewareProblems/Orion?utm_source=thinkingelixir&utm_medium=shownotes) - https://twitter.com/Di4naO/status/1624876674499198976 (https://twitter.com/Di4naO/status/1624876674499198976?utm_source=thinkingelixir&utm_medium=shownotes) - https://github.com/spawnfest/Orion (https://github.com/spawnfest/Orion?utm_source=thinkingelixir&utm_medium=shownotes) – Started as a 2021 Spawnfest entry that didn't complete - https://twitter.com/Di4naO/status/1628067971007479811 (https://twitter.com/Di4naO/status/1628067971007479811?utm_source=thinkingelixir&utm_medium=shownotes) – Difference from FlameOn Twitter discussion - https://twitter.com/lostkobrakai/status/1628069107269570560 (https://twitter.com/lostkobrakai/status/1628069107269570560?utm_source=thinkingelixir&utm_medium=shownotes) – Comment about immutable filesystems - https://www.erlang.org/doc/efficiency_guide/profiling.html (https://www.erlang.org/doc/efficiency_guide/profiling.html?utm_source=thinkingelixir&utm_medium=shownotes) - https://www.erlang.org/doc/man/eprof.html (https://www.erlang.org/doc/man/eprof.html?utm_source=thinkingelixir&utm_medium=shownotes) - https://www.erlang.org/doc/man/fprof.html (https://www.erlang.org/doc/man/fprof.html?utm_source=thinkingelixir&utm_medium=shownotes) - https://github.com/DockYard/flame_on (https://github.com/DockYard/flame_on?utm_source=thinkingelixir&utm_medium=shownotes) - https://github.com/strace/strace (https://github.com/strace/strace?utm_source=thinkingelixir&utm_medium=shownotes) - https://strace.io/ (https://strace.io/?utm_source=thinkingelixir&utm_medium=shownotes) - https://www.erlang.org/doc/apps/erts/tracing (https://www.erlang.org/doc/apps/erts/tracing?utm_source=thinkingelixir&utm_medium=shownotes) - https://github.com/ferd/recon/ (https://github.com/ferd/recon/?utm_source=thinkingelixir&utm_medium=shownotes) - https://hex.pm/packages/ex2ms (https://hex.pm/packages/ex2ms?utm_source=thinkingelixir&utm_medium=shownotes) - https://github.com/ericmj/ex2ms (https://github.com/ericmj/ex2ms?utm_source=thinkingelixir&utm_medium=shownotes) - https://hexdocs.pm/matcha/Matcha.html (https://hexdocs.pm/matcha/Matcha.html?utm_source=thinkingelixir&utm_medium=shownotes) - https://hex.pm/packages/xprof (https://hex.pm/packages/xprof?utm_source=thinkingelixir&utm_medium=shownotes) - https://stackoverflow.blog/2022/12/26/why-the-number-input-is-the-worst-input/ (https://stackoverflow.blog/2022/12/26/why-the-number-input-is-the-worst-input/?utm_source=thinkingelixir&utm_medium=shownotes) - https://ebpf.io/ (https://ebpf.io/?utm_source=thinkingelixir&utm_medium=shownotes) - https://userinyerface.com/ (https://userinyerface.com/?utm_source=thinkingelixir&utm_medium=shownotes) - https://www.boredpanda.com/funny-worst-input-fields/ (https://www.boredpanda.com/funny-worst-input-fields/?utm_source=thinkingelixir&utm_medium=shownotes) Guest Information - https://twitter.com/di4naO (https://twitter.com/di4naO?utm_source=thinkingelixir&utm_medium=shownotes) – on Twitter - https://github.com/DianaOlympos/ (https://github.com/DianaOlympos/?utm_source=thinkingelixir&utm_medium=shownotes) – on Github - https://hachyderm.io/@Di4na (https://hachyderm.io/@Di4na?utm_source=thinkingelixir&utm_medium=shownotes) – on Fediverse - https://www.softwaremaxims.com/ (https://www.softwaremaxims.com/?utm_source=thinkingelixir&utm_medium=shownotes) – Blog Find us online - Message the show - @ThinkingElixir (https://twitter.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 - @brainlid (https://twitter.com/brainlid) - Mark Ericksen on Fediverse - @brainlid@genserver.social (https://genserver.social/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - David Bernheisel on Fediverse - @dbern@genserver.social (https://genserver.social/dbern) - Cade Ward - @cadebward (https://twitter.com/cadebward) - Cade Ward on Fediverse - @cadebward@genserver.social (https://genserver.social/cadebward)

112: Putting LiveView in a Chrome Extension

Play Episode Listen Later Aug 16, 2022 54:34

Google Chrome extension that displays a LiveView and integrates with a web page like Gmail? Steve Bussey shares how he did just that! We learn how it worked, why he did it, the benefits he sees, and how this differs from the conventional approach. He explains the small JS shim used, recommends a library to help when integrating with Gmail and he explains how the user experience is great, particularly when rolling out new versions! Steve goes further to talk about Chrome's new v3 extension API and targeting multiple browsers. Show Notes online - http://podcast.thinkingelixir.com/112 (http://podcast.thinkingelixir.com/112) Elixir Community News - https://github.com/WhatsApp/eqwalizer/blob/main/FAQ.md (https://github.com/WhatsApp/eqwalizer/blob/main/FAQ.md) – WhatsApp static type checker eqWAlizer added a FAQ. - https://twitter.com/robertoaloi/status/1555470447671754753 (https://twitter.com/robertoaloi/status/1555470447671754753) – Experimental support in erlang_ls has also been built for eqWAlizer - https://github.com/erlang-ls/erlang_ls/pull/1356 (https://github.com/erlang-ls/erlang_ls/pull/1356) – Erlang LS eqWAlizer support - https://twitter.com/michalmuskala/status/1554813818475319296 (https://twitter.com/michalmuskala/status/1554813818475319296) – Erlang/OTP's Dialyzer can now be run incrementally, which works out ~7x faster on average - https://github.com/erlang/otp/pull/5997 (https://github.com/erlang/otp/pull/5997) – Dialyzer PR with more details - https://twitter.com/chris_mccord/status/1554478915477028864 (https://twitter.com/chris_mccord/status/1554478915477028864) – Initial verified routes announcement from Chris McCord for Phoenix 1.7 - https://twitter.com/josevalim/status/1554512359485542400 (https://twitter.com/josevalim/status/1554512359485542400) – José Valim gave more clarification on what verified routes means. - https://twitter.com/hugobarauna/status/1554547730302832641 (https://twitter.com/hugobarauna/status/1554547730302832641) – Hugo Baraúna created a 5 minute Youtube video showing how to integrate Livebook with Google BigQuery. - https://twitter.com/akoutmos/status/1556046188784324616 (https://twitter.com/akoutmos/status/1556046188784324616) – Alex Koutmos teased that he's adding Benchee support to Livebook. - https://podcast.thinkingelixir.com/94 (https://podcast.thinkingelixir.com/94) – Benchee discussion with Tobias Pfeiffer in episode 94. - https://erlangforums.com/t/pgmp-postgresql-client-with-logical-replication-to-ets/1707 (https://erlangforums.com/t/pgmp-postgresql-client-with-logical-replication-to-ets/1707) – Interesting Erlang library launched called pgmp - https://github.com/shortishly/pgmp (https://github.com/shortishly/pgmp) – pgmp is a PostgreSQL client with support for simple and extended query, and logical replication to ETS. 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) Discussion Resources - https://twitter.com/yoooodaaaa/status/1544434779327811585 (https://twitter.com/yoooodaaaa/status/1544434779327811585) – Tweet about creating a chrome extension - https://pragprog.com/titles/sbsockets/real-time-phoenix/ (https://pragprog.com/titles/sbsockets/real-time-phoenix/) – Author of "Real-Time Phoenix" book - https://salesloft.com/ (https://salesloft.com/) - https://chrome.google.com/webstore/detail/honey-automatic-coupons-r/bmnlcjabgnpnenekpadlanbbkooimhnj?hl=en-GB (https://chrome.google.com/webstore/detail/honey-automatic-coupons-r/bmnlcjabgnpnenekpadlanbbkooimhnj?hl=en-GB) - https://www.streak.com/post/announcing-inboxsdk (https://www.streak.com/post/announcing-inboxsdk) - https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe (https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) Guest Information - https://twitter.com/YOOOODAAAA (https://twitter.com/YOOOODAAAA) – on Twitter - https://github.com/sb8244/ (https://github.com/sb8244/) – on Github - https://stephenbussey.com (https://stephenbussey.com) – Blog - https://pragprog.com/titles/sbsockets/real-time-phoenix/ (https://pragprog.com/titles/sbsockets/real-time-phoenix/) – Real-Time Phoenix book Find us online - Message the show - @ThinkingElixir (https://twitter.com/ThinkingElixir) - Email the show - show@thinkingelixir.com (mailto:show@thinkingelixir.com) - Mark Ericksen - @brainlid (https://twitter.com/brainlid) - David Bernheisel - @bernheisel (https://twitter.com/bernheisel) - Cade Ward - @cadebward (https://twitter.com/cadebward)

putting blog whatsapp extension initial api chrome gmail gb faq experimental github google chrome ets elixir js postgresql chrome extensions liveview iframe google bigquery chris mccord erlang otp dialyzer

Type systems and checking in Elixir and Ruby

Josh on Narro

Play Episode Listen Later Jan 22, 2021 8:34

Adding type checking to dynamically typed languages is possible, and awesome! https://thoughtbot.com/blog/types-in-dynamic-languages written about a bunch at thoughtbotVSCode Elixir PluginDialyzerthe documentation heresum typesBehaviorsGleamSorbetsorbet-railsRBSread about the ongoing development here

behavior checking rbs elixir xa sorbet gleam itemname dialyzer

Saša Jurić on Training

Play Episode Listen Later Mar 19, 2020 51:01

Saša Jurić is a household name in the Elixir and Erlang space and we are so glad to finally welcome him on to the show today! Author of Elixir in Action, Saša is here to discuss training and his thoughts on getting a team up to speed with regards to testing and beyond. We hear from our guest about his discovery of Elixir, his uncharacteristic early adoption of the language, and why he chose it. From there, Saša talks a bit about his book, the opportunity that arose for him to write it after Manning approached him and how he views its place among other prominent pieces of literature on the subject. We discuss early steps in the process of learning Elixir for new programmers and old, and Saša weighs in on when it might be a good idea to put in the effort. We also get to hear about very big things, where Saša works and the central work and services of the agency. The last part of our conversation is spent on more technical aspects of Saša's work, his approach to coding in general and then approaches to testing and the training side of this. Join us today for this great conversation! Key Points From This Episode: Saša's discovery of Elixir and his first experiences of the language. A lucky opportunity to write a book that presented itself to Saša! The complementary nature of Elixir in Action; reading it in conjunction with other books. Ideas on how to introduce the concepts of Elixir to new programmers and the unfamiliar. The effort needed in order to understand and adopt the new paradigm of Elixir. Saša's work at very big things and the services that the agency offers. The most useful idioms that Saša uses and the modes of operation at that agency. Saša's use of Dialyzer for debugging despite its imperfections. The exploratory nature of good coding and finding solutions as you go. Helper libraries and comparing functions from Saša's own one! Training for unit, feature and integration testing; Saša's approach for his team. Differentiating between the different types of testing and the importance of naming. Clarifying Saša's philosophy on testing and his understanding of the term 'unit'. Links Mentioned in Today’s Episode: SmartLogic — https://smartlogic.io/ Saša Jurić on Twitter — https://twitter.com/sasajuric The Erlangerist — https://www.theerlangelist.com/ Elixir in Action — https://www.manning.com/books/elixir-in-action-second-edition?query=sa%C5%A1a - use special code podexwizards20 for 40% off your purchase at Manning Publications! Michael Stevens — https://www.linkedin.com/in/michaelstephens2 Manning — https://www.manning.com/ Programming Elixir — https://pragprog.com/book/elixir16/programming-elixir-1-6 Learn Functional Programming with Elixir — https://pragprog.com/book/cdc-elixir/learn-functional-programming-with-elixir very big things — https://verybigthings.com/ Dialyzer — https://hexdocs.pm/dialyzex/Mix.Tasks.Dialyzer.html Hackers & Painters — http://shop.oreilly.com/product/9780596006624.do Paul Graham — http://www.paulgraham.com/ Justin Searls Blog - https://blog.testdouble.com/ Marie Kondo — https://konmari.com/ Special Guest: Saša Jurić.

action training ideas mix tasks helper manning marie kondo sas differentiating elixir painters erlang michael stevens juric manning publications dialyzer

Chris Keathley on Performance and Functional Programming

Play Episode Listen Later Dec 19, 2019 35:26

Our guest on the show today is blogger, software cowboy, and podcast host Chris Keathley. Chris is a senior engineer at Bleacher Report, co-host of Elixir Outlaws, and writer of an assemblage of open-source software. He joins us today to speak about his new projects, his journey with functional programming, and what it is like to run Bleacher Report’s infrastructure on Elixir. Chris gives us the lowdown on Norm, a data validating interface he recently completed, weighing in on how it is different from Dialyzer and what it can offer as far as scalability. We hear more about how Chris got introduced to Elixir through Haskell, why he wishes he learned Clojure sooner, and why Ruby on Rails isn’t going anywhere soon. Chris also gets into the tradeoffs these languages make to correlate with Erlang. He argues that Elixir can only be more widely adopted if more people build cool things in it, and then lays out some of its power in supporting Bleacher Report’s user interface. We pick Chris’s brain about what his company is trying to optimize at the moment and hear about their preference for capacity over speed, and their techniques for failing gracefully during traffic spikes. Chris tells us how much he loves Elixir due to its use of ETS and other functionality which allows Bleacher Report to keep running even above capacity. Finally, we hear about some of the observability practices that Bleacher Report uses when deploying new systems and predicting future spikes. Plug in for a great conversation and hear why you should get building with Elixir now! Key Points From This Episode: Chris’s explanation of Norm, his new software that describes data moving through a system. Chris’s introduction to functional programming through learning Haskell, Clojure, and Elixir. What makes a great functional language: immutable data and first class functions. Things that make Clojure great, such as its thought out, holistic design. Characteristics of Cons lists versus RRB trees, and what makes the latter better. An acknowledgment of the necessity of the tradeoffs Elixir makes to interact with Erlang. A little bit about the language Chris wrote to do the admin of code challenges in. Why Ruby (on Rails) will not be replaced by Elixir due to commoditization that surrounds it. An argument that Elixir can only be more widely adopted if more people build with it. Why any language can build any program thus comparisons between them are arbitrary. Where Chris sets the bar as to when something is performant. Chris’s preference for high user capacity capability over speed of delivery at Bleacher Report. Optimization projects at Bleacher Report such as using few boxes and handling traffic spikes. Things Chris loves about Elixir such as its ability to deliver more from its boxes. Elixir’s use of ETS and how Chris coded a complex problem in half a day using it. How Chris detects spikes using time series, StatsD, and other observability tools. Links Mentioned in Today’s Episode: SmartLogic — https://smartlogic.io/ Chris Keathley on GitHub — https://github.com/keathley Chris Keathley Blog — https://keathley.io/ ElixirConf 2019, Contracts for Building Reliable Systems presented by Chris Keathley — https://www.youtube.com/watch?v=tpo3JUyVIjQ The Big Elixir 2019 - Keynote: Adoption - Brian Cardarella — https://www.youtube.com/watch?v=ghpIiQKRfQ4 Bleacher Report — https://bleacherreport.com/ Elixir Outlaws Podcast — https://elixiroutlaws.com/ Norm — https://github.com/keathley/norm Dialyzer — http://erlang.org/doc/man/dialyzer.html Haskell — https://www.haskell.org/ Clojure — https://clojure.org/ Erlang — https://www.erlang.org/ Chris Okasaki — https://github.com/chrisokasaki Discord — https://discordapp.com/company StatsD — https://www.datadoghq.com/blog/statsd/ Prometheus — https://prometheus.io/ Opentracing — https://opentracing.io/ Special Guest: Chris Keathley.

performance cons contracts characteristics plug norm optimization github prometheus bleacher report rails ets elixir haskell ruby on rails functional programming erlang clojure keathley opentracing elixirconf dialyzer

EMx 072: People-Centered Solutions with Travis Elnicky

Play Episode Listen Later Oct 8, 2019 47:54

In this week’s episode of Elixir Mix the panel interviews Travis Elnicky, software architect at Podium. Podium is Utah based company that has been using Elixir for three years. Travis explains Podium’s history and its experience adopting Elixir. When Travis started at Podium they were a small startup with, he was their 16th employee. They were using Ruby on Rails and focusing on collecting reviews for local businesses. When they saw a need for a messenger application, they tried a few solutions choosing Elixir because of the familiarity they felt coming from a Rails background. After switching to Elixir, Podium grew rapidly. Now Podium has 700 employees, 130 of whom are engineers. Travis discusses with the panel how things are run over at Podium. Their teams are aligned around products and features. This makes all their engineers' full-stack developers. Podiums teams run with a lot of autonomy, they also have teams that help with internal tooling to tie the products together. The panel is curious about the recruitment process at Podium. Travis explains that their hiring is mostly based on referrals, which they found has been pretty reliable. The panel discusses the value of referrals incentives programs. By hiring referrals they save money placing ads and going to fairs. Referrals tend to be more aware of the job they are going into and already have a friend to help them transition jobs and frameworks. Next, Travis walks through what it is like for a new hire at Podium. After onboarding, the new hire sits down with their team lead and codes, taking it all the way to production. The panel considers the advantages of new hires diving in, whether or not they know Elixir. It introduces them to the work they will be doing, gives them confidence by contributing to the team, and the one on one attention shows them the culture of unity at Podium. Podium has a lot to offers its developers. It has a team whose focus is internal developer experience. Podium maintains a focus on learning and growing in Elixir. They offer training for those who are unfamiliar with Elixir. Once per week, they do a Nerd Lunch, the company buys them all lunch while Podium engineers teach their fellows about software. Elixir 101 training also happens every week and is also taught by Podium engineers. Allowing Podium engineers to teach gives learners a chance to teach which in turn helps them learn. It also allows engineers to network outside their assigned teams. The panel considers how people-centered all the solutions are at Podium. The panel wonders if Podium ever uses outside trainers or services. Travis shares the wonderful experience they have been having by using Plataformatec’s Elixir Development subscription. He says it has been incredible to be able to jump on a call, talk to them and get some feedback. Using the subscriptions allows their senior developers to level up, while the other classes and lunches helps the junior developers to level up. Podium recently sponsored ElixirConf and send a big crowd to a few different conferences every year. Travis explains the value of the conference is not only in the education received by the engineers who get to go. At Podium, the engineers who go to the conferences then come back and present what they learned at the conference, sharing what they think Podium could apply to their stack. This makes the conferences valuable to the entire team. The last topic the panel discusses in the episode is the CI at Podium. The panel explains that most of the feedback for a new developer should be coming from the CI. Travis explains how the CI is set up. When he started they were using Github and has moved to Gitlab. They use credo checks, unit tests, sobelow, and dialyzer. The panel asks about Elixir formatter and how they check format in the CI. Travis explains what he likes about credo and gives tips for running it. The panel has Travis introduces sobelow and what it does for Podium. Dialyzer is considered by the panel, they explain the trade-off of using dialyzer while sharing times that it had saved their bacon. Panelists Mark Ericksen Eric Oestrich Michael Ries Guest Travis Elnicky Sponsors Sentry– use the code “devchat” for two months free on Sentry’s small plan Sustain Our Software Views on Vue CacheFly Links Two Years of Elixir at Podium: Thoughts https://www.podium.com/ http://pages.plataformatec.com.br/elixir-development-subscription https://docs.gitlab.com/ee/ci/ https://github.com/rrrene/credo/ https://github.com/nccgroup/sobelow https://hex.pm/packages/dialyxir https://hexdocs.pm/mix/master/Mix.Tasks.Format.html https://github.com/elixir-lang/elixir/blob/master/lib/elixir/lib/calendar.ex https://github.com/jeremyjh/dialyxir#explanations https://www.linkedin.com/in/travis-elnicky-4a3b2844/ https://twitter.com/_elnicky https://twitter.com/podium_eng?lang=en https://www.facebook.com/Elixir-Mix https://twitter.com/elixir_mix Picks Mark Ericksen: https://thinkingelixir.com/ Eric Oestrich: Links Awakening Michael Ries: Hacktoberfest https://nats.io/ Travis Elnicky: Designing Elixir Systems with OTP https://www.acquired.fm/

utah mix views tasks centered github referrals podium rails panelists elixir vue gitlab sentry ruby on rails otp link's awakening podiums hacktoberfest cachefly nerd lunch plataformatec elixirconf elixir mix dialyzer

EMx 072: People-Centered Solutions with Travis Elnicky

Play Episode Listen Later Oct 8, 2019 47:54

In this week’s episode of Elixir Mix the panel interviews Travis Elnicky, software architect at Podium. Podium is Utah based company that has been using Elixir for three years. Travis explains Podium’s history and its experience adopting Elixir. When Travis started at Podium they were a small startup with, he was their 16th employee. They were using Ruby on Rails and focusing on collecting reviews for local businesses. When they saw a need for a messenger application, they tried a few solutions choosing Elixir because of the familiarity they felt coming from a Rails background. After switching to Elixir, Podium grew rapidly. Now Podium has 700 employees, 130 of whom are engineers. Travis discusses with the panel how things are run over at Podium. Their teams are aligned around products and features. This makes all their engineers' full-stack developers. Podiums teams run with a lot of autonomy, they also have teams that help with internal tooling to tie the products together. The panel is curious about the recruitment process at Podium. Travis explains that their hiring is mostly based on referrals, which they found has been pretty reliable. The panel discusses the value of referrals incentives programs. By hiring referrals they save money placing ads and going to fairs. Referrals tend to be more aware of the job they are going into and already have a friend to help them transition jobs and frameworks. Next, Travis walks through what it is like for a new hire at Podium. After onboarding, the new hire sits down with their team lead and codes, taking it all the way to production. The panel considers the advantages of new hires diving in, whether or not they know Elixir. It introduces them to the work they will be doing, gives them confidence by contributing to the team, and the one on one attention shows them the culture of unity at Podium. Podium has a lot to offers its developers. It has a team whose focus is internal developer experience. Podium maintains a focus on learning and growing in Elixir. They offer training for those who are unfamiliar with Elixir. Once per week, they do a Nerd Lunch, the company buys them all lunch while Podium engineers teach their fellows about software. Elixir 101 training also happens every week and is also taught by Podium engineers. Allowing Podium engineers to teach gives learners a chance to teach which in turn helps them learn. It also allows engineers to network outside their assigned teams. The panel considers how people-centered all the solutions are at Podium. The panel wonders if Podium ever uses outside trainers or services. Travis shares the wonderful experience they have been having by using Plataformatec’s Elixir Development subscription. He says it has been incredible to be able to jump on a call, talk to them and get some feedback. Using the subscriptions allows their senior developers to level up, while the other classes and lunches helps the junior developers to level up. Podium recently sponsored ElixirConf and send a big crowd to a few different conferences every year. Travis explains the value of the conference is not only in the education received by the engineers who get to go. At Podium, the engineers who go to the conferences then come back and present what they learned at the conference, sharing what they think Podium could apply to their stack. This makes the conferences valuable to the entire team. The last topic the panel discusses in the episode is the CI at Podium. The panel explains that most of the feedback for a new developer should be coming from the CI. Travis explains how the CI is set up. When he started they were using Github and has moved to Gitlab. They use credo checks, unit tests, sobelow, and dialyzer. The panel asks about Elixir formatter and how they check format in the CI. Travis explains what he likes about credo and gives tips for running it. The panel has Travis introduces sobelow and what it does for Podium. Dialyzer is considered by the panel, they explain the trade-off of using dialyzer while sharing times that it had saved their bacon. Panelists Mark Ericksen Eric Oestrich Michael Ries Guest Travis Elnicky Sponsors Sentry– use the code “devchat” for two months free on Sentry’s small plan Sustain Our Software Views on Vue CacheFly Links Two Years of Elixir at Podium: Thoughts https://www.podium.com/ http://pages.plataformatec.com.br/elixir-development-subscription https://docs.gitlab.com/ee/ci/ https://github.com/rrrene/credo/ https://github.com/nccgroup/sobelow https://hex.pm/packages/dialyxir https://hexdocs.pm/mix/master/Mix.Tasks.Format.html https://github.com/elixir-lang/elixir/blob/master/lib/elixir/lib/calendar.ex https://github.com/jeremyjh/dialyxir#explanations https://www.linkedin.com/in/travis-elnicky-4a3b2844/ https://twitter.com/_elnicky https://twitter.com/podium_eng?lang=en https://www.facebook.com/Elixir-Mix https://twitter.com/elixir_mix Picks Mark Ericksen: https://thinkingelixir.com/ Eric Oestrich: Links Awakening Michael Ries: Hacktoberfest https://nats.io/ Travis Elnicky: Designing Elixir Systems with OTP https://www.acquired.fm/

utah mix views tasks centered github referrals podium rails panelists elixir vue gitlab sentry ruby on rails otp link's awakening podiums hacktoberfest cachefly nerd lunch plataformatec elixirconf elixir mix dialyzer

EMx 071: The Problem with Dialyzer with Chris Keathley

Play Episode Listen Later Oct 1, 2019 47:33

In this week’s episode of Elixir Mix the panel interviews Chris Keathley about Norm and his recent talk at ElixirConf. Chris is currently working at Bleacher Report, working mostly on backend systems. The panel starts by complimenting his presentation skills and asking him about his dislike for dialyzer. Chris share the many problems he has with dialyzer. Dialyzer takes a lot of time and has crappy ergonomics. While it tells you a lot about an Erlang system that benefit doesn’t extend to Elixir systems. Neither doesn’t understand protocols. Mostly he feels that most type algebras don’t allow for growth, making changes and making the breaking changes. Explaining that type systems all have their costs and benefits, he feels that you don’t see the benefits of dialyzer until your system is up and running. The panel wonders about Norm, a library written by Chris. Chris explains what it is and what its aims are. He wrote the library to solve some of the problems seen with dialyzer and other problems he was having at work. It is mostly for validating data. He wanted to be able to put checks in where ever he wanted and to make it very hard to break systems. Norm lets you describe data in your system, by taking an arbitrary predicate and making it into a spec. Chris explains how this works and how it will not make any changes until you tell it to. He shares some of the other features offered by Norm. The sweet spot for using Norm is the next subject broached by the panel. Chirs explains that Norm fits well into the boundaries of systems, this is the most obvious place and the best place to start. The least intuitive way Chris has used Norm is to specify the options you need to pass to gen servers. He explains that it is not the most obvious use for Norm but it has been really helpful with the API. Next, the panel asks about changesets and how that works with Norm. Chris explains that changesets are very specific while Norm allows more freedom. The biggest difference between the two is that Norm won’t do casting for you. They intentionally built Norm that way because of the way Bleacher Report uses string and atom keys. In his talk, Chris explains the concept of design by contract. It means that for every function that you have you can specify preconditions and postconditions. Preconditions are things that have to be true prior to calling the function. Postconditions are things that have to be true after the functions been called. Right now Norm doesn’t provide preconditions and postconditions which provides a way to avoid some of the more expensive costs in production. Chris uses Norm in all his opensource projects and in projects at work. He shares the benefits he has seen. He believes that most systems will see benefits from Norm if they have room to grow. In his experience, every time they run into something new and think they may need to expand or change Norm, they find that Norm already has everything they need. Chris asks listeners who want to help contribute to Norm to try it out and to give him feedback. Panelists Mark Ericksen Eric Oestrich Josh Adams Guest Chris Keathley Sponsors Sentry– use the code “devchat” for two months free on Sentry’s small plan Adventures in Blockchain React Round Up CacheFly Links ElixirConf 2019 - Contracts for Building Reliable Systems - Chris Keathley https://github.com/keathley/norm EMx 040: Elixir Outlaws and Adopting Elixir with Chris Keathley EMx 003: Chris Keathley https://keathley.io https://twitter.com/chriskeathley?lang=en https://elixiroutlaws.com/ https://en.wikipedia.org/wiki/Design_by_contract https://www.facebook.com/Elixir-Mix https://twitter.com/elixir_mix Picks Mark Ericksen: zFRAG Eric Oestrich: War Machine Josh Adams: "Unison: a new distributed programming language" by Paul Chiusano https://github.com/unisonweb/unison Chris Keathley: Daniels' Running Formula

design adventures blockchain explaining contracts daniels norm api bleacher report panelists elixir war machine sentry unison chirs erlang josh adams cachefly keathley emx elixirconf react round up elixir mix dialyzer paul chiusano

EMx 071: The Problem with Dialyzer with Chris Keathley

Play Episode Listen Later Oct 1, 2019 47:33

In this week’s episode of Elixir Mix the panel interviews Chris Keathley about Norm and his recent talk at ElixirConf. Chris is currently working at Bleacher Report, working mostly on backend systems. The panel starts by complimenting his presentation skills and asking him about his dislike for dialyzer. Chris share the many problems he has with dialyzer. Dialyzer takes a lot of time and has crappy ergonomics. While it tells you a lot about an Erlang system that benefit doesn’t extend to Elixir systems. Neither doesn’t understand protocols. Mostly he feels that most type algebras don’t allow for growth, making changes and making the breaking changes. Explaining that type systems all have their costs and benefits, he feels that you don’t see the benefits of dialyzer until your system is up and running. The panel wonders about Norm, a library written by Chris. Chris explains what it is and what its aims are. He wrote the library to solve some of the problems seen with dialyzer and other problems he was having at work. It is mostly for validating data. He wanted to be able to put checks in where ever he wanted and to make it very hard to break systems. Norm lets you describe data in your system, by taking an arbitrary predicate and making it into a spec. Chris explains how this works and how it will not make any changes until you tell it to. He shares some of the other features offered by Norm. The sweet spot for using Norm is the next subject broached by the panel. Chirs explains that Norm fits well into the boundaries of systems, this is the most obvious place and the best place to start. The least intuitive way Chris has used Norm is to specify the options you need to pass to gen servers. He explains that it is not the most obvious use for Norm but it has been really helpful with the API. Next, the panel asks about changesets and how that works with Norm. Chris explains that changesets are very specific while Norm allows more freedom. The biggest difference between the two is that Norm won’t do casting for you. They intentionally built Norm that way because of the way Bleacher Report uses string and atom keys. In his talk, Chris explains the concept of design by contract. It means that for every function that you have you can specify preconditions and postconditions. Preconditions are things that have to be true prior to calling the function. Postconditions are things that have to be true after the functions been called. Right now Norm doesn’t provide preconditions and postconditions which provides a way to avoid some of the more expensive costs in production. Chris uses Norm in all his opensource projects and in projects at work. He shares the benefits he has seen. He believes that most systems will see benefits from Norm if they have room to grow. In his experience, every time they run into something new and think they may need to expand or change Norm, they find that Norm already has everything they need. Chris asks listeners who want to help contribute to Norm to try it out and to give him feedback. Panelists Mark Ericksen Eric Oestrich Josh Adams Guest Chris Keathley Sponsors Sentry– use the code “devchat” for two months free on Sentry’s small plan Adventures in Blockchain React Round Up CacheFly Links ElixirConf 2019 - Contracts for Building Reliable Systems - Chris Keathley https://github.com/keathley/norm EMx 040: Elixir Outlaws and Adopting Elixir with Chris Keathley EMx 003: Chris Keathley https://keathley.io https://twitter.com/chriskeathley?lang=en https://elixiroutlaws.com/ https://en.wikipedia.org/wiki/Design_by_contract https://www.facebook.com/Elixir-Mix https://twitter.com/elixir_mix Picks Mark Ericksen: zFRAG Eric Oestrich: War Machine Josh Adams: "Unison: a new distributed programming language" by Paul Chiusano https://github.com/unisonweb/unison Chris Keathley: Daniels' Running Formula

design adventures blockchain explaining contracts daniels norm api bleacher report panelists elixir war machine sentry unison chirs erlang josh adams cachefly keathley emx elixirconf react round up elixir mix dialyzer paul chiusano

EMx 060: Property-Based Testing, Dialyzer, & Inaka with Brujo Benavides

Play Episode Listen Later Jul 16, 2019 67:59

Sponsors Sentry– use the code “devchat” for two months free on Sentry’s small plan CacheFly Panel Mark Ericksen Eric Oestrich Michael Ries Joined by Special Guest: Brujo Benavides Summary Brujo Benavides shares what he is working on right now and how his team feels about working in both Elixir and Erlang. He shares what his team has gotten out of using Elixir and what he thinks his team will get out of Elixir in the future. The panel discusses property-based testing and Fred Hebert’s book on property-based testing. Brujo shares use cases that would benefit from property-based testing and those that would benefit from unit testing. The panel considers dialyzer and shares their experiences using it in their code. Brujo explains how he chooses which tools to use for a project. Inaka is discussed; Brujo explains what they are all about and how to join. Upcoming conferences that Inaka is organizing is outlined and details on how to buy tickets are given. Links EMx 031: Lessons from a Decade of Erlang with Brujo Benavides https://elixir-lang.org/docs.html EMx 047: Property Based Testing with PropEr and Fred Hebert My Take on Property-Based Testing for Erlang & Elixir https://github.com/proper-testing/proper Help Dialyzer Help You! http://erlang.org/doc/man/dialyzer.html http://erlang.org/doc/man/dialyzer.html#gui-0 http://erlang.org/doc/apps/dialyzer/dialyzer_chapter.html#dialyzer_gui Erlang Oddities - Brujo Benavides https://github.com/inaka/elvis https://hex.pm/packages/dialyxir https://github.com/inaka https://github.com/inaka/guidelines https://spawnfest.github.io/ https://www.elixirconf.la/ https://twitter.com/elbrujohalcon https://github.com/elbrujohalcon https://www.facebook.com/Elixir-Mix https://twitter.com/elixir_mix Picks Mark Ericksen: https://www.destroyallsoftware.com/talks/wat I am Mother Eric Oestrich: https://grapevine.haus/ https://github.com/oestrich/telnet-elixir Michael Ries: Foam board https://devchat.tv/elixir-mix/ Brujo Benavides: http://spawnedshelter.com/ http://artemis.cslab.ece.ntua.gr:8080/jspui/handle/123456789/15777

mother lessons panel decade proper foam elixir sentry benavides brujo erlang my take cachefly emx property based testing elixir mix fred hebert dialyzer

EMx 060: Property-Based Testing, Dialyzer, & Inaka with Brujo Benavides

Play Episode Listen Later Jul 16, 2019 67:59

Sponsors Sentry– use the code “devchat” for two months free on Sentry’s small plan CacheFly Panel Mark Ericksen Eric Oestrich Michael Ries Joined by Special Guest: Brujo Benavides Summary Brujo Benavides shares what he is working on right now and how his team feels about working in both Elixir and Erlang. He shares what his team has gotten out of using Elixir and what he thinks his team will get out of Elixir in the future. The panel discusses property-based testing and Fred Hebert’s book on property-based testing. Brujo shares use cases that would benefit from property-based testing and those that would benefit from unit testing. The panel considers dialyzer and shares their experiences using it in their code. Brujo explains how he chooses which tools to use for a project. Inaka is discussed; Brujo explains what they are all about and how to join. Upcoming conferences that Inaka is organizing is outlined and details on how to buy tickets are given. Links EMx 031: Lessons from a Decade of Erlang with Brujo Benavides https://elixir-lang.org/docs.html EMx 047: Property Based Testing with PropEr and Fred Hebert My Take on Property-Based Testing for Erlang & Elixir https://github.com/proper-testing/proper Help Dialyzer Help You! http://erlang.org/doc/man/dialyzer.html http://erlang.org/doc/man/dialyzer.html#gui-0 http://erlang.org/doc/apps/dialyzer/dialyzer_chapter.html#dialyzer_gui Erlang Oddities - Brujo Benavides https://github.com/inaka/elvis https://hex.pm/packages/dialyxir https://github.com/inaka https://github.com/inaka/guidelines https://spawnfest.github.io/ https://www.elixirconf.la/ https://twitter.com/elbrujohalcon https://github.com/elbrujohalcon https://www.facebook.com/Elixir-Mix https://twitter.com/elixir_mix Picks Mark Ericksen: https://www.destroyallsoftware.com/talks/wat I am Mother Eric Oestrich: https://grapevine.haus/ https://github.com/oestrich/telnet-elixir Michael Ries: Foam board https://devchat.tv/elixir-mix/ Brujo Benavides: http://spawnedshelter.com/ http://artemis.cslab.ece.ntua.gr:8080/jspui/handle/123456789/15777

mother lessons panel decade proper foam elixir sentry benavides brujo erlang my take cachefly emx property based testing elixir mix fred hebert dialyzer

Brooklyn Zelenka on Witchcraft - Elixir Internals

Play Episode Listen Later Jul 11, 2019 30:15

Hey everybody and welcome back to Season 2 of the podcast! This season we will be talking about Elixir internals, libraries and the inner workings of the language. In our first episode we are very happy to be joined by Brooklyn Zelenka to start off our journey on the subject with an exploration of her very own Witchcraft. In this episode we talk to Brooklyn about her history with Elixir, how she got started and what attracts her to it. Brooklyn explains the influence that open source philosophy has had on her career in developing and from there she gives a pretty comprehensive introduction to what Witchcraft is, expanding its key concepts. Although this is quite a high level discussion about Elixir and Witchcraft, we are confident that with Brooklyn's expert help even our most uninitiated listener can get some benefit from our conversation. We also talk about type systems, property-based checking and Dialyzer, so for all of this and more make sure to join us as we kick things off for Season 2! Key Points From This Episode: A quick introduction to Brooklyn, where she works and how she got started with Elixir. The influence of open source and library contributions on Brooklyn's development. Getting to grips with Witchcraft; defining monads and functors. Why some of these scary terms do not need to frighten you. A few little things that differentiate Witchcraft and some surprising elements. The convenient guarantees that Witchcraft provides around your data structure. Why there is no type system baked into Elixir; overheads, inputs and outputs. Property-based checking and compile times in Witchcraft. Merging of Elixir and Dialyzer; benefits and problems. Getting in touch with Brooklyn and getting involved with Witchcraft and Elixir. And much more! Links Mentioned in Today’s Episode: Smartlogic — https://www.smartlogic.io/ Brooklyn Zelenka — https://github.com/expede Brooklyn Zelenka on Twitter — https://twitter.com/expede Brooklyn Zelenka Email — hello@brooklynzelenka.com Fission — https://fission.codes/ Elixir — https://elixir-lang.org/ Witchcraft — https://hex.pm/packages/witchcraft Dialyzer — https://github.com/jeremyjh/dialyxir Learn more about how SmartLogic uses Phoenix and Elixir. (https://smr.tl/2Hyslu8) Special Guest: Brooklyn Zelenka.

property witchcraft merging elixir internals dialyzer brooklyn zelenka smartlogic

EMx 039: Types in Erlang / Elixir with Zachary Kessin

Play Episode Listen Later Feb 19, 2019 47:48

Sponsors Sentry use the code "devchat" for $100 credit Episode Summary In this episode, the panelists, Josh Adams, Mark Erickson and guest Zachary Kessin, author of the book "Building Web Applications with Erlang", discuss types in Erlang and Elixir. Expert inputs with examples of implemented projects that use the Erlang and Elixir data types, were discussed. Here are the highlights of the discussion: Different data types in Erlang and Elixir such as structs, tuples. Differences in the Erlang/Elixir data types to other languages. Using data types to generate error messages Decoding and validating input data into functions. Getting type information from a running application. Coding patterns and rules engine in Erlang/Elixir. Dialyzer testing tool that validates code and catches any bugs. Changes in Erlang and Elixir code over the years Elixir ecosystem and the Beam Community Links Dialyzer PropEr Sheriff Dialyxir Typed_Struct Beam_Types GB_Trees Programming Languages on the BEAM A reactive game stack: Using Erlang, Lua and Voltdb Robert Virding Zachary Kessin BEAM Channel - Erlang & Elixir https://github.com/ejpcmac/typed_struct Picks Josh Adams Elixir Components: A 12 minute introduction aws-lambda-elixir-runtime Mark Ericksen BalenaEtcher Zach Kessin Elixir Release Ecourse Shalva Band

types differences proper expert sheriffs decoding coding beam elixir lua sentry programming languages erlang josh adams mark erickson building web applications dialyzer dialyxir zach kessin shalva band

EMx 039: Types in Erlang / Elixir with Zachary Kessin

Play Episode Listen Later Feb 19, 2019 47:48

Sponsors Sentry use the code "devchat" for $100 credit Episode Summary In this episode, the panelists, Josh Adams, Mark Erickson and guest Zachary Kessin, author of the book "Building Web Applications with Erlang", discuss types in Erlang and Elixir. Expert inputs with examples of implemented projects that use the Erlang and Elixir data types, were discussed. Here are the highlights of the discussion: Different data types in Erlang and Elixir such as structs, tuples. Differences in the Erlang/Elixir data types to other languages. Using data types to generate error messages Decoding and validating input data into functions. Getting type information from a running application. Coding patterns and rules engine in Erlang/Elixir. Dialyzer testing tool that validates code and catches any bugs. Changes in Erlang and Elixir code over the years Elixir ecosystem and the Beam Community Links Dialyzer PropEr Sheriff Dialyxir Typed_Struct Beam_Types GB_Trees Programming Languages on the BEAM A reactive game stack: Using Erlang, Lua and Voltdb Robert Virding Zachary Kessin BEAM Channel - Erlang & Elixir https://github.com/ejpcmac/typed_struct Picks Josh Adams Elixir Components: A 12 minute introduction aws-lambda-elixir-runtime Mark Ericksen BalenaEtcher Zach Kessin Elixir Release Ecourse Shalva Band

types differences proper expert sheriffs decoding coding beam elixir lua sentry programming languages erlang josh adams mark erickson building web applications dialyzer dialyxir zach kessin shalva band

Episode 25: Shift-Reduce Warning

Elixir Outlaws

Play Episode Listen Later Dec 13, 2018 50:48

This week the hosts talk with Andrew Summers about the recent improvements to dialyixir and how to incorporate it into elixir applications. Special Guest: Andrew Summers.

shift reduce elixir andrew summers dialyzer

113: There and Back Again: A Quest For Simplicity with Philip Poots

The Frontside Podcast

Play Episode Listen Later Oct 25, 2018 45:06

Guest: Philip Poots: GitHub | ClubCollect Previous Episode: 056: Ember vs. Elm: The Showdown with Philip Poots In this episode, Philip Poots joins the show again to talk about the beauty of simplicity, the simplicity and similarities between Elm and Ruby programming languages, whether Elixir is a distant cousin of the two, the complexity of Ember and JavaScript ecosystems (Ember helps, but is fighting a losing battle), static vs. dynamic, the ease of Rails (productivity), and the promise of Ember (productivity, convention). The panel also talks about the definition of "quality", making code long-term maintainable, and determining what is good vs. what is bad for your codebase. Resources: Michel Martens mote Learn the Elm Programming Language and Build Error-Free Apps with Richard Feldman Worse is Better: Richard P. Gabriel Gary Bernhardt's Destroy All Software Screencasts Zen and the Art of Motorcycle Maintenance: An Inquiry into Values The Calm Company It Doesn't Have to Be Crazy at Work This show was produced by Mandy Moore, aka @therubyrep of DevReps, LLC. Transcript: CHARLES:: Hello, everybody and welcome to The Frontside Podcast, Episode 113. My name is Charles Lowell. I'm a developer here at the Frontside and with me today are Taras Mankovski and David Keathley. Hello? DAVID:: Hey, guys. TARAS: Hello, hello. CHARLES:: And we're going to be talking with a serial guest on our serial podcast, Mr Philip Poots, who is the VP of engineering at ClubCollect. Welcome, Philip. PHILIP: Hey, guys. Thanks for having me on. CHARLES:: Yeah. I'm actually excited to have you on. We've had you on a couple of times before. We've been trying to get you on the podcast, I think for about a year, to talk about I think what has kind of a unique story in programming these days. The prevailing narrative is that folks start off with some language that's dynamically typed and object oriented and then at some point, they discover functional programming and then at some point, they discover static programming and they march off into a promised land of Nirvana and no bugs ever, ever happening again. It seems like it's pretty much a straight line from that point to the next point and passing through those way stations. When I talk to you, I guess... Gosh, I think you were the first person that really introduced me to Elm back at Wicked Good Ember in 2016 and it seemed like you were kind of following that arc but actually, that was a bit deceptive because then the next time I talked to you, you were saying, "No, man. I'm really into Ruby and kind of diving in and trying to get into Ruby again," and I was kind of like, "Record scratch." You're kind of jumping around the points. You're not following the preordained story arc. What is going on here? I just kind of wanted to have a conversation about that and find out what the deal was and then, what's kind have guided your journey. PHILIP: There was one event and that was ElmConf Europe, which was a fantastic conference. Really, one of the best conferences I've been to, just because I guess with the nature of early language, small conference environment. There's just a lot of things happening. There's a lot of people. Evan was there, Richard Feldman was there, the leading lights of the Elm community were there and it was fantastic. But I guess, one thing that people have always said to me is the whole way track is the best track of the conference and it's not something I really appreciated before and during the breaks, I ended up talking to a guy called Michel Martens. He is the finder of a Redis sourcing company and I guess, this was just a revelation to me. He was interested in Elm. He was friends with the guys that organized the conference and we got talking and he was like, "I do this in Ruby. I do this in Ruby. I did this in Ruby," and I was like, "What?" and he was like, "Yeah, yeah, yeah." He's a really, really humble guy but as soon as I got home, I checked him out. His GitHub is 'soveran' and it turns out he's written... I don't know, how many gems in Ruby, all with really well-chosen names, very short, very clear, very detailed. The best thing about his libraries is you can print them out on paper. What I mean by that is they were tiny. They were so small and I guess, I just never seen that before. I go into Ruby on Rails -- that was my first exposure to programming, that was my first exposure to everything -- unlike with Rails, often when you hit problems, you'd start to dive a bit deeper and ultimately, you dive so deep that you sunk essentially and you just accepted, "Okay, I'm not going to bend the framework that way this time. Let's figure out how everyone else goes with the framework and do that." Then with Ember when I moved into frontend, that was a similar thing. There were so many layers of complexity that I never felt like had a real handle on it. I kind of just thought this was the way things were. I thought it's always going to be complex. That's just the nature of the problem. That's just the problem they're trying to solve. It's a complex problem and therefore, that complexity is necessary. But it was Elm that taught me, I think that choosing the right primitives and thinking very carefully about the problem can actually give you something that's quite simple but incredibly powerful. Not only something quite simple but something so simple that it can fit inside your head, like this concept of a program fitting inside your head and Rails, I don't know how many heads I need to fit Rails in or Ember for that matter and believe me, I tried it but with Elm, there was that simplicity. When I came across this Ruby, a language I was very familiar with but this Ruby that I had never seen before, a clear example was a templating library and he calls it 'mote' and it's including comments. It's under a hundred lines of code and it does everything you would need to. Sure, there were one or two edge cases that it doesn't cover but it's like, "Let's use the trade off." It almost feels like [inaudible] because he was always a big believer in "You ain't going to need it. Let's go for that 80% win with 20% effort," and this was like that taken to the extreme. CHARLES:: I'm just curious, just to kind of put a fine point on it, it sounds like there might be more in common, like a deeper camaraderie between this style of Ruby and the style encouraged by Elm, even though that on the surface, one is a dynamically typed object oriented language and the other is a statically typed functional language and yet, there's a deeper philosophical alignment that seems like it's invisible to 99% of the discussion that happens around these languages. PHILIP: Yeah, I think so. I think the categories we and this is something Richard Feldman talks. He's a member of the Elm community. He does a lot of talks and has a course also in Frontend Masters, which I highly recommend. But he often talks about the frame of the conversation is wrong because you have good statically typed languages and you have bad statically typed languages. You have good dynamic languages and you have bad dynamic languages. For all interpretations of good and bad, right? I don't want to start any wars here. I think one of the things that Elm and Ruby have in common is the creator. Matz designed Ruby because he wanted programming to be a joy, you know? And Evan created Elm because he wanted programming to be a delight. I think if you experience both of those, like developing in both of those languages, you gain a certain appreciation for what that means. It is almost undefinable, indistinguishable, although you can see the effects of it everywhere. In Ruby, everything is an object, including nil. In Elm, it's almost he's taken everything away. Evan's taken everything away that could potentially cause you to stumble. There's a lot to learn with Elm in terms of getting your head around functional mindset and also, working with types but as far as that goes, people often call it like the Haskell Light, which I think those are a disservice to Elm because it's got different goals. CHARLES:: Yeah, you can tell that. You know, my explorations with Elm, the personality of Elm is 100% different than the personality of Haskell, if that is even a programming term that you can apply. For example, the compiler has an identity. It always talks to you in the first person, "I saw that you did this, perhaps you meant this. You should look here or I couldn't understand what you were trying to tell me." Literally that's how the Elm compiler talks to you. It actually talks to you like a person and so, it's very... Sorry, go ahead. PHILIP: No, no, I think the corollary to that is the principle of the surprise in Ruby. You know, is there going to be a method that does this? You type it out and you're like, "Oh, yes it is," which is why things like inject and reduce are both methods in enumerable. You didn't choose one over the other. It was just like, "Let's make it easy for the person who's programming to use what they know best." I think as well, maybe people don't think about this as deeply but the level of thought that Evan has put into designing Elm is crazy, like he's thought this through. I'm not sure if I said this the last time but I went to a workshop in the early days in London, which is my kind of first real exposure to Elm and Evan was giving the workshop. Someone asked him, "Why didn't you do this?" and he was like, "Well, that might be okay for now but I'm not sure that would make so much sense in 10 years," and I was kind of like, "What?" Because JavaScript and that ecosystem is something which is changing like practically hourly and this is a guy that's thinking 10 years into the future. TARAS: You might have answered it already but I'm curious of what you think is the difference, maybe it just comes down to that long term thinking but we see this in JavaScript world a lot, which is this kind of almost indifference to APIs. It almost doesn't really matter what the API is for whatever reason, there seems to be a big correlation between the API that's exposed with the popularity of the tool. I think there are some patterns, like something that's really simple, like jQuery and React have become popular because of the simplicity of their APIs. What the flip side to that? What other ways can APIs be created that we see in JavaScript world. Because we're talking about this beautiful APIs and I can relate to some of the work that Charles has been doing and I've been doing microstates but I wonder like what would be just a brief alternative to that API, so it's kind of a beautiful API. PHILIP: I don't know if anyone is familiar with the series of essays 'Worse is Better' like East Coast versus West Coast, from Richard Gabriel. The problem is, I guess and maybe this is just my understanding over my paraphrase of it, I'm not too familiar with it but I think that good APIs take time and people don't have time. If someone launches a V1 at first and it kind of does the job, people will use that over nothing and then whenever they're happy with that, they'll continue to use it and develop it and ultimately, if she's market share and then that's just the thing everyone uses and the other guy's kind of left behind like, "This is so much better." I guess this is a question, I think it was after Wicked Good Ember, I happened to be on the same trend as Tom Dale on the way back to New York and we started talking about this. I think that's his big question. I think it's also a question that still has to be answered, which is, "Will Elm ever be mainstream? Will it be the most popular thing?" aside from the question of whether it has to be or not. For me, a good APIs good design comes from understanding the problem fully -- CHARLES:: And you can understand the problem fully without time. PHILIP: Exactly and often, what happens -- at least this is what happens in my experience with the production software that I've written -- is that you don't actually understand the problem until you've developed a solution for it. Then when you've developed a solution for it, often the pressures or the commercial pressures or an open source is [inaudible] the pressures of backwards compatibility, mean that you can never refactor your way to what you think the best solution is and often, you start from scratch and the reality is people are too far away with the stuff you wrote in the past about the thing you're writing now. Those are always kind of at odds. I think there are a lot of people that are annoyed with Elm because the updates are too slow, it relies on Evan and we want to have a pool request accepted. All of the things that they don't necessarily recognize like the absence of which make Elm an Elm, if you know what I mean. The very fact that Evan does set such a high standard and does want everything to go through his personal filters because otherwise, you wouldn't gain the benefits that Elm gives you. The attention is very real in terms of I want to shift my software now and it becomes easier then. I think to go to a language like JavaScript, which has all of the escape hatches that you need, to be able to chop and change, to edit, to do what you need to do to get the job done and let's be quite honest, I think, also with Elm, that's the challenge for someone who's not an expert level like me. Once you hit a roadblock, you'll say, "Where do I go from here?" I know if I was using JavaScript, I could just like hack it and then clients are happy and everything's fine and you know there's a bit of stuff in your code that you would rather wasn't but at the end of the day, you go home and the job's done. DAVID:: Have you had to teach Elm to other people? You and I did some work like I've seen you pair with someone and guide them through the work that they needs to get done. If you had a chance to do something like that with Elm and see how that actually happens, like how do developer's mind develops as they're working through in using the tool? PHILIP: Unfortunately not. I would actually love to go through that experience. I hope none of my developers are listening to this podcast but secretly, I want to push them in the direction of Elm on the frontend. But no, but I can at least make from my own perspective. I find it very challenging at first because for me, being a Ruby developer and also, I would never say that I understood JavaScript as much as I would have liked. Coming from dynamic language, no functional experience to functional language with types, it's almost like learning a couple of different things at the same time and that was challenging. I think if I were to take someone through it, I would maybe start with a functional aspects and then move on to the type aspects or vice versa, like try and clearly breakdown and it's difficult because those two are so intertwined at some level. Gary Bernhardt of Destroy All Software Screencast, I watch quite a bit of his stuff and I had sent him an email to ask him some questions about one of the episodes that he did and he told me that he done the programming languages course, I think it's on Coursera from Daniel Grossman, so [inaudible] ML which is kind of the father of all MLs like Haskell and also Elm. I find that really helpful because he broke it down on a very basic level and his goal wasn't to teach you ML. It was to teach you functional programming. It would be a very interesting exercise, I think. I think the benefit that Elm gave you is you get to experience that delight very quickly with, "Oh, it's broken. Here's a nice message. I fix the message. It compiles. Wow, it works," and then there's a very big jump whenever you start talking about the effects. Whenever you want to actually do something like HTTP calls or dealing with the time or I guess, the impure stuff you would call in the Haskell-land and that was also kind of a bit weird. CHARLES:: Also, there's been some churn around that, right? PHILIP: That's right. When I started learning, they had signals, then they kind of pushed that all behind the scenes and made it a lot more straightforward. Then I just mastered it and I was like, "Yes, I know it," and then I was like, "All right. I don't need to know it anymore." This is the interesting thing for me because at work, most of our work now is in Elixir and Phoenix. I'm kind of picking a little bit up as I work with them. I think Elm's architecture behind the scenes is kind of based, I believe on Erlang's process model, so the idea of a mailbox and sending messages and dealing with immutable state. CHARLES:: Which is kind of ironically is very object oriented in a way, right? It's functional but also the concept of mailboxes and sending messages and essentially, if you substitute object for process, you have these thousands and thousands of processes that are sending messages back and forth to each other. PHILIP: Yeah, that's right. It's like on a grand scale, on a distributed scale. Although I wouldn't say that I'm that far with Erlang, Elixir to appreciate the reality of that yet but that's what they say absolutely. CHARLES:: Now, Phoenix and Elixir is a dynamically typed functional language. does it share the simplicity? One of the criticisms you had of Rails was that you couldn't fit it in your head. It was very difficult. Is there anything different about Elixir that kind of makes it a spirit cousin of Elm and the simple Ruby? PHILIP: I think so, yes. Absolutely. I don't think it gets to the same level but I think it's in the right direction and specifically on the framework front, it was designed specifically... I mean, in a sense it's like the anti-type to Rails because it was born out of people's frustrations with Rails. José Valim was pretty much one of Rails top core committers. Basically, every Rails application I wrote at one period, at 80% of the code written by José Valim, if you included all the gems, the device and the resourceful and all the rest of it. Elixir in many ways was born out of the kind of limitations of Ruby with Rails and Phoenix was also born out of frustrations with the complexity of Rails. While it's not as simple as say, Michel Martens' Syro which is like his web framework, which is a successor to Cuba if people have heard of that, it is a step in the right direction. I don't understand it but I certainly feel like I could. They have plug which is kind of analogous but not identical to Rack but then the whole thing is built out of plugs. I remember Yehuda Katz give a presentation like 'The Next Five Years' and essentially about Rails 3.0. This is going way back and Phoenix is in some ways the manifestation of his desire to have like the Russian doll pattern, where you could nest applications inside applications and you could have them side by side and put them inside each other and things like that. Phoenix has this concept called umbrella applications which tells that, like Ecto is a really, really nice obstruction for working with the database. CHARLES:: I see. It feels like, as opposed to being functional or static versus dynamic, the question is how do you generate your complexity? How do you cope with complexity? Because I think you touched on it at the beginning of the conversation where you thought that my problems are complex so the systems that I work with to solve those problems must necessarily also be complex. I think one of the things that I've certainly realized, kind of in the later stages of my career is that first part is true. The problems that we encounter are extremely complex but you're much better served if you actually achieve that complexity by composing radically simple systems and recombining them. To the commonality of your system is going to determine how easy it's going to work with and how well it can cope with complexity. What really drives a good system is the quality of its primitives. PHILIP: Absolutely. After ElmConf, I actually invited Michel to come to my place in the Netherlands. He live in Paris but I think he grew up Buenos Aires in Argentina. To my amazement, he said, "Yes, okay," and we spent a couple of days together and there he talked to me about Christopher Alexander and the patterns book, where patterns and design patterns actually grew out of. One of his biggest things was the code is the easiest part, like you've got to spend 80% of your time thinking deeply about the problem, like literally go outside, take long looks. I'm not sure if this is what Rich Hickey means with Hammock Driven Development. I've never actually got around to watching the talk. CHARLES:: I think it's exactly what he means. PHILIP: And he said like once you get at, the code just comes. I think Michel's work, you should really check it out. I'll send you a link to put in the show notes but everything is built out of really small libraries that do one thing and do it really well. For example, he has a library like a Redis client but the Redis client also has something called Nest, which is a way to generate the keys for nested hashes. Because that's a well-designed, the Redis client is literally just a layer on top. If you understand the primitive then, you can use the library on top really well. You can embed Syro applications within Syro applications. I guess, there you also need the luxury of time and I think this is where maybe my role as VP of engineering, which is kind of my first role of that kind, comes in here which is when you're working on the commercial pressure, try to turn around to a business guy and say, "Yes, we'll solve this problem but can we take three weeks to think about it?" It's never going to happen -- CHARLES:: No. PHILIP: Absolutely, it will never going to happen. Although the small things that I tried to do day to day now is get away from the computer, write on paper, write out the problem as you understand it, attack it from different angles, think about different viewpoints, etcetera. CHARLES:: I think if you are able to quantify the cost of not thinking about it for three weeks, then the business person that you're going to talk to is their ears are going to perk up, right? But that's so hard to do. You know, I try and make like when we're saying like, "What technologies are you going to choose? What are the long term ramifications in terms of dollars or euros or whatever currency you happen to be in for making this decision?" I wish we had more support in thinking about that but it is kind of like a one-off every time. Anyway, I'm getting a little bit off track. PHILIP: No, not at all. This is a subject I love to talk about because we kind of had a few a bit of turbulence because we thought, maybe we should get product people in, maybe we should get them a product team going and what I find was -- and this is maybe unique to the size of the company -- that actually made things a lot more difficult because you got too many heads in many ways. Sometimes, it's better to give the developer all of the context so that he can think about it and come up with the best solution because ultimately, he's the only one who can understand. I wouldn't say understands the dollars and cents but he understands the cost implications of doing it in efficient ways, which often happens when you're working in larger teams. TARAS: One thing I find really interesting about this conversation is the definition of good is really complicated here. I've observed Charles work on microstates and I work with him, like I wrote a lot of the code and we got through like five or six iterations and at every point, he got better but it is so difficult to define that. Then when you start to that conversations outside of that code context and you start to introduce business into the mix, the definition of good becomes extremely complicated. What do you think about that? How do we define it in a way? Are there cultures or engineering cultures or societal cultures that have a better definition for good that is relevant to doing quality work of this? CHARLES:: That's a deep question. PHILIP: Wow. Yeah, a really, really deep question. I think often for business, like purely commercially-driven, money-oriented good is the cheapest thing that gets the job done and often that's very short term, I think. As you alluded to Charles, that people don't think about the cost of not doing the right things, so to speak in our eyes and also, there's a huge philosophical discussion whether our definition of good as programmers and people who care about our craft is even analogous to or equal to a good in a commercial context. CHARLES:: Yes, because ultimately and this is if you have read Zen in the Art of Motorcycle Maintenance, one of the things that Pirsig talks about is what is the definition of quality. How do we define something that's good or something that's bad? One of the definitions that gets put forward is how well something is fit to purpose. Unless you understand the purpose, then you can't determine quality because the purpose defines a very rich texture, a very rich surface and so, quality is going to be the object that maps very evenly and cleanly over that surface. When it comes to what people want in a program, they're going to want very different thing. A developer might need stimulation for this is something that's very new, this is something that's going to keep my interest or it's going to be keeping my CPU max and I'm going to be learning a whole lot. A solution that actually solves for that purpose is going to be a high quality solution. Also, this is going to be fast. We're going to be able to get to market very quickly. It might be one of the purposes and so, a solution that is fast and the purpose fits so it's going to be good. Also, I think developers are just self-indulgent and looking for the next best thing in something that's going to keep their interest, although we're all guilty of that. But at the same time, we're going to be the ones maintaining software, both in our current projects and collectively when we move to a new job and we're going to be responsible for someone else's code, then we're going to be paying the cost of those decisions. We both want to minimize the pain for ourselves and minimize the pain for others who are going to be coming and working in our code to make things long term maintainable. That's one axis of purpose and therefore, an axis of quality. I think in order to measure good and bad, you really have to have a good definition of what is the purpose of that surface is so rich but the more you can map it and find out where the contours lie, the more you're going to be able to determine what's good and what's bad. TARAS: It makes me think of like what is a good hammer. A sledgehammer is a really good hammer but it's not the right hammer for every job. CHARLES:: Right. TARAS: I think what you're saying is understanding what is it that you're actually doing and then matching your solution to what you're actually trying to accomplish. PHILIP: Yeah, absolutely and in my experience, we have a Ruby team building a Rails application. That's our monolith and then, we have a couple of Elixir teams with services that have been spun out of that. This isn't proven. This is just kind of gut feel right now and it is that Elixir is sometimes slower to develop the same feature or ship it but in the long term it's more maintainable. I haven't actually gotten dived into to React and all of the amazing frameworks that it has in terms of getting things up and running quickly but in terms of the full scale application, I still think 10, 11 years on, Rails has no equal in terms of proving a business case in the shortest time possible. CHARLES:: Yeah. I feel very similarly too but the question is does your development team approach the problem as proving a business case or do they approach the problem as I want to solve the set of features? PHILIP: Yes. Where I'm working at the moment, I started out just as a software developer. I guess, we would qualify for 37 signals or sorry... base camps definition of a calm company -- CHARLES:: Of a what company? PHILIP: A calm company. Sorry. They just released a new book and called 'The Calm Company' and 'It Doesn't Have to Be Crazy at Work.' I was given in my first couple of months, a problem. It was business oriented, it had to be solved but it had to be solved well from a technical perspective because we didn't want to have to return to it every time. It was standardizing the way that we exported data from the database to Excel. You know, I was amazed because it was literally, the first time that I'd been given the space to actually dive in on a technical level to do that kind of stuff. But I think even per feature, that varies and that sometimes challenging when handing the work on because you've got to say, "This fit. Literally, we're just trying to prove, whether if we have this feature, the people will use it?" versus, "This is a feature that's going to be used every day and therefore, needs to be at good, technical quality." Those are the tradeoffs that I guess, keep you in a job. Because if it was easy, then you would need anyone to figure it out but it's always a challenge. What I like is that our tools are actually getting better and I think, with Elm for example, it's kind of major selling point is maintainability and yet, with Elm, there haven't been that many companies with Elm over a period of years that exists, that can live to tell the tale. Whereas, we certainly know with Rails applications have done well like Basecamp and GitHub. For sure, they can be super maintainable but the fact that it took GitHub to just moved Elm to Rails 5.0, I belief, the fact that it took them years and years and they were running off at fork of Rails 2.3, I think it shows the scale of the problem in that way. You know, Phoenix also went through a few issues, kind of moving architectures from the classic Rails to a more demand driven design model. I think we're getting there slowly, zig-zagging towards a place where we better understand how to write software to solve business problems. I guess, I was really interested in microstates when you shared it at Wicked Good Ember because that to me was attacking the problem from the right perspective. It's like given the fact that the ecosystem is always changing. How can we extract the business logic such that these changes don't affect the logic of our application? CHARLES:: Man, we got a lot to show you. It has changed quite a bit in the last two years. Hopefully, for the better. TARAS: It's been reduced and it's almost a quarter of its size while maintaining the same feature set and it's faster, it's lazier, it's better in every respect. It's just the ideas have actually been fairly consistent. It's just the implementation that's evolved. CHARLES:: Yeah, it's been quite a journey. It parallels kind of the story that we're talking about here in the sense that it really has been a search for primitives and a search for simplification. One of the things that we've been talking about, having these Ruby gems that do one thing and do it very, very, very well or the way that Elixir being architected has some very, very good primitives or Elm, the same kind of thing being spiritually aligned, even though on the surface, it might share more in common with Haskell. There's actually a deep alignment with a thing like Ruby and that's a very surprising result. I think one of the things that appeals to me about the type of functional programming that is ironically, I guess not present in Elm, where you have the concept of these type classes but I actually think, I love them for their simplicity. I've kind of become disenchanted with things like Lodash, even though they're nominally functional. The fact that you don't have things like monoid and functors and stuff is kind of first class participants in the ecosystems, means you have to have a bunch of throwaway functions. Those API surface area is very large, whereas if you do account for those things, these kind of ways of combining data and that's how you achieve your complexity, is not by a bunch of one-off methods that are like in Lodash, they're all provided for you so you don't have or have to write them yourself. That is one level of convenience but having access to five primitives, I think that's the power of the kind of the deeper functional programming types. PHILIP: And Charles, do you think that that gives you the ability to think at a higher level, about the problems that you're solving? Would you make that link? CHARLES:: Absolutely. PHILIP: So, if we're not doing that, then we're actually doing ourselves a disservice? CHARLES:: I would say so. PHILIP: Because we're actually creating complexity, where it shouldn't exist? CHARLES:: Yeah, I think if you have a more powerful primitive, you can think of things like async functions and generator functions, there's a common thread between async functions, generator functions, promises arrays and they're all functors. For me, that's a very profound realization and there might be a deeper spiritual link between say, an async function and an array in the same way that there's a deep spiritual link between Ruby and Elm, that if you don't see that, then you're doing yourself a disservice and you're able to think at a higher level. Also, you have a smaller tool set where each tool is more powerful. PHILIP: You did a grit, I think it was a repository with a ReadMe, where you boiled down what people would term what I would term, the scary functional language down to a very simple JavaScript. Did you ever finish that? Did you get to the monads? CHARLES:: I did get to the monads, yeah. PHILIP: Okay. I need to check that out again. I find that really, really helpful because I think one of Evan's big things with Elm is he doesn't use those terms ever and he avoids them like the plague because I think he believes they come tinged with the negative experiences of people trying Haskell and essentially getting laughed at, right? CHARLES:: Yes. I think there's something to that. TARAS: But we're doing that in microstates as well, right? In microstates documentation, even though microstates are written completely with these functional primitives, on the outside, there's almost no mention of it. It's just that when you actually go to use it, if you have an idea, one of the thing that's really powerful with microstates is that this idea that you can return another microstate from a transition and what that will do is what you kind of like what a flat map would do, which is replace that particular node with the thing that you returned it with. For a lot of people, they might not know that that's like a flat map would do but a microstate will do exactly what they wanted to do when it didn't realize that's actually should just work like that. I think, a lot of the work that we've done recently is to package all things and it make it powerful and to access the concepts that it is very familiar, something you don't need to learn. You just use it and it just works for you. CHARLES:: Right but it is something that I feel like there's unharvested value for every programmer out there in these type classes: monads and monoids and functors and co-functors or covariant functors, contravariant functors, blah-blah-blah, that entire canon. I wish there was some way to reconcile the negative connotations and baggage that that has because we feel kind of the same way and I think that Evan's absolutely right. You do want to hide that or make it so that the technology is accessible without having to know those things. But in the same way, these concepts are so powerful, both in terms of just having to think less and having to write less code but also, as a tool to say, "I've got this process. Is there any way that could it be a functor? If I can find a way that this thing is a functor, I can just save myself so much time and take so many shortcuts with it." PHILIP: And in order to be able to communicate that, or at least communicate about that, you need to have terms to call these things, right? Because you can't always just refer to the code or the pattern. It's always good to have a name. I'm with you. I see value in both, like making it approachable, so the people who don't know the terms are not frightened away. But I also see value in using the terms that have always existed to refer to those things, so that things are clear and we can communicate about them. CHARLES:: Right. definitely, there's a tradeoff there. I don't know where exactly the line is but it would be nice to be able to have our cake and eat that one too. We didn't get really to talk about the type versus dynamic in the greater context of this whole conversation. We can explore that topic a little bit. PHILIP: Well, I can finish with, I think the future is typed Erlang. Maybe, that's Elm running on BEAM. CHARLES:: Whoa. What a take? Right there, folks. I love it. I love it but what makes you say that? Typed Erlang doesn't exist right now, right? PHILIP: Exactly. CHARLES:: And Elm definitely doesn't run on BEAM. PHILIP: I don't know if I'm allowed to say this. When I was at this workshop with Evan, he mentioned that and I'm not sure whether he mentioned it just as a throwaway comment or whether this is part of his 20-year plan but I think the very fact that Elm is designed around like Erlang, the signal stuff was designed around the way Erlang does communication and processes, it means I know at least he appreciates that model. From my point of view, with my experience with Elixir and Erlang in production usage, it's not huge scale but it's scale enough to need to start doing performance work on Rails and just to see how effortless things are with Elixir and with Erlang. I think Elm in the backend would be amazing but it would have to be a slightly different language, I think because the problems are different. We began this by saying that my story was a little different to the norm because I went back to the dynamic, at the dark side but for example in Elixir, I do miss types hugely. They kind of have a little bit of a hack with Erlang because they return a lot of tuples with OK and then the object. You know, it's almost like wrapping it up in a [inaudible]. There are little things and there's Dialyzer to kind of type check and I think there are a few projects which do add types to Erlang, etcetera. But I think something that works would need to be designed from the ground up to be typed and also run in the BEAM, rather than be like a squashed version of something else to fit somewhere else, if that makes sense. CHARLES:: It makes total sense. PHILIP: I think so. I recently read a book, just to finish which was 'FSharpForFunAndProfit' is his website, Scott Wlaschin, I think. It's written up with F# but it's about designing your program in a type functional language. Using the book, you could probably then just design your programs on paper and only commit to code at the end because you're thinking right down to the level of the types and the process and the pipelines, which to me sounds amazing because I could work outside. CHARLES:: Right. All right-y. I will go ahead and wrap it up. I would just like to say thank you so much, Philip for coming on and talking about your story, as unorthodox as it might be. PHILIP: Thank you. CHARLES:: Thank you, Taras. Thank you, David. TARAS: Thank you for having us. CHARLES:: That's it for Episode 113. We are the Frontside. This is The Frontside Podcast. We build applications that you can stake your future on. If that's something that you're interested in, please get in touch with us. If you have any ideas for a future podcast, things that you'd like to hear us discuss or any feedback on the things that you did here, please just let us know. Once again, thank you Mandy for putting together this wonderful podcast and now we will see you all next time.

new york art work russian record argentina quest llc netherlands cuba west coast east coast simplicity nest zen react excel nirvana buenos aires mls api ml github beam apis javascript rails basecamp cpu rack elixir elm coursera mandy moore haskell ruby on rails v1 matz jquery redis readme taras ecto motorcycle maintenance erlang christopher alexander be crazy poots pirsig syro frontside richard feldman yehuda katz rich hickey frontend masters gary bernhardt tom dale lodash richard gabriel charles lowell david have scott wlaschin taras mankovski dialyzer devreps

EMx 021: “Dialyzer Pretty Printing” with Andrew Summers

Play Episode Listen Later Oct 2, 2018 53:34

Panel: Charles Max Wood Mark Eriksen Eric Berry Special Guest: Andrew Summers In this episode of Elixir Mix, the panel talks to Andrew Summers who lives in Chicago, currently. Working on Elixir development, and here to talk about how he wrote the dialyzer pretty printer. He is a software engineer for Albert.io, makes cool stuff every day, loves punk music, and Philadelphia sports. The panel talks about the Dialyzer pretty printing, Elixir, code writing, and more! Show Topics: 1:07 – Why are you famous? 1:11 – Andrew: Answers the question. 1:34 – Chuck: Nice. Is the dialyzer printer complete pretty printing or is it more than that? 1:45 – Andrew talks. He mentions the background information on this specific printer, which was written a decade ago. 4:13 – Panel: One thing that is helpful is that it is a static code analysis. In the Elixir we are writing these spec statements. For nothing else than this type is coming out. Then this looks at the code, and your spec says you are returning this, but I can tell that you are also returning X, Y, or Z. So it is helping us see what we are declaring a code to do, and that’s really what the code is doing. 5:28 – Guest: Yes, exactly. To continue that topic here is what else it’s saying... 6:08 – Panel: Our panelist is not here, but he has had to fix code before with that problem. With Dialect Dialyzer – how do we say this library is out-of-date? The code is out-of-date. How do I get my stuff to pass – to clean up my site? 6:54 – Guest: Containing that warning. Guest goes into further detail how to problem-solve this issue. 8:02 – Panel: So you are saying that I can funnel. 8:20 – Panel & Guest go back-and-forth talking about this topic. 9:49 – Panel: I am still diving into the system. Haven’t really used the printer, yet. Panelist asks Guest a question. 10:04 – Guest: At the forefront there are some configurations to help with that. 11:16 – Panel: Why would someone not want to use this? What are the cons? 11:23 – Guest: It would have to do more with CI than anything (one con). 13:06 – Panel: Lots of people are coming to Elixir New. Great. What is the selling point? Why should someone invest his or her time in this project? 13:33 – Guest: I find looking for a type spec is one more piece of information that could help the reader that would tell them what the code should be doing. Any information from the original author to be passed down is great. Having the machine to check that, whenever you push code, it’s an imperfect check (as we were saying). If it can tell you that you did something wrong, then why not? It gives you that extra red flag. There are huge benefits to that. Same reason we write unit tests. 15:20 – Panel: You are learning Elixir right, Chuck? Panelist talks about tech specs, code writing, and learning projects. 16:25 – Panel: Here is a tip to learning. One thing that I did I came to an existing project and writing a sub-system ( as series of modules) Writing the tech specs. As they are interacting with each other, then writing Dial Elixir, and grab the output to the file path to where my code is. Within my own code find where I am inconsistent. Andrew – you could get pages of output, right? Any tips for users? 17:37 – Guest: Isolate portions of your code base. 19:27 – Chuck: I do like the idea of the umbrella. Phoenix app out into an umbrella. A sub apps and they are more centered, smaller sized. Then, yeah. Start with Dialyzer on just that project. Isolate it, and this app in the umbrella. The output is much smaller, and good success with that. Now, one of the new features you added was the language / the code that it reports is an ERLANG term. That is not familiar to most Elixir developers. Especially if you are new to it. If you are turning this into a friendly Elixir thing, then you had to learn other programs. How did you get into this path? 21:00 – Andrew: Whenever there was complicated “something” at work – I was the person to go to. As I started to do it more and more I saw patterns in the output. Things were kind of predictable, and how to format things. It synchronizes weird. What would I do to write this task? Researched. There are 2 tools = LEEX and YECC. If you have 2 files in your source directory... 22:56 – Advertisement – Digital Ocean 23:39 – Panel: It’s cool. 23:58 – Guest: It brought me back to some courses from school. I thought that was funny. They are pretty contained tools. 24:36 – Panel: Part of your motivation was from Jose. 24:49 – Guest: Yes, definitely. 25:39 – Did you have any questions for Jose? 26:35 – Panel: You added the feature of... CREDO is pretty well-known. 27:28 – Guest: Sure, I guess I did skip some of that. Andrew talked about different libraries, ERLANG modules, and so on. 28:38 – Panel: What else are you doing? 28:45 – Getting error messages fixed for version 1.0. Trying to close-up the residual things. 30:18 – Guest keeps talking about support and other bugs. Andrew: If you see something, say something. 31:00 - Panel: There are languages that run on the beam. Something to create something more standard so different languages can depend on. Is there anything like that? To help you with your tooling? 31:40 – Andrew: Good question! Some of the things that happen at the Dialyzer level, stuff just gets dropped. 33:47 – Guest: How this works all together... 35:15 – Chuck: How to contribute to Dialyxir? 35:30 – Guest: Around error messages – is the best place to look. If you have a good editor hand, good place for that. If you are further into the compiler land – might want to play with that. 36:29 – Guest: ERLEX 36:43 – Chuck: What did you learn about building these libraries? 36:55 – Guest: I learned a lot about the construction of Elixir. Guest dives into this more. 38:25 – Chuck: The principle that you cannot bind... 38:51 – Guest: ...this area of my code-base... it would be nice to turn off those features. When I really do need it – I need it, but not so if I don’t need it. 39:39 – Panel: I want to point someone to a resource: TypeSpecs. 39:54 – Guest: I used that so much! Wonderful resource, I learned so much stuff! I stole all the output from that. I didn’t know that language had that?! 40:20 – Panel chimes in about this resource some more. 41:02 – Guest: We really do have a simple language. There are some weird things, but not a lot of constructs under the hood. Only a few data structures. It could have been more complicated. I was worried about that – but that never happened, because... 41:41 – Panel: Thanks for adding that. Very true. 42:51 – Guest talks about other things that are very simple, too. 44:35 – Panel: Are you doing fulltime with Elixir for programming? 44:35 – Guest: Yes, we are using other Elixir and JS App. In another life I used... They all can teach you something. Sometimes the journey of going there and realizing WHY you don’t want to be there is sometimes worth the journey! 45:20 – Panel asks guest a question. 45:25 – Guest answers question. Andrew: We have enjoyed our time in Elixir. It’s nice. 46:27 – Panel: Anything else? 46:33 – Panel: Where can people find you online? 46:40 – Guest: Elixir Slack, Twitter, GitHub. 47:01 – Picks! 47:05 – Advertisement – Code Badges Links: Andrew Summers’ Twitter Credo Erlang Dialyxir LEEX YECC Credo ERLEX TypeSpecs Curated Dev News for Busy Developers EX_JSON_SCHEMA React – Jsonschema – form Announcing Distillery 2.0 Distillery’s documentation! MKDocs EX_Json_Schema Sponsors: Get a Coder Job Digital Ocean Code Badges Cache Fly Picks: Eric Chrome Extension for News Mark Announcing Distillery 2.0 MKdocs https://hexdocs.pm/distillery/home.html. Charles Launch by Jeff Walker Downcast Andrew Ex json Schema React json schema from

chicago news writing philadelphia launch panel react github printing panelists distilleries credo elixir advertisement isolate schema researched downcast digital ocean jeff walker chrome extensions erlang eric berry cachefly chuck nice panel one charles max wood go1gb907osh060513 elixir mix chuck how andrew summers mkdocs coder job code badges panel you panel it dialyzer leex busy developers dialyxir panel there panel so panel why panel anything panel are

EMx 021: “Dialyzer Pretty Printing” with Andrew Summers

Play Episode Listen Later Oct 2, 2018 53:34

Panel: Charles Max Wood Mark Eriksen Eric Berry Special Guest: Andrew Summers In this episode of Elixir Mix, the panel talks to Andrew Summers who lives in Chicago, currently. Working on Elixir development, and here to talk about how he wrote the dialyzer pretty printer. He is a software engineer for Albert.io, makes cool stuff every day, loves punk music, and Philadelphia sports. The panel talks about the Dialyzer pretty printing, Elixir, code writing, and more! Show Topics: 1:07 – Why are you famous? 1:11 – Andrew: Answers the question. 1:34 – Chuck: Nice. Is the dialyzer printer complete pretty printing or is it more than that? 1:45 – Andrew talks. He mentions the background information on this specific printer, which was written a decade ago. 4:13 – Panel: One thing that is helpful is that it is a static code analysis. In the Elixir we are writing these spec statements. For nothing else than this type is coming out. Then this looks at the code, and your spec says you are returning this, but I can tell that you are also returning X, Y, or Z. So it is helping us see what we are declaring a code to do, and that’s really what the code is doing. 5:28 – Guest: Yes, exactly. To continue that topic here is what else it’s saying... 6:08 – Panel: Our panelist is not here, but he has had to fix code before with that problem. With Dialect Dialyzer – how do we say this library is out-of-date? The code is out-of-date. How do I get my stuff to pass – to clean up my site? 6:54 – Guest: Containing that warning. Guest goes into further detail how to problem-solve this issue. 8:02 – Panel: So you are saying that I can funnel. 8:20 – Panel & Guest go back-and-forth talking about this topic. 9:49 – Panel: I am still diving into the system. Haven’t really used the printer, yet. Panelist asks Guest a question. 10:04 – Guest: At the forefront there are some configurations to help with that. 11:16 – Panel: Why would someone not want to use this? What are the cons? 11:23 – Guest: It would have to do more with CI than anything (one con). 13:06 – Panel: Lots of people are coming to Elixir New. Great. What is the selling point? Why should someone invest his or her time in this project? 13:33 – Guest: I find looking for a type spec is one more piece of information that could help the reader that would tell them what the code should be doing. Any information from the original author to be passed down is great. Having the machine to check that, whenever you push code, it’s an imperfect check (as we were saying). If it can tell you that you did something wrong, then why not? It gives you that extra red flag. There are huge benefits to that. Same reason we write unit tests. 15:20 – Panel: You are learning Elixir right, Chuck? Panelist talks about tech specs, code writing, and learning projects. 16:25 – Panel: Here is a tip to learning. One thing that I did I came to an existing project and writing a sub-system ( as series of modules) Writing the tech specs. As they are interacting with each other, then writing Dial Elixir, and grab the output to the file path to where my code is. Within my own code find where I am inconsistent. Andrew – you could get pages of output, right? Any tips for users? 17:37 – Guest: Isolate portions of your code base. 19:27 – Chuck: I do like the idea of the umbrella. Phoenix app out into an umbrella. A sub apps and they are more centered, smaller sized. Then, yeah. Start with Dialyzer on just that project. Isolate it, and this app in the umbrella. The output is much smaller, and good success with that. Now, one of the new features you added was the language / the code that it reports is an ERLANG term. That is not familiar to most Elixir developers. Especially if you are new to it. If you are turning this into a friendly Elixir thing, then you had to learn other programs. How did you get into this path? 21:00 – Andrew: Whenever there was complicated “something” at work – I was the person to go to. As I started to do it more and more I saw patterns in the output. Things were kind of predictable, and how to format things. It synchronizes weird. What would I do to write this task? Researched. There are 2 tools = LEEX and YECC. If you have 2 files in your source directory... 22:56 – Advertisement – Digital Ocean 23:39 – Panel: It’s cool. 23:58 – Guest: It brought me back to some courses from school. I thought that was funny. They are pretty contained tools. 24:36 – Panel: Part of your motivation was from Jose. 24:49 – Guest: Yes, definitely. 25:39 – Did you have any questions for Jose? 26:35 – Panel: You added the feature of... CREDO is pretty well-known. 27:28 – Guest: Sure, I guess I did skip some of that. Andrew talked about different libraries, ERLANG modules, and so on. 28:38 – Panel: What else are you doing? 28:45 – Getting error messages fixed for version 1.0. Trying to close-up the residual things. 30:18 – Guest keeps talking about support and other bugs. Andrew: If you see something, say something. 31:00 - Panel: There are languages that run on the beam. Something to create something more standard so different languages can depend on. Is there anything like that? To help you with your tooling? 31:40 – Andrew: Good question! Some of the things that happen at the Dialyzer level, stuff just gets dropped. 33:47 – Guest: How this works all together... 35:15 – Chuck: How to contribute to Dialyxir? 35:30 – Guest: Around error messages – is the best place to look. If you have a good editor hand, good place for that. If you are further into the compiler land – might want to play with that. 36:29 – Guest: ERLEX 36:43 – Chuck: What did you learn about building these libraries? 36:55 – Guest: I learned a lot about the construction of Elixir. Guest dives into this more. 38:25 – Chuck: The principle that you cannot bind... 38:51 – Guest: ...this area of my code-base... it would be nice to turn off those features. When I really do need it – I need it, but not so if I don’t need it. 39:39 – Panel: I want to point someone to a resource: TypeSpecs. 39:54 – Guest: I used that so much! Wonderful resource, I learned so much stuff! I stole all the output from that. I didn’t know that language had that?! 40:20 – Panel chimes in about this resource some more. 41:02 – Guest: We really do have a simple language. There are some weird things, but not a lot of constructs under the hood. Only a few data structures. It could have been more complicated. I was worried about that – but that never happened, because... 41:41 – Panel: Thanks for adding that. Very true. 42:51 – Guest talks about other things that are very simple, too. 44:35 – Panel: Are you doing fulltime with Elixir for programming? 44:35 – Guest: Yes, we are using other Elixir and JS App. In another life I used... They all can teach you something. Sometimes the journey of going there and realizing WHY you don’t want to be there is sometimes worth the journey! 45:20 – Panel asks guest a question. 45:25 – Guest answers question. Andrew: We have enjoyed our time in Elixir. It’s nice. 46:27 – Panel: Anything else? 46:33 – Panel: Where can people find you online? 46:40 – Guest: Elixir Slack, Twitter, GitHub. 47:01 – Picks! 47:05 – Advertisement – Code Badges Links: Andrew Summers’ Twitter Credo Erlang Dialyxir LEEX YECC Credo ERLEX TypeSpecs Curated Dev News for Busy Developers EX_JSON_SCHEMA React – Jsonschema – form Announcing Distillery 2.0 Distillery’s documentation! MKDocs EX_Json_Schema Sponsors: Get a Coder Job Digital Ocean Code Badges Cache Fly Picks: Eric Chrome Extension for News Mark Announcing Distillery 2.0 MKdocs https://hexdocs.pm/distillery/home.html. Charles Launch by Jeff Walker Downcast Andrew Ex json Schema React json schema from

chicago news writing philadelphia launch panel react github printing panelists distilleries credo elixir advertisement isolate schema researched downcast digital ocean jeff walker chrome extensions erlang eric berry cachefly chuck nice panel one charles max wood go1gb907osh060513 elixir mix chuck how andrew summers mkdocs coder job code badges panel you panel it dialyzer leex busy developers dialyxir panel there panel so panel why panel anything panel are

Episode 117 feat. Andrew Summers - Dialyzer and its new Pretty Printer

Elixir Talk

Play Episode Listen Later Jun 14, 2018 38:18

We sit with Andrew Summers, contributor to the Dialyxir project and author of its new Pretty Printer. ** SHOW NOTES ** https://github.com/jeremyjh/dialyxir http://erlang.org/doc/man/yecc.html https://github.com/asummers

printers new pretty andrew summers dialyzer dialyxir

EMx 003: Chris Keathley

Play Episode Listen Later May 16, 2018 57:40

Panel: Eric Berry Josh Adams Justin Bean Special Guests: Chris Keathley In this episode of Elixir Mix, the panel talks to Chris Keathley. Chris has been in the Elixir community for a number of years and has been trying to contribute more to the community recently. He created libraries such as Wallaby and has been working on distributed systems tooling more recently. They talk about his various projects that he is working on, such as Raft, Toniq, and Maestro, and much more! In particular, we dive pretty deep on: Chris intro Elixir Wallaby What are you doing with distributed systems now? Raft and Raft for Elixir People like to attack problems with consistent solutions Global process registries What are AP Semantics? What are CP Semantics? Available systems Eventual consistency Clustering inside of VPN Encapsulating state Warehouse kiosks The world fights against state machines Alternatives based on rules or events What projects are you working on now? CAP Theorum Toniq GitHub ecto_hlclock Event sourcing Stems around message ordering Maestro The Little Elixir & OTP Guidebook by Benjamin Tan Wei Hao And much, much more! Links: Wallaby Elixir Raft Raft for Elixir CAP Theorem Toniq ecto_hlclock Maestro Elixir Outlaws The Little Elixir & OTP Guidebook by Benjamin Tan Wei Hao Beam Community Chris’s GitHub Keathley.io @ChrisKeathley Picks: Eric Bob’s Burgers Metabase Justin Phantom Thread Dialyzer Josh Elm Game Jam Chris Wild Wild Country Hammocks Start a garden

EMx 003: Chris Keathley