Finally off school and with a lot of free time in the summer to devote to side projects. To warm myself back into writing blog posts I decided to start with a fairly simple but very useful topic: application configuration.

I’ve seen a few small Erlang projects resort to custom configuration syntax, strange XML parsing, etc. for configuration but Erlang has support for easy application configuration built right in! The syntax is simple enough for a non-programmer to grok and is extremely flexible for application developers. As an added bonus, no external libraries are required.

More…

Up to this point, my experience with Erlang professionally has mostly been with ejabberd. I’ve created many ejabberd modules and have had to modify ejabberd core for certain projects (sometimes heavily). Now that my current client work at CitrusByte is over, I’ve been notified I will be working on a fairly customized Erlang/OTP application. Without going into too much detail, I have just began seriously looking at EUnit.

More…

This is the seventh and final article of the Erlang/OTP introduction series. If you haven’t already, I recommend you read the first article which lays the foundation for the application which we’ll be upgrading in addition to teaching you the basics of Erlang/OTP before jumping into the topic of this article. If you’re a quick learner or you wish to jump straight into this article, you may click here to download a ZIP of all the files up to this point.

The Scenario: ErlyBank has been running strong for a few months now and based on customer feedback, the bank wants to implement some additional features. First, they want us to implement a credit-based account. This is similar to a normal account except that withdrawals may be made to go into the negative, meaning that money is owed on the credit account. They also want us to change the ATM so that people can only use the ATM to pay bills with a credit account. And to top this all off, they want us to do these upgrades without significant downtime.

The Result: We’ll create a credit server to easily add a credit account system and following that we’ll change the ATM. Luckily for us, once we make these changes, there is a straightforward way of upgrading the system in real-time so that ErlyBank won’t experience much, if any, downtime.

More…

This is the sixth article in the otp introduction series. If you haven’t yet, I recommend you start with the first article which talks about gen_server and lays the foundation for our bank system. If you’re a quick learner, you can download the ErlyBank sources as of the beginning of this post.

This article will introduce release management of an Erlang application. This is not necessarily restricted to Erlang/OTP applications, and is a general tool that may be used for all your Erlang applications.

Release Management refers to consolidating an application and its dependencies into a single package which can be easily started and stopped as a whole. Releases can be “installed” into an Erlang runtime system. Releases can also be upgraded in real-time, so when a new version of the application is created, it can be seamlessly installed into the system without bringing it down. (Note that real-time system upgrades are covered in the next article, not this one!)

After bundling the ErlyBank system as an application, restructuring it to be an Erlang release is very easy. But first, we’ll need to do some housecleaning to the directory structure.

More…

This is the fifth article in the otp introduction series. If you haven’t yet, I recommend you start with the first article which talks about gen_server and lays the foundation for our bank system. If you’re a quick learner, you can read the completed erlang files so far: eb_atm.erl, eb_event_manager.erl, eb_server.erl, eb_sup.erl, and eb_withdrawal_handler.erl.

The Scenario: The ErlyBank system is in a nice state right now with everything wrapped up under the supervisor, but ErlyBank is pressuring us to come up with a package which specifies an overall version so the system can be upgraded as a whole and can be controlled easily. They’ve commissioned us to do this task.

The Result: Erlang/OTP has a built-in module for making a set of modules which achieve some set of functionality into an application. An application can be started and stopped as a unit and can easily be reused in other systems.

More…

This is the fourth article in the otp introduction series. If you haven’t yet, I recommend you start with the first article which talks about gen_server and lays the foundation for our bank system. If you are a quick learner, you can view the currently completed erlang files so far: eb_server.erl, eb_event_manager.erl, eb_withdrawal_handler.erl, and eb_atm.erl.

The Scenario: The thing that makes us feel good about banks and ATMs is that they are always there. We can deposit and get money whenever want, 24 hours a day, using an ATM. Or we can go into any bank branch when they’re open, and know we have complete access to our funds. To achieve this security, we need to make sure that our system to run ErlyBank always stays working: the processes must always be running. ErlyBank has commissioned us to achieve this goal. 100% uptime! (Or as close to that as we can get)

The Result: Using an OTP supervisor, we will create a process whose responsibility it is to watch the running processes and make sure they stay up.

More…

