What is Zemble? Zemble simplifies the process of creating modular, scalable, and maintainable applications by offering a robust platform for building composable apps. This open-source effort, spearheaded by Kingstinct, aims to streamline the development process while maintaining high standards of code quality and functionality.

Where microservices introduces complexity by involving infrastructure in it’s approach to separation of concern Zemble aims to provide a plugin system that’s infrastructure agnostic. In the long term we see Zemble providing “fullstack plugins” that are easily reused across projects no matter if those projects are composed as huge monoliths or run as thousands of microservices that communicate with each other. We find it already works very well on backend — while we’re still exploring the best options on frontend composability.

Key Features of Zemble

1. Modularity: Zemble’s architecture promotes the development of modular components, making it easier to manage and update individual parts of your application without affecting the whole.
2. Ease of Use: Designed with simplicity in mind, Zemble allows developers to integrate plugins seamlessly, reducing the learning curve and accelerating development time.
3. Community-Driven: Being an open-source project, Zemble thrives on community contributions, ensuring continuous improvement and alignment with the latest industry trends.
4. Reusability: At Kingstinct we’ve found we often reuse the same patterns over and over again, with smaller adjustments between our various projects. Being able put this into reusable modules makes it easier to both develop and maintain our projects.

After migrating one of our projects we managed to reduce the code in our backend from 70 000 to 40 000 lines of code, getting rid of a lot of bootstrapping code that we could put into reusable zemble plugins instead.

We have put a handful of plugins out there, which aligns with how we build most of our products at Kingstinct. We hope Zemble will be useful to many more, and that we together can build a community of plugins around it.

Getting started is super-easy, just run this to get a backend with GraphQL, routing and testing ready for action:

bun create zemble-app <name-of-your-app> graphql

Also, check out the monorepo to see all that’s available currently — and how you could contribute to the Zemble ecosystem!

Introducing @zemble: Our Vision for Building Composable Systems was originally published in Kingstinct on Medium, where people are continuing the conversation by highlighting and responding to this story.

Kingstinct has always been a value-driven company — where we look for the places where we can make the most impact and improve peoples lifes. My own background as a Type 1 diabetic has increased my interest in Health & Fitness.

One area we’ve taken a deep interest is in health. We’re living in a time when rapid innovation is enabled by increased digitalisation. One of the main blockers here is to make health data accessible and easy to work with for developers.

Apple HealthKit is a great platform for enabling interoperability between apps in their ecosystem — that keeps the users privacy as a first priority. React Native is our favourite platform for building cross-platform app experiences. Early last year we decided to connect the two with react-native-healthkit, to enable more developers to build apps that can seamlessly share health data to create greater value for users.

It’s open source — and it’s been great to see a handful of people contribute to it. It’s mapping directly to the data models of HealthKit which sets it apart from other implementations — this makes it easy to support all types of Health data available in iOS.

Today we’re releasing react-native-healthkit to 4.2.0 — with a handful of fixes, bumping it to the latest Expo/React Native version as well as migrating the example app to Expo. We hope you find it useful! :)

Making Health Data more Accessible with @kingstinct/react-native-healthkit was originally published in Kingstinct on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tip: use git pre-push hooks to automatically run tests and style checks before pushing code

Let me elaborate on the value this provides. Of course it depends a lot on the quality of the tests it runs — but even a simple style check that you always run will eliminate lots of headaches. With this — you just won’t be able to push code with a typo or syntax error.

Why not use pre-commit hooks instead of pre-push? Sure, if it suits your workflow better — go ahead. For me and my team — I find that it might get in the way of our workflow. Sometimes you still want to commit code that doesn’t pass all checks you set up. This doesn’t mean you should push it.

I also prefer limiting the check to the master branch. Why? Once again it suits our workflow better. It’s important to be able to push unfinished features to other branches without perfecting everything. Of course it should be fixed before it’s merged back into the master branch — and our pre-push hook will help with that.

Key take aways

• Use git pre-push hooks to run tests and style checks before you push code
• Just a simple linter will provide much value for little effort — but with that said your pre-push hook is never better than your tests and checks
• I recommend restricting the check to the master branch to keep it flexible.

How to set it up

I’ll show you how I’ve set it up for my node environments — if you’re not using node you could still use the main part which is the pre-push script:

[ \”$(git rev-parse — abbrev-ref HEAD)\” != \”master\” ] || (git stash create pre-push && npm test) >&2

The “npm test” part is the script I’m running to validate my code — replace it with whatever suits your project.

• The first part checks whether your master branch is checked out — and skips the rest if not
• The second part (git stash create pre-push) ensures that the tests are run without any uncommited changes. This is important. Otherwise you’ll risk pushing different code than your tests run on.
• The third part (npm test) is as mentioned the tests you’re using.
• The fourth part is outputting results to STDERR — which is needed for some git clients to output errors.

So to set up this in a node environment we’ll do the following:

npm install --save-dev pre-push

or

yarn add --dev pre-push

After this you just have to add this to your package.json:

…,
“scripts”: {
…
“pre-push”: “[ \”$(git rev-parse --abbrev-ref HEAD)\” != \”master\” ] || (git stash save — include-untracked pre-push && npm test) >&2"
},
…
“pre-push”: [
“pre-push”
],
…

Pro Tip #1: Check yourself before you wreck yourself was originally published in Kingstinct on Medium, where people are continuing the conversation by highlighting and responding to this story.

The two problems with code coverage are:

• A well tested project that grows in size will eventually let code slip through the coverage checks (unless you’re actually doing 100% coverage).
• An old project with low to nonexistent coverage is not fun to start checking coverage on. It just provides you with a feeling of hopelessness!

