This morning I was reminded that, 4 years ago, I was looking for a project to get some experience with Java, C or C++.
So in 4 years, I started 2 Open Source projects, learned 3 new programming languages, and some other technologies and frameworks along the way.
I can say I learned a lot the last few years, on a technical level, but it also made me realise that it is possible to learn new things, if you set your mind to it. You just have to start doing it, try things, fail, learn from it, try again, read a tutorial, look for questions and answers (fe. on Stack Overflow), go to conferences, talk to experienced people, join a project that uses the technology you want to learn.
And this is not limited to technology. Want to learn a musical instrument? How to make a cake? How to become a great speaker? Learn to swim longer or faster?
This is all possible. You just have to start doing it and practice. Taking small steps at the start. Allow yourself to fail, but learn from it and improve. You might need some guidance or coaching, or take a course to give you a headstart.
I'm not saying it won't be hard, sometimes you keep failing, stop making progress and you get frustrated. And that's a time to take a step back, monitor your progress, examine the goals you have set yourself. Are you doing it the right way? Can it be done differently? Do you have all the required skills to make progress? Maybe you need to practise something else first?
Anyway, keep the end goal in mind, take small steps and enjoy the journey. Enjoying what you are doing or achieving is an important motivator.
If you set your mind to it, you can learn anything you want.
Which reminds of this video, how to learn anything in 20 hours :
Thursday, June 09, 2016
This morning I was reminded that, 4 years ago, I was looking for a project to get some experience with Java, C or C++.
Saturday, May 21, 2016
Recently, I came across some code of a web application that, on brief inspection, was vulnerable to XSS and SQL injection attacks : the SQL queries and the HTML output were not properly escaped, the input variables were not sanitized. After a bit more reviewing I made a list of measures and notified the developer who quickly fixed the issues.
I was a bit surprised to come across code that was very insecure, which took the author only a few hours to drastically improve with a few simple changes. I started wondering why the code wasn't of better quality in the first place? Did the developer not know about vulnerabilities like SQL injection and how to prevent them? Was it time pressure that kept him from writing safer code?
Anyway, there are a few guidelines to write better and safer code.
Use frameworks and librariesAbout every language has a framework for web applications (Drupal, Symfony (PHP), Spring (Java), Django (Python), ...) that has tools and libraries for creating forms, sanitizing input variables, properly escaping HTML output, handling cookies, check authorization and do user and privileges management, database-object abstraction (so you don't have to write your own SQL queries) and much more.
Those frameworks and libraries are used by a lot of applications and developers, so they are tested much more than code you write yourself, so bugs are found more quickly.
It is also important to regularly update the libraries and frameworks you use, to have the latest bugs and vulnerabilities fixed.
Code reviewMore people see more than one. Have your code reviewed by a coworker and use automated tools to check your code for vulnerabilities. Most IDEs have code checking tools, or you can implement them in a Continuous Integration (CI) environment like Jenkins, Travis CI, Circle CI, ... to check your code during every build.
A lot of online code checking tools exist that can check your code every time you push your code to your version control system.
There is no silver bullet here, but a combination manual code review and automated checks will help to spot vulnerabilities sooner.
Test your codeCode reviewing tools can't spot every bug, so testing your code is important as well. You will need automated unit tests, integration tests, ... so you can test your code during every build in you CI environment.
Writing good tests is an art and takes time, but more tests means less possible bugs remaining in your code.
Coding styleWhile not directly a measure against vulnerabilities, using a coding style that is common for the programming language you are using, makes your code more readable both for you, the reviewer and future maintainers of your code. Better readability makes it easier to spot bugs, maintain code and avoid new bugs.
I guess there are many more ways to improve code quality and reduce vulnerabilities. Feel free to leave a comment with your ideas.
Friday, January 01, 2016
2015 was an amazing year, learning a lot and making some progress in my Open Source development and climbing activities.
I have no real resolutions for 2016, I'll just spend my time on climbing and Open Source software development, learning new skills along the way and putting them into practice :
- use Ansible (or another configuration management tool) to provision a Vagrant based development environment for Buildtime Trend
- start using Django to add user management to Buildtime Trend as a Service
- learn how to climb safely in less equiped areas using friends, nuts, and other mobile protection
- apply the lessons learned form "The Rock Warrior's Way' while climbing
- visit a few conferences : FOSDEM, 33C3 and Newline, and maybe some more : LinuxTag, DebConf, FossAsia, KeenCon, ...
- do some improvements to my house
- Celebrated New Year in Lisbon.
- Reached a 365 day commit streak contributing to Open Source projects, with 2300+ commits over that period.
- visited FOSDEM 2015, another great weekend of Open Source enthousiast meeting and sharing knowledge in Brussels, with over 500 speakers and 5-10.000 visitors. Happy to meet Eduard and Ecaterina again who came over from Romania, and many others.
- Buildtime Trend was mentioned in the Black Duck newsletter
#OpenSource Wrap Up featuring new projects from #Facebook and #Google and a #ProjectSpotlight on @buildtime_trend http://t.co/WPo18wndI9
— Black Duck Software (@black_duck_sw) February 13, 2015
- Buildtime Trend made it to the top 3 of hot projects on OpenHub
- Reached the most active developers top 10 on OpenHub
- Released Buildtime Trend v0.2 and launched a Heroku app hosting the service.
- Visited Cork and Dublin with Sofie, attending Jeroen's PhD graduation ceremony and meeting Rouslan and his friends.
- Attended Newline 0x05 and did two talks : Buildtime Trend : Visualise what's trending in your build process and What I learned from 365 days of contributing to Open Source projects
- Ended my commit streak after 452 days
- Went on a climbing trip to Gorges du Tarn
- Flashed my first 6a lead climbing on rock.
- Traveled to the US, East coast this time, visiting Washington DC, meeting Lieven H and Wim, exploring New York City with Tine, Lukas and Marie-Hélène.
- One-day climbing trip to Freyr with Peter.
- And another climbing trip to Beez with Lieven V, Ben, Patrick and others.
- 4th blood donation, convinced Tine to join me for her first donation! Well done!
- Deployed a Celery/RabbitMQ based worker to Buildtime Trend as a Service on Heroku, taking some load off the webservice and improving the response times.
- Climbing trip to La Bérarde, with Bleau, doing my first multipitches (Li Maye laya and Pin Thotal) with Mariska and lead climbing a few 6a+ routes. Weather was great, atmosphere was superb, climbing was fun!
- Went to Fontainebleau for the birtdayparty of Andreas. Great fun, nice people, lots of routes. Finished my first red route in Fontainebleau.
- Travelled to California and made roadtrip from San-Francisco, to Yosemite, over Tioga Pass to Mojave Dessert, Red Rock Canyon, Las Vegas, Zion National Park, Bryce Canyon, Grand Canyon and flying back from Phoenix to San-Francisco. I did some climbing and hiking, took a climbing course on using cams and nuts. On the way I met a lot of nice people, with whom I had interesting conversations.
- Released Buildtime Trend v0.3
- Finished online Stanford University course Algorithms: Design and Analysis, Part 1
- Read The Rock Warrior's Way, a must read for any climber
- Visited 32C3 in Hamburg, 4 days of lectures, writing software and talking to other developers. It was amazing, next year again!
Tuesday, November 24, 2015
Visualise what's trending in your build processBuildtime Trend as a Service had a running preview of all the new features :
- introduction of a worker queue to make processing build job logs more scalable
- dashboard chart data can be filtered on build properties
- several new dashboard charts and layout improvements
- enable Keen.io query caching to improve chart loading speed
- the dashboard takes url parameters to set the refresh rate and the default settings for time interval and filter properties
- a statistics dashboard is added to monitor usage of Buildtime Trend as a Service
Do you want to enable Buildtime Trend for your the build process of your project on Travis CI? It is easy to set up.
Buildtime Trend as a Service is currently available for free for Open Source projects, thanks to the kind people of Keen.io.
DonateIf you like Buildtime Trend, you are welcome to support the project, by making a donation. Donations will help pay for the hosting and support further development.
You can help make the project better : we welcome any kind of contributions.
Tuesday, April 21, 2015
It was an amazing week, climbing in Gorges du Tarn with Bleau Climbing team during the second week of the Easter holiday.
Beautiful weather, nice people, good atmosphere, a lot of climbing, some personal bests and climbing improvements on both a physical and mental level.
Some impressions :
- Flashed my first 6a lead climbing on rock : Nique le lière in the Figues au Cul sector.
- Cooked spaghetti for approx. 50 people with a great team (Peter, Lieven, Hanne, Anneke, Jasper and Tim)
- Finished a lot of 5s on sight or flashed them.
- Discovered that my tent isn't waterproof anymore. Luckily there was a bridge that kept part of the camping site dry, so I moved my tent there during the rainy night. Yes, I slept under a bridge. ;)
- Almost finished a 6a+ on Noir Désir and started working in a very exciting 6c on La Muse, two projects for next time, so I know what I'll be training for the next few months. :)
Sunday, February 22, 2015
Visualise what's trending in your build processBuildtime Trend, that generates and gathers timing data of build processes. The aggregated data is used to create charts to visualise trends of a build process.
The major new futures are the support for parsing Travis CI build log files to retrieve timing data and the introduction of the project as a service that gathers Travis CI generated timing data, hosts a dashboard with different charts and offers shield badges with different metrics.
Try it out!The hosted service supports Open Source projects (public on GitHub) running their builds on Travis CI. Thanks to the kind people of Keen.io hosting the aggregated data, the hosted service is currently available for free for Open Source projects.
Get started! It's easy to set up in a few steps.
A bit more about Buildtime Trend
These trends can help you gain insight in your build process : which stages take most time? Which stages are stable or have a fluctuating duration? Is there a decrease or increase in average build duration over time?
With these insights you can improve the stability of your build process and make it more efficient.
The generation of timing data is done with either a client or using Buildtime Trend as a Service.
The Python based client generates custom timing tags for any shell based build process and can easily be integrated. A script processes the generated timing tags when the build is finished, and stores the results.
Buildtime Trend as a Service gets timing and build related data by parsing the logfiles of a buildprocess. Currently, Travis CI is supported. Simply trigger the service at the end of a Travis CI build and the parsing, aggregating and storing of the data is done automatically.
The aggregated build data is used to generate a dashboard with charts powered by the Keen.io API and data store.
Check out the website for more information about the project, follow us on Twitter, or subscribe to the community mailing list.
Tuesday, January 13, 2015
Today I reached a 365 day commit streak on GitHub, with over 2300 commits to Open Source projects in that period. In this post I'd like to share my experiences during this past year and the lessons I learned.
|Github contribution overview|
It started one year ago, on January 14th, 2014, the day I returned from a two week trip to Malaysia. I didn't take a laptop or smartphone on that trip, in order to be 'disconnected' from PC, internet and E-mail for some time. I've taken a habit to have a 'unplugged' holiday about once a year.
I had a streak of over 100 days running before I left on holiday, and had reached 2000+ commits during that year, so I was eager to start committing again, to keep the running total of commits close to 2000 and to start building a commit streak again.
I don't remember if I had a clear goal at that time of the total consecutive days of committing to Open Source projects I aspired to reach. I guess at first I wanted to match the previous record and see how much further I could get.
At the end of June, I got inspired by Josh (@dzello) from Keen.io who had pledged to commit to Open Source projects for 365 days in a row. I had an extensive streak going on at that time, so I decided to try and reach a 365 day streak as well.
@dzello Good luck, I'm currently at #oss162 https://t.co/LlWBoGzDwQ but I take a PC/internet free holiday every now and then.Until then it had been fairly easy to keep the streak going. Doing at least one commit every day is not that hard, and I usually did more than one. I was working on my Android app and I started working on what I called 'my side project' at first. In the last few months my focus has shifted to that 'side project', making it my main project basically, but that's a different story.
— Dieter Adriaenssens (@dcadriaenssens) June 24, 2014
So I had plenty to do and I was well motivated to work on my projects regularly, so it was easy to keep committing daily.
Until summer I didn't do any long trips, so I was either at home at some point during the day or had my laptop with me (when going to Berlin for LinuxTag, for example) so finding a few minutes every day to do at least one commit wasn't a big challenge. Although sometimes, it required some planning.
If I had a social, cultural or sports activity planned in the evening after work, I planned for an 'easy' commit on those days, usually cleaning up some code, fixing coding style, writing a small test, improving documentation or doing a few translations. I kept the bigger work, implementing a new feature, figuring out an API or framework, or doing some bigger refactoring for days when I had more time available.
Then summer arrived and I planned to go on a climbing trip for a week. I was in doubt if I would have time and opportunity to keep committing during the trip. But in the end I decided to take my laptop and give it a try. I worked on bash script to crop and scale Android screenshots that week, something I could easily develop and test without access to internet. On some days I barely managed to contribute, finishing the commit only a few minutes before the end of the day, but in the end I managed to keep the streak going.
Continued committing during my summer holiday and reached #oss190 Now on my way to #oss365 https://t.co/LlWBoGzDwQWith this hurdle taken I imagined reaching the 365 day goal was achievable. I didn't know back then I was to go on a few long weekends to Fontainebleau during the Fall, but again I took my laptop with me on the trip and found time to contribute some code.
— Dieter Adriaenssens (@dcadriaenssens) July 22, 2014
In the end of October I went to California for the Google Summer of Code 10 year Reunion and I had the opportunity to meet Josh, and Justin, also from Keen.io. Josh published a blogpost by that time explaining why he ended his commit streak at Burning Man, and why he wasn't planning on starting the streak again.
I read his post, and it got me thinking. Is this continuous streak a good thing? Sure, it was a motivation on its own, you want to keep going because you don't want to break the streak, you'd have to start all over again for a long time to reach the same number of consecutive days.
Some days you don't have time, or you've had a rough day and don't feel like turning on your PC and doing the required commit for the day, but would rather do something else, forgetting about that ongoing streak.
But I decided to go for it and finish the pledge to reach 365 days of committing to Open Source projects. I found out that my motivation wasn't only in keeping the streak going, but mostly in making progress with my projects.
Now that I've reached the 365 day goal I've come to some conclusions:
- Setting a goal helps to keep you going, but it doesn't necessarily has to be a streak of consecutive days commiting code. Josh mentioned this in his blog post as well, there are other metrics or goals you can aspire. Choose one that works for you and that is realistic.
- A minimum of one commit per day worked for me, and usually I reached more (6,4 per day on average, with a maximum of 27 at some point). But it would be harder for me to set goal of, for example, 30 commits per week. It would put pressure on me every week to reach that goal and it would be counterproductive, for me at least.
- Now that I've reached this 365 day goal I will keep the streak going as long as I'm comfortable with. As I mentioned, the one commit a day goal works for me as long as it doesn't interfere with my other commitments : I have a day job and regularly enjoy social, cultural and sports activities.
- Next time I'm going away for a few days, being it a holiday or a climbing trip I will not take my laptop with me. It will break my streak, but I'm OK with that. Disconnecting from everything for a few days every once in a while is more important to me. Afterwards I'll probably pick it up again and start a new streak, but it doesn't matter how long it will be. I'm glad I reached the 365 days goal, but I don't necessary feel the need to repeat it.
- As mentioned earlier, I found that my motivation lies in working on my projects, in seeing progress as I continue adding features and improving them.
- I noticed a few similarities in motivation for doing sport (and other) activities. When you're running, for example, it helps to set a goal (a total distance or an average pace to reach) or a metric (once or twice a week, no matter how long the distance or time spent). Choose one that works for you to keep you motivated. But also allow yourself to take break if you need one and pick up later again. In the end you should enjoy the activity, setting a goal is just a way to keep you going, but the fun of doing the activity should drive you.
Kudos to those who still have a very long commit streak going!