This is the third article in the otp introduction series. If you haven’t yet, I recommend you start with the first article which talks about gen_server and lays the foundation for our bank system. Again, if you’re a quick learner, you can look at the completed eb_atm.erl and eb_server.erl here.

The Scenario: With central server and ATM software in place, ErlyBank is started to feel good about their technological foundation. But as a security measure, one of their competitors, they’d like a system implemented which dispatches notifications when a withdrawal over a certain amount is executed. They want the ability to change the withdrawal notification amount threshold during runtime. They’ve chosen to hire us to streamline this into the current system software.

The Result: We’ll create an event-based notification system using gen_event. This will give us a base foundation for creating more notifications in the future, while allowing us to easily plug-in to the current server software.

More…

This is the second article in my Erlang/OTP introduction series. If you haven’t yet, I recommend you read the first article which talks about gen_server and lays the foundation for our bank system before moving onto this article. That being said, if you’re a quick learner, you can look at the completed server file and continue from there.

The Scenario: We delivered ErlyBank’s server to them and they were very pleased. But this is the 21st century so they also need a secure and easy to use ATM system, so they’ve asked that we extend the server and also create their ATM backend. User accounts are to be protected with a four-digit PIN. From the ATM you should be able to log in to a previously existing account, and deposit or withdraw funds. There is no need to create a pretty user interface on top of the ATM backend, they have another team doing that.

The Result: First, we’ll extend the server software to hold a PIN for accounts, and add an authorization call to it. Then, we’ll use gen_fsm to create the ATM backend. We’ll rely on the server to do all the data validation.

As always, click read more to get started, if you haven’t already…
More…

This is the first article in a series of articles introducing all the concepts pertaining to Erlang/OTP. In order to find all these articles later, they are tagged with a unique tag to the series: otp introduction. As promised in my initial introduction to OTP, we will be making a server to handle the fake bank accounts of people at “ErlyBank” (Yes, I enjoy coming up with silly names).

The Scenario: ErlyBank is just starting and they want to start off on the right foot by creating a scalable system for managing the bank accounts of its important customer-base. Having heard about the powers of Erlang, we have been hired to do that! But to test us out, they first want a simple server to handle the creation and destruction of accounts, depositing money, and withdrawing money. They just want a prototype, not something they’ll actually be putting into production.

The Result: We will create a simple server and client to do everything they asked using gen_server. Since its just a prototype, we’ll store the account information in memory for now. The accounts will only be referenced by name, no other information is necessary to create an account. And of course we’ll have validation on withdrawals and deposits.

Note: Before beginning this series, I am assuming you have a basic knowledge of the Erlang syntax. If not, I recommend reading my compendium of beginner erlang resources to find a place you can learn Erlang.

If you’re ready, click read more below to get started! (Unless you’re viewing the whole article already )

More…

Many people refer to Erlang as “Erlang/OTP.” OTP stands for Open Telecom Platform, and is more or less a set of libraries which come packaged with Erlang. They consist of Erlang behaviors (or behaviours, technically) for writing servers, finite state machines, event managers. But that is not all, OTP also encompasses the application behavior which allows programmers to package their Erlang code into a single “application.” And the supervisor behavior allows programmers to create a hierarchy of processes, where if one process dies, it will be restarted.

OTP is much too complex of a thing to explain in a single article, and I will not attempt to do so here. Instead, I will be making this a series of articles spanning a couple weeks.

Why should I learn about Erlang/OTP?

The platform which comes with Erlang gives you a rich and very generalized set of libraries and behaviors to easily create highly available, fault tolerant, hot code swapping ready systems. The following is a basic list of what it gives you “for free:”

• Generic server, finite state machine, and event manager behaviors
• Standardized application structure
• Hot swappable code
• Supervisor Trees so your processes always stay up

In addition to these free features, OTP is the standardized way to create systems in Erlang. The big name open source Erlang applications such as ejabberd, CouchDB, and MochiWeb all use OTP.

Therefore, by learning OTP, you will not only gain the knowledge and ability to create powerful Erlang systems, but you’ll be able to readily jump into other open source projects and learn from them, since they follow the same general structure.

If you know the general Erlang syntax, then you’re ready to jump in and begin learning about Erlang/OTP!

Click read more below to read the rest of this introduction

More…