This article presents a business-driven approach to software architecture, focusing on maximizing profitability through technical decisions. It advocates for:
Distributed, stateless services with immutable models for scalability
Isolated third-party integrations without disrupting core logic
Simple, modular design
Best for:
✔ Tech leads designing scalable systems
✔ Managers optimizing dev efficiency
✔ Stakeholders evaluating ROI on architecture
I recently stumbled upon a package called dart_mappable, and I feel compelled to share what I liked about it. If you're involved in Dart or Flutter development, this might be of particular interest to you.
Riverpod is a powerful library that I like to think of as the Swiss Army knife of Flutter development. It offers elegant solutions for both state management and dependency injection, giving you the freedom to "cook" your app architecture just the way you like it.
Code Push in Flutter
In the fast-paced world of mobile app development, the ability to quickly push updates to users is crucial. Enter Code Push - a game-changing technology that allows developers to update mobile apps instantly without going through the traditional app store review process. This article explores how to implement Code Push in Flutter applications using Shorebird, a powerful tool that brings this capability to the Flutter ecosystem.
In this tutorial, I want to talk about the practical experience of native compilation of a production application written in Kotlin with Spring Boot and Gradle using GraalVM. I’ll start right away with the pros and cons of the native compilation feature itself and where it can be useful, and then I’ll move directly to the build process for MacOS and Windows.
At the end of the article, in the afterword block, I will talk in more detail about the project and why such a need arose, given quite a few limitations and pitfalls of supporting native compilation both from Spring Boot and from GraalVM.
Referential transparency, a key concept in functional programming, is often associated with more reliable, easier to test, and safer software. This term refers to a principle in which a function, given the same input, will always produce the same output without producing any side effects.
In the real world of software development, side effects are inevitable. Programs are rarely useful unless they interact with the outside world. This interaction could be reading from or writing to the console, making network requests, querying a database, or modifying a variable.
Yet, despite the necessity of side effects, they introduce risks and complexities. Programs with side effects are harder to test, harder to reason about, and more prone to bugs. They can also make the system as a whole more difficult to understand and maintain, due to hidden dependencies between components.
Enter referential transparency - a concept that means a function, given the same input, will always provide the same output, without creating any side effects. A function that adheres to this principle doesn't read any global state or change any state outside of its scope. The result is code that is more predictable and easier to reason about.
In terms of software safety and reliability, the absence of side effects is not enough. Programs should also be free from external influence - their results should only depend on their arguments. That is, programs should not read data from the console, a file, network, database, or even system variables.
This tutorial will guide you step by step in building an Android chat app in Kotlin with the help of third-party messaging SDKs. The reason I chose Kotlin for this tutorial is that - it is a lightweight programming language suggested by Google for building apps that work on Android devices.
In the steps ahead, I’ll show you how to develop an app in Android Studio, with messaging features that can integrate using SDKs. I use MirrorFly’s chat SDKs throughout this tutorial.
Many of us spend time in specialized telegram groups. The power over communication here belongs to random people with their own shortcomings. Conflict and abuse occurs regularly. Is there another way to keep order so that scam spam doesn't flourish and no one has total control over group members?
In my case, these thoughts led to the development and testing of a system that can be connected to your Telegram today.
In some projects, the build script is playing the role of Cinderella. The team focuses its main effort on code development. And the build process itself could be handled by people who are far from development (for example, those responsible for operation or deployment). If the build script works somehow, then everyone prefers not to touch it, and noone ever is thinking about optimization. However, in large heterogeneous projects, the build process could be quite complex, and it is possible to approach it as an independent project. If however you treat the build script as a secondary unimportant project, then the result will be an indigestible imperative script, the support of which will be rather difficult.
In the previous post we looked at what criteria we used to choose the toolkit, and why we chose gradle/kotlin, and in this post we will take a look at how we use gradle/kotlin to automate the build of non-JVM projects. (There is also a Russian version.)
Gradle for JVM projects is a universally recognized tool and does not need additional recommendations. For projects outside of the JVM platform, it is also used. For instance, the official documentation describes usage scenarios for C++ and Swift projects. We use gradle to automate the build, test, and deployment of a heterogeneous project that includes modules in node.js, golang, terraform.
(originally published on Medium)
I have talked to many Android developers, and most of them are excited about Kotlin. So am I. When I just started learning Koltin, I was solving Kotlin Koans, and along with other great features, I was impressed with the power of functions for performing operations on collections. Since then, I spent three years writing Koltin code but rarely utilised all the potential of the language.
During this year, I did more than a hundred coding problems on Leetcode in Java. I didn’t switch to Kotlin because I know the syntax of Java 6 so well, that I could effortlessly write code without autocompletion and syntax highlighting. But I didn’t keep track of new Java features, as Android support of Java SDK lacked many versions behind. I didn’t switch to Kotlin for solving problems right away. Although I was writing Kotlin code for several years, I felt that I need to make an extra cognitive effort to get the syntax and the language constructions right. Solving algorithmic problems, especially under the time pressure, is very different from Android app development. Still, the more I learned about Kotlin, the more I realised how many powerful features I’m missing, and how much boilerplate code I need to write.
One day, I have decided that I need to move on, so I started a new session in Leetcode and switched the compiler to Kotlin. I solved just a few easy problems, but I already feel that I have something to share.
