<![CDATA[Yet another programming blog]]> 2017-12-28T01:00:37+01:00 https://xaerxess.pl/ Octopress <![CDATA[More Agile than Java - Keynotes from 33rd Degree 2014]]> 2014-06-27T14:44:02+02:00 https://xaerxess.pl/blog/2014/06/27/more-agile-than-java-keynotes-from-33rd-degree-2014 Few weeks ago, on June 9th-11th, I attended 33rd Degree Conference 2014 – a big Java event held in Kraków. It was my first programming conference ever, and I was stunned how awesome it was. I had a great time, met some nice people, had plenty interesting conversations and listened to many inspiring talks. I’d like to share my thoughts on 33rd Degree’s keynotes, which, as it turned out, weren’t strictly about Java or any other concrete programming language, but they concentrated on a developer – how he should work, what he should pursue, and how should he cooperate with business and management – all this as a way of achieving satisfaction and fulfillment.

Think for yourself

First keynote encouraged all developers to take responsibility, to do something that matters for clients. Yes, Marry Poppendieck, creator of lean software development1, told us, programmers, to take matters into our own hands. Ideally, there should be no (unnecessary) management between client and developer but if there’s one, the company should allow programmers to have consumers feedback accessible.

In the example Marry gave from her experience, the company which successfully adopted lean thinking (and development) techniques, reduced time spent on design defining meetings from 20% to 5% time spent on the project, leaving much more space for actual development and much more space for developers to do what they think is best for clients. This is quite similar to what Agile says, and for example Scrum does.

Developers should create right thing to develop, so adding a value to the product and then being able to access feedback from clients (to constantly improve software). Only that kind of attitude allows programmers to achieve satisfaction from work and what is called “the flow”, a psychology term introduced by Mihaly Csikszentmihalyi (who is obviously Hungarian). From Wikipedia) (emphasis mine):

Flow is the mental state of operation in which a person performing an activity is fully immersed in a feeling of energized focus, full involvement, and enjoyment in the process of the activity. In essence, flow is characterized by complete absorption in what one does. (…) Flow is completely focused motivation.

Flow, according to Mary, is each programmers goal, a nirvana everybody should should seek and chase.

Challenge vs. skill

Since flow appeared in almost every keynote on 33rd Degree, I think it’s quite important for each programmer to understand what this diagram means – more skilled developer needs new challenges, or else he won’t be satisfied.

As final advice Marry told us to remember about sharpening the saw – an ability to improve programming skills by doing something which isn’t programming. Jeff Atwood mentions reading programming blogs, HN, proggit; I’d add to that list writing on StackOverflow, following other devs on Twitter, and (starting from 33rd Degree) attending to conferences.

Managers are from Mars, Developers are from Venus

Ted Neward gave second keynote in which he described a really tough relationship between two groups of people from IT industry. This keynote didn’t actually have linear plot and a single conclusion, but rather consisted few interesting (and funny) stories, which I think were supposed to provoke a listener to think about software industry.

In the beginning of his presentation (and after assuring that no managers are present in the room) Ted added a disclaimer: there were many stereotypes in his talk, many personal claims which audience may or may not agree with, because these were his own observations.

So where’s the problem?

Developers struggle with managers who are like from another planet, because these two kinds of people just think and behave differently:

  • Managers don’t really understand these strange people who are doing something which doesn’t really exist! Timelines, excel spreadsheets, meetings – those are real, can be measured and shown to higher management, but bunch of text put into a machine isn’t real.
  • Managers manage people, developers manage machines. Hint: This is not the same.
  • Managers don’t have to be (too) creative, developers do.
  • Managers have time constraints and hourly schedule (which you can measure and arrange), developers have flow and satisfaction.

Ted compared flow to sleep – you can’t force yourself to sleep, you can only setup appropriate conditions for it. And meetings with management, phone calls, etc. don’t help in that.

The keynote was also a (small) rant on role of project managers role in modern software development. Well, it wasn’t a rant per se, but rather small history lesson about “scientific management” and its creator, Frederick Taylor. Long story short: The entire industry is broken because “scientific management” was a lie. Taylor authored “The Principles of Scientific Management” which consisted a basis for what is nowadays taught on Harvard, but his research was actually mostly made up! His “science” wasn’t really science, since it couldn’t be validated, but nonetheless his ideas spread around the world and still are by many considered as valid.

