I will be covering building a weather station using Nerves. I would be glad to cover any questions others have, you can follow along with the progress on frankkumro.com. Part #5 hopefully coming this weekend.
@justuseapen - What kind of chatbot framework will it be and what will it enable you to do? (Sorry if that’s a daft question!)
@frigidcode - I was going to ask what you’ll be doing with the weather station, then found this on your site:
My house is at the top of a hill, and no weather stations are close enough to accurately determine the wind speeds. Being the nerd that I am, knowing the current and historical wind speeds is something I would love to play with. I am most interested in the wind speeds during storms. Being able to use Elixir to build this project makes it even more fun!
I’ll try to answer these one at a time (and contain my ambition for the project).
“What kind of chatbot framework will it be?”
Think Rails for Chatbots. An opinionated framework that favors convention over configuration. It emerged from a project we built last year. We realized that MVC doesn’t fit the application requirements of a chatbot. In the process of developing an alternative, we realized the most intuitive architecture for a cognitive agent would necessarily mirror our own cognitive processes. (Executive Coordination, Fast Thinking, Slow Thinking).
“What will it enable you to do?”
I’m hoping by September you’ll be able to scaffold chatbots for a number of platforms in minutes. Ideally you’ll be able to manage any number of “personalities” in a single repository. We will also have NLP Clients readily accessible either via Hex Package or natively to the framework.
And, I’d love to hear what other people WANT (or expect) in a chatbot framework.
You could probably start a dedicated thread for that though for me personally, it’s something I’d like to be able to use in my own (Elixir) apps, rather than some other platform or service.
There’s actually a bot in Discourse, but I haven’t switched it on as I figured most people on this forum will be tech savvy. If it interests you, you can read more about it here - but it basically walks new members through some basic features
I will be giving a talk on how I got my multiplayer text-based game server, ExVenture, working across multiple nodes. My talk is titled “Going Multi-Node”.
I’ll be speaking about understanding memory usage in BEAM apps.
In short “WOAH I think I got memory leaks here, what do I do?”, so covering tools we can use to diagnose that, why it happened when it happened to me and things I now keep in mind when reviewing code!
I’ll talk about what triggers recompilation in Elixir code, why it needs to happen and how to avoid getting in a situation where you change a seemingly isolated module and get your whole project recompilated.
This is specially ~troublesome~ important as the projects grow beyond 1000+ modules. The talk is mostly based on my experience at the same project I talked about last year in my talk “Phoenix after 100,000 lines”
I’ll also talk about how the elixir team heard feedback from the community and all the new changes that addresses this issue.
I’m going to be talking about building an API with Absinthe and Dataloader.
I will be through the steps to turn a Phoenix app into an explorable GraphQL API. Absinthe and GraphQL were to me when I first started learning them and I want to help others realize that there is nothing to fear. We will generate a Phoenix and Ecto app from scratch and gradually introduce some Absinthe and Dataloader to the code.
It should be a great introduction to Absinthe if you haven’t used it before. Even if you have, Dataloader adds a lot of neat shortcuts that make the code much shorter and easier to work with. If you were wondering if you capitalize the ‘L’ in Dataloader, I was too, so feel free to find out and answer me here!
I will be talking about how you can use Elixir and OTP to bring better visibility to your legacy infrastructure. I will also discuss how to expose the monitoring results in Phoenix and make it available to a metrics pipeline.
The tricky part behind property-based testing is to find the properties we want our code to hold.
I’ll help you find those properties.
Property-based testing is a nice complement to the example-based testing you’re probably used to. It uses data generators to spin up a bunch of tests for you. It can help catch edge cases in your code. However, it can be difficult to make the leap from example-based testing to property-based testing. I want to help you make the leap
Specifically, my talk will focus on how to identify properties to test. We’ll walk through a coding challenge in depth, and we’ll use StreamData to test the properties we find.