My first open source project
Since november last year I started working on the HabboAPI project. While it is not my first repository, and maybe also not the first serious project (that would be my attempt of the RWS library), it's the first where I went the extra mile to create documentation, tests, continuous integration and Packagist support.
I also intend to support this and hope to see other people contribute. So far I have one favourite!
Slope of enlightenment
When it comes to PHP development, something I've been doing for well over 10 years now, I feel like I'm on the so called 'slope of enlightenment' when you look at Gartners Hype Cycle graph.
I spent a lot of time in the 'trough of disillusionment'. First after I learned about security, forcefully so, because my applications and sites were targeted by scriptkiddies. I had to learn about cookie hijacking, XSS and SQL injection. After that I spend more time on defensive programming than actually delivering things. I was bummed out because it felt like I couldn't get anything done. I guess ignorance really is bliss.
Secondly an era that came around was where I had to try and understand concepts such as Git, Composer, PHPUnit and of course make the jump from PHP4 to PHP5; classes and namespaces.
I'm not at the desired 'plateau', but I'm also not panicking.
The lessons I learned
My project is now on Packagist as v1.0.5 and stable on Travis. I already created some Github issues for future versions.
In no particular order, here are some things that I wish I had done, I'm glad I learned from or that I would probably do the same next time.
Unit tests
It kind of goes without saying nowadays, but unit tests are going to save your life. Being able to make changes and run your tests, relying on them to tell you the truth is a wonderful feeling. You're no longer afraid to refactor your code or have to set up your local development server and do some arbitrary tasks to see if it still works as you designed it to.
Example.php
I created an example.php file to test and showcase the usage of my library and I also used this to test my changes visually, next to the unit tests.
In October, I started to have a real use for this library and started to implement it in my new project. I quickly discovered that both my unit tests and example.php
didn't catch all the situations. For example the most basic sad path (as opposed to happy path) caused errors, so instead I had to have it
throw exceptions and then catch it in my project code and that of the example.php page.
I'm not sure what the lesson is, but sometimes you can only find things out during real use, so maybe instead of an example.php, you could
use with a small Hello World application
README
Whether you intend of publishing your project or not, creating a readme is something that you also do for yourself. I still see many projects which have a really minimal readme or none at all. What said readme should include is another topic completely, but luckily for you there are already quite some blog posts about that.
Continuous integration
Something that I only recently became well aware of is continuous integration. Especially the option of running your tests with different versions of
(in this case) PHP, is a wonderful thing and allows you to easily detect what your minimal version should be set to.
Don't be afraid for your git log to look like this, while you're figuring things out.
Tip: If you're using Composer and Travis-ci.org, use composer update in the 'install' phase because
that will take care of the correct dependencies based on the PHP version you're running it from instead of taking it from your Composer.lock file
that has taken your development setup into account.
