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 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.
Buying a camera in 2016 is hard. What kind of camera should you buy?
Should you even buy a camera anymore? Phone cameras are beginning to be very good and they are the cameras that are literally always on you.
The iPhone 6s and Google Nexuses now have 12MP camera sensors and I’m sure other phones have even more ridiculous sensors. Phones still fall short in shooting in low light where they tend to produce noisier photos. Still, shooting with a phone hardly stops you from getting great pictures, just look at Austin Mann’s Instagram feed for example.
But let’s say you want a separate camera. For one, carrying a camera helps put you in shooting mode. Holding a camera in my hand makes me look for photo opportunities, and having the camera ready means I’m more likely to catch the photo. While phone cameras are technically good, a camera camera usually has better usability for taking pictures and adjusting the settings. And shooting with a real camera is more fun.
DSLR vs. Mirrorless Cameras
To date, about one billion articles and blog posts have been written about “DSLR vs. mirrorless”. To summarize them all quickly:
- Mirrorless cameras are smaller and lighter to carry
- DSLRs have better grips (because of the size)
- DSLR batteries last at least twice as long (like 350 vs. 1000 shots per charge)
- DSLRs have bigger image sensors
- Optical and electronic viewfinders are different, or not
- Mirrorless are more fun
Sure there are other aspects to assess like autofocus and selection of lenses but there the gap is getting narrower. And of course people are quick to point out that not all DSLRs are big and bulky and not all mirrorless cameras are small and light. I get it, but that’s the difference in general.
Anyway, what’s interesting reading those articles is that reasons for having a DSLR are moving towards “I’m a war photographer and need the best camera there is.” And that’s a valid point. Mirrorless cameras probably aren’t replacing high-end DSLRs. For example the bigger sensor does help get marginally better pictures when there’s less light or you need to do extensive post-processing. And a DSLR is probably better if you shoot sports for a living.
But for ordinary consumers like me the mirrorless cameras are now starting to be just good enough, judging both picture quality and price. They are capable of producing high quality images in most situations without the “overhead” of carrying a DSLRs with you.
Upgrading from Nikon D90
Most recently I’ve shot with a Nikon D90 DSLR which I bought cheap as used. It was a good camera but the image quality was not quite up to today’s standards. The camera was released in 2008 and sensor technology has advanced a bit since then. Nikon has since release three cameras in the same “prosumer” category: D7000 (2010), D7100 (2013) and D7200 (2015).
Most logical upgrade path would be to purchase the D7200 or a used D7100. Their differences are minor and both would be much better than the D90 for example in low light.
I’m not tempted to upgrade to more high-end Nikon cameras or to switch to full frame cameras (= even bigger sensors). Nikon’s prosumer line has the features I imagine needing and the D7200 at 1000€ is near the upper limit for what I would ever pay for a camera.
I’m not a professional photographer. I like taking photos but practically speaking I only take some silly photos on vacations and parties and that’s about it. There are hardly any situations where the camera would be holding me back.
A Contender Appears
I had almost convinced myself I should buy the D7200… until a friend of a friend posted a long post on Facebook about how they love their Fuji camera and how it totally makes you like photography again. Oh boy.
That person had a Fuji X-T1 which is a bit pricey for my budget but after a frantic googling of all possible Fujifilm cameras I found two other models that had very favorable reviews: the X-E2 and the X-T10. The latter is a slightly stripped down version of the X-T1 (no weather-sealing, smaller buffer) but it’s also more affordable: with a 18-55mm kit lens it costs just a bit more than the D7200.
One key feature that makes Fujis fun is repeated in several reviews: dials on top of the camera. The X-T10 has dials for exposure compensation, shutter speed and drive mode. This may not seem like a big deal, but on Nikon digital cameras those specific functions are handled with two anonymous front and back dials. What’s worse, they seem to be weirdly modal: sometimes spinning the real dial doesn’t change exposure or the front dial won’t change the shutter speed. Dedicating dials with numbers on them for these functions sounds promising.
The top dials also remind me of my first serious camera, the Nikon FA that I inherited from my father. It has dials for ISO, exposure compensation, shutter speed and shooting mode:
That’s one camera I’d like to use if shooting film wasn’t such a hassle.
One downside of Fuji is that their lenses are a bit expensive. There are no 200€ FUJINON lenses similar to the Nikkor 35mm/1.8 (which offers great bang for the buck). All Fuji lenses start at 450€ and quickly climb to 1000€ range, for example for the 23mm/1.4.
However, there are some cheap adapters and some expensive adapters, like Metabones Speed Booster ULTRA which would let me use my current Nikkor lenses on the Fuji. The Metabones adapter is interesting as it has a focal length ratio of 0.71 which combined with the camera’s 1.5x ratio makes an effective 1.07 multiplier. So a 35mm lens with the adapter would act as a 37mm lens. It also increases the maximum aperture by 1 stop.
I found some interesting stories from people switching to Fuji including people who used to own Nikons. I could link to some of them in another post. I haven’t made the jump yet so I’m still speculating while I’m saving the money. But at least the options are now interesting and seem fun!
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. →
Aika ajoin joku kirjoittaa netissä siitä, miten saa liikunnasta ylimääräistä puhtia elämäänsä. Yleensä joku menestynyt kaveri. →