A lot of startups are using “blockchain” as a replacement hyped word for “distributed database”. Well, a blockchain is the most inefficient and slow “distributed database” ever created. Blockchain strength is not in being a database! Stop doing that!

The blockchain power is in avoiding divergent transactions, and guarantee a not falsifiable and immutable history. That is, no node in the system can alter the past of the chain. That’s it. They are huge and specific problems.

Nevertheless, there are industry people saying that “blockchain immutability” is the biggest problem of a blockchain.

And so we have tons of blockchain/alter-coins, but “centralized” or “owned” by someone. But if I need to trust “someone”, why using a blockchain system in the first place! Just use a damn distributed database!

One of the feature I like the most on Rust is automatic documentation. Documentation is a pillar in language ergonomic, and I love that Rust spend so much time into making documentation and documenting code a much pleasant experience.

Rust autogenerated documentation (with cargo doc) looks good, every crate on crates.io get its documentation published on docs.rs, and, most important, every code example in the code is compiled and run as a “unit test” making sure that all the examples are up-to date!

I love that. But what if we want to customize a bit the documentation? For instance, by uploading a crate logo or a custom favicon? Googling this does not provide a lot of information. That’s why I am writing this small how to.

This is the time of the year in which I propose 5 emerging/new languages that you should keep an eye on the next year. I’ve done it last year, and the year before, and the year before that.

This year, however, I am not in the mood of doing it. There are several reasons why. The first one is that this year there have not been a lot of movement on the new programming languages. I am sure there are a lot, but no one got enough attention to make into a list. Therefore, I am concerned that I will just starting to repeat myself talking about the same stuff.

Some time ago I found on my grandma’s house an old Italian book on cryptography from 1897. Why a 120 years old book on cryptography was on my grandma house, is a mystery. I’d like to think that some grand-grand-parent was a late 19th century hacker. Anyway.

The book title is “Crittografia ossia l’arte di cifrare e decifrare le corrispondenze segrete” of Count Luigi Gioppi of Turkheim.

Well, I don’t know if this book is hard to find. In any way, I decided to take a photo of every page to share and preserve this book. The book is very old and some page is ruined, sorry if the quality of the photo is not optimal. I’ve done my best for not destroying the book in the process. :)

I will release the photo one chapter at the time. Keep this page in the bookmark.

To test PureScript I decided to implement a very simple project: a page showing today’s date according the calendar used in Dwarf Fortress. It is easy enough to be tackled without me knowing nothing about PureScript and Halogen in a week: you take today’s date, you apply some math, and you print your result on an HTML widget. At the same time, I think it is complex enough to have a grasp of PureScript potential (at least, in the allocated time).

Because I started a small series about astronomical algorithms and the magic of math in space, I think we need to cover an important prerequisite. In the series, I will talk a lot about ellipses (duh), I will move from the semi-axis majors, to the periapsis, to eccentricity, to ellipse’s center and ellipse’s foci. I am concerned that things can get more complicated than expected if the readers does not know many of the geometric properties of the ellipse. For this reason, I put here this vade mecum on the ellipse geometry. A summary with all the basic points and lengths. A place that I can link everywhere I need to refresh a definition.

Today, during my daily web crawling, I found this article by Matt Mullenweg. I will not dwell in details, you can read the full story in the linked post. But I try to give you the core of the announcement: WordPress just decided to abandon React. This is a big news, with many implications and a few lessons to learn. Let’s go by steps.

As you probably know, I am working (slowly) on an astronomically accurate calendar generator. All the orbital calculations involved are quite challenging, and I am discovering a lot. It is a lot of fun (except for the all the times I need to do some trigonometric magic to make some formula work).

Anyway, during this process, I am reshaping and producing many many formulas. I am sure that in six months I will forget all the motivations behind them. For this reason, I want to try to save some of them here. In this way, I will have a good place where to look back at my notes and, moreover, I can be useful to other people trying to do some low-accuracy orbital calculations.

I want to start from the beginning: orbital period and orbital trajectory.

Position of the planet on the orbit

First of all, we need to have a clear idea of what are the orbital elements. If we consider a true three-object system (e.g., sun-earth-moon) things get very, very messy. A complete orbital diagram for such system involves an impossible number of angles, axises and intersections between imaginary lines.

For this reason, for simplicity, we want to start from a very basic two-objects system: a point object orbiting around another (more massive) point object. In this situation, there are no rotation axises, there are no orbital inclination. There is only one object orbiting the other.

We also assume that the mass of the star is much greater than the planet mass. In this way we can consider the star “fixed” and put there our system origin. As we know, an orbiting system like this obeys to the Kepler’s laws of planetary motion:

The orbit of a planet is an ellipse with the star is at one of the two foci (F in the above diagram).

A line segment joining a planet and the star sweeps out equal areas during equal intervals of time.

The square of the orbital period of a planet is proportional to the cube of the semi-major axis of its orbit.

We will look at Law 2 and 3 later, for now the first law is enough. Orbits are elliptical. This seems easy but keeping track of non-uniform movement along an ellipse is more complicated than you think. Assuming that you know how an ellipse is defined (eccentricity, major axis, minor axis, and so on) we are interested in one measure: the true anomaly. This is the angle between the planet P and the star in F. In the diagram, this is the angle f.

