[erlang-questions] Looking for slides of a lightning talk

[Loïc Hoguin]

Hey,

Don't worry if I am sounding a bit condescending in some parts of this 
reply, I'm not rude, I'm just french. :)

On 07/12/2012 12:30 AM, Ian wrote:
> On 11/07/2012 11:47, Thomas Lindgren wrote:
>> 1. Too few dedicated erlang web programmers, so still a lot of DIY.
>> This may be a bootstrapping/community issue. Which is nontrivial, by
>> the way.
>>
>> 2. Packages: Let me gripe a bit. At work, we've had endless trouble
>> with Ruby gems, some hair tearing with CPAN, and have spent a couple
>> of man years on packaging for RH and Debian. The whole process is
>> still pretty clunky and hacky. So not a solved problem in the rest of
>> the world either IMO and the erlang way has some advantages. But I
>> agree that more love is needed to catch up, especially on usability.
> Things need A LOT more love. I want to use cowboy to write some web
> software. Looks easy enough. There are Erlang drivers for the database I
> need to use, so all looks OK to proceed.  I have just started with
> Erlang so not too familiar with things yet. This is my experience.
>
> 1) Found cowboy needs rebar - and rebar documentation is
> thin/non-existent/hiding.

I'll make sure to add instructions about that in the upcoming Cowboy 
documentation.

> 2) Find rebar is not available on windows.  OK. I'll upgrade a VM I have
> to Unbuntu 12:04. (which takes 3 hours, fails and needs nursing back to
> health.  After removing and re-installing some packages things are now
> OK, apart from the occasional crash.  Aside - virtual box provides a
> rather standard environment, so should not be a problem. And I though
> Linux was supposed not to crash like Windows. Not my experience.  Oh
> well - press on.

Cowboy isn't available on Windows either, AFAIK. None of my software has 
been tested properly on Windows (or at least I didn't get feedback about 
it). I think few open-source Erlang developers use Windows and unless 
they send patches or finance some work towards this it's going to 
improve very slowly. Not trying to make an apology of it, just 
explaining the whys.

> 3) I discover that the install of rebar into an apt-get install of
> Erlang will cause all sort of problems.
>
> In my book that means that at least one of those installs is not simple
> minded, or had inadequate checking.
> It is simply wrong. Maybe both. No matter, decide to install from source.

That's because Debian and Ubuntu's Erlang packages is completely broken. 
Can't really blame Erlang for that.

> 4) Screw up courage and download and compile Erlang 15B - all goes
> well.  Woo-Hoo on a roll here!

As you noticed it's much easier from source. There's also Ubuntu 
packages provided by Erlang Solutions, or tool assisted source install 
using kerl. But these are all third party.

> 5) Download, and compile rebar from source. That appears to work and it
> tells me to put it on the path.
>
> 6) Eh? Type "path" - gets "not installed" error message. Back to Google.
> Eventually find the command I need is env.  See path is a whole slew of
> directories.

I'll definitely sound condescending with this one, but this is an honest 
question. Why do you not know about the PATH environment variable? 
That's generally useful in any kind of development work. Should this 
also be included in the various projects' documentation?

> Which should I use? Will the next upgrade to Ubuntu wipe some of them?
> Don't know. Don't know how to find out. Look in each one and decide that
> /usr/local/bin is probably a fair choice, because it contains erl. Copy
> rebar in.
>
> 7) Now I can start the instructions at
> http://blog.pqsdk.org/from-zero-to-deployment-with-cowboy-in-5-minu
>
> Note the title includes the sales pitch "In 5 minutes".  I have already
> spent many hours getting the the start position. (At least I hope its
> the start position).

Don't think I knew about that one. There's probably various other 
tutorials here and there not explaining everything properly. I'm open to 
suggestions for the steps you feel are needed to be put in the 
documentation.

I doubt you can go from 0 knowledge to running Cowboy application in 5 
minutes though, Cowboy has a few pre-requisites like knowing rebar or 
knowing how to design and build an OTP application. Should all this be 
explained in the documentation though?

