As developers, we view code as one thing: a tool to build our projects with. But what if I told you that it can be so much more: CSS can be a paintbrush and HTML your canvas. In this talk, you will learn the basics of creating pure CSS images. You will find out everything about shapes, how to use less markup and why gradients are not just pretty, but pretty useful too. All these learnings will be brought into real life projects to show that nothing you create for fun has to be useless.
This talk will inspire you to view code differently and maybe even to create your own CSS drawings.
With the rise of both React Native and GraphQL lots of developers ask how to use both of them for building data driven mobile apps.
React Native is a perfect choice for mobile app development and it works very well with GraphQL powered backend. In this talk we will see how we can build React Native application that is powered by GraphQL. We will understand benefits of using GraphQL for server interaction and how we should integrate our GraphQL queries with popular state management systems.
Thanks to a suave OCaml backend, it’s possible to compile ReasonML to native code on nearly any platform. When ReasonML is paired with a library called Reprocessing, you can easily create compact, performant applications that run natively in the browser, on desktops, phones, and even embedded devices.
Does this really work? Will it hold up to scrutiny? Is it too good to be true?
Let’s find out together!
In 1976 McCabe developed metrics to determine the complexity of the code we write. One year later Halstead formulated a metric to achieve something similar. 30 years later, we still rely on those numbers that describe the complexity of our code, but do these metrics tell truth about our code?
I believe not. Thanks to our modern, sophisticated toolchain we have many metrics at hand that Mr. McCabe & Mr. Halstead could only dream of. In this talk, I´ll explain how the combination can give us much better & “more human” advice about the flaws of our codebase - not as abstract numbers, but as concrete pointers to the parts of our code that really need our love & attention.
A common “How to” for measuring the complexity of your code looks like this (see *1): “Install it - Create the report - Watch the report - And now go try make your code better!”. This is not far from the famous “How to draw an owl” (see *2) & only slightly worse than trying to understand this complex topic from wikipedia and the related formulas (see *3)
Aside from understanding these abstract numbers, we need to ask ourselves if looking at those metrics isolated is still the way to go more than 30 years after its invention. Our ecosystem has grown and so has the available data about our code.