Stay ConnectedJoin our weekly discussion of the popular functional language built on top of the Erlang virtual machine. Each week, we discuss the world of Elxiir, Phoenix, OTP, and then BEAM.
Become a supporter of this podcast: https://www.spreaker.com/podcast/elixir-mix–6102049/support.
Copyright: © 2018 Intentional Excellence Productions, LLC
In this episode of Elixir Mix the panel interviews Parker Selbert. Parker lives in Chicago and runs a consultancy with his wife. He joins the panel to discuss a library that he wrote, Oban. Parker starts by explaining what Oban is and why he wrote it. Oban is a way to run reliable background jobs by persisting them in the database. Oban is akin to Sidekick, Parker explains, he wanted something similar to Sidekick for Elixir. He made a few improvements including moving it to Postgres from Redis. He shares the common problems found using Redis and how easy Postgres was to use for this library. The panel asks Parker about his Oban Recipes. Parker explains why he wrote the recipes and what some of them contain. After releasing Oban he received many questions asking about how to use Oban. Parker took the most common questions and wrote 7 blog post outlining how to use Oban. Parker shares his favorite features found in Oban and walks the panel through its architecture. The panel asks him about the maturity and usage of the library. Parker tells them that the usage has been steadily climbing. The episode ends with the panel discussing the Oban UI and how it works. Panelists
"The MaxCoders Guide to Finding Your Dream Developer Job" by Charles Max Wood is available on Amazon. Get your copy here today only for $2.99!
Advertising Inquiries: https://redcircle.com/brands
Privacy & Opt-Out: https://redcircle.com/privacy
Become a supporter of this podcast: https://www.spreaker.com/podcast/elixir-mix--6102049/support.
In this episode of Elixir Mix the panel interviews Nathan Long about Pheonix Phrenzy. Nathan explains what Pheonix Phrenzy is and what the contest is all about. The panel explains how exciting it is for everyone to see what Live View can really do. With all the submissions open-sourced, the consider what a great resource the submissions are for those learning to use Live View. Nathan explains his motivations behind Pheonix Phrenzy. He explains what they learned from this contest and what they may do in future contests. Nathan shares how wonderful it was to work with everyone at Dockyard on Pheonix Phrenzy. He explains how the competition worked, the role of the VIP judges and how the site was designed to make the contest as fair as possible. The top three submissions are shared, the panel is impressed by how different each of the projects are. Nathan shares all the amazing things developers get when they use Live View. The panel considers when to use Live View. The episode finishes as Nathan shares what he would like to see in the future versions of Live View. Panelists
In this episode of Elixir Mix the panel interviews Jason Fertel who runs the marketing automation team at PepsiCo eCommerce. Jason shares the story of bringing Elixir to PepsiCo eCommerce and explains how it became their go-to for application development. Jason explains what they do at PepsiCo eCommerce. They build software to optimize everything from supply chain to marketing and sales for big companies in eCommerce like Amazon.com and InstaCart. He explains the difference between what they do at PepsiCo eCommerce and other CPG’s. The panel asks Jason about what Elixir has brought to the table at PepsiCo eCommerce. He explains why he chose Elixir when he started out as a one-man development team. Elixir is powerful, straight forward and easy to learn. It is efficient and has everything you need out of the box. Jason shares how using Elixir has also had a positive effect on hiring. The panel considers how using Elixir has benefitted hiring at their companies as well. The episode ends with Jason outlining their stack and sharing the tools they are using. He also overviews some of the projects they are working on, including sales and marketing automation, end to end supply chain optimization and something exploratory with IoT. They try to foster a culture of exploration and innovation at PepsiCo eCommerce and Jason talks about a Nerves project they are working on to alert consumers when it is time to purchase more snacks. Panelists
On this episode of Elixir Mix the panelists interview Eric Oestrich, one of the regular panelists for the show. Eric is a developer at SmartLogic where he works with Elixir and recently has been working with deployments. He has a project called Grapevine which is similar to steam but for text games. Mark opens up the discussion by asking Eric to talk about his game ExVenture which is a MUD game. MUD stands for multi user dungeon and ExVenture is a multi user version of a text adventure game from 1978 called Dungeon. He shares more details of the game and how it’s played. Erit explains that Grapevine was spawned from ExVenture and Mark asks him to expound more on Grapevine. ExVenture is open source and it is an application that is currently running in production. This provides opportunity for those not interested in making or playing a MUD to get involved and work on a project. Eric also goes into detail about the livestreaming he does and how to get involved. Since the project is open source, Eric is able to do development live, on screen and this allows the viewer to see the development process first hand and watch Eric work through challenges in the code. The topic then shifts to some of the features that are in Grapevine. Eric details some of the OTP style concepts used, the types of servers used and how they’re used, and how telnet sessions are maintained for connecting. The Elixir Mix panelists also discuss how this application is deployed. The application is on DigitalOcean with 2 dedicated cores and he uses Docker to build the releases. Eric also explains how he uses scripting with his releases and how his deployments work. The panelists also discuss how Eric is using Docker for releases but not on the server and why he’s doing deployments the way he is. The last topic covered by the elixir experts is statistics. They cover the metrics section in Grapevine, how he uses Telemetry events, and other methods he uses to gather metrics Panelists
Jeff Kreeftmeijer works at Appsignal where they create a tool for application monitoring that works in Ruby and Elixir. He works specifically with integrations focusing in Elixir and also writes articles for their Elixir and Ruby newsletters. Jeff started as a Ruby programmer but had an interest in functional programming which lead him to gain an interest in Elixir. When he started at Appsignal they were already considering an Elixir integration and that made it a perfect fit. Jeff then shares more details about his involvement in Appsignal’s two newsletters called Ruby magic and Elixir alchemy, both of which are aimed at more experienced programmers. He also details his experience with articles that he wrote on Live Share and how he came to write them. The panelists also introduce the Go game that is written about in these articles. The next topic covered by the Elixir experts is the Go game Live View implementation mentioned in Jeff’s articles. The panelists draw comparisons of how something similar could have been implemented in React. Jeff highlights that he doesn’t have to write JavaScript and doesn’t have to worry about state either. However, in part 1 of Jeff’s current implementation he used a struct to track the state. In part 2 of the implementation, where he implements the code rule, he has another struct that tracks the game. The panelists then discuss how Jeff maintains the game state. In the first version of the implementation he keeps it in the Live View process and when he implemented multiplayer he had to move the game state to a GenServer. He also shares some of the details of why using a GenServer is necessary for multiplayer. Jeff is then asked what his experience was like using a dynamic supervisor and he shares the technical ideas of how this helped him in the project. Next the conversation moves to how the game is able to communicate moves between players to each other. The issue with connecting two sessions to the same Live View is that one player won’t be updated if the other makes a move. Jeff details how using a Pub/Sub helps to overcome this issue. The panelists also discuss ideas of how the game could be implemented in a multi server instance. Jeff shares how his article series still has many more installments that can come out, specifically citing that they haven’t even covered assigning player connections with different player callers. This kind of functionality would handle the assignment of which players controlled which pieces. Jeff closes with highlighting the convenience that comes from using the libraries that they are using as they natively come with technologies they find helpful for building out an interactive, collaborative project. Lastly, the panelists discuss what Jeff is currently doing to work more with these same technologies. Jeff shares that he has a side project where he tries to build a fish tank with artificial intelligence and how he uses Live View for this project. Panelists
This episode of Elixir mix opens with Lars Wikman and Emilio Nyaray sharing how they came to be working together on a project called Inky. Inky is an E-Ink display that works with Nerves and Elixir. The project started when Lars wanted to use the Inky device from Nerves but didn’t want to install Python to do it. Emilio wanted to join because he found it fascinating to be able to control this device with Elixir. Lars and Emilio share some details of how this project came about and how it works. The inky comes in multiple sizes with the smaller pHAT display being about the size of a business card and the Inky wHAT being closer to the size of a Raspberry Pi. Lars shares that one of the biggest gotchas with these displays is the refresh rate. Once the pixels are changed the device can be turned off and still remain the same because they are physically changing. The panelists highlight that very little troubleshooting time had to go in to the Nerves portion of the project. Lars describes how he began looking at using Nerves just after it was announced and how he decided to use it in this project. He also shares how he wants to take on a project to put together a cross stitch of a bigger display that can change each day. One way to do this is by putting multiple pHATs together but Lars would prefer to use a wHAT. The conversation then moves to Emilio sharing his journey to the Inky project. He has been working with Erlang professionally for a year. Ever since he worked with a startup in 2012-2013 where they used Erlang, he has had a strong desire to work with functional programming. This desire eventually lead him to work with Elixir and Phoenix to write a timesheet application as a consultant. When he got in to working with Nerves he borrowed a touchscreen at work and was blown away by how it worked. Emilio also details an audio controller interface side project that he is currently working on. The panelists then talk about the elixir community, what they love about it, the friendliness of the small community, and some individuals that have had an impact on them. The discussion then moves on to the profiling tools eprof, fprof, and cprof. These tools are built into the Erlang Ecosystem. Eprof is a time profiling tool. Fprof is a time profiling tool as well, but it uses trace to file for minimal performance impact. Cprof is a simple call count profiling tool. Emilio shares how he came to be familiar with these, how he used them, and the benefits he saw in his application from using these tools. These profiling tools are also available in Elixir. The panelists also discuss eflame which is a flame graph profiling tool that is very easy to use. Emilio and Lars detail how they used a low dependency approach to be able to fake a display on the desktop for Inky and develop on the desktop.
Panelists
This episode of Elixir Mix features Arkadiusz Gil. Arkadiusz is a software engineer at Erlang Solutions. He is also a member of the observability working group of the Erlang Ecosystem Foundation. The purpose of this working group is to nurture different areas of the community to maintain libraries, improve tooling, and create documentation. He became a member of this group because of his work on Telemetry. The panelists discuss the background of Telemetry and Arkadiusz explains how it was originally written in Elixir and why they decided to switch over to Erlang. Arkadiusz explains how he became involved in Elixir and Erlang. When Mark asks why he prefers Elixir to Erlang he responds with explaining his affinity for the Elixir syntax and tooling that’s available. The conversation then moves to how Telemetry came about. Telemetry started with the goal of creating a tool for monitoring Elixir applications but the creators had no idea what that application would be like. Arkadiusz then describes how he did an exercise with colleagues to identify the specific needs for such an application and how to implement it. The panelists discuss how Telemetry is integrated. They also discuss how to get started with Telemetry metrics and Arkadiusz shares some of the details of how the monitoring service works. The next topic that the Elixir experts cover is how to monitor business data and activity. Arkadiusz explains the mechanism that can be used to attach to events in a custom way to retrieve the exact data that the user needs. He shares that Telemetry can really be used any time a user wants to expose a specific piece of data at runtime. Mark asks how this attaching works and this leads to a deeper technical discussion on how Telemetry attaches a mechanism to the application and returns that data, as well as how the listeners work when an event is fired and new data is sent to it. The panelists then discuss how OpenCensus works with Telemetry. OpenCensus is a project created to culminate API’s that can be used in different languages to create metrics and other data. Arkadiusz shares a hypothetical example of how this works and how Telemetry works with it. The observability working group has helped contribute to OpenCensus. OpenCensus has a smooth integration and is built to run as smooth as possible. A user can use OpenCensus to build metrics based off of Telemetry events. The OpenCensus project is now called OpenTelemetry and it is a merger of OpenCensus and OpenTracing. Finally the Elixir experts cover real world examples of users implementing Telemetry as well as how to get involved with the observability working group and Telemetry. For the observability working group it is best to reach out to them telling them what kind of tooling that would be great to work across the ecosystem and other help they need. One of their goals is to put together a set of best practices for monitoring services. Panelists
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
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
Our TOPPODCAST Picks 
