In Goxfer — Part 4, I’ve coded the Goxfer program, pushing stored data online.
Now, it’s time to recap this adventure and to understand what I got from it.
In this article, I cover the last part of this journey:
At the beginning of this hacking adventure, I wanted to do something useful, having fun, learning new technologies and documenting everything so it would have been available for sharing.
So, firstly I’ve listed the objectives and I tried to follow them as much as possible:
- training on the job
- having fun
- getting things done
- making something useful
- sharing with someone
Of course I got much more from this adventure but I wanted to stick to this list, in any case.
In fact, during the journey, I faced some unexpected situations and experimented unwanted emotions.
An unexpected journey
When I started, I was quite thrilled and galvanised from the new challenge: taking all of my transactions of 2016 and putting them on Buxfer, using a various and heterogeneous group of technologies and languages, some of them very unusual to me.
Albeit goals were well defined and so the main objective (putting my transactions online), some unexpected complications came up.
For instance, testing: I didn’t think enough about automated testing on a big dataset. I had to do manual testing many times, by picking bunches of data from the result set, checking if they were ok and then trust them as safety. Obviously, I was wrong: manual testing can give you just a shallow idea of what’s going on underneath.
So, that situation was tedious because it would require me to spend a lot of time writing automated tests or performing new manual tests, just to have better results.
Another example, Buxfer’s APIs.
As I said in Part 4, initially they were bugged and I discovered it later, when I had already written the Cleaner, the Collector and part of the Goxfer program.
I had to stop the whole project, raise an issue on Buxfer’s Help Desk and wait at least one month to get the APIs fixed.
I was frustrated, demotivated and furious with myself: I should have check the APIs earlier, before starting the project.
That’s called Feasibility study.
But also unexpected good side effects shown up!
For instance, Hackernoon accepted this series and published it on their homepage.
My company helped me sharing my story on social networks.
I also had the opportunity to hold a webinar where I talked about this journey to a group of nerds of my city, Reggio Emilia.
Those things increased a lot my happiness and motivated me to take new hacking challenges!
Despite of these good, bad… well just unexpected events, I’ve achieved the main goals.
Happiness lies in the joy of achievement and the thrill of creative effort
Franklin D. Roosevelt
Training on the job
This point was quite necessary.
When you do hacking, it’s important to get something from that experience, something that can enrich you and your skills set.
In this case, I wanted to improve my knowledge about GoLang and Python, languages I don’t generally use in my job.
Also parsing CSV data is not a thing I do in my daily duties.
So, the goal was training myself with both known and unknown techs during the writing of this project.
Actually, this training required more in terms of time: for example, when I was looking for a solution on Stackoverflow or Google, I could have just copy’n’paste it inside my project but this would have broken the rule of training on the job. So, I checked the documentation, I tried to understand the code of other people and then used it inside my programs, sometimes in different ways.
But it worthed. I mean it.
Another interesting point was having fun.
Yes, because if you don’t enjoy the hacking moment, it is useless.
You do hacking in your spare time so you‘re entertaining yourself with something geeky.
If you take it seriously, like a job-task, then it’s better to stop and going out for a walk. Your life and the people around you will thank you for that 😬
Getting things done
But hey, don’t get stuck with just learning and having fun!
As I said, those things are ok, but you have to get things done!
This point became very useful when I was spending too much time, looking for the best solution for certain problems.
It’s ok finding good solutions but if you’re a perfectionist, like me, sometimes you lose the real goal of the project, that in this case wasn’t just learning and implementing like a pro but putting my transactions online.
Follow the flow but don’t let it divert you from your destination.
Making something useful
This was a good point.
I don’t mean I was creating something useful just for me but also for someone else.
Yes, if you’ve followed the entire series maybe you’ve found some technologies useful to your job or a good motivation to do hacking and having pet projects, like this one.
Keeping this in mind, I was keen to create, document and finish a working program that one day will be useful even for others.
Sharing with someone
Last but not least, sharing.
Even if we (developers) spend much of our time working alone in front of a notebook, sharing remains vital for our existence.
We live in a society full of unique and different people that can appreciate, contest, contribute or just take a look to our projects and we need to confront each other.
Sharing is the best way to do it, especially with well documented articles, full of code snippets, links to external resources and quotes.
So, please, let the world knows what you’re doing and why you’re doing it 😉
End of this journey
Woah, here we are, at the end of this journey: what an adventure 😁
Actually, I don’t have anything more to say or to show!
I’m just happy for this project and for sharing it with you, dear reader!
So, if you enjoyed, don’t forget to 👏, comment and/or share it!
See you in the next adventure!
Source code is available here: https://github.com/wilk/from-csv-to-buxfer