With newer versions of Ecto you can use Ecto.Schema without even importing Ecto.Repo or setting up a traditional database. Why would you wish to?
Your microservice or other lightweight app may not use a database but you'll probably still need to wrangle some serious data: complex params, JSON request/response bodies, RabbitMQ payloads, etc. That's data that you'll need to parse, cast, and validate.
I'll step you through how to use Ecto.Schema on its own to cast and validate various kinds of data, and how to extract the final results whether the data is valid or invalid.
I'll also discuss some of the stumbling blocks and limitations I've encountered while leveraging Ecto.Schema in this way.
About Rosemary: Rosemary is passionate about writing software with Elixir and Phoenix, and works as a back-end software engineer for RentPath LLC. In her spare time she enjoys hiking, swing-dancing, and rowing (crew).
Coming with Erlang R19 is the option to use your own distribution module. This creates the possibility for having auto-connecting Nerves devices without worrying about the local network or specifying node names upfront. In this talk I will explore the different solutions up until now. One of which was my first go at creating "distributed blinky" (having a led blink on 2+ devices taking turns). Then I will take a look at how we can create our own distribution module and see how we can leverage that so we don't need any upfront knowledge about node names and are independent of the local network. Our goal is to create an autonomously connecting Nerves cluster with zero effort! But, can it be done?
From the conclusion, it is to put a star on projects at GitHub. I'm very happy someone putting a star on my project. So if you already put a star on any projects, it encourage the open source community. But have you put a star on projects developed as oss used in your project? All of them? This talk proposes a solution that activates open source community by putting a star on projects which you depend.
Takayuki Matsubara is a software engineer at M3, Inc. His day job is building and maintaining web apps. He loves open source community, has created chrono_logger, Power Assert in Elixir and other various.
We all use Hex every day on our Elixir projects, but how many of us really know everything Hex can do and how it works? Taking a deep dive into the Hex internals will show you some tips and tricks you can use on a future project.
About Todd: Todd is a Senior Software Engineer at Weedmaps, where he builds solutions for the cannabis industry. Previously, he has built solutions for the K-12 education market, worked in advertising, and as the front-end lead for Newegg.com. In his free time, he enjoys tinkering with hardware, woodworking, and spending time with his wife and 4 kids.
Ruby is used everywhere now. In this talk we will compare Ruby concurrency with Node.js, JVM, Erlang and others.
Ruby supports concurrency but with GIL, it can't run threads parallely. We will explore options available that makes this problem irrelevant.
Node.js doesn’t support concurrency or parallelism. Node.js is single threaded. It runs an event loop which makes non blocking IO possible. We will explore why Node.js fits well to only certain types of problems only
JVM supports native threads and can do parallelism. But in JVM memory is still shared among different objects. We will explore JVM architecture in regards with memory. Where JVM gets it wrong.
Erlang/Elixir achieves concurrency and parallelism with shared nothing, immutable data, first class processes, actor model. We will explore whether this approach is better for solving every kind of problem.
Talk will have deep comparison with all of these platforms in regards with what most real world project need,
Anil Wadghule, @anildigital
I am a geek but a senior software developer by profession, currently working for Equal Experts, India. When not programming, I spent time in exploring music around the world. Emacs is my text editor of choice. I love watching Japanese animes.
Making distributed systems that scale to many machines is easier done with Erlang/OTP than most other technologies. Deploying, managing and monitoring thousands of Erlang nodes prepared for massive load, however, remains a tough (and repetitive) challenge. In the context of the EU funded RELEASE project, the main task of WombatOAM is to provide the scalable infrastructure for deploying thousands of Erlang nodes. It provides a broker layer capable of dynamically scaling heterogeneous cloud clusters based on capability profile matching.
In this talk, I will tell you how the scalability and robustness capabilities of WombatOAM were addressed, allowing us to deploy and monitor 10,000 Erlang nodes running an ant farm simulation in 4 minutes. The talk will cover the journey – focusing on the analysis of WombatOAM (using WombatOAM, as we like dog food), on the applied techniques and on the key decisions taken when advancing WombatOAM.
Learn how to detect bottlenecks in concurrent system.
Explore an approach to scaling Erlang clusters.
Discover how to predict and prevent possible outages.
Developers, Support and Operations staff who believe devops is the way (and do not want to be woken up at night).
"Building a Graphical IDE in Elm/Purescript for an Embedded Language that Compiles to the Erlang VM"
Our PLC programming language implementation gets compiled to BEAM files and runs in the Erlang VM. That allows us to take advantage of Erlang's distributed model, and through our custom websocket library the IDE can talk directly with a Cowboy handler running on the device, to get debugging information in realtime.
We'll also cover our choice of framework when porting the IDE to Purescript, good and less good parts of the two languages, and how they relate to Haskell.
Phoenix and Phaser might sound like a cheesy pop band but get these two frameworks playing nice together and you're guaranteed a party. Both are blistering fast, and incredibly easy to use. Building multiplayer games has never been easier.
This talk will take you on a step by step guide building yourself a game template, and then using that template to create several multiplayer games. We will introduce you to the joy of creating games using these two wonderful frameworks, and demonstrate some of the possibilities, as well as highlighting some of the challenges and common pitfalls to avoid when developing multiplayer games.
Beginners and anyone interested in having fun with Phoenix channels.
Keith is a programmer, sailor and kitesurfer in any order. He is passionate software development and particularly enjoying building fun social games. He is currently writing a book of the same title as this talk
As software developers, a lot of the time we’re building applications that rely on some sort of network connection. Due to Ruby’s great abstractions we take most of the network related stuff for granted. We think we know how all of that works, but do we? Let’s go over the fundamentals together, learn about how Ruby models TCP Sockets and how we can make a good use of it.
This talk will explore the fundamentals of programming with sockets. This includes creating sockets, client and server life-cycle, reading and writing data, non-blocking IO and connection multiplexing. We’ll wrap up by looking at how those concepts are used in real world problems by web servers.
About Sebastian Sogamoso
Hola! My name is Sebastián. I am love pair programming and have a passion for teaching. I am part of the Cookpad, Inc team.
I organize RubyConf Colombia and I am also involved with local software development groups and help organize the Bogotá Ruby and Elixir meetups.
Delivered at WindyCityRails 2016 in Chicago, IL, USA.
Learn more about WindyCityRails at http://windycityrails.com.
Phoenix contexts are a powerful code organization tool - but without a clear idea of what business domains live under the hood of your systems, naively creating contexts leads to over-engineered, fragile systems.
Today, we’ll learn about the philosophical roots of Bounded Contexts from the hard-earned wisdom of Domain-Driven Design. We’ll quickly get our hands dirty in the nuts and bolts of a Context Mapping exercise, a strategic design tool that reveals domain-specific system boundaries. With our newfound architectural vision, we’ll learn how to write context-driven Phoenix code and develop some organizational rules around communication, boundary enforcement and testing between contexts. We’ll leverage the unique powers of Elixir that make this style of architecture so natural and see how using contexts easily leads to highly-cohesive and loosely-coupled outcomes!
About Andrew: Andrew is a software engineer at Carbon Five, where he builds digital products for companies of all shapes and sizes. He enjoys trail running anywhere there are mountains. Though he currently lives in Oakland, he dearly misses his years living in (and eating through) Los Angeles.