Guidelines for new contributors: Indentation and styleguide?

[Caleb Tutty]

Hi all,

I'm keen to make more contributions, but I just had a few queries about conventions in this project.

I've previously set up my editor (vim) with Rubocop integration, which can be pedantic about spaces and Ruby idioms using the Ruby styleguide (https://github.com/bbatsov/ruby-style-guide).

I just wanted to ask:

Is it a hard convention in this project to use hard tabs instead of two spaces? Would you prefer pull requests which don't reindent?

Is there a preference to use the Pythonic for ... in syntax over the Ruby-esque .each do |arg| ... end ?

What areas are the biggest pain points which you would prefer work sunk into? Where would you like to see the most refactoring? Is improving Code Climate scores a priority? Would moving from cron to Sidekiq (as I've seen discussed in another thread) be preferable?

I'm also preparing to share our experiences of trying to migrate (in phases) to a high availability dockerized Alaveteli installation, which meant trying to separate out pieces into smaller parts and not relying on a single server to do all the work. To make this a reusable image based on injected environment variables has required some assumptions which are a little different from how the project is structured and I would love to ask a few more questions about that a little down the road.

- Caleb

[Louise Crow]

Hi Caleb,

These are great questions, thanks for asking them.

Is it a hard convention in this project to use hard tabs instead of two spaces? Would you prefer pull requests which don't reindent?

The project got started with a convention for indentation with 4 spaces, rather than the conventional ruby 2. I'd very happily accept a pull request that converts the whole project to 2 space indentation, but in the meantime, I think a mix could get confusing, so would prefer pull requests that don't reindent. If there are hard tabs in some files, that's a slip on our part, I think. Happy to fix them.
 

Is there a preference to use the Pythonic for ... in syntax over the Ruby-esque .each do |arg| ... end ?

No, actually the converse, we just haven't removed all the 'for ... in' occurrences yet.
 

 

What areas are the biggest pain points which you would prefer work sunk into? Where would you like to see the most refactoring? Is improving Code Climate scores a priority? Would moving from cron to Sidekiq (as I've seen discussed in another thread) be preferable?

There are two things that spring immediately to mind - one is the extraction of incoming mail processing into a queue separate from the request cycle or from xapian indexing [1], the other is a general improvement in the quality of some bits of the code by refactoring into smaller, tested, self-explanatory methods. I see you have submitted a pull request to use SMTP rather than sendmail - a previous discussion thread on this list may be relevant to that [3] - Matthew Landauer wanted to use a queue to process outgoing, rather than incoming, mail in order to allow for retrying if the smtp server is unresponsive. Those things together make me think that adding a simple queue to Alaveteli might be a place where you can scratch your own itch and make a big contibution to the project at the same time. We'd talked back then about using delayed_job rather than sidekiq - I think delayed job would still be my preference on the grounds of simplicity and not bringing in other dependencies, but if you've got a strong preference for something else, I'm happy to have the discussion about pros and cons.

I'm also preparing to share our experiences of trying to migrate (in phases) to a high availability dockerized Alaveteli installation, which meant trying to separate out pieces into smaller parts and not relying on a single server to do all the work. To make this a reusable image based on injected environment variables has required some assumptions which are a little different from how the project is structured and I would love to ask a few more questions about that a little down the road.

Yes, do please! I think that would be an interesting conversation to have.

Cheers

Louise


[1] https://github.com/mysociety/alaveteli/issues/974
[2] https://github.com/mysociety/alaveteli/pull/2305
[3] https://groups.google.com/forum/#!searchin/alaveteli-dev/$20Email$20configuration$20$26$20background$20job$20queue$20for$20Alaveteli/alaveteli-dev/jL-7pChXd90/f0ndDMHpzZMJ
 

[Andrei Cristian Petcu]

Hi,

>> I'm also preparing to share our experiences of trying to migrate (in
>> phases) to a high availability dockerized Alaveteli installation, which
>> meant trying to separate out pieces into smaller parts and not relying on a
>> single server to do all the work. To make this a reusable image based on
>> injected environment variables has required some assumptions which are a
>> little different from how the project is structured and I would love to ask
>> a few more questions about that a little down the road.
>>
>>
> Yes, do please! I think that would be an interesting conversation to have.

I am also interested in dockerizing the application. I think using
docker for deployment is a good idea but since there are so many tools
around Docker it is hard to pick the perfect one.

I used https://github.com/phusion/baseimage-docker in a previous project
to run multiple processes into the same container. Separating processes
per container has been a bad experience for me. I wanted a lightweight
virtual machine, like a Vagrant that I can use in production. I also
took a look at rocket but I am not sure if it is mature right now.

I am open to discussions and I do not have strong preferences for one
technology or another but making the app container friendly is a subject
I am really interested in.

Thank you,
Andrei Petcu

[Andrew Black]

>  I think a mix could get confusing

I would agree with that. I have worked on a project where people have changed indentation conventions in a haphazard way and indeed it was confusing.