هلالtonight’s moonشمسةthe sixteen-petal rosette — how it is drawn

The observatory

Tonight’s moonهلال

Next new moon
—
Next full moon
—

The first thin crescent — هلال, the hilal — is the moon a day or two out of conjunction, and it is a beginning. The Hijri calendar is lunar: twelve months of twenty-nine or thirty days, a year some eleven days shorter than the solar one, so its months walk backwards through the seasons. A month opens when the new crescent is seen — and the naked-eye hilal is a hard object, thin and low and lost in the dusk it hangs in, which is why what counts as seeing it has been argued over for centuries.

That is one reason the astronomers of the medieval Islamic world measured the moon as closely as they did. Al-Battani, who spent most of his life at Raqqa and died in 929, left the earliest surviving zīj — a book of astronomical tables — in the Ptolemaic tradition, and tables like it could place the crescent before anyone went out to look for it. The disc above is worked the same way: everything on it follows from ψ, the angle between sun and moon, which fixes both the phase and the lit fraction, (1 − cos ψ) ⁄ 2.

The observatory

The sixteen-petal rosetteشمسة

the compass circle · sixteen points

Everything here is stepped off one circle. Sixteen points around it, each joined to the sixth from it; the {16/6} star polygon that follows then supplies its own measurements — the petal valleys at 0.689 R where consecutive chords meet, the ring at 0.390 R where they cross closest to the centre. Nothing is chosen by eye.

Patterns built on that kind of scaffolding are girih, the interlaced strapwork behind much of Islamic geometric ornament; cut from glazed terracotta and set piece by hand-chiselled piece, the same figures become zellij, the mosaic of Morocco and al-Andalus this page is named for. What craftsmen carried between sites was the construction rather than the finished design: the Topkapı Scroll, 114 patterns from the Timurid workshops, is the one pattern-book of its kind to survive. The eight-pointed star this rosette closes on is the khatam — two squares laid across each other, the octagram the Qur’an uses in its margins as the Rub el Hizb.

Ahmed El Gabri

أحمد الجابري

Two-centred drop arch — the Mosque of Ibn Tulun, Cairo, 876–879

Blog

Death by thousand config files

· front-end · config · build tools · tooling

Today, a couple of hours ago Prettier released version 1.6.0 with support for .prettierrc & .prettierignore files. If you follow me on Twitter you might have noticed how much I love prettier. But at the same time, you might have noticed my growing pain of the endless stream for .*rc & .*ignore files.

One of the things that I really liked about prettier was the lack of config by any means, files, etc…

  • .babelrc - also will support .js
  • .eslintrc.js - supports .yaml & .js
  • .eslintignore
  • .npmrc - Just has save-exact = true
  • .nvmrc - to make sure everyone is using the same node version
  • .yarnrc - has exact "true" & save-prefix "". We use yarn
  • package.json - aside from the normal package.json stuff, it contains jest configuration which I could have already kept in a jest.config.js.
  • webpack.config.js - still a config-ish file, that depends on the loaders that you use can depend on the other .*rc files too. For example, babel-loader will pick up the config from .babelrc. If you have eslint-loader it will pick up .eslintrc, etc…

Here are a couple more that we might have in the next few days/weeks:

  • .flowconfig
  • .stylelintrc
  • .stylelintignore

And of course:

  • .prettierrc
  • .prettierignore

honorary mention:

  • .tsconfig.json - for typescript
  • .bsconfig.json - for bucklescript if you use ReasonML actually in ReasonML this might be the only config file you need next to webpack.config.js. Another reason to like it.

and more…

Not to mention that babel-env & autoprefixer now use the browserlist project, which allows you to pass which browsers you want to support so they can handle the polyfills & prefixes for you & guess what? It also has it’s own files!

So that makes the total 14 files in our repo. Isn’t this a bit too much for config files? Before everyone starts yelling at me that I can add most of these configs inside package.json - which I don’t mind doing - and most probably will start doing. that’s not the main issue.

The issue is

  • This loop will never end: tomorrow someone comes with a new great tool called X & they decide they need some config for it & boom we have .Xrc & .Xignore now. This loop will never end this way.
  • They are not separate. 90% of the time you will need to change a couple of them if you want to add a new tool because all of them relate/work with each other. Which makes it painful to deal with.

So I have a simple question here.

I know that not all of these .*rc files can be merged into one, but at least can we agree that many of them can? most of these configs are just JSON objects so why not store them all in one place?

Also, this way if a new tool comes out we just need to add a new key. It doesn’t solve the whole problem but at least it keeps us a little bit saner.

What is wrong with this? And yes it must be a .js file:

  • Comments are easier than in .json files
  • You can change the config depends on the environment.
  • If you want, you can dynamically generate your config.
// use this to toggle on/off some configs or switch them completely
const isPROD = process.env.NODE_ENV === 'production'

module.exports = {
    jest: { ... },
    babel: { ... },
    prettier: { ... },
    stylelint: { ... }
}

Or even better!

So people might say & how is this better than having multiple files?

The answer is, it’s not much better but at least we can have these:

  • Less cognitive load
  • One place to handle most of the logic (env switching, etc…)
  • Restoring some sanity?

I do like all of these projects, they are amazing projects made by smarter people than I am. I never felt JavaScript fatigue, but I started to feel Config/rc files fatigue.

You can share this post or reach me on @ahmedelgabri.