The idea

Let’s solve this once and for all. Instead of checking the coverage of the entire codebase or files — let’s check the coverage of our actual changes.

This way we can ensure that what we’re commiting is tested. It works great both for that huge codebase that is pretty well tested where something still might slip though the cracks-and it’s equally good for a project that starts out with 0% coverage.

What we need

To make this work we basically have to do three things:

• Use a tool that’s able to check the coverage on your diff. We use a python package called diffcover.
• Generate reports that this tool is able to use. For diffcover this would be the cobertura format. Usually this is something you can just enable with a simple config change in your test setup.
• Run this check as a pre-push script. This is something I covered in my last Pro Tip.

How to

I’m doing fullstack JavaScript so I’ll show you how to do it in a Node/Mac environment. The steps are similar for other frameworks — so you should be able to use this principle however your setup looks.

1. Set up a pre-push script (if you haven’t done it — here you go)
2. Install python and pip if you haven’t already (Python’s installed by default on Macs)
3. Install diffcover:
   pip install diff_cover
4. a, Make sure your tests outputs a cobertura report. For jest you’d just add it to the coverageReporters array:
   “jest”: {
    …,
   “coverageReporters”: [
    …,
   “cobertura”
   ],
    …
   },
   b, For istanbul you’d add it to .istanbul.yml like this:
   reporting:
    …
   reports:
   -cobertura
    …
5. Run your tests to generate coverage and add this script to your package.json with your cobertura path:
   “cover-check-diff”: “diff-cover my/cobertura/file.xml — fail-under=90”
6. Make sure this script is being run in your pre-push sequence.

Wrapping it up

What we did here is get rid of most of the pains of code coverage — and at the same time we made it valuable in any project regardless of previous coverage.

Pro Tip #2: Leave it better than you found it — Code coverage done right was originally published in Kingstinct on Medium, where people are continuing the conversation by highlighting and responding to this story.

• eslint-config-kingstinct-react-native
• find-and-replace-immutable

ESLint and React Native

eslint-config-kingstinct-react-native is an ESLint configuration that builds on top of the popular Airbnb styleguide with these additions:

• lodash-fp (immutable flavour of lodash)
• promise — I recommend using Bluebird which has more features than the built in promises
• prettier — cause code should be pretty
• jest
• flowtype
• react-native

On top of these plugins I’ve made some rule adjustments to improve my efficiency. I like to keep the rules strict — but it’s important that it supports my productivity. So rules that takes time, doesn’t provide much value and isn’t fixed on-the-fly by eslint will get disabled.

Immutable find-and-replace

find-and-replace-immutable exposes two simple but essential helper immutable methods that I always end up using in my react-native projects:

• replaceAt (index, objectOrMapFunction, array)
• findAndReplace (findPredicateFunction, objectOrMapFunction, array)

It uses lodash/fp under the hood, which I recommend as it’s the immutable flavour of the popular lodash library.

An ESLint config and an immutability helper for React Native was originally published in Kingstinct on Medium, where people are continuing the conversation by highlighting and responding to this story.

With a simple swipe you can mark a task as completed or plan to do it in the future.

It’s available globally on iPhone, iPad and Android today — and it’s totally free. Try it out and let me know what you think!

Lyster App

Lyster on Apple AppStore

Lyster on Google Play

Lyster Released was originally published in Kingstinct on Medium, where people are continuing the conversation by highlighting and responding to this story.

The basics

I’ve arrived at a concept. A flow. It’s based on what I’ve seen in the successful projects I’ve been part of and is now the way I work. This is not a “new lean” or “new agile”. It’s not a new software development paradigm. I do think it has a place in the creative flow for both individuals and teams, and it works great with agile:

1. Prototype until you know what you’re building
2. Lay a solid foundation
3. Build something awesome

1. The Prototype Phase

The prototype phase is all about creative freedom. Whether it’s about how to solve a customer case or how to build your next startup product this is where you try it out without getting caught up in technicalities and time-wasters. Use tools you’re familiar with, this is key.

If something takes time — drop it for now or simplify it. The goal is to give whatever you’re creating a good run-through, so that you understand what you’re building and know what challenges lie ahead.

You should be able to demo this, at least internally. After this you should have a much better view of how advanced your project is and how long it will take.

2. The Foundation Phase

The foundation phase is all about setting up a solid foundation that you can build quickly on. This involves choosing the right tools for the job, setting up infrastructure and processes that ensure that you and your team can cram out as much quality stuff in as short period of time as possible. If you’re into TDD this is where you start TDDing.

Focus on DevOps, architecture and make decisions that based on your experience from the prototype phase will work. It might involve throwing everything from the prototype phase away, in fact you should probably consider doing just that.

3. The Build Phase

The build phase is where you and your team are able to put out as much quality features as possible in as short period of time as possible. If a new feature requires more creative freedom — move back to the first phase before ironing out the infrastructure for that feature. If you see time wasted on infrastructure or tests — or a drop in quality; take another look at the foundation phase and see what adjustments you can do to boost productivity and quality.

Basically the first two phases is just about making the build phase as efficient and fun as possible. The build phase is where you’ll put in most time so make sure the first two makes it as smooth as possible.

To be continued..

This is an introductory post. I will dig deeper into this process the following weeks. Some of the subjects I plan to write about are:

• Key players in each phase
• Software tips and techniques to assist this flow
• I might throw in a few case studies from actual projects

How to Create Products with Speed and Quality was originally published in Kingstinct on Medium, where people are continuing the conversation by highlighting and responding to this story.