Anyway Cowboy lacks proper user guides because the API is just about to 
change a little and I didn't want to duplicate efforts in writing for 
before and after, as the steps to 'get started' are changed the most.

> 8) Issue first command and find hg is not an installed command. Apt-get
> install hg can't find the package.
>
> It wasn't the start position!  Google turns up that hg is actually
> called mercurial and gives me the magic incantation to install it.
>
> 9) hg installs and I get to clone woody from bitbucket.  Step 1 complete.
>
> 10) Next command is ./app.sh cowgirl .   I think that create the app (or
> at least its framework). It reports no errors.
>
> 11) Then ./build-compile.sh  - OK, build and compile.  NO errors. Great.
>
> 12) Next comes  ./build-release.sh
>
> This fails saying files exist and were not generated. It adds that I
> need force=1 on the command line to force it. Why? If forcing is a good
> idea, the software should just do it. Heck, its only to learn. I can
> delete and start over if necessary - just press on. Add force=1 to the
> command line.
>
> 13) When I do I get this.
>
> ian@REDACTED:~/projects/cowgirl$ ./build-release.sh force=1
> ==> rel (create-node)
> ERROR: One or more files already exist on disk and were not generated:
>      * "reltool.config"
>      * "files/erl"
>      * "files/nodetool"
>      * "files/cowgirl"
>      * "files/app.config"
>      * "files/vm.args"
> To force overwriting, specify force=1 on the command line.
> ==> rel (generate)
> ERROR: generate failed while processing /home/ian/projects/cowgirl/rel:
> {'EXIT',{{badmatch,{error,"Release \"cowgirl\" uses non existing
> application cowgirl"}},
>           [{rebar_reltool,generate,2,[]},
>            {rebar_core,run_modules,4,[]},
>            {rebar_core,execute,4,[]},
>            {rebar_core,process_dir,4,[]},
>            {rebar_core,process_each,5,[]},
>            {rebar_core,process_dir,4,[]},
>            {rebar_core,process_commands,1,[]},
>            {rebar,main,1,[]}]}}
> ian@REDACTED:~/projects/cowgirl$
>
> This is copy/pasted from the log, so I can see I did indeed spell force
> correctly.

All these steps are about that third party tool, which hasn't been 
updated in a long time, and the rebar you use is probably too recent for 
it. Things still change a lot in both rebar and Cowboy so it's not 
surprising to see old guides stop working here and there.

> Where now? Is the pre-existence of those files a problem? I have no
> idea, and no idea how to find out. However experience tells me to make a
> real effort to fix the first error, even if later ones can be ignored.
> Should I delete them all and try again?
>
> What does the error in the generate mean? It can't mean the application
> cowgirl does not exist because hg/mercurial  brought it down without
> errors and app.sh created it without errors.

That tool is building a release. Do you know what a release is? It's one 
of the most advanced topic in Erlang/OTP, a lot of Erlang developers 
never used releases. That guide/tool is clearly not something useful for 
beginners.

> The talk is right. Erlang is just too damn difficult to do the easy stuff.

The problem you point out is general lack of good user guides. Erlang's 
community has many experts writing amazing software, some of it open 
source, but most of them do not have the time or skill to properly write 
good documentation. Writing good documentation is a work on its own and 
few developers are good at it. On the other hand, these experts are 
generally here on the mailing list or on IRC where they can provide 
quick help to solve specific problems. (And don't look at me, I'm no 
expert.)

> It may have been humorously presented (I wasn't there), but the
> take-away it so true.
>
> Early difficulties are putting off many would-be adopters.
>
> (And I'm stuck!  Help appreciated! )

Easiest way to start is to clone the cowboy_examples repository and play 
around with the existing code: https://github.com/extend/cowboy_examples

I've started rewriting examples with one proper application per example 
and hope to have most examples from misultin ported to Cowboy along with 
a few others and the user guides ready by the end of summer. Right now 
unfortunately I'm focusing on my OSCON talk next week so this has to 
wait a little. But I'm open to any and all suggestions on what you want 
in the documentation and/or examples for Cowboy or any of my other projects.

Hope this helps.

-- 
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu