That’s a good idea. There should be an installation guide. I’m not sure if you mean for production or for development but we are still looking for “best” IDE.
I tried to use RubyMine but now I’m using IntelliJ. I was missing some keybinding options in RubyMine. But we also use VS Code and Spacemacs, although that is for nerds 
.
To programming in Ecto. I’m simply no fan of code-first approach. It’s the same story as with Entity Framework. It’s based on the idea that anyone can create databases without the knowledge of their inner workings. While this is true for Ecto and Entity Framework, it truly creates databases on it’s own, the only way how can they achieve this possibility for so many different database engines is to be quite general. So you have this huge powerhouse named Postgres at your disposal and you use like 10-20% of it’s power just because you don’t have to use SQL.
Look for example at this article.
Why would anyone think that the code below is better than to have a stored procedure/function and make a simple call to it.
articles = Repo.all(
from c in "articles",
join: sq in fragment("(SELECT ts_rewrite(plainto_tsquery(?), 'SELECT * FROM aliases') search_query)", ^term),
on: fragment("search_vector @@ ?", sq.search_query),
where: not is_nil(c.publish_at) and c.static == false,
order_by: fragment("rank DESC"),
select: %{
id: c.id, title: c.title, slug: c.slug, display_date: c.display_date,
rank: fragment("ts_rank_cd(search_vector, ?, 32) AS rank", sq.search_query),
introduction: fragment("ts_headline('english',CONCAT(introduction,' ',main_body), search_query, 'StartSel=<mark>,StopSel=</mark>,MinWords=50,MaxWords=100') AS headline"),
tags: c.tags
})
But there are other reasons I don’t like this approach as well. For decades we were taught to separate our concerns, to have system boundaries that just have public interfaces and so we created stored procedures, precompiled pieces of database code, and we’ve been calling them. Database owners could rework whole database without us knowing and even care but then Linq to SQL and Hibernate came and told us we should not separate concerns anymore and instead lock our databases in application code.
So now when you want to update simple thing in database you have to redeploy your whole application. That simply cannot be better.
And the last point, one of the benefits of using Ecto or EF or what have you is that you can switch your database at anytime. You can use MS SQL today, Postgres tomorrow and mysql the day after but in my 15 years of professional programming I don’t remember any project that would do that. And I have been to plenty. I’m not saying it’s not happening but how often it actually does? Is this really a valid point?
I’ve just remember one more thing, rollbacks in migration scripts. With ever increasing pressure to go full CI/CD and can easily imagine a situation in which someone who is not familiar with how things work just go to his CI/CD tool and presses “Rollback to version” button and his CD will truly rollback to some previous version of an application without any problem. Everybody is cheering and happy to the moment they realise rollback also meant to remove tables in their database. 
So we will cover usage of Ecto in all ways in https://intophoenix.io but internally try to have as many stored procedures as possible.
P.S.: I was one of the people who believed it’s a good thing to use EF but then I realised it’s actually a false marketing and they are dragging me down because I’m unable to change anything without a full migration of my application.
A ano, je milé vidět, že nejsme v tom Elixírovém boji osamoceni na českém poli. Budu se snažit dostat Elixir/Phoenix do České pojišťovny. Je to takový muj vnitřní cíl.
I use to VS Code and I’m satisfied with him. I thought that vim is for nerds 
