The solution is just to run your entire pipeline under Rosetta. (Ideal solution is to get everything on latest versions which support M1, but this is just not realistic with most projects.)

Copy the Terminal app

Copy and paste the Terminal (or in my case iTerm app — reason why I use this is support for split windows) and rename one to Rosetta. Press cmd-I and make sure “Open using Rosetta” is checked.

Add current architecture to your $PROMPT

You can always print the current architecture using uname -m command. Since I’m switching around a lot, I wanna know which one is running:

I edited theme in my oh-my-zsh installation by editing file ~/.oh-my-zsh/themes/robbyrussell.zsh-theme (theme I'm using).

This is the updated version:

declare -A archs
archs=(
    ["arm64"]="$bg_bold[yellow]%}%{$fg_bold[black]%}m1%{$reset_color%}"
    ["x86_64"]="$bg_bold[red]%}%{$fg_bold[black]%}x86%{$reset_color%}"
)
arch=$(uname -m)
label=$archs[$arch]

PROMPT="%{$label %(?:%{$fg_bold[green]%}➜ :%{$fg_bold[red]%}➜ )"
PROMPT+=' %{$fg[cyan]%}%c%{$reset_color%} $(git_prompt_info)'

ZSH_THEME_GIT_PROMPT_PREFIX="%{$fg_bold[blue]%}(%{$fg[red]%}"
ZSH_THEME_GIT_PROMPT_SUFFIX="%{$reset_color%} "
ZSH_THEME_GIT_PROMPT_DIRTY="%{$fg[blue]%}) %{$fg[yellow]%}✗"
ZSH_THEME_GIT_PROMPT_CLEAN="%{$fg[blue]%})"

Using red box to indicate I’m on older system, and yellow to show I’m up to date.

Install separate copy of Homebrew

I’m assuming you already installed Homebrew under M1. Make sure you have by running this command:

m1 ➜  ~ which brew
/opt/homebrew/bin/brew

We’re going to add another installation and put it in /usr/local.

Open your Rosetta terminal and install Homebrew. (Just follow the instructions on the website.) It will automatically create a binary in /usr/local/bin/brew.

After you installed it, your brew command still points to your M1 installation. So let's open .zshrc and add an alias:

alias brow='/usr/local/bin/brew'

I saw the idea of using brow on some other blog (can't remember where) and I thought that was pretty neat. Basically, you'll run brew for M1 commands and you'll run brow for Rosetta commands.

Install dependencies using `brow`

Now install whatever dependencies you’ll need for Python and its packages. For me this was:

brow install zlib
brow install openssl
brow install pcre

Install Python under Rosetta using pipenv

In your project directory, create a Pipfile:

[[source]]
name = "pypi"
url = "https://pypi.org/simple"
verify_ssl = true
[requires]
python_version = "3.7"

I use version 3.7 here, because such version doesn’t exist on my system yet, so I know it will be installed using pyenv.

Whatever you do, make sure Pipenv doesn’t reuse existing version of Python that was installed under M1. Python has to be installed under Rosetta.

Activate Python and install requirements

Run pipenv shell and then start installing:

pip install -r requirements.txt

Another alternative is that your Pipfile already contains your requirements, in which case they would be installed in the previous step.

If you encounter any problems with missing libraries (such as zlib), relink them using brow link zlib and make sure to run those export commands that brew spits at the end, for example:

For compilers to find zlib you may need to set:
  export LDFLAGS="-L/usr/local/opt/zlib/lib"
  export CPPFLAGS="-I/usr/local/opt/zlib/include"

For pkg-config to find zlib you may need to set:
  export PKG_CONFIG_PATH="/usr/local/opt/zlib/lib/pkgconfig"

(For zlib try exporting this too: CFLAGS='-I/usr/local/opt/zlib/include -L/usr/local/opt/zlib/lib')

This should work!

Now you have two Homebrew installations and two version of each Homebrew package — one compiled under M1, and one compiled under Rosetta.

There might be some issues when switching between the environments, but I’m assuming you’ll be running your backend under Rosetta, so it shouldn’t be a problem.

How to install Python under Rosetta 2 was originally published in Thinknum on Medium, where people are continuing the conversation by highlighting and responding to this story.

Here at Thinknum, we store an increasing amount of data in graph databases.

Using graphs allows us to derive some unique insights, by following a path of relationships and collecting information along the way.

The industry has two popular languages: Cypher, with its declarative SQL-like notation, and Gremlin with its imperative style. Using these languages is a powerful way to answer any query you may think of.

Graph databases are growing in popularity, as more organizations find that they are the right tool to work with their data.

As more users are exposed to these technologies, there is a growing need to access them in a user-friendly way, and we felt that too.

However, when we set out to find an easy to use, web-based, Tableau-style UI to work with these databases, we returned empty handed. Every program is still centered around writing queries by hand, and then inspecting the results using some kind of visualization.

That’s still very far from what we needed and imagined. We wanted to build a query, and work with the results; See them as a graph, but also turn them into a chart if we wanted.

Over the last year or so, a part of our team set out to fix this problem. We decided to build a UI for graph databases that would act as a “data lab” (a term we’ve used since the birth of Thinknum.)

And so today we’re officially announcing Graph UI. It is a feature-rich UI to work with your graph database.

You can build your query visually by defining a series of steps to take through your database. For example, you may want to start with movies, follow all the directors, and end up in their hometowns.

Along the way, you can collect data that might be useful in the final report. For example, you may want to see how many Oscar movies each hometown produced. You can have endless use cases.

And now, you can ask these questions without writing any code, just by using the drag-and-drop interface in Graph UI.

Once you’ve collected your data, you can turn to the analysis portion, which works the same as any relational tool. You can display your results as a table, and from there, you can turn it into various charts.

There’s a lot more to Graph UI, and you can learn all about it over here. If Graph UI seems like a great fit for your needs, feel free to sign up for the waitlist. You can email us directly with any questions!

Introducing Graph UI was originally published in Thinknum on Medium, where people are continuing the conversation by highlighting and responding to this story.

I always had a passion for “Mac applications”. Perfect integration with the system, beautiful design, great ease of use…

My favorite example has always been Things. It’s a joy to use. This idea is dead after today.

Because us, macOS developers, we’ll have to compete with the shit that is iOS apps running on Mac. We’ve seen Catalyst. Not even Apple can ship a nice Catalyst app.

And it’ll be so easy to run your iOS app on the Mac that no one will bother crafting beautiful, native macOS experience.

So… Crappy day for macOS developers.

From Stop Trying to Make Hard Work Easy with Nir Eyal:

It’s the same deal with flow. You’ve heard, I’m sure all of the research on flow, and it’s actually not very good advice for most people. Because again, it makes you think you can make anything effortless. You know, professional basketball players are in flow. But how do you get into flow when you’re doing your taxes?

Same with writing. I’ve written two books, and hundreds of articles. Writing is never easy. It’s boring. It’s frustrating. It’s difficult. It’s anxiety producing.

You don’t. If you’re doing taxes, you don’t get into flow.

Some days there’s just no flow, and we need to accept that. Stop looking for the easy way out. Work is hard sometimes.

The key is to still push yourself through the boring tasks. Train yourself to concentrate even through the difficult.

The Pomodoro technique helps a lot. Do the hard thing for 25 minutes, then you get to take a break.

My typical coding workflow is to use Tomato 2 to work for at least 25 minutes. (The app won’t interrupt me once the time is up.) If it’s going well, I’ll continue and find myself working for an hour. But if it’s really difficult, I’ll just take a break, then repeat.

At KgBase, we recently rewrote our graph UI to use WebGL instead of SVG. Our goal was to:

1. Improve performance and allow 1,000s of nodes to be rendered
2. Keep using React, if possible. We want to quickly iterate on new features, and React lets you prototype faster.

A very common tool for rendering WebGL content is Pixi.js. It’s typically used for making simple games, but it works very well for our use case.

If you want to integrate Pixi.js with React, you’ll need to use React Pixi, (or react-pixi-fiber, but I’ll get to that later.)

In its initial version, our rendering code was this simple:

You can just take all the nodes, and for each render your own NodeView component that takes care of rendering a single node:

Now notice the Circle component. This is not part of react-pixi. We're importing that from our own ./Primitivesfolder.

React Pixi shows you how to build your own components like above right on their landing page:

Notice anything wrong with that code?

I didn’t either, until we got into a specific situation:

When you click on a node, we want to highlight it. We do it by setting alpha of clicked node to 1.0, while decreasing alpha of all other nodes to 0.2 or so.

With the implementation above, each change in alpha will call applyProps, which will re-draw the entire shape. So we call this snippet 1,000 times each time user clicks a node:

If we just want to change the alpha, this is all we have to do:

So the proper way to implement your custom Rectangle/Circle component would be like this:

The important part is to make sure that there is no unnecessary re-drawing of your component. Whenever you see code like this:

You should refactor it: Always compare your props to oldProps, and only re-render if something changed.

Interesting fact: Default implementation of Text in react-pixi will also update the component each time, even if nothing changed. Default implementation looks something like this:

The action of setting new text value (instance.text = text) is an expensive operation! It will cause your Pixi instance to be re-rendered. Instead, always check if re-render is necessary.

To fix this, you’ll need to create your own component, called for example FastText:

And now rerendering will only happen if text was really changed.

There are a lot more performance questions to consider when dealing with Pixi and WebGL. What I described above is a good first step to writing performant code. Always be careful for what happens in applyProps. It should never be creating new Graphics objects, and it should not even be changing properties needlessly. It should always be comparing current and old properties before changing anything.

Like I said, this is a good first step. We’ve been able to render up to 5,000–10,000 nodes fairly effortlessly with this approach. There’s more to be done for higher FPS and more nodes, but that’s a topic for another blog post.

Writing high performance React-Pixi code was originally published in Thinknum on Medium, where people are continuing the conversation by highlighting and responding to this story.

I recently decided to create a private NPM package for some of the UI we use in our apps. The goal was simple. I wanted to install and start using the package with one line of code: yarn add rainbow-buttons. ("Rainbow" buttons being an example.)

I had some clear requirements for this package:

• It should be written in TypeScript, like the rest of our codebase
• It should contain its type declarations, so that we wouldn’t have to install separate package from @types/rainbow-buttons.
• It should contain React components. We’ll want to do <RainbowButton>Hello!</RainbowButton>.
• It should contain it’s own CSS styles written in Sass. Those should be imported automatically when I run import {RainbowButton} from "rainbow-buttons".

Unfortunately, it wasn’t straightforward at all. I came across quite a few problems. In this blog post, I’d like to go through these problems, explain what caused them and how to address them.

Pitfall 1: Don’t forget to use peer dependencies

At my first attempt, I added all of package’s dependencies into its regular, production dependencies list. This was a bad idea of course.

What happened was that my React dependency, for example, was installed by my package, but also by the host project. So now I had two instances of React, possibly at two different versions.

This is kinda obvious now, but that’s why NPM/Yarn has the concept of peer dependencies. Your package will specify which dependencies it needs, and the host project is responsible for installing them.

Pitfall 2: Don’t use WebPack, use Rollup

I was seeing a lot of errors when just trying to build the package with WebPack. One of the problems was with peer dependencies. They were defined in peerDependencies section of package.json, but as soon as I removed the actual files from node_modules/, the build broke. So to fix that issue, I had to add them also to devDependencies, because Yarn won't install peer dependencies on regular yarn install, only dev and prod dependencies.

My package.json was quickly becoming a mess. I had to keep @types packages in dev dependencies, and regular packages in both dev and peer dependencies. Go figure.

There were more strange errors which I still don’t know how to resolve. Most likely version mismatches.

But somehow, everything works fine once I switched to Rollup. If you haven’t used it yet, it’s an alternative packaging tool which is primarily used in libraries. It’s used by React, D3.js, and many more popular open-source packages. There is a great article explaining the main differences, and a great article explaining how to use it with TypeScript.

I ended up with fairly simple config file:

import typescript from 'rollup-plugin-typescript2';
import pkg from './package.json';
import postcss from 'rollup-plugin-postcss';

export default {
  input: 'src/index.ts',
  output: [
    {
      file: pkg.main,
      format: 'cjs',
    },
    {
      file: pkg.module,
      format: 'es',
    },
  ],
  external: [
    ...Object.keys(pkg.dependencies || {}),
    ...Object.keys(pkg.peerDependencies || {}),
  ],
plugins: [
    typescript({
      typescript: require('typescript'),
    }),
    postcss({
      modules: true,
      namedExports: true
    })
  ],
}

The ES module makes sense when you pair it with module config in your package.json:

"main": "dist/index.js",
"module": "dist/index.es.js",
"types": "dist/index.d.ts",

You can see a few more nifty things going on in that config file:

• It’s automatically defining all peer dependencies AND dependencies as external. The resulting package should only contain the package files.
• It’s taking care of CSS compilation including generating modules to be used as import * as styles from "./styles.scss"

But here’s the important thing: Rollup doesn’t need your peer dependencies to be actually installed in node_modules/. It just needs your @types/* packages, which are installed as dev dependencies, so they would be present in node_modules/ at all times.

It allowed me to clean up my package.json with double dev and peer entries for my peer dependencies. The package.json file can now be this simple:

"devDependencies": {
  "@types/react": "16.4.6",
  "@types/react-dom": "16.8.3",
  // ...
},
"peerDependencies": {
  "react": "*",
  "react-dom": "*",
  // ...
}

Pitfall 3: Avoid symlinks, don’t use yarn link

Our package relies on types packages for some 3rd party libraries, such as @types/react or @types/recompose. These are defined as dev dependencies in package.json.

With this setup, compiling the main project would return a bunch of Duplicate identifier errors all over the place:

After some Googling, I figured out the problem is with TypeScript compiler. These type definitions now exist in project’s node_modules, but also in package’s node_modules. Somehow, TypeScript is not able to deduplicate these type definitions when symlinking is used. And yarn link relies on symlinking.

This can be resolved with some smart configuration in your main project, but my favorite solution is to use yalc. It’s a simple tool that simulates publishing to NPM by actually copying the files.

The usage is simple:

# In your package:
yalc publish

# In your main project:
yalc add rainbow-buttons

# In your package, after a rebuild:
yalc push

The last command is the most interesting: When you run yalc push, it will go to each project where it's used, and automatically copy the newest files over.

So I end up running this each time I change any code in my package:

yarn build && yalc push

You can read more about the issue in this blog post.

Conclusion & source code

That’s it, a summary of some real-world problems you can come across when developing a non-trivial TypeScript package for React.

If you’re interested in source code of this particular package, we’ve actually published it as open-source library called react-tour. Feel free to work through the configuration files if anything’s not making sense.

Common pitfalls: Creating a custom NPM package with React and TypeScript was originally published in Thinknum on Medium, where people are continuing the conversation by highlighting and responding to this story.

During these 20 minutes, only think about the problem you’re working on. Nothing else.

Try to visualize how you’re gonna work on it when you’re back. Try to picture the solution. Try to envision the steps you’ll take.

Then go back and get started. Stay as focused as you were during your walk.

This works like magic.

What I really liked about The Martian, is that it’s taking place in the near-future. No crazy aliens, no jumping between galaxies. The storyline could be the reality in a decade or so. The book was also technically very sound, another reason why we all liked it so much.

Getting to the point now. I started reading Winter World, a book by A.G. Riddle. It reminds me so much of the Martian! I’ll try to describe it without any spoilers.

The story is set in near future. The Earth is cooling down significantly, and no one knows why. Until they find a possibly alien object in space, which also destroys the ISS, right after being discovered.

Our protagonists, James and Emma (and a team of scientists) go on a space mission to investigate these artifacts. The trip takes 4 months, and they spend it building drones. Then they finally find something unexpected… And you’ll have to find out yourself what happens next.

I’m sharing this as a book tip, because I think it would have the same appeal to tech people, as Martian had.

It’s the same concept. Skilled engineer/scientist has a mission to figure out something technical, and they have to do in on a deadline, or face dire consequences.

The story is a little more detached from reality (aliens), but we don’t really meet them (thus far — I’ve only ready about 1/3 of the first book), so there’s an air of mystery.

I’m not sure about the technical details, but I have no complaints — no obvious flaws. Their “space drones” sound pretty convincing. You’ll also find similar conversations about NASA and space travel in general, as in The Martian.

So all in, it’s a great space book to relax with. It will definitely go on my list of what I call “mild sci-fi books”.

A digression: Why I need App Store

Here’s why I need App Store: I need a reliable updates system. My first iteration has minimal set of features. I’m planning to improve it soon. And then again, and again. But I need reliable updates to do that.

I could use Sparkle, but if I can have this feature for free, I’ll take it. I would rather spend my time building features, instead of implementing Sparkle.

Another reason for App Store: It’s part of my idea validation. The app is called “Median for Appfigures”. I’m deliberately optimizing for “appfigures” keyword, because it will answer an important question: Is anybody searching for Appfigures app on the App Store? If not, I may as well move on the another idea.

(My ultimate plan is to support more data services, so that you could have all this “data at your fingertips”, but that’s for later.)

My expectations were low

Right after the rejection, I submitted an appeal. I didn’t expect much. I heard the stories. Once your app gets rejected, there’s nothing you can do, I thought. Especially if you’re small and irrelevant.

So I Tweeted about it, and I received a lot of responses. Most of them were supportive. A lot of them suggested that I should skip App Store. However, the best advice was to try and work with Apple. I honestly didn’t think that would help. But it did.

To my surprise, I got a reply to my appeal. (At this point, I wasn’t expecting one.) Just two days later I received a response, which basically said “Yup, we checked again, you’re fine, actually.”

Unbelievable, I thought. The best part? This heart warming message at the end: “Thank you for your commitment to Mac app development.” I’ll be much more patient in the future, now that I’ve seen a positive side of App Store.

Thanks, everyone!

Thanks to everyone who replied and retweeted my little frustrated Tweet. It’s really good to be around this community of iOS devs — big or small, doesn’t matter. Thank you!

Edit: 2 days later, the appeal worked. More here.

I’ve always wanted to build a desktop app that would let me access my most important data quickly. Like those old dashboard widgets used to.

I finally got around to it, and started with Appfigures, my favorite service to track App Store sales. I wanted to ship something to users, so I built my first iteration in 26 days of weekends and evenings:

Sometimes I just have a quick question for my data, and this lets me get an answer in the matter of seconds. It’s very limited now, but I have a lot of ideas for improvement. (I’ve tried building this idea before. That failed, and I keep coming back to it.)

Unfortunately, App Store Review team didn’t agree:

We noticed that your app offers a subscription with a mechanism other than the in-app purchase API.

Can anyone explain to me, how did they let the official Appfigures app into the App Store? It’s the same thing, and I’m pretty sure they don’t have IAPs. It’s just a dumb viewer of the data.

There are countless apps that use 3rd party data, even if a subscription is needed. This doesn’t make any sense.

Worst part — there’s nothing I can do. I have no idea how to fix this, except for finding a brand new project to work on.

Is there anyone who has experience with a situation like this? I would appreciate a ton any tip how to proceed. Please let me know in the comments, on Twitter or via email. (vojto at rinik dot net)

I’m not a big company, I’m not a big name, and it seems Apple couldn’t care less about people like me. But every success story started like this. I wish Apple would help us, instead of sabotaging all good efforts.

If you’re iOS developer, please feel free to Tweet this. I’m too irrelevant for anybody to notice, but with your help, there’s a chance…