There was also a story about Scott Adams, creator of Dilbert, which basically showed how fuzzy is project management as a discipline. Funny and not funny at the same time.

Power to the Programmers

Second day begun with Tom Gilb’s talking about… much the same as Marry or Ted the previous day, only that Tom was concentrating on other aspects. Numbers, measures, tests were essential. That, combined with very dense slides made this session very weary, but also very striking.

Basically Tom showed scientific way of agile programming, proven to be right, because he presented many real case studies from his experience. The major idea was to delegate power to devs, so that they can analyze their own defects and fix their own process. These are few points I managed to write down:

  • automate and test as much as you can,
  • small, concrete targets (“quality requirements”),
  • be agile (“design is an iterative process”),
  • measure and validate everything.

Conclusions (taken directly from slides) match what we heard from day 1 keynotes:

  • Devs are better at managing their own work environment, than their managers are.
  • ‘Directors’ [i.e managers and architects] should NOT design the work environment.
  • Devs should ‘evolve the environment’:
    • through practical deep personal insights,
    • and take responsibility for their own work situation.

The talk is definitely worth watching when published, because then one would be able to listen and stop to read whole slide, and think about Tom’s ideas and experiences, which seem quite accurate.

Crazy and Focused

Next keynote was very different from previous one – Daniel Steinberg’s slides were raw, contained one word or maximum one sentence on each page, there were no numbers, several images and videos, yet this keynote was by many called the best on whole conference.

In his inspirational speech, Daniel encouraged every listener to think out of the box, and see users not as crowd, but as a single person.

Yes, developers should change lives, but since changing whole world is impossible, we should change at least one life – it should be our target. As an example, Daniel showed one of Apple’s ads – it was not about product itself, but rather what the product gives to the world. It adds a value to a user, the user. The Apple ad, Think different, in which Steve Jobs himself presented many modern visionaries, people who changed the world, like Albert Einstein, John Lennon or Dalai Lama. Each of them was “crazy”, crazy enough to think they can change the world.

We can succeed only if we focus on an individual, try to have closer relationship with client and pay attention to details. Daniel’s talk wasn’t just about slogans, it was his life manifesto, his personal experience, which made whole keynote very genuine and honest.

The Joy of Functional Programming

This was a proper entertaining and interesting keynote – Venkat Subramaniam had great contact with audience, did some live pair programming, and conveniently introduced lambdas to broad audience! It was also most “tightly coupled to Java” session among all keynotes, but still I think it should be interesting to every programmer.

Venkat presented a story of “mainstream”: how beliefs like Earth being flat and center of the Universe once were mainstream, but Copernicus and Galileo revolutions changed people’s perception of the world. In 20th century men landed on the Moon and nobody is claims that knowledge which in Medieval was mainstream is now valid.

In 2014 Java world was introduced to functional programming – lambdas and streams API were introduced in Java 8. So now imperative, object oriented programming is what average Java considers “mainstream”, but is it ultimate, one and only way of writing Java code? No, Venkat shows that functional programming in Java not only is possible, but superior to current standards. Declarative, functional code is both more readable and efficient comparing to classic imperative code. To do the transition, programmer must change way of thinking – once he does, he’ll feel benefits.

Venkat explained “scary” functional programming concepts in very plain and clear was. For example it’s his explaination of lazy evaluation, which feets in tweet:

If you weren’t on this keynote, you should watch it when it’s published, because all of that was told with help of audience member, Maria, who was asked by Venkat to volunteer and do the keynote with him.

The keynote turned out to be fantastic and I really look forward to see more Venkat’s talks.

Get Unblocked

Get Unblocked – 33rd Degree Conference from Denise Jacobs

I did a longer break before last session and skipped Eclipse keynote entirely, but stayed for the very last part of 2014 33rd Degree. Not only I didn’t regret waiting for last keynote, but I found it very motivating and stimulating (similarly to Daniel Steinberg’s one from the day 2). What’s more, Denise Jacobs presentation was an excellent closure to whole conference: it had subtitle “Allow Creativity to Flow”, mentioning flow there wasn’t a coincidence – it’s the same flow from day 1 keynotes, so clearly flow was conference MVP.

In the beginning Denise did a comparison:

So programming feels like magic. But it’s not. It’s magical, but not magic, because developers use creativity for everyday work. In real life we are distracted by management, bureaucracy, time constraints, hard working conditions, etc. So how achieve flow? There are many ways, Denise mentioned several practical examples:

  • rest or lay down, have a daydream,
  • get shower and relax,
  • get physical,
  • don’t write TODO lists, write TODON’T lists,
  • say NO to distraction (i.e. wear headphones).

