# erlang Published articles for erlang. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Specula: Scaling formal specifications for autonomous model checking of system code DevFeed: [Specula: Scaling formal specifications for autonomous model checking of system code]() Original publisher: [Read original article]() Author: Murat (noreply@blogger.com) Published: 2026-08-12T21:33:44Z Content type: opinion Language: en Sources: [Metadata]() Topics: [Concurrency](), [scaling](), [bug](), [Code](), [systems](), [Software](), [Open Source](), [Network](), [C](), [Erlang](), [MongoDB](), [Rust]() Tags: [agentic](), [bug](), [code](), [concurrency](), [developers](), [distributed](), [erlang](), [etcd](), [formal-methods](), [mongodb](), [network](), [open-source](), [paper-review](), [rabbitmq](), [rust](), [scaling](), [tla]() ### AI overview An opinionated analysis of Specula, an agentic system that automatically derives TLA+ specifications from software, validates them against code, model-checks for concurrency bugs, and generates integration tests. The article discusses reported results across 48 open-source distributed and concurrent systems, including 249 bugs found, while also raising unresolved questions about the approach. ### Source excerpt Specula is an agentic system that automates the process of software bug finding through authoring and model-checking a spec for the code. It derives TLA+ specifications automatically from the code, checks code-spec conformance through trace validation, model checks the spec to find concurrency bugs, and reproduces the bug at the code layer by writing integration tests with precise timing. I remember reading the Daikon paper "Quickly detecting relevant program invariants" in 2000 and getting impressed by it, and here we are after 26 years, solving the end-to-end problem much better than I ever thought would be possible in a push-button manner in the year of our lord 2026. But somehow, I am still somewhat unsatisfied with the paper. This may be me being hypercritical and trying to get more out of the paper by arguing with it. So bear with me until I resolve (or learn to accept) these problems over time. I know many of the authors of the Specula work, and respect them, and I know they won't take my critiques about the larger problem in a wrong way... I am trying to make sense of the terrain myself. So, let's look at what Specula gets right, its major contributions, and then dive into my unresolved questions and existential thinking about the terrain. Why is Specula an Impressive Achievement Specula is run on "slices of" 48 complex open-source distributed and concurrent systems including MongoDB, Microsoft's SONiC network OS, GCC's libgomp, Etcd, and RabbitMQ's ra. It found 249 bugs, 207 of them new. The 48 systems span 7 languages, from C to Erlang to Rust. This is very impressive, and it earns the "scaling" claim in the title of the paper. Hand-crafting TLA+ specifications may take weeks (especially for unfamiliar code bases), and Specula completes end-to-end checks in 1.4 to 9.8 hours at a median token cost of 57 dollars per system. Did I mention this is all push-button? Developers just review the end results. They may not even have to look at the TLA+ specs, and the ## How Klarna Migrated the KRED System from Mnesia to Postgres with Zero Downtime DevFeed: [How Klarna Migrated the KRED System from Mnesia to Postgres with Zero Downtime]() Original publisher: [Read original article]() Author: Onno Vos Dev Published: 2025-02-26T09:04:27Z Content type: article Language: en Sources: [Klarna Engineering]() Topics: [Databases](), [Erlang](), [Replication](), [sharding](), [Transactions](), [systems]() Tags: [cluster](), [databases](), [erlang](), [klarna](), [memory](), [postgresql](), [production](), [replication](), [scaling](), [sharding](), [software-development](), [software-engineering](), [transactions]() ### AI overview This article describes Klarna's migration of KRED, an Erlang servicing system, from Mnesia to Postgres with zero downtime. It explains the original replicated seven-node architecture, the system's scaling challenges, and a plan involving sharding across multiple clusters. ### Source excerpt How we migrated from Mnesia to Postgres with zero downtime Back in December 2004, an Erlang application was born called KRED (referring to the freshly-started company called Kreditor, now known as Klarna). KRED is one of the "servicing systems" at Klarna and keeps track of consumer debt (among other things). It was powered by Mnesia and consisted of a cluster of 7 nodes, each holding a full copy of the database on disk. The data was replicated using a custom replication mechanism built in-house by Klarna. One node was elected as the leader and its database was considered the source of truth in the system. All database transactions were executed on the leader and writes were replicated to the rest of the nodes, the so-called followers. The Mnesia database was around 15 TB and at its peak in 2018 around 1.3 TB was held in memory at all times. Considering that few suppliers were selling hardware with such specs, it's easy to claim the crown of one of the biggest Mnesia databases in terms of in-memory storage, that was running in production. The rest of the data was offloaded to disk using mnesia_eleveldb. KRED has been a stable workhorse at Klarna so why change a winning concept? Get ready, for a two part blog post where we'll first go through our journey of how we went about this and secondly, how we made Mnesia behave just like Postgres and implemented our version serializable isolation level on top of Postgres! How the journey started Three engineers, sat down in a bar in Stockholm, Sweden and asked this question: 'When Klarna truly takes off, will KRED survive? Assuming "no", and presented with a blanco check, how would we tackle this problem?' The answer quickly revolved around the issues of running Mnesia on an even larger cluster and with leveldb compaction hitting some hot tables during peak times. One can only imagine how that problem would just continue to get worse over time. Considering the three engineers had worked on KRED for a long time, scaling KRED wa ## New Chainguard Images December 2024: Adoptium, AWX, CouchDB DevFeed: [New Chainguard Images December 2024: Adoptium, AWX, CouchDB]() Original publisher: [Read original article]() Published: 2025-01-16T00:00:00Z Content type: release Language: en Sources: [Chainguard: Unchained]() Topics: [Adoptium](), [openjdk](), [Ansible](), [Java](), [NoSQL](), [Open Source](), [Erlang](), [.NET MAUI](), [Process]() Tags: [adoptium](), [ansible](), [apache](), [awx](), [chainguard](), [chainguard-images](), [container-images](), [couchdb](), [erlang](), [helm](), [java](), [jdk](), [linkerd](), [net-11](), [nosql](), [open-source](), [opentofu]() ### AI overview Chainguard describes its December 2024 batch of 39 new Chainguard Images, highlighting images for Adoptium, AWX, and Apache CouchDB. The article notes FIPS-enabled variants and summarizes the intended uses and image characteristics. ### Source excerpt Chainguard released several new images in December 2024, including images for Adoptium, AWX, CouchDB, and others. Check out the full list. ## 1BRC--The Results Are In! DevFeed: [1BRC--The Results Are In!]() Original publisher: [Read original article]() Published: 2024-02-04T15:34:00Z Content type: article Language: en Sources: [Gunnar Morling]() Topics: [Java](), [Pull Request](), [Go Language](), [Rust](), [Databases]() Tags: [c](), [c-plus-plus](), [c-sharp](), [competition](), [databases](), [erlang](), [go](), [java](), [leaderboard](), [pull-request](), [rust]() ### AI overview This article reports the final results of the One Billion Row Challenge, a competition to aggregate random temperature values from a one-billion-row file. It describes participation across multiple programming languages, databases, and tools, and notes that 164 submissions were reviewed after the competition closed. ### Source excerpt Table of Contents Results Bonus Result: 32 Cores, 64 Threads Bonus Result: 10K Key Set Thank You! Which Challenge Will Be Next? Oh what a wild ride the last few weeks have been. The One Billion Row Challenge (1BRC for short), something I had expected to be interesting to a dozen folks or so at best, has gone kinda viral, with hundreds of people competing and engaging. In Java, as intended, but also beyond: folks implemented the challenge in languages such as Go, Rust, C/C++, C#, Fortran, or Erlang, as well databases (Postgres, Oracle, Snowflake, etc.), and tools like awk. It's really incredible how far people have pushed the limits here. Pull request by pull request, the execution times for solving the problem layed out in the challenge -- aggregating random temperature values from a file with 1,000,000,000 rows -- improved by two orders of magnitudes in comparison to the initial baseline implementation. Today I am happy to share the final results, as the challenge closed for new entries after exactly one month on Jan 31 and all submissions have been reviewed. ## Router 2.0 Common Runtime Router: The Road to Beta DevFeed: [Router 2.0 Common Runtime Router: The Road to Beta]() Original publisher: [Read original article]() Author: Elizabeth Cox Published: 2023-10-30T22:00:00Z Content type: article Language: en Sources: [Heroku]() Topics: [Heroku](), [Routing (disambiguation)](), [Erlang](), [servers](), [Concurrency](), [legacy](), [Scalability](), [Open Source]() Tags: [concurrency](), [engineering](), [erlang](), [http-server](), [legacy](), [modernization](), [open-source](), [release](), [router-2-0](), [routing](), [scalability]() ### AI overview Heroku describes the beta release of Router 2.0, a replacement for the existing Common Runtime router planned for 2024. The article explains the legacy router's Erlang-based architecture and the challenges that motivated a new implementation, including safer delivery of routing features and planned HTTP/2 support. ### Source excerpt Last month, Heroku announced the beta release of Router 2.0, the new Common Runtime router! As part of our commitment to infrastructure modernization, Heroku is making upgrades to the Common Runtime routing layer. The beta release of Router 2.0 is an important step along this journey. We're excited to give you an inside look at [...] The post Router 2.0 Common Runtime Router: The Road to Beta appeared first on Heroku. ## Taking Another Look at Phoenix and Elixir - Part 1 - Upgrading DevFeed: [Taking Another Look at Phoenix and Elixir - Part 1 - Upgrading]() Original publisher: [Read original article]() Author: Fuzzygroup Published: 2020-09-15T14:23:00Z Content type: tutorial Language: en Sources: [Scott Johnson]() Topics: [Elixir](), [phoenix](), [Homebrew](), [Package manager](), [Erlang](), [Rails]() Tags: [elixir](), [erlang](), [homebrew](), [installation](), [phoenix](), [rails](), [tooling](), [upgrade]() ### AI overview A practical guide to upgrading Elixir, Erlang/OTP, Mix, Hex, and Phoenix, then creating a sample Phoenix application and preparing to compare it with an existing Rails codebase. ### Source excerpt I've been on the fence about Phoenix and Elixir for a while and I thought I'd take at least a quick dive. I've had a development system for Phoenix and Elixir since at least 2016 but I haven't done much. This means that the first task is bringing it into the 2020s. Upgrading Elixir I installed Elixir via HomeBrew which means it is a simple: which elixir /usr/local/bin/elixir Note: It can be hard sometimes to know if you installed things via HomeBrew and checking their location is an easy cheap as HomeBrew installs stuff to /usr/local/bin And then: brew upgrade elixir And then: elixir --version Erlang/OTP 23 [erts-11.0.3] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [hipe] [dtrace] Elixir 1.10.4 (compiled with Erlang/OTP 23) You can also use just -v: elixir -v Erlang/OTP 23 [erts-11.0.3] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [hipe] [dtrace] Elixir 1.10.4 (compiled with Erlang/OTP 23) Upgrading Mix and Hex Mix and Hex give the equivalent of a build tool (like Rake from the Rails world) and a Package Manager (like Gem / Bundler). To upgrade mix, you use: mix local.hex Found existing entry: /Users/sjohnson/.mix/archives/hex-0.20.5 Are you sure you want to replace it with "https://repo.hex.pm/installs/1.10.0/hex-0.20.5.ez"? [Yn] Y * creating /Users/sjohnson/.mix/archives/hex-0.20.5 And that will upgrade both mix and hex. Upgrading Phoenix The phoenix framework version I have dates back to 1.2 or 1.3 I think. The first step is to figure out what version I have: mix phoenix.new --version Phoenix v1.3.3 The method to upgrade the Phoenix framework itself is: mix archive.install hex phx_new 1.5.4 I used a google query to discover that the current Phoenix framework version was 1.5.4. The other way to find this version number is to go to this url: https://hexdocs.pm/phoenix/installation.html And then look at the drop down of different versions in the left hand sidebar. The latest version is always at the top. Creating a Sample App My fir ## Developer Spotlight: Postmates DevFeed: [Developer Spotlight: Postmates]() Original publisher: [Read original article]() Author: Richard Moot Published: 2019-08-14T10:00:00Z Content type: article Language: en Sources: [Square Corner Blog](), [Square Corner Blog RSS Feed]() Topics: [API](), [Binance](), [Back end](), [Front end](), [React](), [Elixir](), [Erlang](), [Go](), [Python](), [Redux](), [Scala](), [TypeScript]() Tags: [api](), [apis](), [backend](), [developer](), [developer-velocity](), [elixir](), [erlang](), [frameworks](), [frontend](), [go](), [integration](), [java](), [kotlin](), [python](), [react](), [redux](), [scala](), [slack](), [spotlight](), [swift](), [typescript]() ### AI overview Square's developer spotlight features Postmates and discusses its integration with the Square Orders API, along with Postmates' engineering organization, development practices, and technology stack. ### Source excerpt Postmates talks with us about their integration of Orders API ## The Evolution of the Developer Retreat DevFeed: [The Evolution of the Developer Retreat]() Original publisher: [Read original article]() Author: Bruce Eckel Published: 2018-09-06T00:00:00Z Content type: opinion Language: en Sources: [Bruce Eckel - Computing Thoughts]() Topics: [Kotlin](), [Elixir](), [Flutter](), [Erlang](), [Android](), [iOS]() Tags: [android](), [conferences](), [developer](), [elixir](), [erlang](), [events](), [evolution](), [flutter](), [ios](), [kotlin](), [self-organizing]() ### AI overview The author reflects on a developer retreat that used no central theme or fixed structure. Participants worked independently, shared discussions, and explored Kotlin, Elixir, Erlang, and Flutter, among other topics. ### Source excerpt I've been experimenting with different forms of events for many years now. Mostly this has been in the form of self-organizing conferences, but in recent years I've tried going further, to even less structure. I've held a number of "developer retreats" where we had a theme that everyone focused on, and those have been quite interesting and valuable. To be honest, what I really wanted to try with the developer retreats is zero structure. ## CloudFormation vs. Terraform DevFeed: [CloudFormation vs. Terraform]() Original publisher: [Read original article]() Author: Wojtek Gawroński (afronski) Published: 2017-04-11T08:00:00Z Content type: comparison Language: en Sources: [Wojtek Gawroński]() Topics: [Terraform](), [AWS CloudFormation](), [Amazon Web Services](), [Infrastructure as code](), [vendor lock-in](), [Disaster Recovery]() Tags: [aws](), [aws-cloudformation](), [c-sharp](), [canvas](), [clojure](), [css](), [css3](), [disaster-recovery](), [erlang](), [html](), [html5](), [infrastructure-as-code](), [javascript](), [mono](), [net](), [node-js](), [sicp](), [terraform](), [vagrant](), [vendor-lock-in](), [webgl]() ### AI overview This comparison examines Terraform and AWS CloudFormation for automating cloud infrastructure. The author explains the decision to use a pure CloudFormation setup, choose AWS, and drop Terraform, while discussing provider dependence, vendor lock-in, and disaster recovery considerations. ### Source excerpt CloudFormation vs. Terraform. a There is a time when every project that uses a cloud computing service has a difficult choice to make - should we automate the infrastructure or not? Immediately after, another question pops up - how should we do it? Should we use a dedicated tool (AWS CloudFormation, Azure Resource Templates, OpenStack Heat or Google Cloud Deployment Manager) or a provider-agnostic solution? And then - immediately after a surprise comes in - at first glance, there is no other tool like Terraform available on the market (but there is - it is called Foreman :wink:). So we have a good tool, built by amazing people (HashiCorp) which does not rely on any particular cloud - problem solved? Not entirely. As a grown up, you know that like the ORM does not let you change database on the fly, Terraform will not let you automatically switch your cloud provider for your entire system. From the other hand - you fear vendor lock-in, and for sure you are considering how to design and prepare disaster recovery scenarios. A lot of unknowns, isn't it? I would like to show my rationale for a new project and infrastructure for which I, among others, was responsible. The motivation which drove us towards a pure CloudFormation setup, the reason behind our bet on AWS, and the motivation behind the decision to drop Terraform. Keep in mind that all remarks and comments pointed in this article are constructive criticism - it does not change my opinion about companies that created those tools at all. I have huge respect for both for AWS and HashiCorp - the work they have done, especially in tooling and cloud computing landscape is outstanding. As a user of AWS Services and HashiCorp tools I am grateful for the work they did. If you do not have experience with CloudFormation or Terraform - please read either amazing documentation or any other introductory article. I will assume your basic knowledge about these two. Terraform is not a silver bullet. When I evaluated Terraform, i ## Socket API thoughts DevFeed: [Socket API thoughts]() Original publisher: [Read original article]() Author: Marek Published: 2017-02-22T23:00:00Z Content type: opinion Language: en Sources: [Marek Majkowski]() Topics: [Unix](), [Processes](), [Concurrent Programming](), [IO](), [Streams](), [Erlang](), [Go Language]() Tags: [api](), [erlang](), [go](), [processes](), [stream](), [unix]() ### AI overview The article examines whether Unix processes, file descriptors, and select() were designed around CSP-style communication. It concludes that they were not, while discussing composability limits and buffering-related problems in Unix process and I/O models. ### Source excerpt Socket API thoughts I/O multiplexing, commentary Some time ago I wrote about a history of syscall. While that piece was a necessary introduction to the followup post, it triggered interesting discussions. It took me a while but I finally realized what is the core question I asked myself. Here it is: Were Unix processes intended to be CSP-style processes? Are file descriptors a CSP-derived "channels"? Is "select()" equivalent to ALT statement? The direct answer is "no". CSP is younger than Unix. ## How V8's compilation cache supports function inlining DevFeed: [How V8's compilation cache supports function inlining]() Original publisher: [Read original article]() Author: Wojtek Gawroński (afronski) Published: 2016-04-08T17:45:00Z Content type: article Language: en Sources: [Wojtek Gawroński]() Topics: [Compiler](), [V8](), [JavaScript](), [JIT](), [Optimization](), [Node.js]() Tags: [article](), [c-sharp](), [cache](), [canvas](), [clojure](), [compilation](), [compiler](), [css](), [css3](), [erlang](), [html](), [html5](), [inlining](), [javascript](), [mono](), [net](), [node-js](), [optimization](), [sicp](), [v8](), [vagrant](), [webgl]() ### AI overview This article explains why just-in-time compilation in V8 is difficult for JavaScript and discusses compilation caching as an optimization technique related to function inlining. It distinguishes compilation caches from inline caches. ### Source excerpt A mythical beast called JIT I have recently bumped into one of those articles which title sounds rather like "one weird trick" ad. Guiding just from it, you can imagine how small amount of information is contained there, and by actually going through that link there you will definitely make sure that it has some knowledge, but no real explanations are in place. Of course, a final explanation is indeed really simple - Function.prototype.toString() returns everything even the comments inside the function body, size of that string is a feature that allows the optimizing compiler inside V8 to make a decision to inline that particular function or not. There is even a command line switch which to use to modify a limit and a default value. Simple enough? Not really. That article left a lot of unanswered questions. Probably because of that JIT compilers and its optimization techniques are kind of black magic. Why is it hard? Obviously compiler engineers are not dumb people (they are actually really smart) and they are not obfuscating and complicating this by accident or on purpose. They are working hard, especially with such weakly typed and underspecified languages like JavaScript to provide you an optimized version of your code. Why is it a hard job? It is all about guarantees. How many of them you can recall from memory when it comes to JavaScript? Not a lot of them, right? That is not good, especially from the perspective of a compiler engineer. JavaScript is everywhere, success of the internet spread this language, and nowadays success of Node.js pushed this language from front-end, even to server-side - and everywhere people are talking about performance. Obviously not about native like performance for scientific computations, but the more complexity is pushed to the application layer, the more of it will have to be optimized after all. That's why compilers and their creators have to be smart people - they have to deal with complexity of your applications and "illness ## Jenkins 2.0 DevFeed: [Jenkins 2.0]() Original publisher: [Read original article]() Author: Wojtek Gawroński (afronski) Published: 2016-04-03T15:30:00Z Content type: release Language: en Sources: [Wojtek Gawroński]() Topics: [Jenkins](), [Automation](), [Open Source]() Tags: [automation](), [c-sharp](), [canvas](), [clojure](), [compatibility](), [css](), [css3](), [erlang](), [html](), [html5](), [javascript](), [jenkins](), [mono](), [net](), [node-js](), [open-source](), [release](), [sicp](), [vagrant](), [webgl]() ### AI overview This article reviews the beta release of Jenkins 2.0, covering its improved user interface, built-in delivery pipelines with Jenkinsfile support, and stated backward compatibility with Jenkins 1.x. It notes that the current LTS version remained recommended for production deployments at the time. ### Source excerpt Jenkins 2.0 Introduction Recently maintainers of Jenkins - the leading and most popular open source automation server - announced that long awaited version 2.0 is available to download and additionally it is marked as a beta release. It means that they're still recommending current LTS version for a production deployments, but new version is coming really soon. So let's look what it offers! What's new? Improved usability (aka "New UI") That is probably the most single awaited feature in Jenkins community. It means a lot for both, power users and newcomers. A lot of feedback was taken into account when preparing that feature. Old pages (e.g. Create Item or Job Configuration) look really clean and modern (we finally have tabs in Job Configuration page), new views like Pipeline Stage view (we will describe whole feature in the next section) look even more awesome: But that's not the end of goodies from that release. Delivery pipelines Finally Jenkins will be packaged with built-in delivery pipelines feature. It means that it will not require anymore plugins for doing that. It brings finally support for Jenkinsfile - concept which allows to codify your pipelines, and store it inside version control (either together with application source code or outside, in one of your supporting repositories). Besides that - finally no more XML fiddling when it comes to job configuration, because it will use a nice DSL: node { git url: 'https://github.com/joe_user/simple-maven-project-with-tests.git' def mvnHome = tool 'M3' sh "${mvnHome}/bin/mvn -B -Dmaven.test.failure.ignore verify" step([$class: 'ArtifactArchiver', artifacts: '**/target/*.jar', fingerprint: true]) step([$class: 'JUnitResultArchiver', testResults: '**/target/surefire-reports/TEST-*.xml']) } That is a well known concept, similar to the job DSL plugin. But finally, it will be built-in and ready to use right after installation, without any additional effort. Full backward compatibility That is the most important thing ## Writing custom modules for Ansible DevFeed: [Writing custom modules for Ansible]() Original publisher: [Read original article]() Author: Wojtek Gawroński (afronski) Published: 2016-03-28T19:00:00Z Content type: tutorial Language: en Sources: [Wojtek Gawroński]() Topics: [Ansible](), [modules](), [Automation](), [configuration-management](), [Erlang](), [JSON](), [YAML](), [Scripting]() Tags: [ansible](), [automation](), [c-sharp](), [canvas](), [clojure](), [code](), [commands](), [configuration](), [configuration-management](), [css](), [css3](), [erlang](), [html](), [html5](), [javascript](), [json](), [modules](), [mono](), [net](), [node-js](), [programming](), [scripting](), [sicp](), [vagrant](), [webgl]() ### AI overview This tutorial explains Ansible modules, including their role in remote infrastructure management, YAML-based declarative configuration, dependencies on the provisioned machine, and JSON input/output requirements. It then introduces a case study for implementing a custom module in Erlang to process XML status pages. ### Source excerpt Writing custom modules for Ansible Introduction What is Ansible and what is a module? If you are a big fan of automation, if you are focused on spreading and building software in line with DevOps culture, tools related with automation / configuration management like Chef or Ansible are probably well known to you. From the other hand that what differentiates those tools is a topic for a next blog post. Without diving into those differences, let's briefly zoom into details for those people which do not know what Ansible and modules are. Ansible is a free-software platform for configuring and managing machines. It combines deployment, ad-hoc tasks execution and configuration management. This tool uses YAML and declarative way of defining steps, which are modifying state of your fleet. Module is a single piece of those steps, a well defined way of executing certain tasks on the remote infrastructure. It executes commands, and communicates by outputting JSON to standard output - it means that it can be written in any programming or scripting language. Development Before we'll start actual implementation we need to know how it works underneath. Requirements If you want to write a custom module, we stated above that you have to be aware of two things. Your module code will be executed on the provisioned machine, so all dependencies which your module requires, have to be there. Second, your module communicates over specific input and output protocols. It uses certain syntax for sending input parameters (either sent as a stdin or a file) and JSON protocol which will be consumed as an output of the module. And nothing more - any other, non-JSON compliant output will be treated as an error, and would not be consumed by Ansible properly. Case Study We would like to consume XMLified status pages and do certain actions based on checked and exposed facts, scraped from aforementioned place. Because I like Erlang, I will use that language to implement that module. We will do it usin ## Maintaining a 500-Day GitHub Contribution Streak for Documentation and Habit Building DevFeed: [Maintaining a 500-Day GitHub Contribution Streak for Documentation and Habit Building]() Original publisher: [Read original article]() Author: Wojtek Gawroński (afronski) Published: 2016-02-17T22:30:00Z Content type: opinion Language: en Sources: [Wojtek Gawroński]() Topics: [Git](), [dotfiles](), [Open Source]() Tags: [c-sharp](), [canvas](), [clojure](), [css](), [css3](), [erlang](), [git](), [github](), [html](), [html5](), [javascript](), [mono](), [net](), [node-js](), [open-source](), [projects](), [sicp](), [vagrant](), [webgl]() ### AI overview The author describes maintaining a 500-day GitHub contribution streak and explains that the practice supported personal documentation, disciplined commit history, workload planning, community activities, and open-source contributions. The article also notes that contribution histories can be artificially altered using separate repositories and rewritten dates, and that streak quantity does not measure programming quality. ### Source excerpt 500 shades of Green No, it is not fake. I did it - I have managed to have real streak which last 500 days in a row and document it on Github. But, you can do it in a different way - there are couple of projects which allows you to create arbitrary history of your contributions (it uses a separate repository for that and well - it cheats using ability of git to bend the time). One is here. :wink: No, it does not mean anything. I am not a better programmer than anyone else, definitely quantity does not involve quality (I will describe this in details below). No, it does not mean that I did not have proper holidays or that I have spent all my free time on that. Why did you do that? Mainly because of two reasons: documentation and creating habits. Many of the repositories like afronski/playground-notes, afronski/dotfiles or afronski/papers_i_love are pure and private documentation of my notes, publicly visible settings and observations with commit history. It also helped me when it comes to developing new habits: Taking care about commit history, proper commit messages, linear and nice history. Working with facilities like rebase, squash or fix-ups helped me a lot in daily job. Besides that some commits have attached story with explanation why I applied that change. It is sometimes priceless, because I can drop my mental overhead related to fear of forgetting something important. And when I hit the same wall again I can tackle it with certainty and exact solution. Example here. Also having a daily habit of delivering something valuable is crucial. It helps a lot when it comes to daily work, when it comes to planning the workload, actual steps to be done. It also helps regarding planning my weeks and during a lot of other related activities - like meet-up organization, building community around them or preparing real contributions to open source projects. Another point is related with developing other habits. It is easier to develop a new habit on top of existing foundat ## My year in review - 2015 DevFeed: [My year in review - 2015]() Original publisher: [Read original article]() Author: Wojtek Gawroński (afronski) Published: 2015-12-31T15:00:00Z Content type: article Language: en Sources: [Wojtek Gawroński]() Topics: [Programming](), [Elixir](), [Microservices](), [phoenix](), [ClojureScript](), [Erlang](), [JavaScript](), [Node.js](), [Bash](), [C](), [Python](), [Ruby]() Tags: [blog](), [c-sharp](), [canvas](), [clojure](), [css](), [css3](), [erlang](), [html](), [html5](), [javascript](), [languages](), [microservices](), [mono](), [net](), [node-js](), [open-source](), [programming](), [sicp](), [vagrant](), [webgl](), [year-in-review]() ### AI overview A personal review of 2015 covering talks, meetups, blog posts, books, programming languages, and plans for 2016. It highlights work involving microservices, Elixir, Phoenix, Node.js, Erlang, ClojureScript, and several other languages. ### Source excerpt My year in review - 2015 Github Talks Nov 2015 - Evolution > Revolution - how should microservices be built? Sep 2015 - Elixir + Phoenix Jun 2015 - ZeroMQ in Node.js Apr 2015 - Erlang Ecosystem (PL) Feb 2015 - Elixir Feb 2015 - ClojureScript + Om = ♥ Details: My Talks Meetups Two meet-up groups created and continued in 2015: NodeSchool Silesia Silesian BEAMers Blog Most viewed blog posts by me Books List of book which I've read in 2015 and reading challenge. Favorite technical book of 2015 Pragmatic Thinking and Learning: Refactor Your Wetware - blog post about it Number of books read 20 Programming Favorite programming languages (or related) I've hacked on/with this year Languages with pet projects: Erlang #1, Erlang #2, Elixir #1, Elixir #2 ClojureScript Programming languages used for work-related projects this year JavaScript - ES 5 (Node.js, Front-End), JavaScript - ES6 (Front-End), Java, C, Ruby, Python, Bash Programming languages that I hope to explore next year Idris, Rust, Prolog Plans for 2016 Apply 100:10:1 rule to my open source work. Proceed with cost-benefit analysis and focus on monetization in terms of open source work. Try to kick-off another meet up in Silesia region - Papers We Love. Learning (even more than previously) about theory and how to design distributed and real-time systems. Focus on doing interactive blog posts and higher quality (premium?) materials. Push even harder work related with quality and visibility of blog posts. Take more time to discover new music. Happy New Year! :wink: ## Elixir's gen\_event Behavior and Its Event Manager and Handler Design DevFeed: [Elixir's gen\_event Behavior and Its Event Manager and Handler Design]() Original publisher: [Read original article]() Author: Wojtek Gawroński (afronski) Published: 2015-11-02T15:00:00Z Content type: opinion Language: en Sources: [Wojtek Gawroński]() Topics: [Elixir](), [modules](), [Processes](), [Concurrency](), [Simulation]() Tags: [c-sharp](), [canvas](), [clojure](), [concurrency](), [console](), [css](), [css3](), [elixir](), [erlang](), [handler](), [html](), [html5](), [javascript](), [module](), [mono](), [net](), [node-js](), [process](), [sicp](), [vagrant](), [webgl]() ### AI overview This article examines Elixir's gen_event behavior, explaining how event managers receive events and dispatch them to installed handler modules. It presents the design as a pattern the author considers problematic, while noting that the article dates from 2015 and that Elixir has changed since then. ### Source excerpt Beware: this article is from 2015 and in Elixir world couple things changed a bit. Here you can find the updated version of this blog post. What is wrong with gen_event? I never used gen_event, I think it is a bad pattern. At first it may look like a controversial statement, but I heard a lot of those complaints from other people. Originally, I heard that exact statement during the presentation made by Garrett Smith about pattern language - someone asked about that behavior at the end. More recently I heard similar thing in José Valim's presentation about what will come next in Elixir. It confuses me every time I hear that, so I want to investigate topic more deeply. But before we will dive into reasons and explanations, let's recall what is the purpose of this behavior. What is gen_event? OTP introduces two different terms regarding that behavior - an event manager and event handler modules. Responsibility of event manager is being a named object which can receive events. An event can be, for example: an error, an alarm, or some information that is to be logged. Inside manager we can have 0, 1 or more event handlers installed. Responsibility of the handler is to process an event. When the event manager is notified about an event, it will be processed by all installed handlers. The easiest way to imagine that is to think about manager as a sink for incoming messages and handlers as different implementations which are writing messages to disk, database or terminal. Another example can be taken from my implementation of Francesco Cesarini's assignment called Wolves, Rabbits and Carrots simulation. Main purpose of that task is to introduce concurrency, but internally it is a simulation - so certain events are happening, and they will be broadcasted to the rest of entities. In that case simulation_event_stream is an event manager: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 -module(simulation_event_stream). -export([ start_link/0, co ## SICP in Clojure - Chapter 5 DevFeed: [SICP in Clojure - Chapter 5]() Original publisher: [Read original article]() Author: Wojtek Gawroński (afronski) Published: 2015-10-19T14:00:00Z Content type: tutorial Language: en Sources: [Wojtek Gawroński]() Topics: [Clojure](), [Compiler](), [Lisp](), [Programming](), [Functional programming](), [Hardware](), [Data structures]() Tags: [blog-post](), [c-sharp](), [canvas](), [clojure](), [compiler](), [css](), [css3](), [data-structures](), [erlang](), [functional-programming](), [gc](), [hardware](), [html](), [html5](), [javascript](), [languages](), [mono](), [net](), [node-js](), [programming-language](), [sicp](), [vagrant](), [webgl]() ### AI overview This blog post discusses Chapter 5 of Structure and Interpretation of Computer Programs through Clojure. It explains register machines, their data paths and controllers, and the relationship between hardware, Lisp-like languages, and compiler construction. ### Source excerpt SICP in Clojure - Chapter 5 In one of the previous blog posts I have announced that I would like to start a new series of posts. It is a persistent journal from my journey through aforementioned book. I hope that you will enjoy it and find it useful - the main goal is to make this series a place where we can return in future, recall ideas and thoughts that accompanied reading process. Introduction We are heading to the end of the book. It is the last chapter, and in the previous blog post I have already mentioned that last two chapters are really specific. And that is true, especially in terms of 5th chapter's content. High-level Convenience Using high-level languages have many benefits. In terms of Clojure and other Lisp-like languages I would start with an automatic memory management and GC, various data structures or various optimizations, like tail-recursion etc. We do not think very often about how it is implemented, especially at the lowest level - in the hardware. Can you imagine how the hardware should look like, to be capable of running code written in programming language from Lisp family? This is the main topic of the last chapter. Authors are starting with basic theory related to register machines and ending with the recipe for building a compiler. This blog post will be mostly theoretical, and instead of code examples, and exercises related with a topic "How to build a Clojure compiler", we will take a peek under the hood, directly into the language implementation. But first, let's bring some definitions to the table. What is a register machine? Register machine is a type of a computer, which sequentially executes instructions. Those instructions are operating and modifying a set of a memory elements called registers. A typical operation will take operation arguments from registers, and it will push the result of that instruction to another register. When it comes to the designing of such machines, at first you need to create its data paths - which the ## SICP in Clojure - Chapter 4 DevFeed: [SICP in Clojure - Chapter 4]() Original publisher: [Read original article]() Author: Wojtek Gawroński (afronski) Published: 2015-10-05T14:00:00Z Content type: tutorial Language: en Sources: [Wojtek Gawroński]() Topics: [Clojure](), [Lisp](), [Code](), [Functional programming](), [Programming language](), [Refactoring]() Tags: [abstraction](), [c-sharp](), [canvas](), [clojure](), [css](), [css3](), [erlang](), [functional](), [html](), [html5](), [javascript](), [lisp](), [mono](), [net](), [node-js](), [programming-language](), [sicp](), [structure](), [syntax](), [vagrant](), [webgl]() ### AI overview This chapter in a series on SICP in Clojure explains Lisp concepts including homoiconicity, metalinguistic abstraction, and metacircular evaluators. It describes how homoiconic languages represent program structure as data and introduces evaluators written in the language they interpret. ### Source excerpt SICP in Clojure - Chapter 4 In one of the previous blog posts I have announced that I would like to start a new series of posts. It is a persistent journal from my journey through aforementioned book. I hope that you will enjoy it and find it useful - the main goal is to make this series a place where we can return in future, recall ideas and thoughts that accompanied reading process. Introduction By finishing the previous chapter we learned more about functional programming, designing and dealing with stateful computation and a little bit about laziness. It was pretty much a general purpose programming book till now. Last two chapters of the book are really ... Lispy. :wink: Chapter which will be discussed today is focused on Lisp core values built around universal evaluator, homoiconicity and linguistic abstractions. What is homoiconicity? Very concise, I would say a mathematical, definition will explain it as a isomorphic relation between language AST (Abstract Syntax Tree) and its syntax. In more human friendly words - it is a property of a programming language in which the program structure is similar to its syntax. If such language is homoiconic, it allows all code in the language to be accessed and transformed as data, using the same representation - because AST is exactly the same as the language itself. All languages from Lisp family have this property, also languages like Io, Julia or Prolog also have this ability (to a certain degree of course). Keep in mind that it does not mean that having a macros system in the language makes it homoiconic. Metalinguistic abstraction Title of this section sounds like a difficult concept, where the core idea is really simple. Aforementioned abstraction is an ability to create new languages. We have done that previously (e.g. by creating various Domain Specific Languages when solving exercises). By the creation, authors also mean ability to evaluate (or interpret) constructs written in that newly created dialect, by calcul ## SICP in Clojure - Chapter 3 DevFeed: [SICP in Clojure - Chapter 3]() Original publisher: [Read original article]() Author: Wojtek Gawroński (afronski) Published: 2015-09-18T14:00:00Z Content type: article Language: en Sources: [Wojtek Gawroński]() Topics: [Clojure](), [Functional programming](), [Lisp](), [Software Engineering](), [Programming]() Tags: [beginners](), [c-sharp](), [canvas](), [clojure](), [css](), [css3](), [data-structures](), [design](), [erlang](), [functional](), [functional-programming](), [html](), [html5](), [javascript](), [learning](), [mono](), [net](), [node-js](), [programming](), [sicp](), [software-design](), [vagrant](), [webgl]() ### AI overview A journal-style discussion of studying SICP through Clojure, explaining how the book's treatment of software design, functional programming, modularity, and data structures can complement learning a Lisp-like language while requiring care with Scheme-specific concepts. ### Source excerpt SICP in Clojure - Chapter 3 In one of the previous blog posts I have announced that I would like to start a new series of posts. It is a persistent journal from my journey through aforementioned book. I hope that you will enjoy it and find it useful - the main goal is to make this series a place where we can return in future, recall ideas and thoughts that accompanied reading process. Introduction In the previous blog post (which had surprisingly good reception on the Hacker News) we have analyzed second chapter of the book. We did not know, that around the corner there is a ground breaking "twist" prepared by the authors in the 3rd chapter. We will face it today. I should also mention that recently SICP Distilled went publicly, which is also a very good tour on the book, with a different approach. Nevertheless, I am still going my way through the book and I have got couple of interesting observations from the aforementioned chapter. But first, I would like to address one question which was posted on the Hacker News thread. Clojure is not a Scheme and SICP will not help you to learn Clojure Even if the first part is not debatable at all (how come one language could be identical to another one, even if they have common roots), then the second one is definitely dependent on the point of view. Mine is really obvious - Clojure is my first contact with a Lisp-like language. And book has much more to offer than a simple language course. I would say that a language course and SICP can be complementary. How? Basically (from my observations) aforementioned book is about good software design and how to approach functional programming and functional design in a dynamicly typed language. It attacks various problems like modularity, data structures, and many more. It provides a good foundation for beginners, and I strongly believe that it can be beneficial for more advanced programmers. By taking that book and completely new language, I am treating this book more like a referenc ## I wrote Antigen in Go: Antibody DevFeed: [I wrote Antigen in Go: Antibody]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2015-06-06T00:00:00Z Content type: opinion Language: en Sources: [Carlos Becker]() Topics: [Go Language](), [Haskell](), [Erlang]() Tags: [code](), [concurrently](), [erlang](), [execution](), [go](), [language](), [learning](), [post](), [thoughts](), [variables]() ### AI overview A personal account of learning Go while building Antibody, a reimplementation of Antigen. The article discusses Go's syntax, built-in formatting and error checks, and its concurrency features for processing plugin bundles. ### Source excerpt Learning Go was in my TODO list for a while, and finally I did something about it. This post contains some thoughts about it... ## Why Clojure? Part 2: Effortless async by design DevFeed: [Why Clojure? Part 2: Effortless async by design]() Original publisher: [Read original article]() Published: 2013-04-05T00:00:00Z Content type: opinion Language: en Sources: [Adam Bard]() Topics: [Clojure](), [async](), [Concurrency]() Tags: [agents](), [async](), [asynchronous](), [clojure](), [clojure-functions](), [code](), [design](), [erlang](), [stack-overflow](), [threads]() ### AI overview This second article in a series argues that Clojure makes asynchronous web programming straightforward. It explains using Java threads and closures, futures for deferred results, and Clojure's thread-safe state-sharing mechanisms, including Atoms, Refs, Agents, and Vars. ### Source excerpt As a second part in what I've decided will be a series attempting to justify my choice of Clojure as a general-purpose web language, I'd like to talk a little bit about writing asynchronous code in Clojure, and just how easy the design decisions made by Mr. Hickey make that. ## Seven Languages in Seven Weeks: Erlang DevFeed: [Seven Languages in Seven Weeks: Erlang]() Original publisher: [Read original article]() Author: Carlos Alexandro Becker Published: 2012-12-18T00:00:00Z Content type: tutorial Language: en Sources: [Carlos Becker]() Topics: [Erlang](), [Concurrency](), [function](), [pattern matching](), [Processes]() Tags: [concurrency](), [erlang](), [function](), [pattern-matching](), [process](), [recursion]() ### AI overview A beginner documents working through Erlang exercises from "Seven Languages in Seven Weeks," covering recursion, pattern matching, list comprehensions, regular expressions, concurrency, process monitoring, and process restarts. The author notes that some solutions may contain errors while learning the language. ### Source excerpt So, I just bought "Seven Languages in Seven Weeks". I've read the Ruby chapter, not a big deal at all, so I skipped it. I also skip Io, Prolog and Scala (for now), and then, fall in Erlang! ## Battle Language à la Marmite DevFeed: [Battle Language à la Marmite]() Original publisher: [Read original article]() Author: Dimitri Fontaine PostgreSQL Major Contributor; Author Published: 2012-03-01T13:49:00Z Content type: opinion Language: fr Sources: [Dimitri Fontaine]() Topics: [Lisp](), [Emacs](), [Common Lisp](), [Erlang](), [Haskell](), [Ruby]() Tags: [article](), [code](), [emacs](), [emacs-lisp](), [erlang](), [haskell](), [language](), [languages](), [lisp](), [roots](), [ruby]() ### AI overview The author recounts participating in the Battle Language event at La Marmite, where they presented Emacs Lisp as part of the broader Lisp family. The presentation briefly covered John McCarthy's axiomatic approach and referenced Paul Graham's The Roots of Lisp and its Common Lisp implementation. The event also included discussion of functional and object-oriented languages, including Erlang, Haskell, and Ruby. ### Source excerpt J'ai eu la chance hier soir de participer à la Battle Language à la Marmite, où j'avais proposé de parler de Emacs Lisp, proposition qui s'est transformée en porte-étendard de la grande famille Lisp. J'ai utilisé avec plaisir certains contenu de Lisperati dans ma présentation et je vous recommande le détour sur ce site ! J'ai dans cette présentation très rapide (5 minutes seulement) mentionné l'approche axiomatique de John McCarthy lorsqu'il a découvert le language, on peut en lire un peu plus sur le site de Paul Graham et son article The Roots of Lisp et le code associé, une implémentation du LISP de McCarthy en common lisp. ## Tsung: An Open-Source Distributed Load-Testing Tool for Multiple Protocols DevFeed: [Tsung: An Open-Source Distributed Load-Testing Tool for Multiple Protocols]() Original publisher: [Read original article]() Author: Dimitri Fontaine PostgreSQL Major Contributor; Author Published: 2011-08-02T08:30:00Z Content type: article Language: en Sources: [Dimitri Fontaine]() Topics: [Testing](), [Benchmark](), [Erlang](), [PostgreSQL](), [Protocol (disambiguation)](), [sessions](), [Open Source](), [Development]() Tags: [benchmark](), [erlang](), [load-testing](), [open-source](), [postgresql](), [protocol](), [sessions](), [testing]() ### AI overview The article introduces Tsung, an open-source, multi-protocol distributed load-testing tool built with Erlang. It describes benchmarking applications, recording and replaying sessions at high scale, PostgreSQL support, and integration with pgfouine for converting PostgreSQL logs into Tsung sessions. It also mentions the uTsung variant used in video games and a video demo. ### Source excerpt Tsung is an open-source multi-protocol distributed load testing tool and a mature project. It's been available for about 10 years and is built with the Erlang system. It supports several protocols, including the PostgreSQL one. When you want to benchmark your own application, to know how many more clients it can handle or how much gain you will see with some new shiny hardware, Tsung is the tool to use. It will allow you to record a number of sessions then replay them at high scale. pgfouine supports Tsung and is able to turn your PostgreSQL logs into Tsung sessions, too. [Next page]()