• What we'll do
January this year, two _earth-shattering_ attacks have been made public: **Meltdown**, also known as #IntelBug, and **Spectre**, touching all platforms. They are possible thanks to speculative execution of code (a very interesting feature of modern CPU architectures) and affect pretty much everybody (a bit of a simplification here but you have a modern CPU, you're affected). Attacks are incredibly widespread since they are unearthed from the very bottom of all tech-stacks: the CPUs. Let's discuss both of them.
Short, one minute read: https://danielmiessler.com/blog/simple-explanation-difference-meltdown-spectre/
As ever, this is going to be reading club, so:
## Reading materials
These are two academic papers discussing both attacks and their discoveries. The site (both meltdownattack.com and spectreattack.com URLs are for one site) also holds nice and easy to digest information about the attacks.
Google Zero Team announcement: https://googleprojectzero.blogspot.co.at/2018/01/reading-privileged-memory-with-side.html
CERT KB page for the issue: http://www.kb.cert.org/vuls/id/584653
• What to bring
Paper or digital copies of reading materials, mainly two papers:
• Important to know
To be truly secure: change your CPU to one that's not affected. :( Yeah, we know.
Next best thing is to UPDATE YOUR OS. All major OSes have released / will soon release patches.
To be somewhat secure:
Turn on site isolation in Chrome/Chromium.
Turn off SharedArrayBuffer in Firefox.
Don't use browser AND password manager simultaneously (there's a JS exploit already, I hear, didn't verify).
Logos we used are kindly done by Natasha Eibl, https://vividfox.me/. She made them part of the public domain.
Zapraszamy wszystkich na spotkanie, które poprowadzi online Jarek Pałka, który od wielu lat jest członkiem SCKRK. Będzie on opowiadał o implementacji maszyn wirtualnych od kuchni. Ponieważ większość z nas pracuje w technologiach, które wykorzystują maszyny wirtualne pod spodem, może być to bardzo dobra okazja do poszerzenia swoich horyzontów. Jest to też dobra okazja, żeby komuś pomóc, ponieważ warunkiem udziału w prezentacji jest pomoc małemu Julkowi, który walczy z ciężką chorobą.
Spotkanie odbędzie się zdalnie przez Hangout/Zoom (szczegóły zostaną podane zainteresowanym w późniejszym terminie). Zapisy odbywają się na Facebooka poprzez przesłanie Jarkowi potwierdzenia przelewu dla Julka na konto Fundacji Iskierka.
Wszystkie szczegóły znajdziecie na stronie wydarzenia: https://www.facebook.com/events/366193627124681/?active_tab=about
For our English speaking members:
Jarek Pałka, long time member of SCKRK is organising an online presentation about Virtual Machine implementation techniques for charity. The presentation will be in Polish, but if you are interested in attending it in English, please let Jarek know. If enough people show interest, he can do another talk for you.
Code Retreat is a fun exercise. You meet a bunch of strangers and friends alike, mix with them for a 45 minutes pair-programming and try to solve a simple (deceptively!) problem in a TDD manner.
So, you code a lot and... you learn a lot. Different IDEs, different languages, different versions of Java, different testing frameworks, keyboard shortcuts, etc. etc.
The exercise is famous enough to have its global edition, every November. Hence - this meeting.
Aside from the first (two?) session(s?) each session will have its unique constraint, to make things more interesting. :-)
We WON'T be doing Game Of Life this time.
- your own laptop or PC (with power)
- anything else you need to have to code (fave keyboard included)
- set your IDE and test framework for all languages you wish to use on that day (yes, languages, this event is multi-culti or language agnostic if you prefer).
Registration for this meetup opens at 7pm on Wednesday the 29th of March and is limited to 115 attendees.
Happy databases are all alike; every unhappy database is unhappy in its own way. Following Tolstoy's insight into distributed systems, we discuss the myriad ways in which the conversations of computer families can break down, leading to broken promises and broken hearts.
Aphyr, or Kyle Kingsbury, is a computer safety researcher working as an independent consultant. He's the author of the Riemann monitoring system, an introduction to programming in Clojure, and the Jepsen series on distributed systems correctness. He smashes databases in San Francisco.
Where / when:
Office open from 18:00
Codewise (http://codewise.com/) is a place where talent thrives. Since 2011 it has provided a collaborative environment that fosters creative solutions and growth, enabling it to build its flagship marketing technology platforms, Zeropark, the leading performance traffic exchange, and Voluum, which provides a powerful suite of campaign management and analytics products across mobile and desktop. Entirely self-funded and headquartered in a new 3,000 sqm office in Krakow, Poland, with a second office in London, England, Codewise employs 130+ talented individuals from six different countries and supports customers in over 190 countries worldwide.
How many of you have every used an ORM framework to control your transactions? How many times have you caught yourself on implementing additional validation layer to ensure data integrity? Feral Concurrency Control: An Empirical Investigation of Modern Application Integrity is an in-depth evaluation of application-level mechanisms for maintaining database integrity. The study is mainly based on transaction control in Ruby on Rails ORM, but the conclusions are easily applicable to other popular frameworks such as JPA or Hibernate.
Paper to read:
Feral Concurrency Control: An Empirical Investigation of Modern Application Integrity (http://www.bailis.org/papers/feral-sigmod2015.pdf)
Lifeguard: Grzegorz Bańczak
• Summary on the morning paper:
Please note: changed day of the week
This time the meetup will be held on Tuesday 16th May! It's an one time exception, further meetups should be as usual on Wednesdays.
Robin Hood hashing was introduced by Pedro Celis in his thesis in 1986
The idea is that entries are moved around based on how far they are from their initial buckets — the initial bucket being the bucket to which an entry is hashed. Robin Hood hashing takes buckets from entries that are closer to their initial buckets compared to the entries that need to be inserted.
In that way, it takes from the riches and gives to the poor, which is where the name “Robin Hood hashing” originates.
Whitepaper to read (pages 12-18): https://cs.uwaterloo.ca/research/tr/1986/CS-86-14.pdf (https://cs.uwaterloo.ca/research/tr/1986/CS-86-14.pdf)
• good summary article: http://codecapsule.com/2013/11/11/robin-hood-hashing/ (http://codecapsule.com/2013/11/11/robin-hood-hashing/)
• simple rationale article: https://www.sebastiansylvan.com/post/robin-hood-hashing-should-be-your-default-hash-table-implementation/
• example cache strongly inspired by robin-hood hashing in Akka (https://github.com/akka/akka/blob/master/akka-remote/src/main/scala/akka/remote/artery/LruBoundedCache.scala#L50)
Lifeguard: Konrad `ktoso` Malawski
These days, your API most likely serves multiple clients - tablet and phone apps, rich web applications, perhaps even other applications that talk to it. These clients tend to have different needs - mobile clients will often show and need to fetch less data than the desktop client, or another application might want to access collections of resources rather than a single resource that would be displayed by a user facing mobile app. REST, which we discussed a few meetings ago, does not provide solutions for this problem. However, certain tools have cropped up that do: GraphQL and Falcor. This week we are going to focus on GraphQL.
Article to read: The Web After Tommorow (http://tonsky.me/blog/the-web-after-tomorrow/)
Secondary article to read: The official GraphQL blog (http://graphql.org/blog/) (all 5 articles)
Meeting Lifeguard: Grzegorz Bańczak
We typically select only one resource to read for a meetup, so this might seem a little excessive, but in our defence there is no academic paper introducing GraphQL. The Web After Tomorrow article is a great opinion piece that should help us ground our discussion in terms of why GraphQL is important, and where does it fit in the array of technologies that will likely be found in the future APIs/backends. However, as inspiring as the article is, the discussion would be pretty shallow if we all didn't have even a basic practical idea about how to work with GraphQL and how it looks like, which is where the blog comes in.
Feel free to share interesting resources you find about GraphQL in the comments section!
At a certain scale, transactions become impractical. In fact, in the era of microservices, many developers run into the problem of having to work around not being able to use ACID transactions across multiple of these distributed (micro)services. The paper that we are going to discuss this week describes approaches to dealing with partitioned data in the context of transactions.
Paper to read:
Life beyond Distributed Transactions:an Apostate’s Opinion (http://www.ics.uci.edu/~cs223/papers/cidr07p15.pdf) by Pat Helland
Medius, ul. Królewska 57, Biprostal Building 8th floor
Many decades of work have been invested in the area of distributed transactions including protocols such as 2PC, Paxos, and various approaches to quorum. These protocols provide the application programmer a façade of global serializability. Personally, I have invested a nontrivial portion of my career as a strong advocate for the implementation and use of platforms providing guarantees of global serializability.
My experience over the last decade has led me to liken these platforms to the Maginot Line. In general, application developers simply do notimplement large scalable applications assumingdistributed transactions. When they attempt touse distributed transactions, the projects founderbecause the performance costs and fragility makethem impractical. Natural selection kicks in.
Instead, applications are built using different techniques which do not provide the same transactional guarantees but still meet the needs of their businesses. This paper explores and names some of the practical approaches used in the implementations of large-scale mission-critical applications in a world which rejects distributed transactions. We discuss the management of fine-grained pieces of application data which may be repartitioned overtime as the application grows. We also discuss the design patterns used in sending messages between these repartitionable pieces of data. The reason for starting this discussion is to raise awareness of new patterns for two reasons. First, it is my belief that this awareness can ease the challenges of people hand-crafting very large scalable applications. Second, by observing the patterns, hopefully the industry can work towards the creation of platforms that make it easier to build these very large applications.
• Summary on The Morning Paper blog (https://blog.acolyer.org/2014/11/20/life-beyond-distributed-transactions/)
• Feral Concurrency Control (http://www.bailis.org/papers/feral-sigmod2015.pdf) - a paper describing transactions from a smaller scale web app
• Google Spanner (https://research.google.com/archive/spanner.html) - a paper describing a system where two layers of Paxos are utilised to enable transactions in a massively distributed system
We weren't planning on organising Global Day of Coderetreat (http://globalday.coderetreat.org/) this year, but thanks to Tomek, we won't have to abandon the tradition!
The Global Day of Coderetreat takes place on 22nd October. Yet again, we're coming together to hack on Game of Life in pairs, in variously hindered 45-minute long sessions.
A Coderetreat is a whole day long (9 hours!) exercise in Pair Programming and TDD. We start early - 9am, but rest assured that the experience is well worth getting up at the brink of dawn. After introductions, a cup of coffee, a bite to eat and an explanation of the problem we are going to solve (Game of Life), we will proceed with 3 programming sessions, each 45 minutes long and ending with a retrospective. Oh, and did we mention pair programming? You will be switching pairs after each session. Next we will have a nice, relaxing, catered lunch break (yay! free food!), followed by 3 more sessions and a final retrospective.
You will get all of this free stuff thanks to our awesome and generous sponsors:
• EPAM (https://www.epam.com/) (http://www.abb.pl/isdeliverycenter)will host us in their amazing venue and supply us with the breakfast, lunch and beverages during the day
• Symentis (http://www.symentis.pl/) will give out t-shirts to all the attendees
A few important notes:
• id, so you can enter the building (especially if you registered with a nick, or are here just as a guest, not in your full name). Building security may require you to sign that you were there. We will try to be there and mediate, but please take ID with you.
• Laptop with power cord.
• IDE for all languages you want to code in. Download what is necessary, libs, compilers, interpreters... set yourself up PRIOR to actual event. We don't always have full WiFi available on the premise.
• SCM (Git, Bazaar, Hg,...).
Come and join!