But what about title? Why should we get unblocked, what exactly blocks us? Well, there could be any experience which stops us from being creative, some memory from childhood or situation from work, anything. If we realize that and rejects all these blocks and fears, we’ll succeed and we’ll be fulfilled and happy doing what we do.

Very often we have flawed and false picture of ourselves, but obviously “You can’t compare your insides to other people outsides” – our “inner critic” does comparisons wrong. What we can do is to move forward, unblock ourselves and be creative, then the joy will come.

Epilogue

Now I can see why conference budget is important for companies which want to have great coders – meeting other enthusiasts, Open Source communities’ members, “charging batteries” with motivating creativity talks – all this gave me something I was missing and I hadn’t even knew.

I was sitting in hallway alone, just twenty minutes after the conference ended (I live just 15 minutes by bike from the place where 33rd Degree was held) I realized that there are many thing in my life I can change and make better. So with this post it begins. I hope you enjoyed reading. If you attended 33rd Degree, I hope that it was a good remainder about what you experienced. If you weren’t there in 2014, I’d like you to wait for recordings and see what possibly interested you.

Initially I wanted to write about all talks I attended, but as you see I’m quite verbose and it’ll be far to long post if I mentioned them. Maybe one day…

One more mention – special thanks for Spatrez for bringing real coffee to 33rd Degree and kudos to barista who even in third day, after thousands of coffees, did proper, tasty lattes and cappucinos.

It seems I consumed almost 1% of coffees served there :)

  1. Quick introduction by Martin Fowler: You don’t do agile or lean you do agile and lean.↩

]]> <![CDATA[How I hijacked a CPAN module]]> 2014-03-12T19:01:51+01:00 https://xaerxess.pl/blog/2014/03/12/how-i-hijacked-a-cpan-module Today Neil Bowers (@neilbowers) wrote a blog post titled “What happens when you upload to CPAN?” – a sneak peek at the very last part of module releasing process (when you do cpan-upload and recieve these two strange emails). Although I’ve already released few distributions, PAUSE still seems to me as a mysterious tool with design (i.e. web interface) from previous epoch1, but somehow capable of managing over 29000 distributions maintained by over 11000 authors. What intrigued me in Neil’s article was the “hairy” part (namespace indexer), particularly a conclusion (“the permissions check should be separate from, and earlier than, the indexing stage”) and these three points:

  • PAUSE checks each package in your release to see if you’re allowed to release it. You must either be the owner or have co-maint (see the doc for PAUSE::Permissions). If you’ve flagged the package with no_index in the metadata, then the check is skipped.
  • You are given ownership (‘f’ permission) for any packages that don’t currently have any permission associated with them in PAUSE.
  • The second email is sent to you, with the results of the permissions check.

What wasn’t clear to me was whether PAUSE let me do an “unauthorized release” of a module which doesn’t have any owner listed in 06perms.txt. To find out, I wrote a simple script which found modules without owner (using PAUSE::Permissions) and then checked which of these are existing distributions (using CPAN::Source2).

As a result I had a list containing few “abandoned” distributions, from which I chose one: YAML::AppConfig – previously released in 2006, with few bugs on RT. I made two small fixes, bumped version to 0.17, made gzipped dist file and uploaded it to CPAN. I was expecting I’d receive two emails from PAUSE, the second informing me that distribution wasn’t indexed due to insufficient permissions. To my astonishment, I actually got “Status of this distro: OK” and “Status: Successfully indexed”, and after few hours every piece of Perl / CPAN / PAUSE ecosystem listed my release as proper one. I’ve checked 06perms.txt and found:

YAML::AppConfig,MOCONNOR,c
YAML::AppConfig,XAERXESS,f

PAUSE gave me ‘f’ permission, which I thought are given only to original distribution author. According to one of last Perl Advent Calendar articles covering PAUSE permissions model:

The ‘f’ permission (‘first come’) says that I was the first person to upload the module.

…who I wasn’t. At this point I closed a bug on RT, and started tweaking YAML::AppConfig, which, although “hijacked”, I consider suitable for my Monthly New Distribution Challenge 2014.

To sum up, either my understanding of PAUSE permissions is wrong or they have some flaws (or maybe features?). If I’m wrong, please correct me.

