04 September 2018
Recently, Vivus received few issues reporting glitchy animations on the latest Chrome. I decided to check the damages but couldn’t find any issues from the demo page. It’s only when a contributor posted detailed steps on how to reproduce it that I realised the damages. Vivus animations via SVG load did not work on the last version of Chrome. That was critical. Especially because Google ship updates that get seemlessly installed. Meaning all Chrome users are affected. Panic at the highest level.
The first thing that came to my mind was to find a backup solution to ship as quickly as possible. Thankfully I had a solution in the back of my mind that could fix another problems related to CORS. Until 0.4.3, Vivus was creating an
object tag linked to the SVG to load. Once loaded, the
svg tag would be extracted and moved to the main document. Then the animation could start.
The patch consisted to use
fetch to download the SVG and append it to the main document.
From the few contributors testing it, the behavior was right and working: good enough for
As part of the issue, the user pixedelic came to the conclusion that it was a browser bug that needs to be reported, and posted the link to the Chromium bug tracker. It’s the platform where the maintainers of the browser keep track of all the reported bugs. Got scared, and slightly lazy to setup a demo stripped down from Vivus. But I understood that I had to grow up and take some responsabilities.
Late that night, my first bug report on Chrome got posted. Yay!
Quickly after posting it, few maintainers labelled the ticket as valid and found the cause of the problem. It got patched very quickly and got shipped in the following version. All good then.
This experience slightly reminded me my first pull request on GitHub. The discovery of a new place you don’t know. Some jargon you’ve never heard before. And the importance of starting tickets with a well documented and detailed message.
04 July 2018
It happen quite often, I need to flip a coin to take a decision. But over the last year, I became cashless, making it more difficult to flip a coin. But I found a backup: websites. There are a loooooot running a simple
document.write(Math.random()>.5?'yes':'no') with 1.6Mb of advertising. Got bored of this, I needed something nicer to watch, as hypnotic as fruit machines. So I created FlipBits.
Put down the slider to the quantity of simulation you want to make, then watch the future being decided in front of you. As I define it : the best random powered AI to take decisions.
No trackers, no ads, works offline. Try FlipBits.
Code available on GitHub.
Yes, I used an iPhone X for the mockups, even if the PWA implementation is not amazing and the notch should be killing that layout.
04 March 2018
Ok, from the start, this is absolutely silly but I had to make mock ups. It’s therapautic, once done it can leave my mind.
JustEat and Grindr share a lot of common data: display data points related to your position, each point got a variable interest, in-between exchange is mandatory to continue, some points can be promoted.. Why not mix the two?
Anyway, this can also work with Tinder. Ignore the pizza once, get unmatched forever.
21 February 2018
Part of many dev interviews require a session on HackerRank to test candidate capacities on algorithms.
Let’s be honest, this is frustration at many levels. Many of us will stress about it and cannot show the best of themselves. On the other side, youngsters getting out uni are fully prepared for this after many years of theory. But the most important: it’s not a good way to test a candidate.
Nobody will spend most of their time writing any of these algorithms or similar. It might represent 3% of your job, at best.
We need a better test. Something that will test what they gonna really do. Like dealing with out of date legacy code. Debbuging some crappy stuff. Facing technical issues in weird conditions.
Let me introduce SpaghettiRank.
It works exactly like HackerRank except the exercise will show you some out of date code. The goal is to explain what it does, explain the choice of the author, and add new feature without breaking the existing ones.
Putting people in front a piece of code they didn’t write tell you more about your candidate than anything else. Their reaction to something badly designed will let you see if they try to understand author design choice or just shout how stupid the author was. Asking to add a feature reveal their feeling about following the existing logic (even if the conception is not ideal) to keep consistency or prefer to rewrite everything. These situations can also bring you to talk about their previous experiences and discover more about them. Having to work on a piece of code from the framework you use show you their experience with it in a very short time.
Because seriously, you know how to write a binary search tree? Well go debug an old Angular 1.2.14 directive without tests and docs that keeps creating undigestable errors logs that are longer than the bible!! [Undigestable.. Angular.. you get it? Ok, Im out]
In the meantime, you can still show a real pull request to a candidate ask them to analyse it. It should be good enough.
Fusion of hipsters and pixel art
14 January 2018
Triangulart is an old project that came up when I needed to build an illustration based on triangles. After spending too much time on Illustrator to figure out how to make it easy I realised I could build my own editor as a WebApp. It didn’t represent a lot of efforts because most of the code was coming from triangulr to generate the grid, then few UI elements and DOM event to build a basic editor. It was minimalist (even brutalist) but did the job pretty well. It was enough to waste few minutes on it. HackerNews proved it to me by keeping my link at the top for a good Friday afternoon.
After few months (or year?) it was time to improve the tool. Some missing features were crucial when a big project is done with it. The opportunity was perfect to learn VueJS which was used for the UI.
As part of the new features:
- Undo: it’s first time I had to code a stack to reverse operations on the canvas and it was pretty simple to do. This feature is probably the most important.
- Selection tool: doodling something and lacking space was one of my biggest frustrations. I wanted to be able to select an area of triangles, move them, fill them or even delete them. It wasn’t easy to implement but worth it!
- Touch friendly: it wasn’t the priority but ended up being the most amazing feature. Being able to use the app on old iPads is really enjoyable. It gave me please to reuse my outdated Nexus 7.
- PWA (Progressive Web App): being able to play with it offline was a big plus. Not very complex to do, most of it was taken from breaklock. It was mostly designing icons.
- Local Storage: got always scared that my browser crash and loosing all my work. Having an auto-save at regular intervals is very handy.
- SVG output: to export artworks, it was available in two formats: JSON the editable version, the SVG the final output. So to make it less confusing, there’s only one format: SVG. It contain all the required data and can also be used in graphical editors.
The interface and code is not perfect. There are some good code split to do, better routing, better menu layout..
Also, moving to canvas would be a huge performance gain for big workspaces.
I’m looking forward to see what users gonna make with it.
However, I thought back about the reasons I created this app to reach the conclusion that my life follow this pattern:
- Got an art project in mind
- Start working on it
- Realise that code could help me
- Abandon research on the project to focus on code
- Build a webapp
- Expose it to the world
- Polish it (maybe a v2)
- Move on and never do the art project
‘‘What? Is it a webapp?’’