Jan Pospíšil (@korel_cz)
- spent 1.5 years working in Amsterdam
- teams are working by compenents - menu, featured widget, hotel listing, hotel detail page...
- but it is not an issue if one team changes another's team component -> developers are expected to be intelligent enough to know their limits and experience
- each team can work as they want (some teams use Jira, some not and preffer blackboard or sticky notes...)
- core - one of the biggest Perl codebases worldwide (some Perl core developers work at Booking)
- no cool stuff (no ReactJS, no Node.JS, no HTML 5, no CSS BEM, no OOCSS, no LESS, no SASS, no Stylus...)
- jQuery 1.4.1 FTW!
- everybody knows or can learn jQuery
- fighting with the limit of 4096 selectors per single CSS in IE8
- everything is A/B tested
- 99% of the tasks is implemented and released in 1 day
- no internal testing, except some Selenium smoke tests
- even bug fixes are released as experimental A/B features
- if(experimentXEnabled) { newCode } else { oldCode }
- experimental features (experimentXEnabled) can be enabled or disabled using the A/B testing tool
- easy to rollack if it contains errors (this is why they do not test)
- LOTS of code is again removed after the results of A/B testing - some developers may not like that
- thanks to the HUGE traffic it's possible to run a LOT of A/B test simultaneously
- single A/B experiment has balanced mix of other A/B experiments -> it can be interpreted alone
- some advanced statistics may be required
- obsessed with monitoring
- another way to find bugs in code or issues with depoyed features
- all irregulaties has to be explained
- most of the issues is caused by the superrior powers though (e.g. drop of the sales during the Super Bowl finals)
- database team is separated - they are storing the credit card data -> law restrictions and regulations
- refactoring is NOT encouraged
- and nobody wants to do that, as any deployed code may be removed as the result of A/B testing
- no code style at all (not even TABs vs. spaces, etc..)
- it is not efficient to train developers in any formal style, they can use any style they like
- the production code is not nice and with bad architecture (e.g. no architecture)
- some code is 10 or more years old
- some files are huge and hard to work with
- but in the end:
- why it should be too hard for a developer to read code with different formatting?
- after some time, even the worst code can be decrypted
- and it is easier and more productive to hire more developers to figth with the bad code, than to do the refactoing all the time and work on the endless hunt for a perfect code
Adam Motvička (@motvicka)
- freelance developer, most known project - Zidlomat.cz (non profit!)
- the only good reason to become an enterprenour: Because my current job doesn't fullfill me
- bad reasons: money, freedom, more free time, I want to chnage the world
- steps:
- overcome the major weakness (I'm an introvert and I don't know how to talk to people; or I can't speak English...)
- build personal brand (do sexy projects, even if it doesn't generate money)
- meet people, go to the interesting (university) lectures and conferences,
- have mentors (more of them)
- create a group of people with similar goals (e.g. who went also freelance recently); (6 people who meet every 3 weeks; 15 minutes for everbody to explain his situation or issues - the rest helps him, as they have similar issues; public encouragement)
- https://github.com/seznam/IMA.js-skeleton
- Docker + Apache Mesos
Jan Bareš, Moravia IT
- pseudotranslations - automatically generated translations which are used to check the UTF conpatibility and UI (if there is enough space for all strings, if the formating doesn't break, etc...)
- modern tool for translators should automatically detect placeholders (and protect them)
- standardized format for localization - XLIFF
- context (desctiprion) should be part of the localization (e.g. in the comments)
- do not join strings, do not reuse strings (Home - Domu, Domov, Doma?)
Kamil Gregor
Usage of the bayesian analysis:
- Statement to be analyzed (e.g. "Russia sels weapons to Crimea")
- Estimate the basic subjective probability (based on the common knowledge, history, exprience...)
- hight probability = only basic evidence required to confirm the claim (e.g. testimony)
- low probability = conclusive evidence required (testimony can be false, etc...)
-
can be used as a framework - for moderated discussion:
-
all participating sides should do their own analysis, which is later compared and discussed
-
High probability example: Abraham Lincoln was a real preson
-
Low probability example: Abraham Lincoln was just a mythical figure.
Evel Meckarov (@@futureof7)
- learn X in Y minutes - nope
- learn from the BEST professionals (they are all on the internet), do not acceppt anything less
- learn from the professionals with REAL experience (from a real world, as recent as possible), not just with theoretical (university) knowledge
- advantage of big corporations: there usually is a lot of internal education programs (but sometimes outdated or in bad quality)
- build your own education workshop (simplify a lot, have fun and focus on the basics, gamification) (bad: decide some managerial decision bullshit; good: you are lost in the jundge and you have to decide who should live)
- gamification - actual hard tasks, not the "everyone is the winner" stuff
- nobody should be able to do the task completely right
- build workshops on a real experience (choose only stuff you're experienced with), not on a stuff from books (I finished this book about Gardening, I can do a workshop now!)
- mentors, more of them! - offer them your help
- encourage feedback, especially negative one (from the right people)
- recommended reading: Robert Greene - Mastery