Anyway, does module hijacking counts as a module adoption?

Follow-up

I didn’t mean to disclose potential security threat, and I’m sure I’ll be more careful in the future writing about similar issues. Luckily, as you can see in the comment, @rjbs was in the right place in the right time (i.e. Perl QA Hackaton 2014) and fixed the bug in PAUSE.

To be honest, I looked at PAUSE code after I had “hijacked” module, but setting up PAUSE is “Very Hard™”. For example, I didn’t have any Apache 1.3 with mod_perl1 ready at hand, nor any spare time to compile it. Hope it’ll be easier in the future.

One more thing – I took the opportunity and “adopted” YAML::AppConfig: fixed all bugs, made all tests pass, added changelog, modernized its metadata, and uploaded version 0.19 on CPAN. If you spot more bugs (either in PAUSE or YAML::AppConfig), please report them. It’s open source after all.

  1. That said, I really like the idea of PAUSE and MetaCPAN dashboard integration.↩

  2. I had to fix CPAN::Source first; I’ll try to publish fixes for it later, because actually it’s a nice tool with 100% test failed on CPAN Testers.↩

]]> <![CDATA[Using ExtUtils::MakeMaker for my first co-maint release - Bloom::Filter]]> 2014-02-28T16:32:34+01:00 https://xaerxess.pl/blog/2014/02/28/using-extutils-makemaker-for-my-first-co-maint-release-bloom-filter After over 7 years, a new release of Bloom::Filter is out! Thanks to Maciej Ceglowski (MCEGLOWS / @baconmeteor), who was kind enough to give me co-maint permissions. If you don’t know what bloom filter is1, please read “Using Bloom Filters” (article written by Maciej in 2004, but still up-to-date and very interesting). Instead of writing about bloom filters, in this blog post I’d like to concentrate on Perl module release process, as a part of my personal “diving into Perl” process.

First, just a quick summary what’s included new version of Bloom::Filter:

As you can see – only minor changes, no new features or optimizations. Still, it was hard for me to deal with “legacy” distibution – written by someone else in 2004, last released in 2007, when Perl was in different shape and some tools didn’t exist yet. Bloom::Filter is my third module I uploaded on CPAN, but first managed by ExtUtils::MakeMaker (EUMM). Previously I used Dist::Zilla (dzil) and Dist::Milla (milla) to create a module from scratch and release it, which was quite overwhelming in case of Dist:Zilla (even with great documentation and tutorial), and very easy in case of Dist::Milla.3

However, what should I do to make a realease of EUMM module was not very obvious to me. Despite I had read few blog posts and tutorials dealing with “How to bootstrap release and manage a Perl module?” topic, none of them actually compared side by side and explained differences between dzil, milla, EUMM and other tools such as Module::Build, Module::Install, CPAN::Uploader4. It was quite confusing for a newbie like me and I had to read documentation of each of these modules to find out if I needed that module or not. As it turned out, managing distribution created with EUMM is harder comparing to Dist::[ZM]illa, because one has to do many things manually. EUMM documentation says it’s just an utility designed to write a Makefile for an extension module from a Makefile.PL. Bearing that in mind, next steps involved digging in EUMM documentation and hacking Makefile.PL. In particular, these are some problems I had to deal with (each of these should actually begin with “Contrary to dzil / milla, …”):

  • To maintain compatibility with older EUMM version, I had to remove some features by hand in Makefile.PL. I guess I expected that MakeMaker is actually MakeMakerMaker, which it isn’t, obviously.
  • README and LICENCE were not autogenerated and I had to maintain cohesion between Makefile.PL and these files.
  • After doing make dist there’s no next step to do actual release – tag, push and upload, another tool must be used for that (I used CPAN::Uploader).

So I found out EUMM is not a distribution making swiss knife, just a tool for managing Makefile creation process. That said, I don’t see a reason to use “raw” ExtUtils::MakeMaker or Module::Build plus some release tool instead of Dist::Milla – for my needs it’s more than enough, it takes care of all boilercode I don’t need to write, does all git-related release stuff, and changes version all over module.5

Speaking of versioning – according to David Golden’s article, it should be a boring task. It wasn’t, at least this time. I had to face two (actually three, third was, as always in Perl, TIMTOWTDI) issues here:

  • There was already 1.1 release on BackPAN (How is that possible?)

  • What is proper next development release for 1.0? I tried

    my $version = Perl::Version->new('1.0');
