<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Posts on Блog</title><link>https://blog.mistadikay.com/posts/</link><description>Recent content in Posts on Блog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Tue, 24 Sep 2024 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.mistadikay.com/posts/index.xml" rel="self" type="application/rss+xml"/><item><title>An antidote to stressful sprints</title><link>https://blog.mistadikay.com/an-antidote-to-stressful-sprints/</link><pubDate>Tue, 24 Sep 2024 00:00:00 +0000</pubDate><guid>https://blog.mistadikay.com/an-antidote-to-stressful-sprints/</guid><description>There exists a common dissatisfaction with Scrum&amp;rsquo;s idea of delivering software in increments aka sprints. The author of Why Scrum is Stressing You Out, for example, argues that since sprints never stop and the pressure to deliver is always on, developers are becoming more and more stressed and don&amp;rsquo;t have time to perform supporting activities like testing, bug fixing, documentation, and deployments.
Why it happens The main reason is: sprints are simply too full.</description></item><item><title>When polymorphism bites you in the butt</title><link>https://blog.mistadikay.com/when-polymorphism-bites-you-in-the-butt/</link><pubDate>Mon, 02 Jul 2018 12:00:00 +0100</pubDate><guid>https://blog.mistadikay.com/when-polymorphism-bites-you-in-the-butt/</guid><description>A curious problem I faced recently when Java polymorphism met Scala polymorphism and they gave a birth to an ugly baby that I had to confront.
A short prehistory: we have a huge monolithic Scala web-application that was written 4 years ago and was barely maintained since then (however, it worked surprisingly well all that time). There are a lot of Java dependencies used in the project and despite the claims that Scala has &amp;ldquo;seamless Java interop&amp;rdquo;, it&amp;rsquo;s not all rainbows and unicorns.</description></item><item><title>reBEM: React ♥ BEM</title><link>https://blog.mistadikay.com/rebem-react-bem/</link><pubDate>Mon, 21 Mar 2016 12:00:00 +0100</pubDate><guid>https://blog.mistadikay.com/rebem-react-bem/</guid><description>It’s been about a year since me and Kir Belevich started using React at Lazada Group for some internal admin interfaces. We learned a lot during that time and our minds have been heavily shifted by that one-way data-flow philosophy React pushes.
Since React is not exactly a framework, but just a view library, we have both freedom of choice and a burden of responsibility, like: how to structure your application, how to manage its state or how to style your components.</description></item><item><title>Declarative data fetching in React components with Baobab</title><link>https://blog.mistadikay.com/declarative-data-fetching-in-react-components-with-baobab/</link><pubDate>Sun, 19 Jul 2015 12:00:00 +0100</pubDate><guid>https://blog.mistadikay.com/declarative-data-fetching-in-react-components-with-baobab/</guid><description>Reactive future What we love about React is how simple and enjoyable its declarative way of constructing components. And when GraphQL was introduced our minds were blown because we realized: we can do the same with data, describing what our components need and not caring about how and when it will be delivered.
Also, Netflix introduced JSONGraph and Falcor this May. What’s interesting here is that working completely independent from Facebook they came up with very similar ideas.</description></item></channel></rss>