Hello there. I'm this guy and this is my home page. Below are all blog posts I have written since 2007. Some of them are silly, but self-censorship would be worse I guess.
I’ve been watching a lot more Youtube lately. Maybe their algorithms have gotten better at recommending interesting videos or maybe it’s that there’s been little else to do lately.
Youtube is finding more videos in random categories I didn’t know were a thing but I find intereseting. I thought I’d share a couple of them. Of course as with anything on Youtube, these are wildly popular within their niche and might be old news. Anyway, today’s recommendation:
Daniel Duskin’s mixing videos:
Daniel is a mixing engineer (selling sound mixing services) and he demonstrates his skills on Youtube by strapping a GoPro to his head and fliming himself mixing classic songs on an analog mixing console. Like Queen’s “Don’t Stop Me Now” above.
Daniel doesn’t try to replicate the original songs but does a quick, maybe even better, mix from individual instrument tracks (sourced where???). It’s wild to see and hear how a song comes together with each new instrument.
Another video of mixing The Doobie Brothers’ “Long Train Running” has explanations of what he’s doing although heavy with mixing lingo:
Daniel makes mixing look so easy and effortless. Of course one thing to note is that the source material on these videos is super good.
A lot of effort went into composing and recording these songs and planning how all the instruments play together even before mixing. “Long Train Running” is already groovy as hell with only the drums and guitar. You wouldn’t be able to quickly mix ten garbage tracks and make the song sing the same way.
Bonus round: Nile Rodgers Tells The Story of “Let’s Dance”
This is a quick, heartwarming story of how Nile Rodgers, one of all-time best guitarists and artists took David Bowie’s simple guitar riff and turned it into “Let’s Dance”, a massive hit in 1982. Pure magic.
I’ve been building a SaaS product called InfoToggle as a side project. My previous post has details on what it is and what it does.
As a programmer having a side project is a good way to learn new technologies that you might not come across in your regular job. Having a project means there’s a clear problem you want to solve and you get to choose the most suitable tools to solve it.
In the context of InfoToggle I had a chance to learn multiple new tools, including Laravel, Docker, React Hooks, Stripe, and some AWS features like CloudFront.
Laravel: thumbs up
A big initial impetus for this whole project was to test out Laravel framework. I had heard many good things about it and wanted to see what a modern PHP framework would look like. I’e used Zend Framework in my jobby job and it works there but it’s no fun to use really.
Laravel’s tagline “freeing you to create without sweating the small things” is pretty spot on. The framework has a lot of built-in functionality and sensible defaults for creating basic web apps. Creating new routes, controllers, database migrations, and events is all very streamlined.
Occasionally some of the inner workings of Laravel might feel a bit too magical which might become a problem in a bigger web app. The call stacks for some of the errors are *wild* but mostly it just works and it’s fast enough for a basic web app. Laravel’s documentation is also pretty good, at least compared to Zend.
Technical Challenges with Stripe
One of the biggest hurdles was building the subscription system. Billing happens through Stripe and integrating with their subscription flow took a month and a half (not full time, but working hours here and there.) That’s a pretty big chunk of time where little progress was made.
Don’t get me wrong, Stripe is probably the best payment processor there is and others would probably have taken far longer. The problem with Stripe was mostly that there are quite many different ways to create a sign up / subscription flow and there is no clear path to choose the correct one.
On top of that their documentation occasionally had PSD2-related warnings “Are you in Europe? Then you probably shouldn’t be using this method but this other one here which is in beta and doesn’t have the same features.”
Stripe webhook matching
Most of Stripe’s flows work by sending requests to a webhook you set up. One of the biggest source of my confusion was that there was no single way of matching an incoming webhook event to a customer.
You can tie a “client reference ID” to Stripe’s customer objects (usually the customer’s ID in your own system) but only some of the events sent back to you include the reference. Other times you are left trying to match a subscription ID to a ID you know or in worst case an email address.
Some of Stripe’s events include a Customer ID (in Stripe’s system) and once you can match that to a known ID you are mostly set. But for example the “customer created”, “subscription created”, and “invoice created” events can arrive in any order and each has a different set of identifiers that you must keep track of and try to match to later requests. I still have a hundred line function whose only job is to match an incoming Stripe event to a customer in my database.
I’ve avoided Docker for a very long time, mostly because in my job I have worked on just a single project where I had the development and production environments set up. But at this point Docker seems to be required knowledge pretty much everywhere so why not try it?
It seems that waiting with Docker was partly a good thing. Researching how to configure Docker (and Docker Compose) revealed that the configuration options and syntaxes haves changed at least a couple times. This made following tutorials quite difficult as most of the examples didn’t work anymore when run against a recent version of Docker.
What’s positive about docker is that it makes deployments easy. Replicating the production environment is also easy although I haven’t needed that apart from adding a separate testing environment.
Docker was also the biggest source of WTFs along with Stripe. Most of this stems from all Docker tutorials and examples being about building a development environment with Docker.
Very little of that is applicable when deploying to production which was what I tried to achieve. For example Docker volumes work completely different locally and on a server. In the end I needed to have two separate configurations for building the development environment and the production environment which feels a bit silly.
Another small disadvantage with Docker is that deployments on the go over a cell phone connection take a long time. Apparently there’s quite a lot of data transfer happening?
Quick shout out to React Hooks: they work, and make developing basic components that much nicer. Use them.
That’s it for now! Everything sort of works and I’m pretty happy with the stack as it is. There are also many parts that didn’t get a mention, maybe more on those next time.
I’ve been building a product for displaying announcements and alert messages on ecommerce websites, called InfoToggle. It started out as a side project and has now grown to a point where it might actually be useful to others as well.
The problem InfoToggle solves is pretty simple and is something we see in my current work at POP Vakuutus quite often. We sell insurance but a successful sale depends on multiple external systems, for example the national vehicle database Trafi, a credit check service, and customer authentication, a service provided by banks. Any of these systems might and do break from time to time. Especially Trafi has a notoriously bad uptime record and often does unscheduled service breaks they only announce afterwards. During an outage we might not be able to sell a single vehicle insurance but such is life.
If any of these services breaks there’s not much we can do but wait. One thing we can do is communicate the disruption and its extent to our customers. Due to the ecommerce aspect it has to be done in a way that doesn’t scare away customers not affected by the disruption. If a disruption prevents customers from buying a car insurance, it’s best to only inform customers about to buy car insurance and preferably ask them to try again later.
Here’s where InfoToggle comes in: it lets site owners create messages for situations like these and easily *toggle* them on. For service breaks known in advance a message can be timed to be visible the duration of the break.
Of course the messages added to your site can be whatever: announcements, discount codes… InfoToggle lets you add any HTML, CSS, and JS code you need to your site. But I feel it’s useful to frame it around situations where you quickly need to communicate things to your customers. Once an initial set of messages have been defined they can easily be duplicated and modified.
Not every site needs a system like this–a good CMS will let you do all of this. What I’m willing to bet is that there are a lot of ecommerce sites that don’t have a good CMS :)
InfoToggle started as and still is a side project. One motivator was to try out new tech (which I will expand on later) and have fun coding challenges.
It also provides a chance to practice many non-technical skills like product development and marketing.
Of course being limited to a couple of hours after work and on weekends means any progress is a bit slow but the development combined to trying to sell a product gives great focus. There are countless things you could do but you have to choose the single most important feature (or bug) and get it done. I think it’s also great for learning new things.
InfoToggle is now at a point where technically it works and it’s in production use. There are a ton of features and improvements still to do but I also need to focus on marketing and selling hard. All in all it’s still super early and we’ll see how it goes. I’ll keep you posted :)
After some unfortunate bike-thieving-events half a year ago I was left with only one bike: a White road bike. It’s a good bike, I even scored a pair of carbon wheels for it.
Still, one bike is hardly enough. This year I wanted to continue the cycling season through the winter so a winter bike was needed. I also wanted a mountain bike even though I’ve spent very little time in the forest lately. But it might happen, you know?
Could these two bikes be combined? Maybe a rigid mountain bike that’s fast on the road but still survives some trails?
My last mountain bike had a suspension fork. It was nice. Trying to decide if having a rigid mountain bike was sane I came across this perfect answer on Quora:
Anyway, as you might have guessed from the picture, I found a used RCZ mountain bike for a fair price. With a belt drive instead of chain, no suspension and no gears it’s very low maintenance and perfect for winter cycling. The tires hold OK in snow and icy asphalt. How it handles in the forest remains to be seen but I try not to stress too much about it.
I did take the bike on to some trails and participated in VPCX anniversary competition (a local, not so serious cyclocross competition). The bike’s geometry was good but the gearing was really not suitable for off-road. Still a lot of fun.
Some experiences from folks who’ve switched to from Nikon to Fuji systems, something I might be doing as well. Many of these talk about Fuji’s X-T1 which is the big brother of the X-T10 I’m interested in but also about the reasons for switching.
What’s funny is that almost all of them seem to be doing the switch after owning a Nikon D800. That’s one particularly big DSLR which might play a part in why people start looking for something smaller.
Bjorn Moerman’s experience switching from Nikon D800 to then Fuji family.
When was the last time Nikon or Canon came out with a brand new camera feature on a camera that has been out more than 12 months?
I sincerely believe that by 2020 there will be hardly any new classic DSLR's being sold.
A video from Lukas Gisbert-Mora, a wedding photographer, about the reasons why he switched to Fuji X-T1. Including limitations of the Fuji.
At a wedding, actually on the dance floor, when I compared my shots taken with a Nikon and the Fuji, I could actually see that the Fuji was performing better.
When you look in the EVF (electronic viewfinder) it tells you exactly what the exposure is like, before you take the shot. You can actually be much quicker with [the Fuji] than a DSLR ... You just keep the camera to your eye and just adjust the aperture.
Mel Hattie, from the perspective of switching a full $$$$ Nikon system and actually saving money in the process.
Despite the solid construction, the Fuji X-T1 is very light. There's a noticeable size and weight difference when I'm carrying it around, and I feel comfortable pulling it out on the street without attracting a lot of attention.
There are definitely things I'll miss about the Nikon D800: Dual card slots, snappier autofocus, higher ISO tolerance, the video capabilities.
Andy Mumford’s comparison of Nikon D800E and Fuji X-T10. Many side-by-side photos from both cameras
After spending some time playing around with the images from the XT10, I'm really impressed by the image quality and really don't feel as though I'm losing anything significant from the Nikon D800E in real world shooting conditions.
I think we’ve reached a point with image quality where improvements are more technical than real world for the work I do and I want small, light, cameras that feel almost invisible when shooting with them or carrying them around, and I want a camera that's fun to use and experiment with.
Back to Work is a great podcast about productivity,communication and many other things. From time to time the hosts Dan and Merlinrecommend books and comics they’ve read. The books cover a wide range as well,from Buddhism to Unix to cooking. →
The other day I stumbled upon a Facebook argument about meditation: is it about suppressing bad memories, or processing bad memories? The personthinking meditation suppresses memories naturally considered it harmful, and apossibly dangerous fad. →
You go into the woods and come back with an idea. How does that work? →
It seems that blogs are more or less on their way out. On the other hand people publish more material than ever, but it’s divided into a multitude of services based on content and context. Personal life updates go to Facebook, vacation photos to I... →
This is Water from Patrick Buckley on Vimeo. →
Edgar Wright - How to Do Visual Comedy from Tony Zhou on Vimeo. →
David Fincher - And the Other Way is Wrongfrom Tony Zhou on Vimeo. →
Beware: the posts below are all in Finnish.
OpenStreetMap on projekti, jonka tarkoituksena on kerätä yhteisöllisesti karttatietoa ja jakaa sitä vapaasti eteenpäin. Vähän niin kuin Wikipedia, mutta kartoille. →
Pysäkit on iOS-applikaatio, joka näyttää HSL:n pysäkkiaikatauluja. Se on ensimmäinen tekemäni Phonegap-applikaatio ja ensimmäinen App Storessa julkaisemani applikaatio. →
Näin uudenvuoden jälkeen on hyvä palautella mieleen miksi uudenvuodenlupaukset ovat huono idea. →
Olin vuoden 2012 juomatta alkoholia. →
Miten päädyin käyttämään OS X:ää, mutta en aina Applen tietokoneilla. →