- @Hywan: Numbers and news,
- @Grummfy: Hoa Apex 4th edition,
- @iraphael Bank account,
- @Hywan: Discourse,
- @Pierozi: Infrastructure,
- @ashgenesis: PHP 7.1,
- @ashgenesis: New flyers for Hoa, designed by BrandBrothers,
- @Hywan: New fashion is to blame dependencies.
Numbers and news
We record 2,650,816 installations on Packagist. We record 1732 stargazers and 606 forks on Github.
Discourse is a new sponsor! Hurray!
New baby in the hoackers, that’s so great!
Hoa Apex 4th edition
2 possibilities. Either we join a big event (also organized by the guys who are organizing the next Hoa Apex, namely @Grummfy and @maitrepylos) or we keep it as usual. In the former case, the event could be delayed. In the latter case, we could schedule the event for November.
Maybe this is too early. We need time to find sponsors for the food, to find good transport fees etc.
Location: Bruxelles or Namur (Belgium). Confirmed!
This is a difficult topic. The fundation is French, with French laws, but the president is a french leaving in Switzerland, and the treasurer is a swiss leaving in Switzerland.
Classical banks do not want us. We need another bank. We are trying N26.com (ex number26). Internally, they are changing a lot, which postpone their opening in Switzerland. We are patient and we are waiting. We are waiting since almost 1.5 years so we can still wait few months.
Our mail server (including mailing list) has been removed due to innatention few months ago. This is hard to restore. Our comment system (http://posativ.org/isso/) is cool but we do not have an administration panel. We tried to develop one https://github.com/hoaproject/W3/issues/57. Some people complained about mailing list.
We talk to Discourse and they have accepted to host an instance of Discourse for us! Hurray! Accessible at discourse.hoa-project.net. Under configuration. They are 4 administrators so far with 4 moderators. We are currently working on the setup.
We will replace our comment system by Discourse too.
We will publish a blog post when it will fully configured and usable.
We are so happy to finally have a new platform to exchange.
Maybe we will host our own instance in the future. Currently we don’t because our machines are not powerful enough (https://www.scaleway.com/).
We have a big project, called Infrastructure (https://github.com/hoaproject/Infrastructure). The goal is to fully automate our infrastructure, from VM to services.
After months of work, we face two issues:
- This is a huge project,
- The goal was to setup the CI and the mails, and it’s still not here.
Having something under development in not a solution. We need a CI. We need mails. The other services are working (Git, HTTP, SSH, databases etc.).
Long discussion about our goals and short-term needs.
Solutions: We should use our AWS instances with AWS tools. Then automate things slowly. Step by step, instead of addressing the whole thing in a single step. For the CI, we will maintain all the scripts for Travis. For the mails, we have Discourse to replace mailing lists and Gandi to replace mails, so it’s fine.
Infrastructure is not dead. It will evolve to something a little bit different. Current landing code is working great.
PHP 7.1 is in beta. There is some BC breaks we have to catch. 2 majors yet:
- PHP identifiers are changing, https://github.com/hoaproject/Consistency/issues/12,
voidis a new keyword, https://github.com/hoaproject/Consistency/issues/10.
We are using atoum for the unit test framework behind
Hoa\Test. This issue https://github.com/atoum/atoum/pull/615 is blocking. We have to fix it too.
BrandBrothers (http://brandbrothers.fr/) is the company behind our new logo. They are offering us to design flyers, in case of events or files. This is an excellent offer, thanks! Go!
New fashion is to blame dependencies
Hoa’s libraries have smart dependencies. Small ones, addressing the SOLID principle, with a high quality and safety. However, the new fashion is to blame project with several dependencies and to promote project with zero or few dependencies.
What people see with Hoa is 4-5 dependencies per libraries. This is true. 1 dependency = few files. What some people would prefer is 1 dependency per library, so 1 dependency = many files. This is just a perception; We are not going to change that.
However, we must communicate about our design and why this is smart to have small and reusable dependencies (it reduces the bug surface, reuse the code so upgrade performances etc.).
If this is justify and clarify, no worry.
Goals for the coming month