Geecon is one of the biggest events in Polish IT calendar. This time I re-visited it, and wanted to share my thoughts not to forget things I learned. Following post is to sum up the 1st day.
10:00 AM, Pete larson
Conference started with 2 „soft” talks. The first brought to my mind that it us – developers – who are primarly responsible for the code quality. If we are insisting enough on some solutions, our managers (so called „business”) can learn how important it is to use the good tool for that task. And the whole quality comes from the team cooperating well. To do more, learn from your colleagues and teach them.
10:30 AM, Cliff Click
What happens if someone comes and breaks your flow, shouting at you? The only thing we can work on then, is our reaction. If we had to cope with problem, it is good to wonder what is the lesson we can learn. There is a nice saying.
„Harnest the best, toss the rest”
And if askedy some difficult questions, it is better to prepare response beforehand. You should be self-confident when talking about money, too. It happens in our IT world pretty often, huh? So the good part is to acknowledge that salary related discussion are kind of fight, a fight there are rules in, but still don’t forget you’re fighting. So know your value and do not surrender.
11:30 AM, by Peter Palaga
First we were introduced to differences between source and binary dependencies. Usually working with Maven you are using only binary, already compiled dependencies. With the tool introduced by Peter you can use source dependencies, meaning you can use git repository versions in your project. It can work with Maven or Gradle but we are advised to use Maven version. Basically srcdeps is intercepting calls to Maven repo and if there is „*-SRC-commitid” it goes to git repo searching for version, compiling in on-the-fly.
1:10 PM, by Marcin Grzejszczak
In the end of the day we as devs are being payed for a value we deliver. Delivering has to happen regularly, otherwise we have to face consequences. There are many changes we are introducing so there can be more errors after the deploy. In the ideal world, deployment should happen even without us being conscious of it. But we can safely go into this direction if we care for backward compatibility. This is the time where contract test come to a stage. Producer defines a contract, then tests are generated automatically to check if producer „do not lie”. We were shown a implementation of such a paradigm using spring specs. Having it as a part of your build process we can learn quickly (fail fast) if someone breaks the contract. This is the time where PaaS shines, as with it creating new environments is a piece of cake. It also encourages you to put your infra as a code, thus making it fully reproducible everywhere. Marcin showed that using CloudFoundry, that can be even run on local PC. It moves me to intensify my work on K8S as we have Openshift at my place. The difficult part in maintaing changes is especially having DB rollbacks. The ideal solution would be to avoid is whatsoever. And at the end we faced controversial opinion on removing E2E at all, if we have business allowance for so, and Test Pyramid shape is close to the perfect one. Gonna test
Bats as tool for testing bash scripts.
by Jarosław Ratajski
Problem: many companies are using JVM, so to use Haskell on JVM. Follow possibilities you have at your workplace and stop fighting against this – this is why I am happy to have docker in at my desk 🙂 Using ETA as compiler, which is linking *.hs code to fat runnable we car run Haskell anywhere. Jaroslaw showed that writing quicksort implementation. Haskell is being built by CABAL. ETLAS is used for ETA. It contains some import from C-langages which makes it little dirty. We could learn that you can even become an ETA developer and contributor easily, because it is hard to find developer fluent in that language.
Static vs Dynamic typing
by Thomas Enebo
Thomas first of all nicely introduced himself, as him being professional programmer for around 30 yrs. We had some tricky quiz, moving us to guess if the lang is static or dynamic. It is really hard to guess it only looking at a code snippet. There is some disambiguity in many definitions of what exactly is dynamic vs static typed language.
„If it is only compile phase to check quality of your prod app – you are doing it wrong”.
This is the testing culture, that helps you to maintain a high quality code, even TDD acronym was mentioned during the talk. From the Thomas experience you can see he was able to check lots of languages, analyzing their dynamic’ness and static’ness. With dynamic vs static differences it is clear when using IDE, most of ‚dynamic users’ tend to choose bare text editors. Static pros: when codebase is bigger static typing is helpful, as you can treat it as kind of documentation.