$version->inc_alpha;
say $version;

    which is unexpectedly 1_01, not 1.0_01 but for Perl::Version->new('1.1') it’s actually 1.1_01.

I’ve decided to just do one release for 1.1, without any dev releases. Luckilly, it worked without any problem, although it takes a while to see the release on (Meta)CPAN. Now, when this post is finished, I have to contact some downstream authors, which I know have been using patched version of Bloom::Filter and point them to the new release.

Oh, there’s this question which I am asking myself: should I move an old (i.e. co-maintained) module to Dist::Milla, or should it stay on EUMM forever?

  1. In few words: bloom filter is a space-efficient probabilistic data structure, which is used to test whether an element is a member of a set (from Wikipedia).↩

  2. Actually I don’t know how to filter closed issues which were fixed in 1.1 on RT… Any help?↩

  3. I have to write a blog post about my dzil and milla experiences eventually…↩

  4. I deliberately listed tools which aren’t used to same tasks, although my first impression was different.↩

  5. Dist::Milla is also contributor-friendly.↩

]]> <![CDATA[About blogging - a case study]]> 2014-02-23T16:16:11+01:00 https://xaerxess.pl/blog/2014/02/23/about-blogging-a-case-study To blog or not to blog: that is the question. Or is it? I believe that today, in Web 2.0 era, everyone should share the knowledge, exchange thoughts, make the world better place, etc. (see previous post about blogging). Yes, it may sound a bit idealistic, but I’ve always wanted to have a personal blog about programming and stuff I do, because I think it can make a difference for someone. In my case blogging didn’t work out (until now), probably because of two assumtions I made: write regularly in Polish and serve blog on my own blog engine on my own VPS. My first try from 2009 is still out there – it was a blog engine written in Django (a Python web framework), styled with custom, rather primitive CSS and filled with very few posts. As a small, personal project it failed, but because an old Polish sentence says “humans learn from failures” (I don’t know if there’s English equivalent), I’ll write down what was wrong back then and what I’ll try to do this time.

  1. In those days I was too ambitious. Have a blog, write a blog, develop a blog engine and layout, manage a server. The new site is hosted on GitHub Pages using Octopress as static site generator and customized Octostrap3 as blog theme. Basically I stripped all my assumtions to write (quite) regularly, let’s see if that’ll do. (There are few defaults of Octopress I’d like to change someday, but let’s just hope it won’t distract me from writing.)

  2. For my first blog I chose wrong technology: Python, which is fine language, but I’ve never worked proffesionally in Python, and Django, which is fine platform, but not for personall blogging. Basically I told myself: “During studies you made few projects using Python, you made one using Django, but neve atually learned any of them.” So I grabbed Django Book, collected some resources found on the web and spent few days writing code, setting up server, tweaking layout, etc. There was not much time left for blogging because I was busy mastering Python and digging into Django (ex. I was writing posts from shell instead of using dedicated admin interface). It wasn’t a bad experience (I dove into Python and Django which was fun after all), but combining blogging with programming didn’t work out for me. I think UNIX philosophy “do one thing and do it well” will function well this time – all I need to write a post is just a text editor (cough Emacs cough), then do some rake / git stuff and it’s online. Maybe another time I’ll write a blog engine or static site generator but for now I’ll just write content.

  3. I also chose wrong language (for content). What I mean is I’m proud being Polish, but every blog I read is written in English, even if author is Polish. English is lingua franca in programming, science and business in XXI century and there’s no need to resist that trend. Consequence of choosing Polish as a language was much smaller audience, so this time (as you can see) I’ll write in English. Maybe now someone will even leave a comment under one of my posts. Who knows, I’ll wait. Also, when I feel the blog is ready, I’ll start promotion, i.e. tweet about it, subscribe it to some aggregators and so on.

  4. I’m rather a perfectionist and quite often I hesitate if what I’m going to share on the Internet is well-written, does not have obvious errors, or is worth it. For now, I’ll do my best to release early, release often. After all, this post is on GitHub and you can fill an issue or make a pull request. Actually, feel encouraged to do so, stuff here is available under Creative Commons Attribution license.

  5. Previously my blog had no purpose, it was basically about nothing (partly because I treated it as a programming excercise). For contrast, the new blog shall be about everything. By everything I mean I’ll try to write about every thing I think “Hmm, that’s nice, never thought of that” or “Finally solved that!”. There were far too many situations when I thougth “I should share this somehow” and I didn’t.

