Codeship Blog

I don't think so. First, just to make sure there aren't any points of confusion... Erlang/Elixir processes are not OS processes (https://elixir-lang.github.io/getting-started/processes.html). As such, we really can't speak of processes in Erlang/Elixir and other kinds of systems on any sort of equal footing. In Erlang, processes are much lighter weight than OS processes. And you do expect them to go wrong... so Erlang has the idea of "Supervision Tree" where there are Supervisor processes whose job it is to monitor other processes and to manage their failure when it occurs. There can be multiple Supervisors which influence one another, or not, as you design them too (thus the "tree" bit). Naturally you plan for these sorts of failures in designing what is/is not a process, what dependencies there may be, what any Supervisor watches and how the Supervisors relate to one another.

Erlang/Elixir also seems to have one of the strongest availability and concurrency stories out there on its own. Part of this comes from the aforementioned built in assumptions around isolating and managing failed processes, but the other is in terms of the relative ease of starting processes as needed, and accessing the processes of other Erlang VMs (same server or not). It's clear you have to architect and build things correctly to take full advantage of these capabilities, but I think you can get to the place you describe without necessarily taking on a bundle of different applications for…

(disclosure: I do work for Codeship :P )

There are a lot of really great reasons to use Docker, or any container technology for CI.

First off containers give you a standard interface to a reproducable build. This means you can run something in a container and expect it to behave the same way as something a co-worker runs on their workstation, or something run in the staging or production environments. For CI this is an absolute necessity. Rather than running tests locally, and expecting a CI server closely tracking the production/staging environments to catch issues with different version of the OS or libraries you can expect any build that passes locally to also pass on CI. This cuts down on a lot of potential back and forth. The only shared dependency between CI/local/prod/staging is docker itself.

Another benefit is (almost) complete isolation. This means rather than having different vm images tracking different projects, you can have a single vm image with docker, and have each container running on the vm for any version of any build across your system. From a CI perspective you can abstract most of the complex configuration for your applications into "docker build -t myapp_test ./Dockerfile.test && docker run myapp_test".

Containers use a differential filesystem, so N running containers for an application will take up 1 X the size of the container image + N x the average space of changes made in the running containers on top of that base image. This makes larger…

I don't think the article could have said it much better.

SQL is super powerful and makes much sense in so many ways. Nearly all apps have a relational structure to them and SQL is a reasonable way to interact with them.

Some of my favorite conversations from the Postgres community 5-6 years back were when they were talking about a time when Postgres was being disrupted. The gray bearded DBAs (Hi Berkus and others) were talking about JSON like it's fad and how it's going to come to pass. They were saying so because they'd heard about this disruption before... there was this new thing XML and these document databases were so much more powerful. They waited a few years and added an XML datatype [1]... And then XML databases came and passed.

At first they scoffed a bit on JSON as the new hip thing, but came around a little in Postgres 9.2, and then in 9.4 [2] we all really got what we wanted.

SQL has never been a particularly elegant language, but it's always been a powerful one. The lone knock against has either been usability or scalability [3]. On the usability side that's a bit of a hard one as well it's not super pretty. But once you understand it's foundations around relational algebra or relational calculus you're so far ahead. On the scalability side there are definitely some options such as Citus, but also core Postgres is massively improving here.

[1] https://www.postgresql.org/docs/9.3/static/datatype-xml.html

[2]…

Codeship - Boston, MA or Vienna, Austria

At Codeship we build a continuous Deployment service. Our mission is to make software teams more productive by helping them to release early, often and safe. We're building for the builders.

We've been in production release for several years, have thousands of developers using the service and are growing rapidly. We've closed our Series A earlier this year.

We're looking for Rails Developers, SysAdmins/DevOps, designers and frontend developers who love building tools for other developers.

Read more about us on our Jobs Page: https://codeship.io/jobs And how we work in our Blogposts: http://blog.codeship.io/category/the-codeship-workflow

Send me an email to flo@codeship.io. You'll like it here!

I think it's time people start using something better than bash/zsh that is decades old, like fish or even come up with a more modern shell.

Even by looking at these examples, you see it has less verbosity like "then" and "do", you can reference arguments as $argv instead of cryptic $@ and exit status code as $status instead of $? which is confusing with $! and the likes.

https://blog.codeship.com/lets-talk-about-shell-scripting/

https://fishshell.com/docs/current/tutorial.html

Shell is such an integral part of admins and programmers workflow yet I find it hard to believe this field has been so slow at improving. Even the fish site jokingly states "Finally, a command
line shell for the 90s" implying the others are even older.

Crystal is really nice! Cloning Ruby syntax but making it prettier is probably one of the smartest language design decisions that have happened in a long time.

It's definitely gotten further on my radar in the past year or so, though I remember reading this a few years ago and finding it pretty cool then, too:

https://blog.codeship.com/an-introduction-to-crystal-fast-as-c-slick-as-ruby/

Relevant HN thread: https://news.ycombinator.com/item?id=12223395

Seeing Lilith in (what was, I think) December was what really alerted me to the fact that it had come along so far, I had mostly thought it was dead before.

Lilith: https://github.com/ffwff/lilith

Relevant HN thread on Lilith: https://news.ycombinator.com/item?id=21860713