Felipe Lincoln

First I was using #GitHubProjects to manage my todo lists and annotate things about the development process. I decided to give #Trello a try because I was not happy with the #GitHubProjects UX and now I feel way more capable of managing my development tasks. I wouldn't go back.

I am using #Pylint to check for missing documentation and check for bad written code. It is easy to use and quite simple to understand its report.

I can't think of a way one can develop a real product not having to rely on #git. For the past couple of months I have been working intensively on my website and hence #git became part of my daily routine. It feel a lot comfortable being able to make changes to my main project not worrying about side effects it can have given that you can restore everything to the last version if the new code you introduced totally crashes the application.

Using #DockerCompose is a simple manner to mimic the production product seeing that it can get yourself working with local servers built from docker containers.

My website is brand new and one of the few requirements of testings I had to implement was code coverage. Never though it was so hard to implement using a #docker container. Given my lack of experience, every attempt I tried on making a simple code coverage test using the 4 combinations of #TravisCI, #CircleCi with #Coveralls, #Codecov I failed. The main problem was I was generating the .coverage file within the docker container and couldn't access it with #TravisCi or #CircleCi, every attempt to solve this problem seems to be very hacky and this was not the kind of complexity I want to introduce to my newborn website. This problem was solved using a specific action for #GitHubActions, it was a 3 line solution I had to put in my github workflow file and I was able to access the .coverage file from my docker container and get the coverage report with #Codecov.

My project is currently on the ground, I am trying to keep things as simple as it can be. #GitHubActions can do everything I need at this stage. I can not justify the use of a #TravisCi or #CircleCi yet.

The website I built is totally open source, hence every piece of my code should be documented and available for contributors. #Sphinx and #ReadTheDocs are the perfect match for this circumstances. It automates the process of generating the HTML pages with #Sphinx and #ReadTheDocs implement continuous deployment getting the last version of my #GitHub master branch. Once configured, the only work I have is making docstrings, the hard work is done entirely by these two fantastic tools.

Since I came from python I had two choices: #django or #flask. It felt like it was a better idea to go for #django considering I was building a blogging platform, this is kind of what #django was made for. On the other hand, #rails seems to be a fantastic framework to get things done. Although I do not regret any of my time spent on developing with #django I want to give #rails a try some day in the future for the sake of curiosity.

I am running raw HTML5 and CSS3 only, no front-end javascript framework. This is because I didn't want to introduce complexity to the website for the first release version. I can not justify the use of a js framework yet but some day it will be a must.