The #VIZcoin revolution

Or, why and how I built a visibility-bitcoin exchange site.

A few months ago, I saw this tweet.

The tweet translates to

BREAKING Value of #Visibility slightly rising against the Euro today on the international markets. Forecasts indicate a rise in salaries for #ShittyStartups.

I thought it was bitterly funny, so I retweeted it and more or less forgot about it.

But then again, I think pretty much every freelance out there got offered to work for exposure, at least once in their life. I know I did. I also thought that people would stop expecting us to work for free after a while, but I occasionally still get the odd offer, despite my CV and portfolio clearly show that I have experience and titles enough that in fact I should get paid twice as much as I am now — but that’s just me rambling, I’m actually reasonably happy with my current job and salary. 😃

So, I decided to launch my #finntech #startup disrupting the market of #visibility and #exposure: VIZex.

It is exactly what it looks like: an exchange rate tracker with a calculator to convert vizcoins to bitcoins because one fake currency can only translate to another — and also because it was harder to get actual updated forex rates than it was worth for a quick joke.

Yes, but why?

In part, because I didn’t want to just vent frustration on Twitter. Instead, I wanted to make something more tangible and visible (!) than an angry Internet post here and there. And in part, because I have been out of the web-development loop for a while, and I wanted to catch up with the Kardashians.

Ok, so what did I do?

First of all, nowadays if you are doing a statically rendered, server-side thing with just the bare minimum of JS on top, you are out. Instead, all the cool kids out there are separating backends from frontends, which is a thing that would normally fill me with joy because finally people are paying attention to stuff like the separation of concerns, right? Instead, in this case, it filled me with existential dread, but my engineering side kicked in and I decided to do things right instead of being lazy.

Backend

The problem was very simple: to make a backend API that would serve the exchange rates in standard OHLC format, at hourly intervals. I spent a lot more time thinking about this than would have been reasonable. I have been looking forward to doing some server-side Swift pretty much since server-side Swift has been a thing, so the backend language was not even a question. The question was regarding which framework I was going to use. Right now, there are a bunch of alternatives, the most popular being Kitura, Perfect, Zewo, and Vapor, and there are tons of comparison posts all over the Internet.

In my case, I needed an API with a single endpoint that served a set of numbers in JSON format, so I was not too concerned with performance. I went for Vapor first, but couldn’t get it running on my Mac because of Homebrew, so I fell back on Kitura because a) it’s backed-up by IBM, and b) I didn’t particularly like Perfect, and Zewo seemed too much like the newest cool kid on the block, so it didn’t quite inspire trustworthiness to me. I’m not the greatest judge of character, though. 😏

Overall, I am very pleased with my API. I like Swift, and Kitura is a nice enough framework to work with. I wanted to move quickly and get things up and running, so I didn’t want to spend days elbow-deep in documentation. This meant that my code has a few kinks that need working out, and I am still confused about a few things, like what the heck happened to execution environment variables and debug/release configurations, or when will Xcode properly integrate with the Swift Package Manager, or are we ever going to see a decent third-party IDE fully support Swift and the SPM? These are the important questions in the life of a server-side Swift developer.

The next important question, one that I could answer, was: how do I generate plausible data? I mean, despite traders swearing on their mothers that trading is not a random walk, the truth is that, at least locally, it probably is a random walk—I mean, it’s gambling, after all. So, given that I resolved to only show a graph 48 hours long, presenting hourly intervals, I decided to use a Perlin noise generator, and it’s doing a pretty good job. Take that, forex.

You can have a look at the source code in my Github account.

Frontend

The last time I did web frontend work on my own, LESS was all the rage, jQuery was still the go-to library for all things Javascript, and you wanted to do most of your computing on the server because clients were crappy and unpredictable. Yes, it’s been a while, now Sass is all the rage (or is it Next? or is it Pure? or is it…), there have probably been three or four JS frameworks born in the time I typed this post, and browsers are still crappy and unpredictable, although they are slowly getting better.

In my current job, we manage a large JS-heavy web site based on Angular 1 (!) and React and stuff, with a segregated API in Java — yes, I know. So, I figured, I’ll give this ECMAScript 2015+ fad a go.

For the graph, I used D3. At first, I used P5, but then things turned out a bit more complex than I expected, so I figured I’d try D3, given its popularity. Maybe I’m missing something, but I think I ended up manually coding an SVG document from scratch, using that very poor excuse for data binding that apparently makes D3 what it is. I literally had to take a shower afterwards.

With the graph done — and not even like I wanted it to be — I moved on to the exchange calculator. React was kinda the obvious choice here. I use it at work, it’s pretty neat, the whole JSX thing is gross but then again JS is gross, so overall I just went with it and was not even entirely disgusted. Updating the component’s state confuses me to no end, but in the end, I managed to get it working.

To tie everything up together, I used Webpack. I am honestly not sure what is going on when I run it. I guess I was expecting something more like a GNU Make plus a kind of a file watch thing, something like a configurable pipeline of building minions that would neatly do what I want them to do. I’m not sure I’ll be using it for my next project, unless it makes absolutely sense, or someone forces it down my throat. Even at work, we gave up on it, though I’m not sure what we replaced it with. 😛

Have a look at the source code, if you dare.

Deployment and HTTPS

HTTPS is cool, it’s important, and it’s a no-brainer with Let’s Encrypt, if you have your own private server, or an open-minded ISP.

Deployment was also quite easy with Docker on my own VPS.

In conclusion

VIZex.co was a fun project. I can’t say I learned a lot, but at least I got my feet wet, and I have now a decent platform to explore modern web-development further — though I remain skeptical, but that’s probably just me and the type of software that I normally develop.

Ironically, I am doing this for the exposure, so if you liked this post and VIZex, give it a round of applause here on Medium, and spread the word among your freelance friends. Hopefully, the next time someone offers you visibility in exchange for work, you will point them at VIZex.co and ask them for an adequate amount of bitcoins instead — or the equivalent in your own preferred currency! 😜

Speaking of coins, I’m doing this for fun and for free, but my ISP, quite reasonably, asks for money. If you could spare a few coins, I’d greatly appreciate it. Just scroll down on VIZex.co!

And if you are wondering why I spelled #finntech with two ‘n’s, that’s because it stands for Finnish Technology. 😅

More by Andrea Franceschini

Topics of interest

More Related Stories