DEV Community: Sanga

Kotlin Emojis Riddle 😈

liskov — Thu, 25 Mar 2021 16:36:26 +0000

What's wrong with this Kotlin code?

val emojis = listOf(“❤️️“, “🍔”)
val emojiIndex = someNullableInt ?: 0 % (emojis.size - 1)
val selectedEmoji = emojis[emojiIndex]

Let's decompile it to java code:

List emojis = CollectionsKt.listOf(new String[]{“❤️️“, “🍔”})
int emojiIndex = someNullableInt != null ? someNullableInt : 0 % (this.emojis.size() - 1);
String selectedEmoji = (String)this.emojis.get(emojiIndex);

Can you see the problem now?

the answer is below, don't look straight away :)

Answer:

In case someNullableInt is not null, emojiIndex will be assigned with the original value of someNullableInt and not its modulo.
This can cause indexOutOfBoundException.

how can we fix it?

the answer is below, don't look straight away :)

To fix it we need to add () around someNullableInt ?: 0 ->

val emojiIndex = (someNullableInt ?: 0) % (emojis.size - 1)

Which will compile to the following java code:

List emojis = CollectionsKt.listOf(new String[]{“❤️️“, “🍔”})
int emojiIndex = (someNullableInt != null ? someNullableInt : 0) % (this.emojis.size() - 1);
String selectedEmoji = (String)this.emojis.get(emojiIndex);

as you can see, now it will do modulo as expected. Case solved.

Thank you for reading, look for our next Byte

Made with ❤️ by Sanga

Controlling the beast

Matan Lachmish — Wed, 03 Mar 2021 16:15:49 +0000

We have all seen these happen too many times:

Every big project starts as a small one.
and a small project does not need a lot of stuff, right?

It doesn't need TESTING 🙈
It doesn't need SECURITY 🙉
It doesn't need CI/CD 🙊

Well, if you plan for this project to stay grounded and never make the leap to become a production product then you are probably right 🐒

This Byte is about another item that is usually left out until the project is too big and desperately needs it - CONTROLLING

Controlling

Every system needs a way to control its production product, for instance:

User's data
Content served by your app
Feature flags
Many more...

The greedy way

"For now, let's just create admin APIs"

Well, you do have a way to control but in the cost of:

Constant manual dev effort (the worst kind of dev effort 😉)
Inconsistent way of use, the risk of breaking something up is always high
Obscurity of implementation, APIs that are not consumed by any client can break/change without anyone knowing.
Centralized knowledge of how to control your system

The better way

Some call it "Admin Panel", others "Back office", I've heard "Dashboard" and "Console".

In Sanga we call it Control™

An easy-to-use app that provides a safe and consistent way of using those notorious "Admin APIs".

Controlling the beast at Sanga

As soon as we felt that those admin APIs are being used more than "just a couple of times" we've built our Control™ using Vue.js.

As straightforward as it may sound, our "definition of done" for a feature includes the ability to manage the feature through Control™.

That means that for every feature we:

Think what are the possible ways to control this feature
Design the relevant admin APIs
Enhance Control™ with the ability to interact with these APIs

Fun fact

Once you have such a capability, new features are being designed with control in place. That leads to some super cool capabilities that otherwise would probably be developed as stiff client-side logic that would be re-written endlessly.

Thank you for reading, look for our next Byte

Made with ❤️ by Sanga

Cross platform object oriented design 💣💥💥

liskov — Wed, 10 Feb 2021 08:38:42 +0000

Confused about too many names for the same property?

Tired of remembering all names other teams gave to the same feature?

Lisko, please give an example:

A good example from the industry is "String template":

iOS developers call it "String interpolation"
Kotlin developers call it "String template"
Javascript developers call it "Template literals".

But it is the same thing, like this giraffe. The only thing that changes is your point of view.

Shared architecture - same name on every stack

We at Sanga first encounter this issue with our IOS <-> backend
architectures and communications between them. When we saw it work
perfectly and without any misunderstanding we applied it to other sides
of our dev stack such as our frontend sphere, and it fitted like a glove.

The universal design language we created:

Contracts - The objects that pass between our stack parts
View Layer - Controllers, the topmost layer that creates an interface to be consumed (can be UI in an iOS app or REST API in a µservice)
Service - Business logic layer
Repository - Responsible for CRUD operations on our model.
Factory - Responsible for Converting Contracts to Models and vice versa.

Shared code

Shared architecture makes it possible to have a shared code.

We are currently on our journey to find the right way to share code between the different stack layers - but I wouldn't conclude it yet - as we didn't solve this question yet. when we do it will be one hell of a byte!

Thank you for reading, look for our next Byte

Made with ❤️ by Sanga

Monorepo

liskov — Wed, 20 Jan 2021 14:43:57 +0000

what?

Monorepo is when putting code of several micro-projects in one code repository.

So it's kind of a Monolith?

Well, that's the missing part of the micro-service architecture.

Splitting our code into micro-projects, each with its own tests, deployment, scaling, etc., introduces a new challenge of maintaining and using many microcode repositories.

Monorepo will hold the collection of micro-project while sharing the echo system of testing, deploying, etc.

when?

When your team needs to run fast -> faster -> fastest.
When there are too many repositories and no one understands what/where they are and if their dependency versions are aligned.
When small library change follows with 30 PR's on 30 git repositories (was the story of my life).
When there are a small number of teams working together because when there are a greater number of teams working on the same git repository, it can do worse than better.

When -> now()

Things to consider while working with a mono repo:

Per micro project build&deploy:
- use git diff to find out what directory changed
- build&deploy only this part
Code owners:
- what team is responsible for what part of the code?
Generate micro project script:
- Creating new microservice should be done in seconds(take a look at https://yeoman.io)
- Each new microservice should be built automatically by the same standard as all other services
Contract lib:
- All services contracts speak in the same language: Rest/Grpc/etc...
- All services use the same libraries with no duplicate code.

Listen to our CTO, Matan Lachmish, talks about Monorepos on Developing Symptoms podcast (for Hebrew speakers)

Thank you for reading, look for our next Byte

Made with ❤️ by Sanga

Architecture - The Pancake Theory

waffleman — Wed, 20 Jan 2021 12:35:41 +0000

It's very easy to get technical when discussing architecture,

But I believe that's not how you suppose to play that game at all.

The most important thing when building a layered system is to have a clear vision that is agreeable by all team members.

A clear vision helps us stay consistent in the way we think and approach those layers.

Pancakes

As a B2C SaaS company we decided to break down our architecture layers the following way:

As we see it, each layer is defined by its core purpose and expose an interface to be consumed by the layer above it.

e.g The services layer holds Sanga microservices and expose resources that are being consumed by the client layer via restful api.

Maple & Butter.

@#$% yeah, lets put some maple & butter on those pancakes 😉

Similar to how restful api acts as the tunnel that the services layer expose to the client layer above it (no news here 🤷‍♂️),

The infrastructure layer does the same by exposing the resources it creates to be consumed by the services layer via kubernetes (e.g Database, S3 Bucket).

That means that when a service is being deployed,

it looks for the resources it needs in Kubernetes secrets (big news here 🤯).

Thank you for reading, look for our next Byte

Made with ❤️ by Sanga

Welcome to Sanga Bytes

Matan Lachmish — Wed, 20 Jan 2021 12:09:18 +0000

This is exciting...

Every big journey start with one small step,

and this is the very first (and very small) step of Sanga's tech blog.

Let us introduce you to our Byte size concept.

The theme of our company's tech blog is to share with the dev community the concepts we came to refine during our journey of developing Sanga.

We aim to share ideas and ignite a thought process.

You will not find tutorials, or a very detailed step by step posts on how to write your first microservice or how to use Combine with Swift UI.

Instead, you will find a very concise concept written in a Byte size format.

Meaning, no more than a couple of paragraphs and an image.

We hope that this format will increase the relevancy of each post to all sort of backgrounds and stacks.

And we are positive that reading a Byte size post is easier than a Gigabyte one.

Thank you for reading, look for our next Byte

Made with ❤️ by Sanga