tl;dr: WordArt.

I was born in the late 80’s. It means I had some tough choices when I grew up in the 90’s. One of them was choosing a WordArt title for a school assignment.

As part of my daily job I need to upgrade stuff that affect dozens of developers. It freezes some of the deployments and make developers not so happy :-)

I needed to do it with some creativity and I got my nostalgic attack after Ran Greenberg told me “Your font looks like WordArt” and remembered the struggle I had when I was a kid.

Solution

I created a library for react called react-wordart. Now the deploy freeze looks much better and super user friendly.

I used https://github.com/transitive-bullshit/create-react-library for generating the library and just to write the code so huge kudos to Travis Fischer.

Most of the work from there was to write the css. Luckily I have internet… I used this article and I had the css. Also used classnames package for controlling dynamic classname and voilà.

Using create-react-library I got example project out of the box, and ran npm run deploy and there it is: https://yershalom.github.io/react-wordart

After I read this comment on my thread at Reddit, I decided to split the css to its own repo: https://github.com/yershalom/css-wordart

The usage is pretty simple:

And then just like that I had my nostalgic moment and created an open source out of that.

Hoped you enjoyed reading!

• yershalom/react-wordart
• yershalom/css-wordart
• transitive-bullshit/create-react-library

When dev gets nostalgic was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

I took Flutter for a round for the first time and I enjoyed every moment of it. Well, the syntax was different for me, but still liked it a lot. Here are my thoughts about my first experience with Flutter.

Installation

I work with MacOS, so I started with the Get Started: Install on macOS page. Just download the zipped sdk and add it to your PATH.

I ran the flutter doctor command to check that everything was OK. I had some issues like install flutter plugin on Android Studio. I installed the plugin and saw this (woo hoo):

The next step was to configure my editor, in this case Android Studio. Only few clicks and I had the flutter and dart plugins installed on my editor. Easy peasy.

Get Started

Let’s write some code, or at least run it.

The first step of the getting started step is to create a new flutter project in Android Studio and run it. Everything worked like the docs said, profit!

Coding

Awe yeah! Coding is here.

The goal of the code lab was to achieve infinite scrolling ListView app, called: Startup Name Generator. Something like this:

This tutorial was very informative and I learned how to build a layout; how to use an external package and the difference between StatelessWidget and StatefulWidget.

At the end of the tutorial, there was a summary of what was achieved and if I wanted to continue (yes, please), and a little teaser:

I clicked on part 2. The mission was to add a favorite icon and a navigation for the favorite names.

The first 3 steps are building the environment, so you can skip them if you did these in part 1. I learned app hot reloading, navigation (Flutter has it out of the box) and how to add icons from the flutter material design.

The last step of this tutorial contained a few links for further tutorials and knowledge-bases, but I was too eager to try something out and google the things I needed.

My first Flutter project

When I’m testing a new mobile framework or language, I like to build a simple reddit app. Fetch hot topics, see some posts and read and comment. It’s a good practice, since it combines http call, parsing objects, navigation and webview. You can see the examples on my Github, written in Kotlin and in React Native.

Don’t change a winning team

So I didn’t. I wrote a new simple reddit app with flutter. I googled how to stuff and I had my first screens:

So far, so good. But I wanted to test more Flutter’s features. I decided to add a Bottom Navigation Bar. I built another screen using the SpaceX API and created a list of history SpaceX launches.

Simple ListView with cards, containing the mission name, mission patch and success or failure.

I wanted to try image handling and camera access.

I added another screen called Picky. I added add a photo icon on the app bar for adding a picture, and two rotate icons for rotating the image.

To sum it up, I love Flutter. The Flutter plugin for Android Studio is more than amazing, letting you build both iOS and Android. More than amazing.

You can grab the source code from here: https://github.com/yershalom/reddit_flutter

Hope you like it! If so, you can follow me on Twitter.

I love you Flutter was originally published in HackerNoon.com on Medium, where people are continuing the conversation by highlighting and responding to this story.

In this article, I will tell you about the versioning scheme we use for our React Native modules at Wix.

TL;DR: semver syntax and git commits.

Background

The mobile Wix app is a modular app written in React Native. What does this mean? We have one app and many modules. The app repo is essentially a package.json with modules as dependencies, a few engine configurations, and build scripts. That’s it. By default, for standard builds, it will just use the version marked as GA, saying they’re ready for release.

Get it Done

A module is an independent product unit, it can communicate with other modules. All these modules need a version so the app (package.json) should know which version to install. We are using a library written in-house. It is based on Semantic Versioning (semver) syntax and git commits calculation.

We use a versioning scheme that supports patching — why? Life can be rough, and sometimes we need to create hotfixes. We do that by creating a branch from the previous release of a certain module. By following the state of the project’s git tree, a version is automatically calculated in the following manner:

Major: manually from package.json.

"version": "2.0.0"

Minor: number of commits on the master branch.

Patch: number of commits in <branch> since diverged from master. On the master branch, it will be 0.

So if my version in package.json is 3.0.0 , and I have 1,842 commits in my master branch, and I work on the master branch, I’ll get: 3.1842.0 .

For a custom branch, let’s say my version in package.json is 1.0.0 . I checked out my branch when the master had 687 commits, and I push 3 commits to my branch, I’ll get: 1.687.3 .

Problem

Let’s say two developers are working on the same module, which is pretty reasonable. They both want to fix a bug from the same master version: 1.265.0 . They both pushed one commit. Both of them would get the 1.256.1 version, and that’s bad since you can’t have the same two versions on the npm registry.

Luckily, we can also use the build counter. For example, add the build counter (which is unique) to the version, following the patch version, like this: 1.256.1-build.1435 . I must say that this is an edge case, but still, we needed a solution for that, too.

In conclusion, I would recommend using git for calculating the versions for you. Tag every commit with the version so you could connect your module version to the commit.

Hope you enjoyed it!

A better versioning scheme for your React Native modules was originally published in Wix Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.