So, many promises, not only to myself, but for me it’s time to put the bar a bit higher.

P.S. English punctuation is killing me, in Polish there are much simpler rules for placing a comma before and, or, but, etc., etc. (ex. there is no comma before “etc.” in Polish). So please forgive me my ignorance and suggest an edit if you spot an error.

]]> <![CDATA[New module on CPAN - Task::BeLike::XAERXESS]]> 2014-01-31T22:38:02+01:00 https://xaerxess.pl/blog/2014/01/31/new-module-on-cpan-task-belike-xaerxess Perlbrew is a great module. I use it on every machine – it lets me install modern Perl versions on systems which ship with ancient a.k.a. good-old perls like 5.8 or even those from previous millennium. But there comes a problem – every perlbrewed perl has a separate environment and it lacks all CPAN goodies you installed and used earlier. Plus, if you have few machines and / or like to experiment with various operating systems (like me), you have to install modules you use again and again.

To address this issue I’ve released Task::BeLike::XAERXESS. It’s a Task module which has a simple purpose – it installs a module bundle I frequently use. What’s more, because I uploaded it to CPAN, you can use install, try or modify it (the source code is on GitHub).

I don’t expect that anyone besides me will ever install and use Task::BeLike::XAERXESS, but there was another reason I made this module: do a module release with Dist::Milla. Let me cite:

Milla is a Dist::Zilla profile. It is a collection of Dist::Zilla plugin bundle, minting profile and a command line wrapper. It is designed around the “Convention over Configuration” philosophy (Opinionated), and by default doesn’t rewrite module files nor requires you to change your workflow at all (Unobtrusive).

I wanted to compare milla with pure dzil because I used latter once (to release my first module – Time::Duration::pl) and last few days there was quite much buzz about Dist::Zilla being suitable module releasing tool. I’ll write all my observations later in separate post, in just one sentence – milla is great: powerful like dzil but much simpler, it has everything I need to release a Perl module.

]]> <![CDATA[MANIFEST - or (future) content of this blog]]> 2014-01-27T00:04:43+01:00 https://xaerxess.pl/blog/2014/01/27/manifest-or-future-content-of-this-blog I’m starting a programming blog (again). I don’t know if it’ll be successful (where successful means updated regularly for me), but I’d like to begin with meta-post about what I want to have here. Since I’ve been (proffesionally) working as a Perl, Java and JavaScript developer for few years, vast amount of topics will be about these programming languages, with Perl being main one.

Short clarification here: Perl has a facinating community with really, really great developers, and if you look back to previous sentence you’ll see that I only linked to Perl webpage, contrary to Java and JavaScript. The reason is simple: these two J* languages have no proper webpages and no (open-source) community. You can go to java.com and click big red download button, but that’s all. Google “java” and you’ll see “Oracle” and “™” higher than “OpenJDK”. Typing JavaScript in Google gives you zero language/community hits (let me just say that w3schools is first one); ECMAScript is all about standards and many JS devs aren’t be able to tell what ECMAScript is.

On the other hand, googling “perl” gives you hits like:

  • “The Perl Programming Language – www.perl.org”,
  • “Perl programming documentation – perldoc.perl.org”,
  • “The Comprehensive Perl Archive Network – www.cpan.org”,
  • “Strawberry Perl for Windows”,
  • “Perl Monks”,
  • “The Perl Foundation”

from which every single resource is awesome – if you’ve been using Perl for a while, you just can’t not appreciate whole ecosystem and say Perl is dead because it’s simply not true at all.

Besides writing about software engineering and programming languages, because I believe in free and open-source software and culture, I’ll probably cover these topics, too. (Lately I started contributing to various open-source projects, I’ve been using GNU/Linux for almost nine years, I really enjoy both). For now, I’d like to point you to this blog post (by @pjf) which I fully agree with:

“While I’ve always known open source software is great, I’m increasingly starting to appreciate that open source developers are also great.”

What’s more, I’d like to share everything on this site for free, so I’m making all my code available under MIT license (unless marked otherwise) and all my writing available under Creative Commons Attribution license. You can grab the code of this blog is on GitHub, use it, fork it, modify it, etc. I’ll also be grateful for all suggestions and for spelling or grammar fixes because blogging in English and not being native English speaker is a challenge.

Anyway, enjoy reading, consider leaving a comment or following me on some social media, and have a nice day.

]]>