As you can see, if we know this angle, and we know the orbit dimensions, we know where the planet is on the orbit. Because orbit dimensions are usually given (there are many sets of equivalent dimensions, for the moment, we don’t care), the only thing we need to determine the planet position over time is the true anomaly over time.

Computing the True Anomaly

Computing the true anomaly over time is not a trivial task. Before we can compute the true anomaly, we need some intermediate steps. The first stop is computing the mean anomaly. Imagine a circle with radius (the semi-axis major of the ellipse, in other words, half the “width” of an ellipse). Imagine now a body orbiting this circular orbit with constant speed (because circle) with the same period () of the real planet. The angle of this imaginary body at time is the mean anomaly.

Computing the mean anomaly over time is very easy, after all, it is moving with constant speed. Therefore:

Now, we introduce a new angular measure, the eccentric anomaly. This is the angle shown in the above diagram. It represents the angle between the circular orbit center C and the kind of projection of the real planet position on the elliptic orbit on the imaginary circular orbit we defined before. To compute this value we use the Kepler’s Equation:

Note that is just the ellipse eccentricity. This is a wonderful relation between the mean anomaly and the eccentric anomaly. However, give this formula, it is impossible to express in closed form. For this reason, there are a thousand of methods for approximating this value.

The one I prefer is the recursive one. In short, we rewrite the formula as

You can note that we have expressed a kind of recursive function. Thus, we can replace on the right with the same formula again

And we can continue the process over and over, every time obtaining a closer approximation. I usually do this process 3 times, and, with some trigonometric magic trick, I get the following formula

Finally, we can rewrite this formula in a way that it is easier for the computer (it is faster, it performs less sin and cos, and reduce the floating-point errors):

Cool. Now it is time for the last step of our process. We have seen that the eccentric anomaly is just the “angle between the center of the circular orbit and the projection of the real planet on it” (this is a very loose definition, but I think it is the most intuitive approximation). Therefore, to find the real angle we just to “project the planet back” to the elliptical orbit. Fortunately, this is much less painful problem. The relation between the two angles is given by the following formula (where is the true anomaly).

This can be rewritten as

A formula that finally concludes our journey.

Conclusions

This is everything for now. I’ve put many concepts on the table and, before we move on, we need to be perfectly at ease with the tree angular orbit measurements, the anomalies. In the next articles we will see how to use them to compute some basic orbital events (such as equinoxes) using these formulae.

Bibliography

I have some book that was extremely useful in this task:

Astronomical Algorithms by Jean Meeus. This book is a 20+ year old book for writing astronomical algorithms on a computer. For this reason the code examples are in BASIC. Yep. But the math and the core of the problems are all there. This book is still a gold mine if you are interested in this kind of works.

Introduction to Geodetic Astronomy by T.B. Thompson. There is no link for this, but you can use your web search ability to find a PDF version, somewhere. This is an even older book (December 1981) but, at least, there is no obsolete code. The book is all about the celestial math governing the Earth and the Sun (and other orbiting spheres).

If you want something more recent, there is Astronomy on the Personal Computer by Montenbruck and Pfleger, but I didn’t read it. I know many people suggested me this book and the examples involve a more recent C++, but it costs a lot for a book that I need for a side project.

You know, I quite enjoy TypeScript. It is not my favorite language ever, I am more a functional type of guy, but it is the best way to bring order into the JavaScript mess without too many hassles. Moreover, it is the language in which I prototyped my Astronomical Calendar Generator. Now that I’m working on extending it, I want to keep using TypeScript and stop falling in my usual decision paralysis. Anyway… First thing I needed to do is how to unit test a TypeScript source base. It is easy, but not intuitive. So let’s see how to do it.

There are two “problem” with TypeScript unit test when building a bundled JavaScript file for a web page. Problem A: you need a way to import directly the TypeScript code and write the tests in TypeScript too. It is logically the right thing to do. You can probably work with the output JS and write JS tests, but, come on…

Problem B is a bit more subtle. When you use TypeScript for a web page, the output get compiled in a monolithic file using some module system (in my case the require.js AMD format). When you test it, instead, you run your code in a Node.js instance that can not understand the AMD format (and you get the infamous define is not defined error).

Fortunately, we can solve these issues very easily. Let’s go step by step. Suppose you have a tsconfig.json file like this:

The first step is to install all the tools we need. I will use mocha, chai, ts-node and amd-loader.

npm install -g mocha chai ts-loader amd-loader

The first two are one of the many suites for unit testing. ts-node is a tool for compiling on-the-fly TypeScript code commands. Imagine it as a REPL for TypeScript, it works exactly as node but you can write in TS. The last one, amd-loader is a tool that allow use to run mocha on the AMD output blob.

Now, we will install the type definitions for mocha and chai.

npm install @types/mocha @types/chai

We need these for writing TypeScript unit test (Problem A). At this point, we can create a folder tests and write our first test.

As you can see, before running tests, we need to tell mocha to “import” two libraries. ts-node/register, so that mocha can “understand” TypeScript code; and amd-loader, so that mocha can import AMD bundled modules.