Pooya Esfandiar

Raspberry Pi Pico as AM Radio Transmitter

2026-02-28T00:00:00+00:00

Obligatory legalese: emitting radio waves, even low-powered and/or short-lived may not be permitted in your jurisdiction.

Years ago, people figured out Raspberry Pi’s can accidentally double as FM radio transmitters without a need for any radio front-end (if we don’t count a single jumper wire working as an antenna). They achieved this by tying a GPIO pin to a software-controlled clock around 100 MHz to modulate audio. This created a low-powered FM radio transmitter. Due to the pin producing a square wave instead of a neat sine wave, it also emitted weaker harmonics at 300MHz, 500MHz, etc., but any basic FM radio could pick up the audio. I wondered if a similar feat could be achieved by much less powerful Raspberry Pi Pico microcontrollers.

While a Pico board doesn’t have the same architecture that allows FM transmission on regular Pi boards, it has a unique feature: PIO. This allows running programs based on a minimal instruction set independent of the CPU at the system clock rate. A simple program (“turn the pin ON, turn the pin OFF”) can then produce a square wave at half the system clock rate. Pico boards could be overclocked at ~200 MHz, allowing a similar carrier frequency, but the exact frequency cannot be controlled by software in any practical way. This rules out clean FM.

A Pico board can however allow better control at lower frequencies within the typical AM radio station (~1000 KHz). While square waves are well-suited for frequency-modulating any PCM audio file (ignoring the unwanted harmonics), they cannot be used well for amplitude modulation. They can only encode ON or OFF instead of different audio amplitudes (think 1-bit envelope). Alright, no emitting arbitrary “.wav” files. We can at least emit a single audio frequency at a time using On-Off Keying. Let’s make some retro game sounds!

With assistance from LLMs, I wrote this code that emits the Shave and A Haircut melody on a 1000 KHz carrier. Here’s a basic AM radio picking up the audio:

Your browser does not support the video tag.

One of the pins is programmed to produce a constant 1000 KHz square wave using PIO. The main program then turns the PIO on and off at the intended frequency. e.g. to emit an A4 pitch (440 Hz), it turns the 1000 KHz square wave on and off 440 times a second. To the radio receiver, this means a 440 Hz square wave audio. Using this technique, it emits the well-known Shave and A Haircut melody on a loop.

Real-Time Visual Synth Driven by RP2350

2026-01-13T00:00:00+00:00

RP2350 is the dual-core microcontroller at the heart of Raspberry Pi Pico 2 boards. Although the RP2350 has two identical Arm Cortex-M33 cores, it is usually programmed in an asymmetric multiprocessing (AMP) style, which doesn’t provide a shared task scheduler (e.g. a la FreeRTOS SMP). It’s still simple to divide and pin different tasks onto either core and use the two fast hardware FIFOs for inter-core communications.

Recently, I acquired a 1.3” 240x240 LCD made especially for Raspberry Pi Picos. It can be attached directly to the board pins, where the command and data signals are sent to its ST7789VW control chip via SPI and the joystick and 4 button inputs are received via 9 GPIO pins. This provided a chance to test how far I can push the microcontroller in creating a real-time visual synthesizer.

With help from generative AI, I created a “plasma effect”, which is generated by combining several sine waves over a 2D grid and animating them over time. The rendering happens using a single frame buffer. For each pixel, its coordinates and distance from the center are fed into sine functions, and the results are added up to create smooth interference patterns. A time parameter continuously shifts the phases of these waves, making the pattern flow and evolve. Another phase offset is used to cycle through colours for an extra ethereal feel. I programmed the joystick to shift the colour phase and change the animation speed, and the 4 buttons to switch between 4 presets for plasma parameters.

You can find the source code in this standalone repo or in my collection of Pico projects. The LCD vendor provides a C SDK shared between multiple products. I extracted the part specific to my display and changed it to use a 240x240 frame buffer for rendering, before sending every frame to the display.

At first, I used a single core to render each frame in memory and then send the entire frame via blocking SPI. The rendering uses floating point calculations, which are expensive, even with RP2350’s single-precision FPU. I didn’t make any attempts at optimizing the rendering code itself (except creating a sine look-up table upfront), as I was curious how much faster/smoother the animation can get if the tasks of rendering and driving the display are divided between the two cores. The rendering represents any CPU-heavy graphical calculations.

The single-core demo got me to a measly 3.3 FPS, which is too choppy and unacceptable even to a non-gamer! I then separated rendering and writing into the display to run in parallel between the two cores. Once the frame is ready, the renderer sends a signal to the display core to shovel the data out. Typically, writing into and reading from the same frame buffer could create “tearing” glitches, but with the relatively slow-moving and flowy animation, it wasn’t an issue. The dual-core demo reached 5.5 FPS, which feels more like an animation even if it’s still choppy.

To further play around with my Pico, I could be using Direct Memory Access (DMA) or Pico’s unique Programmable I/O (PIO) to speed up the display driver. Currently, the renderer is much slower than the driver (equivalent to 8.5 FPS), so even using CPU-free solutions to move pixels won’t be enough to speed up the animation. Perhaps splitting the rendering into the 2 cores to run in parallel could help, but we’re then gradually getting into why GPUs exist in the first place!

Sonar-Powered Creepy Halloween Ghost

2025-12-02T00:00:00+00:00

I recently bought a Raspberry Pi Pico W, which comes with a Bluetooth module, along with an HC-SR04 ultrasonic rangefinder. I wanted to hide it inside Halloween decorations and program it to make a creepy ghost sound that intensified as my child’s Halloween party guests approached it. The children might have already aged out of being scared by it, but it was a technical success after all. I’m sharing the source code and some of the details here.

The ultrasonic rangefinder works by emitting high-frequency sound pulses and measuring how long it takes the echos to return from nearby objects. The emission and measurement has to be manually driven by the microcontroller. The microcontroller’s job is to measure the distance regularly and if someone is standing within the range, produce a creepy ghost sound; a sine wave within 300-600 Hz with some extra low-frequency modulation to give it a “breathing” effect.

Circuitry

The rangefinder requires 5V and Ground that could be easily obtained from Pico’s VBUS and GND pins. Its TRIG pin, to drive wave emissions, can be controlled by a regular GPIO pin (GP2) as 3.3V is enough, but its ECHO pin outputs 5V. In order to prevent the rangefinder from frying the board by sending 5V into the receiving GPIO pin (GP3), I use a simple voltage divider using a 10K and a 15K ohm resistors. ECHO is separated from GP3 by 10k ohm, which is in turn pulled down to GND by 15k ohm. This brings down the voltage to about 3V, which reliably registers as high for a GPIO pin.

There isn’t anything else to the circuit besides powering the board via USB.

Source code

Instead of using the standard C/C++ SDK, I opted for Arduino-Pico v5.3.0. You can still program the board in C++ (Arduino styled), but it comes with a convenient Bluetooth driver and the IDE makes debugging via the serial port simpler. The source code contains all the logic in a single Arduino file.

The setup defines the I/O pins and makes a connection to the Bluetooth speaker as an A2DPSource. For connection to the Bluetooth speaker, I specified my speaker’s MAC address for reliability and simplicity. The main loop is in charge of driving the rangefinder and calculating and streaming the ghost sound, so to keep it tight and performant, I pre-calculate the sine function for 256 values (with linear interpolation between them) during the setup and store them in a look-up table.

The main loop polls the ultrasonic sensor by sending a 10-15 micro-second TRIG pulse and measuring how long the ECHO pin stays high. From this round-trip time, I compute the distance. The results are surprisingly accurate. If an object is within the range (15-150 cm), it starts generating a sine wave, whose frequency (300 to 900 Hz) and amplitude are a function of distance. This creates the illusion that the “ghost” is screaming harder as you get closer. As the pure sine wave can sound a bit artificial, I add a low-frequency oscillator to the mix. I maintain two separate phase accumulators; one for the main tone and one for the modulation, and read both from the lookup table. I apply smoothing and clamping functions to avoid clicks or harsh transitions. This is the part where generative AI and a few iterations helped me get the best results.

The audio output is then calculated at the sample rate of 48KHz. The left and right channels have the same value (mono) and I use a 2048-frame buffer for streaming the audio via Bluetooth. Raspberry Pi Pico is not exactly a high-performance microcontroller, but it could handle driving the sonar sensor and Bluetooth streaming in the same loop with occasional buffer underrun (resulting in clicks). To avoid that, the second core could be used to separate the sensing and streaming tasks, and ensuring the streaming takes priority over sensing (no major change in distance is expected anyway).

Serverless Photo-Sharing App Using Amazon Web Services

2017-03-10T00:00:00+00:00

As the self-appointed IT director of my new family, I was tasked with finding the best solution to easily upload, back up, and share pictures and videos of our newborn daughter. While there are a myriad of cloud services that a normal person would go for, I didn’t want to rely on them to safeguard our most precious moments. To be honest, I was also itching to create a serverless app on AWS, without committing to much cost or maintenance overhead.

AWS has a host of relatively cheap services that makes creating small serverless apps easy. The JavaScript API allows you to keep most of the logic in your browser, where you can access AWS directly or through a proxy (e.g. API Gateway). I’ll explain how I used them:

Cognito for authentication: The main users of this app were my family and friends, so I only had to worry about unintended mistakes as opposed to malicious abuse. This allowed me to create pre-defined users for different roles (e.g. admin and visitor), and use Cognito to authenticate them. The JavaScript API lets you safely hard-code the public codes in the web page, and log in using a password only.
IAM for authorization: Once users are authenticated, IAM should give them minimal privileges to do their tasks. For example, I gave file upload access to admin users, but only read access to visitors. The Principle of Least Privilege prevents users from wreaking havoc. IAM didn’t have the finest-grained access levels, but for a trusted set of users, that should be good enough. For more flexibility in authorization, of course, it has to be done on a proxy or web server.
S3 for storage: Amazon’s simple storage is truly simple to use. I used it to store media files, thumbnails, and the static website assets. You may make the static site public, but put media files behind Cognito. The nice thing about S3+Cognito is that you can use the Cognito token in the S3 URL and access it in your website as you normally would with hosted images.
DynamoDB for database: The list of galleries and files, timestamps, captions, user access, and comments have to be stored somewhere. While S3 provides limited ability to store metadata for each file, the permanently-free tier of DynamoDB has enough capacity to store them in a few tables. The NoSQL (or rather schemaless) nature of the database makes it easy to quickly add new features.
Lambda for processing: A serverless architecture will not be complete without a function-as-a-service component! In this case, I used a S3-triggered function to create an entry in the database and process newly-uploaded images and videos. It could do anything as simple as generating thumbnails (Lambda is pre-packed with ImageMagick), or dealing with EXIF idiosyncrasies.

As for front-end, there wasn’t much needed for this app. Besides the good ol’ AWS JavaScript API, I used Bootstrap for easy styling, Knockout for two-way data binding, and Unite Gallery for media viewer. Unite Gallery is an open-source library with a few available themes and easy setup. However, getting videos to play on mobile and JPEG EXIF orientation proved to be challenging.

If I found time to improve the app, these areas would come up next:

CloudFormation: As of now, most of the configuration has been manually done and its persistence is at the mercy of AWS. I can use CloudFormation to formulate how everything was set up, so it can be retrieved if anything goes wrong. Amazon provides CloudFormer to create a template from an existing architecture, but it didn’t cover the bulk of my configuration around Cognito and security policies.
Automatic rotation: not all browsers can show the right orientation of cellphone images based on their metadata. I can use a Lambda function to automatically rotate images based on their EXIF orientation field.
API Gateway: Using the combination of API Gateway and Lambda, there would be no need to give users direct access to AWS resources. This will improve the security and may make the app useful for other people who can have a more serious use case for it.
Backup: A scheduled task that backs up media files and database records and writes them onto cheaper storage (e.g. AWS Glacier). For a more paranoid approach, I can also store them on another cloud service provider such as Google Cloud.

I’d be happy to get feedback on the design, and ways to improve the architecture.

Chilkoot Trail: The World's Longest Museum

2016-08-08T00:00:00+00:00

Chilkoot Trail, a 53-km trail from Dyea, Alaska to Bennett, BC, was the main way for gold rush prospectors in late 1890s to get to Klondike River in Yukon. This slideshow contains photos of my 5-day hike through this historic trail.

Day 0: I fly to Whitehorse, Yukon where the group will get together the day after to drive to the trailhead. I have some time to explore the city.

The world's largest wind vane at the Yukon Transportation Museum. The wind is blowing eastward.

Whitehorse in Arabic letters

A common mode of transport in the old days, used by Royal Mail.

SS Klondike was the largest ship that operated on Yukon River

SS Klondike's engine room

SS Klondike's kitchen

"Gold! Gold! Gold! Gold!" An old newspaper from Seattle shows how the gold rush started. When a large shipping of gold from Yukon arrived in the US, media started creating hype, and people desperate from the economic downturn swarmed towards Yukon to get a piece of that pie. Little did they know how brutal the winter conditions are, and how little gold they can claim after the news was already out.

Gold rush prospectors had to carry a huge amount of luggage with them. After arriving in Alaska, they had to take Chilkoot trail, and after reaching Bennett Lake, they could use Yukon River for rafting up to Dawson City (gold fields). Pictured is the 45-degree-sloped Chilkoot Pass which was the most difficult part of the trail. The Canadian police was stationed at the top of the pass.

Day 1: all packed up and ready to hit the trail. First we need to drive to Alaska for the trailhead.

Emerald Lake gives a preview of how the last part of the trail will look like.

Fireweed is Yukon's flower (their official floral emblem)

The road to Skagway, Alaska goes through White Pass, which was another major way during the gold rush. The railway on the less-steep White Pass made Chilkoot Trail obsolete in 1899.

This is how much "teeth" a train needs in order to carve through snow

Skagway, Alaska. After the gold rush, people's major occupation here was trapping animals. They now trap cruise ship tourists.

After watching a short movie about how to avoid or possibly fight bears, we take a short drive to Dyea, Alaska. The sunny weather at the trailhead is promising.

Beaver-created ponds. The first part of the trail is mostly swamps in a coastal rain forest. We have to keep making a lot of noise to scare the bears away.

Finnegan's Point is where we stop for the first night. It's after 10PM, and the sun has set behind the glacier across Taiya River.

All food, fuel, toiletry, and pretty much anything that smells has to go inside the bear cache, which is at least 50 meters away from the tents.

Day 2: It's still sunny and we are still in the rain forest. This means a lot of mosquito bites. The trail permit hanging from each hiker's backpack shows we are one of 50 people that are allowed on the trail at the same time.

Devil's Club. Not so fun to whack to find your way through.

We only had to carry around 1 litre of water at a time. Fresh streams provided a reliable source of water throughout the trail.

Making your clothes wet could mean hypothermia at night. These finicky bridges can have up to one person at a time, but they mean no need to cross the river and risk getting wet.

Old baking oven in Canyon City. This city used to have thousands of people with shops and restaurants. It existed for about two years only and then was deserted.

Large boiler in Canyon City that powered the tramway. Only the richest prospectors would pay to use the trams.

Can you spot the old telegram cable?

Stove in a shelter to warm up

Our tour guide provides warm gourmet camping food. Priceless!

The second night at Sheep Camp has rain in the forecast. Time to pitch the tent tightly to avoid getting wet.

Day 3: This is the big day when we have to take the steep slopes, and to add insult to the injury, it starts raining. Leaving the camp at around 6am, we are pretty miserable.

The silver lining is that rain and fog make for good pictures. We are now exiting the rain forest and going above the tree line.

The old tram station at the top of the cliff.

The Scales: the Canadian government required gold rush prospectors to bring enough necessities to survive in the brutal winter of Yukon. The supply checklist includes items such as 150 pounds of bacon and 5 yards of mosquito nets. These scales were used to ensure the 1-ton supply is up to par.

This is where the Chilkoot Pass or "golden stairs" starts. The steep slope and grave winter conditions killed many people and horses. Their bones are scattered around the trail.

The Golden Stairs: this is the most difficult part of the trail, and the rain made it more dangerous. The top of the stairs is only a false summit; there are two more stretches of stairs left after that.

Snow patch and rain make for a fun slide, even if you don't intend to.

At the top of the stairs, on the US side of the trail, there's a monument to commemorate gold rush prospectors.

This is it; the summit! We are in Canada now and we get to go to the small warming hut to escape rain and gusting winds. We meet the Canadian warden who has worked there for decades. Time-wise, we're only halfway through the third day, but the psychological sense of achievement makes you forget that.

After the summit, we have a long trek through the Alpine tundra zone of the trail.

Wild flowers carpet the kilometer-high plains

After 10.5 hours we reach the aptly-named Happy Camp with the first sight of the washrooms. Probably one of the most scenic outhouse locations!

Didn't know a warm Lipton soup in a cup could feel so good!

Hanging wet gear to dry overnight

Having put warm and dry clothes on, we go to our tents for the third night of the hike.

Day 4: today is a rather short day to rest our bodies. We get the last view of "river beauties" before we exit the alpine zone.

It's called Long Lake. Isn't it?

Deep Lake. Glacial water and the sediments make interesting hues of colour.

We are now entering the Boreal forests. There are lots of evergreen trees and lakes.

The remains of a boat. After crossing the Chilkoot pass, prospectors started building boats to use lakes and rivers to carry their 1-ton supplies. Needless to say, they only worked for a few months of the year.

The lakes turn into rapids in canyons. Many people died in this canyon, trying to haul their supplies on an unprofessionally-made boat.

We meet a porcupine (far away on the trail). This is not bad considering we won't likely see any large animals. They're usually scared away from big groups of people.

We finally arrive at Lindeman Lake.

The sandy beach and the turquoise colour reminds you of Caribbean climate. The temperature disagrees.

This shelter is at the former location of Lindeman City at the shore of Lindeman Lake. It was a huge tent city to serve gold rush prospectors, and at its peak, its population reached more than 10,000 people.

The Lindeman Camp was closed a couple of weeks before us, because of a bear attack. Luckily only properties were damaged, but the two involved bears were shot to death.

An old first-nation cemetery.

Day 5: Our last day is another 12 km from Lindeman Lake to Bennett Lake. Our trek in the Boreal forest goes along many lakes. Pictured is Bare Loon Lake. We can hear loons around the lake, but I cannot see any.

As per our tour guide, this little lake is ideal for a family of elks to call home.

We don't see any elks, but the droppings are a telltale sign of their presence.

A small trapper's hut. The roof is adorned with bones of humans and animals.

If the trail wasn't diverse enough, we now have to cross sand fields. It looks like a desert.

Lo and behold: here's Bennett Lake. Bennett itself is still meters away, but it doesn't mean you can't take a triumphant picture.

Distances between campsites and landmarks if you start from the Canadian side.

This church is the only standing building from the gold rush times. It's only a shell so no one can enter.

Bennett Train Station. This is part of the old White Pass railway. Trains still operate here, but only for tourists. Since Bennett has no road access, this is a common way for hikers to get back to civilization.

A White Pass railway worker carrying supplies around. He doesn't know how old that car is, but it still runs fine.

To end the hike on a high note, we're skipping the train and instead taking a float plane.

The pilot gives us the usual safety lecture. "The red lever opens the door, but please don't do it during the flight"

The plane takes off pretty close to the trees.

A river snaking along

The river has changed course many times and has created such beautiful shapes

View of suburban Whitehorse along the Alaska Highway. This highway was created during World War II to connect Alaska to the rest of US.

Finally, downtown Whitehorse is in sight. The plane gets ready to land on a nearby lake.

The hike concludes with receiving a certificate. It shows an old picture of prospectors taking the golden stairs.

Slideshow plugin by Pixedelic.

If you liked this, you may also like my Iceland Trip post.

JavaScript Online: hosting a static site cheaply and effortlessly

2016-05-12T00:00:00+00:00

A friend of mine was trying to get hired as a software developer, so he asked me about resources to hone his skills and practice for programming interviews. I came across a few websites where you could solve programming puzzles online. Your code would be sent to a server to run in a sandboxed container, and you would shortly get the result. My friend was specifically learning JavaScript. That made me wonder how cheaply and effortlessly I can create and maintain a similar site for JavaScript only.

The most expensive parts of hosting are usually tied to the computing power of servers. No server can beat the increasingly cheap option of not having a server at all. If your website can work with static resources, you can store everything you need on a storage service, configure your domain, spend a few cents a month, and never have to break a sweat about how your website is running. But how much can you accomplish with a static website?

In the case of an online JavaScript practice service, you can get away with not having a server for many things:

Core: The core of your service, running users’ code, can be delegated to their browsers. For this, web workers are a great feature that cleanly isolate potentially harmful code, and are supported in modern browsers.
Assets: All assets on landing pages, blog posts, and other informational pages are static.
Security: Users can see how you are running their code, see your test data for programming problems, and reverse-engineer them. In this case, let’s agree, it is actually serving the purpose of teaching JavaScript.
Personalization: Local Storage can be used to store the history of their problem-solving. This doesn’t survive a browser data deletion or moving to another device, but oh well!
Community and Engagement: I haven’t added any feature of such nature yet, but there are free or cheap services like Disqus or SumoMe that can add comments or email collection widgets to your static page. I’m not aware of any service for a leaderboard, but I’m sure if the site becomes popular enough, I can roll my own AWS Lambda script to take care of that.

In order to create the site, I’m using a Node.js script. Jade templating engine, Markdown language, Uglify-js, and Express.js for a local test server have come in very handy. I’ve written an automated build script, where I only need to add a single JSON file for every problem, and it creates the whole page, adds it to the index and sitemap, and deploys new or updated files to Google Cloud Storage. Google Cloud Storage makes it easy to host a static website, but it doesn’t support HTTPS yet. I’m using Cloudflare’s free plan to add HTTPS, server-side analytics, a caching layer, denial-of-service protection, and even a widget to show warnings if a browser is not supported.

I might open-source this in the future, but for now, feel free to practice JavaScript online for fun or technical interviews!

Just How Bad Is The Airbnb Effect in Vancouver?

2016-02-18T00:00:00+00:00

The price of real estate in Vancouver has been rising for years, and if you’re not the gambler type, renting has never been a more financially sensible option. However, according to a report by Canada Mortgage and Housing Corporation in October 2015 (PDF), the vacancy rate in City of Vancouver is at 0.6% with some neighbourhoods at as low as 0.3% (English Bay).

If you are a renter like myself, and you’ve decided to stay put for a while, it doesn’t affect you in the short term (British Columbia has a rent increase cap at less than 3% per year). But tough luck if you want to move for any reason! I’ve heared anecdotes of reasonable Craigslist listings being snatched up in the matter of hours, and what’s left is flawed units or extortionately expensive ones.

Another rumour is about people who buy properties in popular locations, and instead of putting in on the rental market, they effectively run a hotel business on Airbnb without all the pesky licenses and regulations. As much as I love using Airbnb for private rooms in cities I visit abroad, the NIMBY in me is not very happy about this trend. That’s why I decided to crunch the numbers and have a better idea of just how bad the Airbnb effect is here.

Luckily, there’s a website that continuously scrapes Airbnb listings and publishes the data. I grabbed the Vancouver data from December 2015. It contains all the listings that were available in 2015. For the purpose of this analysis, I only looked at private homes (no shared or rooms), and only those with at least 90 days of availability to filter out occasional travellers that rent out their principal residence.

The Inside Airbnb data comes with the neighbourhood of each unit, but it doesn’t exactly match the official neighbourhoods posted on the City website (e.g. Gastown is in Strathcona in one and in Downtown Eastside in the other). While the city has over 20 neighbourhoods officially, the CMHC rental report is broken down into 10 zones only. For the sake of visualization, I had to roughly map neighbourhoods to zones, but it shouldn’t affect the results much.

The following map shows Vancouver neighbourhoods with information about their rental situation (click on each to see). I calculated the estimated number of vacant units by multiplying the total number of rental units in each zone by the reported vacancy rate. The map is colour-coded by how high the number of Airbnb listings are relative to the number of vacant units (darker red for a higher ratio of Airbnb listings over vacant rentals).

It seems that central areas and those closer to transit have it worse. Downtown has more than 10.2 times Airbnb listings than it has vacant units for long-term rental, but it’s as much as 15.8 times in Mount Pleasant and Renfrew Heights. It’s not easy to draw a conclusion about how releasing all those Airbnb listings into the rental market would do. Maybe more people would move to Vancouver and the rents wouldn’t budge much. Maybe more people would move in and rents would go lower too, but at the cost of lowering the overall income tax. I leave that analysis to people with more expertise, but it’s obvious that better regulations for those underground hotel businesses would make life slightly easier for locals who can’t or don’t want to buy into the real estate insanity.

I'm Open-Sourcing My Node.js App

2016-02-06T00:00:00+00:00

After over one year of working on my side project and trying to monetize it, I’ve decided to call it quits and share my journey and the source code with the community (Github). In this post, I’m going to explain the whole development process, describe my failed attempts, and get into more technical details in case someone wants to use the app as a boilerplate to create their own.

The Idea

I was itching to create my own software-as-a-service web application while working full time. After all, the idea of having a few sources of passive income is frequently sold to software developers, and I wanted to take part in the “micropreneurship” revolution. I also wanted to practice time management and prove to myself that I can build something from scratch, and possibly have an extra source of income. There’s no need to mention the rewarding sense of building things on top of all that.

The idea of an automated virtual phone system is neither original nor sexy. In fact, there are many companies out there that are doing the exact same thing (e.g. Grasshopper, eVoice, MightyCall, etc.). This meant I might be able to take over a very small part of an established market. I knew Twilio provided an easy-to-use API, so I just had to do the math and see how high the barrier to entry is.

Research and Design

I researched the feature set of top players. I gathered a list of features that I thought I could implement in a few months and prioritized them. I then used KickoffLabs to create a fake landing page advertising all those features. Next thing I needed to do was to buy some paid traffic and measure what percentage of the visitors are willing to press the “Get Started” button. Even though pressing that button doesn’t mean the intention to pay, it indicates the pitch is compelling enough for them to spare a few seconds of their time.

When I got a good conversion rate on the fake landing page (and collected a few email addresses of prospects), and compared the cost of acquiring new customers to their potential lifetime value, I started the design phase. At this stage, I carefully listed all possible features from competitors, and added some of what I thought a potential customer would need based on pure speculation. Then, I sorted them by how important they are and how much time each one of them would take me. The outcome of this stage was a high-level list of features that my minimum viable product (MVP) needed.

The next stage was technical design. I decided to use Express.js framework on Node.js, and use Twilio and Stripe as external service providers for telecom and payment processing respectively. The free tier of Amazon Web Services provided enough computing power to get a staging server up and running. I tried not to use anything too close to the cutting edge, and compromised with more established libraries like jQuery, but I leave the details for the “Under The Hood” section of this post. The technical design was based on an MVC architecture, and I only needed pen and paper to document the database design and screen mockups.

The Interesting Part: Coding!

As many other fellow software engineers can agree, coding is the most interesting part of the process. It’s certainly not the most important part though. Having been coding for 15 years, I found this part well inside my comfort zone. The real challenge was time management and staying focused. Working full time and the human need to be offline leave too little time for extra screen time. However, what really helped me was the great power of habits. I spent an hour or two every single day. No exceptions. If I was very tired or feeling down, I would work on the parts that didn’t need much attention, but the trick was to keep up the streak.

I used Trello to break down the tasks and keep track of my progress. As expected, I had to deal with numerous unexpected issues. Any line of code that you create or comes with external libraries, and any API call to service providers is a potential headache. I took pleasure in solving them one at a time, and I think the source code at its current state contains a wealth of solved problems that I’ll certainly use in my future projects.

I asked a few friends to beta-test the app for me. I applied their feedback and fixed a few bugs. The development took 3-4 months, and I was ready to launch the product after all. I used a free Bootstrap theme to design the landing page. The only money spent so far was about $40 to get the logo designed and register the domain.

Going to The Market

To an engineering-minded person without any serious business experience, this part is the most daunting. To a business-savvy person, this is probably the most important part. Even though engineers like to make fun of all those “I have a great idea and will give 5% equity to an engineer to implement it” Craigslist ads, a person that can execute well on the idea is rarer than a 10X unicorn engineer.

So I got started by creating a couple of social media accounts, and buying some paid trafic from Google search network. The way my app was designed required users to enter their credit card number before buying a virtual phone number. I was too afraid of abuse, and didn’t want to give away too much freebies to acquire new customers. The first campaign showed that I need to be more open. A good number of people signed up, but all of them stopped at the payment screen.

I added a couple of free trial options. I also commissioned a friend to create a low-budget explainer video. I also changed the on-boarding workflow so users can see the control panel before entering their credit card number. These changes allowed more people to get into later stages of the sales funnel. However, none of the users that bought a phone number started paying for it after the trial period.

I guess I didn’t have enough motivation to try inbound marketing, or cold-calling potential customers. They were certainly outside my comfort zone. Attempts at selling the website on Flippa or finding someone to help me with sales and marketing didn’t go anywhere either. The amount of effort that it takes to get any traction for this web app seemed too high, and it eventually led me to open-source it and move on.

Under The Hood: Source Code

I used Express.js on Node.js for back-end, and Bootstrap and Knockout.js for front-end. Twilio was the obvious choice for telecom API, and I hooked up my app to Stripe for payment processing. I deferred writing tests for when I had paying customers, but the software was designed robust enough to evolve into a solid application once it was proven in the market. I used exact versioning in my NPM manifest file, and included all the packages in the Git repository to remove any incompatibility or NPM infrastructure risks.

The architecture on the back-end is MVC, and the front-end uses AJAX calls to populate the page. The server merely sends a Knockout-enabled page to the client, which in turn calls an API command or two to get the required data in JSON format. By this design, I avoided the headache that managing a single-page application will give you, and provided a blank page for users as soon as possible. I think users like to see “somehintg” (the loading indicator) very soon, but show more patience for loading data after that.

There are many opportunities to refactor the code (especially in front-end views), and there are certainly bugs to be found. However, here’s a list of different libraries and components that I used or wrote:

Express.js: Express is a great web framework, and the rich ecosystem of middleware allows you to shop around for best solutions to common needs.
Passport: A useful library for user authentication. I had to write my own session store that uses MySql (session_store.js), and use bcrypt to encrypt passwords, but Passport pretty much provided the rest.
Sequelize: It’s a good ORM that you can use for data modelling. Express doesn’t come with an ORM, so I had to pick between this or Bookshelf. I finally went with Sequelize, and it worked just fine for me. Getting entity relationships right was a bit tricky though.
Q: This promise/async library helped a lot with avoiding the infamous Node.js callback hell.
BigNumber.js: When it comes to money calculations, you shouldn’t trust JavaScript at all. To avoid using their float numbers, I used BigNumber. It’s a bit slow to write simple math, but the reliability makes it worthwhile.
Connect-assets: This is an older asset packaging library. It minifies and aggregates Javascript files, and compiles stylesheet files. That’s good enough for smaller web apps.
Moment: The absolute best when it comes to manipulating dates. Its timezone library made working with timezones a breeze.
Jade: I used this for my views. It removes the HTML clutter.
NodeMailer: I wrote utility files to compile Jade files, and send emails via Amazon’s mail service.
Twilio: If you’re using Twilio, their Node.js library is a no-brainer.
Stripe: Not having to deal with storing credit cards is great. They provide an easy API, and all you need to store and work with is tokens instead of sensitive user information.
secret_sauce.js: This is a “secret” API call that I thought might be useful for invoking certain scheduled tasks, for instance cleaning up expired sessions, or charging customers. I never got to the stage that required automating them though.
Bootstrap: Some people may be allergic to Bootstrap at this time, but it gives you a generic well-designed-looking page for cheap.
Knockout.js: This is great for front-end data binding. If all you have to do is deal with a few forms on your page as opposed to a full-on single-page app, Knockout.js is your friend!

Conclusion

Creating Phonjour was a great learning experience for me. I don’t regret putting effort into it, and I hope the journey and the code scraps can be useful to others as well. In my future attempts at a side project, I’ll try to find a business-savvy person to take care of the business side.

Keeping It Simple and Clean (Part 2)

2015-06-28T00:00:00+00:00

For part 1 click here!

Do NOT Repeat Yourself

Another way to ensure things will remain simple is the DRY Principle (“Don’t Repeat Yourself”), which states “every piece of knowledge must have a single, unambiguous, authoritative representation within a system”. Violating the DRY principle can hurt on many different levels; if a state is stored in multiple places, a piece of code is copied and pasted, or a logic is handled by multiple components. As a result the information stored by the program is likely to become incorrect, your code is prone to contagious bugs, or miscommunication between team members are made easier.

Every time you find yourself copy/pasting a piece of code only to change it slightly, think again about how a helper function can be extracted. If a small piece of algorithm or logic has to be repeated in more than one place, that’s another candidate for refactoring. Except for special cases in distributed computing, no information should come from more than one source either. Even if the logic around it is obvious to you at this time, modifying the logic later will prove tricky to other team members or your future self.

Fundamentals: Data Structures and Algorithms

If you’re a hobbyist or only getting your feet wet, you may be excused, but there’s absolutely no excuse for any career programmer at any level to not learn computer science basics. I skip telling horror stories about huge mistakes made by people who hated math at school and assumed “theoretical stuff” are only for academics. One of the most important areas is data structures and algorithms.

One significant benefit of learning the basics is being aware of time and memory complexity. How long a piece of code might take, or how much space would it need? What if it’s fast for my test data, but it becomes prohibitively expensive in production? Your textbooks provide simple tools to answer those questions, and even if you haven’t read them, you can at least get familiar with a few common data structures and algorithms and know how they scale as the data grows. However, there will never be a right answer to out-of-context design questions involving time and memory complexity, because design decisions will almost always involve some trade-off between time, memory, development time, maintenance costs, etc.

Another benefit of getting familiar with the basics is being able to follow the flow of information. Where the information is stored, how it is stored or retrieved, and where and why it is needed are usually answered by being aware of the underlying data structures and their algorithms. Besides the theoretical aspects, there are also best practices that come from experience and other software engineering practices. For instance, it’s established that DOM is mostly used to represent data, and should not be used to store data (HTML5 data attributes aside).

YAGNI

“You Aren’t Going To Need It”. Very well said! If a feature is not required by business, or there’s no certain near-future plans to add it, you wouldn’t implement it. The same logic can be applied to lower-level design decisions. More often than not, people would like to look way ahead and over-design their systems for a rainy day when the dreaded future feature will come and they just kill it with their (over-)preparedness. The idea behind the YAGNI principle is that even if future is foreseeable, you shouldn’t sacrifice the current code base because of that.

Like many other similar principles, it doesn’t give us a certain recipe, but it tells us that, because of human nature, we’re more likely to over-design than under-design.

Idioms and Design Patterns

Standing on the shoulder of giants should feel good. Walking on a beaten path will tell you other people have gone down the same path. The same goes for time-tested patterns in programming. Design patterns and programming idioms specific to a tech stack are the gift of past engineers to us to deal with the same issues. The only downside is that it may not be obvious which patterns will fit our current needs. A pattern that perfectly answers a specifc situation, may be too complicated for another. Therefore, design patterns should always be used carefully.

Intermediate engineers, after learning a few design patterns, tend to over-use them. Obtaining the hammer of design patterns shouldn’t deceive you into seeing every programming issue as a nail. Take caution and be fine with rolling your own, but certainly add them to your toolbox as they will often come in handy.

Keeping It Clean

Writing clean code is more than an obsession with aesthetics or mindless principles. There are numerous papers on how having a consistent coding style will make programmers more productive. Just like a well-written novel, a clean code doesn’t require excessive cognitive power to read and understand, and it saves more of your human RAM for important coding decisions.

A clean and consistent code base will save other people and your future self time in reading, debugging and modifying. I’m not going to expand on how to write clean code, but I felt it was important enough to deserve a mention. Here are a few bullet points on keeping the code clean and consistent:

Code should be self-documented. The modules, the fields and methods, and even the variable names should make it obvious what they’re storing or doing.
Documentation. Not everything can be conveyed by writing self-documented code. Sometimes, adding a concise comment next to an inevitably complicated piece of code can help others understand it faster. In my opinion, external documentation should be saved for very specific cases like space shuttle or robotic surgery software. It’s often unnecessary for the rest.
Coding Style. This one tends to be ignored as a nuisance to sloppy programmers. The value of familiar style is mostly psychological, and it’s shown to result in more productivity. If your team doesn’t have a styling guide, just take one of the common ones and pitch it.
Consistency. Humans are more efficient on auto-pilot, and the most important factor in achieving that is consistency. Consistency can be maintained on many levels from styling to naming to larger design patterns.
Simplicity? Sometimes making a code more readable may go against keeping it simple. Again, it’s an art to find the right balance. Adding an interim variable to put a name on a value in the middle of calculation is justifiable. Adding a whole class to store that value is not.

Keeping It Simple and Clean (Part 1)

2015-06-28T00:00:00+00:00

When I started programming circa 2000 as a hobby, all I cared about was how cool my programs and games were. It was mostly about using whatever tools I had at my disposal to make them happen. Participating in programming contests later turned me into a sloppy programmer that would take clever shortcuts, and see every small problem as an opportunity to apply a complicated cocktail of data structures and algorithms that I’d learned at school. That was sometimes the only way to solve some of those problems, but nothing at school or those contests prepared me for the great lesson that I would learn in real-world programming.

“I didn’t have time to write a short letter, so I wrote a long one instead.” - Mark Twain

Writing simple letters is not easy. Writing simple programs is not easy either. I learned that taking pride in the ability to make complicated contraptions that accomplish a simple task is a sign of professional immaturity. I learned an engineer who can keep things as simple as possible is the real programming artist. No expression could articulate it any better than Antoine de Saint Exupéry’s if I’m allowed another quote from another great author: “It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away”.

This principle can almost perfectly translate to engineering. The KISS principle (“Keep It Simple, Stupid!”) is a great example of putting simplicity first. As a more software-engineering-centric example, Agile principle #10 states that “simplicity, the art of maximizing the amount of work not done, is essential”. One would ask what simplicity means in software, and how it could be achieved. Let’s see if we can find the answer.

Simplicity in software

There’s been extensive academic research, and many metrics were invented by academics and good-old general line managers to measure software productivity, complexity, and value. The general consensus is that software is too complex to be accurately quantified, but there are oversimplified metrics that can still tame some of that complexity. Lines of code is probably one of the first metrics that was used in the industry. It’s very easy to measure and it correlates well with complexity, but it’s not too difficult to make some condensed piece of software that no one can understand and cannot be legitimately considered simple.

Other metrics usually try to quantify software complexity in terms of branches, components, number of interfaces, or moving parts in general. As this is not an academic post, and I don’t have enough authority to analyze them, let’s just leave the nitty-gritty details to academics and admit that simplicity to the average developer Joe is more of an art than science. Maybe the hipster artisanal JavaScript programmer at your local Starbucks can get it right easier than the Ivy school PhD student after all.

How to achieve simplicity

You must have realized by now that there’s no silver bullet to achieve simplicity. There are however tools and patterns that make it easier for us to eradicate complexity in software, one wrong design decision at a time. I’ll enumerate some of the tricks, but it won’t be a comprehensive list by any means.

Understand the damned code first

Chances are you’re not creating everything from scratch. You’re working on something that a few other poor souls put together, and if you don’t want to be sticking more incongruous mud on the pile, you’ll need to understand a thing or two about the code base. This will first and foremost keep you from re-inventing the wheel; someone before you probably encountered a similar problem and spent time to fix it properly, so why not make use of that?

Another important measure, especially when fixing bugs, is to understand the root cause of the unwanted behaviour. If you don’t kill the bug where it lives, and just try to stick a band-aid on the symptoms, you’re picking an uphill battle with a bug that you don’t even fully know. In a well-designed code base, the root cause should ideally be in one place, so you’d need to address it in a single place instead of chasing it around and playing whack-a-mole with every symptom of the bug.

It always pays off to at least have a basic understanding of what every major component in code does. This helps you make proper use of them. Misusing or abusing other components will make the software more fragile, since other developers cannot always guess unorthodox application of their components and every change can potentially pull the rug from under your code.

Encapsulation

The integrity of systems is better protected if their boundaries are well defined. Logical components of software should also have their own boundaries. Encapsulation is facilitated and enforced in some object-oriented languages, but in general, some discipline will make it possible in every language. Classes, private fields and subroutines are examples of encapsulation tools that can be implemented in languages as wildly loose as JavaScript.

The best way to achieve encapsulation is to define modules, clearly define the boundaries, and separate the concerns of those modules. This is a very high-level recipe, and in practice, things can get sticky and impossible to separate. However, it should be obvious to software engineers, when deciding where to put anything, whether defining the boundaries will add any value or it’s turning into another anally-retentive obsession with how to store your possessions in one of the 100 drawers in the bedroom.

For part 2 click here!

How A Software Engineer Invests His Savings in Canada

2015-05-01T00:00:00+00:00

Obligatory legalese: this post is about my own personal finance in Canada, not general financial advice. There’s always risk in investments, and they’re done at your own risk.

Backstory

As I graduated from grad school and my paycheques started exceeding my expenses, I realized I have a new grown-up issue to deal with; not too bad for an issue! I wasn’t very comfortable with buying invisible assets that constantly fluctuated in price. When I cut through common human irrationality and realized saving my surplus income in a savings account is a sure-fire way to decay my assets, I started looking into buying shares in funds.

As a rather young software developer without much responsibility, I should be more risk seeking. As much as gambling with individual stocks is tempting, I decided against it; there’s a high risk there and high upkeep for staying current with financial news. Composite funds, with their broad range of risk profile from aggressive leveraged funds to those tied to non-Greece government bonds, provide a low-maintenance, low-risk investment vehicle.

What

Mutual funds are typically very convenient to buy. They’re usually offered in employees’ benefits for RRSP matching or automated withdrawals. The downside is that they take away a big chunk of your money every year. It’s common for them to rake in 2-3% of your savings, even in years when they lose 20-30% of it investing in volatile securities. Exchange-traded funds (ETFs), on the other hand, provide a much cheaper option (usually less than 1% management fee), have higher liquidity, and have been proven to be as effective as actively-managed funds. You’re basically betting on the whole civilization to stay in place, and slowly move forward as it has so far.

Canadian Couch Potato had a good model portfolio back then. I started putting my money in 3 ETFs: 40% trusting governments and companies to pay off their bonds (XBB.TO), 40% trusting the world is moving forward (XWD.TO), and 20% in betting that conservatives in Canada will make their social backwardness worth it (ZCN.TO). This portfolio has a very low management fee, and is traded in Toronto Stock Exchange, so no money is lost in exchange rates.

Where

I opened 3 accounts with Questrade: TFSA, RRSP, and a margin account that holds the rest. They don’t have well-lubricated processes, have subpar customer support, and won’t just stop spamming you, but they have something unique; it’s free to buy ETFs with them. The spread of buy and sell prices is very low, and they don’t have any hidden fees, so it makes dealing with them worth it.

As a sidenote, if you’re going to start saving with them, you can use their referral program to earn $25-250 in cash when opening a new account. They also gives the referrer a $25-50 bonus, so if you don’t know anyone with a Questrade account, feel free to use my QPass key: 486304026379159

How

The first thing I accomplished was to max out my TFSA account. TFSA is a great Canadian program that allows you to earn investment income tax-free. At this time, assuming annual 10% gain from the ETFs, Canadians can save up to ~$1000 a year in taxes. The growing limit of TFSAs and the magic of compound interest will make them a bigger deal in the future. After maxing out the TFSA, I started contributing to my margin and retirement accounts. You can use up to $25K of your RRSP in buying your first home, but anything beyond that is about how much you value your future self.

It’s important to keep your portfolio as balanced as possible (40-40-20 in my case). Selling ETFs on Questrade costs money ($5-10 per trade), so I avoid re-balancing the portfolio unless the gap is too large and new contributions can’t close it. I also try to move funds to TFSA as soon as the limit grows (usually January 2nd), and to RRSP once I decide how much I’m saving this year in my retirement account. This helps keep the taxes low, and sometimes helps with rebalancing. A spreadsheet is all I need to determine how to do the re-balancing.

What Else?

The housing market in Vancouver is overvalued according to unbiased experts. I don’t want to lock all of my past and future savings in a single asset that can dip in value at anytime. Buying a house also eliminates some of your options, and makes your unexpected expenses much more volatile. Real estate is therefore out of question, and that doesn’t leave anything else that can meet my criteria of low-effort, low-risk investment.

Good luck with your investments!

Faith-Free Mindfulness Meditation

2015-01-17T00:00:00+00:00

For a long time, I was dismissing suggestions to try out mindfulness meditation. It sounded like newly discovered eastern religion nonsense, advocated by the new age crowd or people desperately trying to fill the spiritual void in their lives. I didn’t care that they advertised relaxation as a side effect. Cutting through the mumbo jumbo to mine practical recipes for peace of mind didn’t seem worth it. Mindfulness remained an untouched realm of good-feeling insanity until frequent remarks on Hacker News made me discover Sam Harris’s new book.

Sam Harris has a reputation for fighting blind faith and irrationality. He’s also a renowned neuroscientist, which gives him all the authority to talk about faith-free mindfulness meditation. In his new book, Waking Up, he brings the attention of scientifically-minded folks to the baby of mindfulness in the bathwater of eastern religions. He’s extra careful to not make any irrational assumptions, and keeps apologizing for using conventionally-unscientific words like spirituality. Sam doesn’t make any claims about reducing our consciousness and sense of self to the physical world. He just invites us to experience meditation for ourselves.

Beside enjoying the read on human brain wonders such as split brain experiment, I was able to identify what Sam calls “the illusion of self” with my psychedelic-induced experiences back in the day. While on magic mushrooms for a few times, I witnessed the illusion of self; my ego, my sense of self, faded away and I was able to look at myself as a separate person. My psychedelic journey was -luckily- very positive, and I always suggest friends to carefully try it out at least once. I didn’t know psychedelics are a shortcut to the state of mindfulness. Wouldn’t it be great to get the same feeling of relaxation, general satisfaction in life and compassion toward others without taking the biological and legal risks?

The point of this post is not to describe what mindfulness is and how one should meditate to reach that state. There are a variety of resources on the subject, and if someone wants to start looking into them, it should be rather easy to get started. The marginal benefit that people get, even at the beginning of their quest, makes it easier to keep motivated and explore more. If you are as skeptical as I used to be, I hope this will convince you to give mindfulness the benefit of the doubt. I did and have been enjoying it so far.

Crawling/Scraping with Apache Nutch on AWS

2014-12-28T00:00:00+00:00

As I was waiting to start a new job in January, I took on a consulting gig to implement a scalable web crawling/scraping system for a company in Vancouver. My client insisted it has to be done using Apache Nutch, which is a great tool for high-scale scraping.

Even though Nutch is first and foremost a web search engine, its “fetcher” component remains a best-in-class web crawler. In fact, Lucene and Hadoop were originally two components of Nutch if this indicates anything about Nutch’s quality. The plugin-based architecture of Nutch allowed me to easily cherry pick crawling-related parts, and plug in custom indexers for my client.

Another reasonable requirement by my client was using Amazon Web Services (AWS) for running the crawler. Without that requirement, I would advise the same too. AWS Elastic MapReduce (EMR) makes it incredibly easy and cheap to start a Hadoop cluster, and it’s seamlessly integrated with other relevant AWS services such as S3. Using EMR is slightly more expensive than setting up your own Hadoop cluster on EC2, and there are a few quirks (e.g. you cannot use the cheaper generation of small and medium instance types), but the reduction in labour costs and general headache very well justifies it.

Nutch’s plugin system conveniently provides a few extension points, where you can hook up your plugins, and they’ll be called at the right stage with all the available information. I only needed to extend HtmlParseFilter to scrape data off of HTML files, and IndexingFilter and IndexWriter to store the extracted data on my client’s existing database. HtmlParseFilter provides the HTML file’s source, and in this case, regular expressions were powerful enough for me. If HTML parsing is required, the highly resilient TagSoup is shipped. You can even use the likes of Selenium to bypass scraper-deterring AJAX calls.

Once I finished writing and testing the plugins locally, it was time to deploy them on a Hadoop cluster. The process is seamless for the most part. There’s probably no software more native to Hadoop than its parent, Nutch. This Makefile is a good start for writing deployment scripts. However, it doesn’t readily work since the AWS command line interface has changed. Another obstacle in deployment was a flaw in Nutch, where your plugin binaries were not present on cluster slaves, so I had to extract and copy the JAR files to the shared filesystem (HDFS) as a bootstrap action.

After overcoming configuration hurdles, the first scraping adventure went really well. It took 10’s of hours on a cluster of 5 smaller slaves for a particular retailer’s website. Scraping is IO-bound in general and doesn’t need heavy-duty machines. Combine that with AWS spot instances and it ends up dirt cheap. I didn’t touch most of the default configurations, and it seemed the bottleneck was the built-in minimum wait for politeness to the target servers. Nutch’s crawl artifacts are also saved on HDFS and can be easily saved on S3 in Snappy format for later analysis.

As the last words, Nutch provides all conventional features for responsible crawling/scraping; from robots.txt compliance, to custom user agent, to minimum delay between calls. Have fun!

Iceland Trip

2014-08-03T00:00:00+00:00

Last month, I had a 11-day trip to Iceland, and spent most of it taking a road trip around the country. A few unprocessed pictures taken by my phone don’t quite capture how amazing my experience was. This slideshow is my attempt at sharing some of it nevertheless.

Reykjavík from above. Colourful rooftops seems to be a distinctive feature of Icelandic buildings.

Þingvellir, where North American and Eurasian plates visibly part, and where the first Icelandic parliament was formed in 930.

Geysir. Geysers are named after this, but it's currently dormant.

Strokkur, Geysir's little sister that squirts boiling water up to 20-30 meters every few minutes. Tourists are solemnly awaiting the next squirt, while the gusting wind makes a creepy noise.

Gullfoss; the gold waterfall. Majestic, isn't it?

Dried fish [bones] to be sold to the developing countries.

The wind on the Southern side of Iceland was exceptionally fast, as you can see. It was categorized as class 7, where class 10 is a full-blown hurricane.

A remote shot from Eyjafjallajökull, whose eruption cancelled many European flights in 2010.

A black sand beach.

Dyrhólaey. I was hoping to see some puffins on the cliff, but they were all gone.

One of interesting tourist attractions seems to be created by tourists. I'm guessing hitch-hiking hippies.

This comfortable bed took a river of lava to flow on the field, centuries for it to cool down, and decades for the moss to grow on them.

An Icelandic turf church. The turf provided great insulation when the technology hadn't caught up with the harsh climate.

A glacier hike on one of many "tongues" of Vatnajökull glacier; Europe's largest glacier. The occasional thunder-like sound was an indicator of the glacier moving 5-50 cm every day.

Drifting ice bits on the shore.

A lagoon formed by the melting glacier. The icebergs are usually very huge, and what you see is literally the tip of the iceberg.

Hiking at Hvannagil. The loose, flat rocks make it fun to descend gliding.

The valley was full of cascading falls.

Seyðisfjörður. A beautiful city on the East Fjords, protected by avalanche obstacles.

A remote view of Seyðisfjörður, with the all-too-common farm sheep on the loose. The winding road to the city was featured in "The Secret Life of Walter Mitty".

Dettifoss, view from the East side.

A pond at Ásbyrgi, a horseshoe-shaped depression. Sigur Rós performed one of their free concerts in this area.

Honeycomb rock formation.

kirkja or church. A cave formed by honeycomb-shaped lava rocks.

A mud pit with boiling water. The yellow colour around the pit is caused by sulphur sediments.

Getting a kick out of hydrogen sulfide, a gas smelling like something between rotten eggs and flatulence.

Mývatn nature baths. The naturally-hot torquise water coming from a geothermal power plant makes for a relaxing swim at around midnight.

A dormant volcano crater.

A natural hot water bath in a rift. An earthquake decades ago strangely made the water too hot for bathing.

Mývatn lake, a definite attraction to bird watchers and biodiversity researchers.

Can't get enough of waterfalls!

Interesting rock formation, and yes, a waterfall in the background!

A view from Akureyri, the capital of North Iceland. It lies on the shores of Eyjafjörður, the largest fjord in Iceland.

A church.

Inside the Harpa concert hall.

Sunset in Reykjavík just before midnight.

An example of failed legislation: Iceland's laggard lift of prohibition in 1989 was followed by banning all advertisement or bar signs mentioning any "strong" beer. Businesses conveniently advertise their "light" beer as a result.

Slideshow plugin by Pixedelic.

If you liked this, you may also like my Chilkoot Trail post.

Toastmasters for Engineers

2014-05-21T00:00:00+00:00

About a year ago this time, I joined a Toastmasters club, and today, I had my 9^th prepared speech out of the 10 you need for your first title (i.e. Competent Communicator). Toastmasters is a huge network of self-organizing clubs that help members improve their communication and leadership skills.

I realize that different Toastmasters clubs could have slightly different rules and different cultures, so your mileage may vary. However, the cult-like general guidelines of this huge non-profit organization ensure your experience will not be that club-specific.

If you’re the quintessential engineer with limited communication and soft skills like myself, I’d recommend giving it a shot. Each club has a specific schedule for its meetings, and each meeting may contain a few prepared speeches, impromptu talks, evaluations, and other supporting summaries (e.g. grammar usage summary). Almost every role in each meeting will get an evaluation at the end. There are one-off contests once in a while too.

Every club member will be working on two tracks in parallel; communication and leadership. I personally put more focus on my communication track, which at the beginner’s level, consists of presenting 10 prepared speeches for the audience. Each speech has specific objectives, and as you progress, they become more advanced. For instance, they start from merely not using notes to watching for your body language and vocal variety.

The leadership track was never very attractive to me. The tasks in that track are obviously designed to help organize the club without any control from Toastmasters itself. Most of the administration is done by volunteers, and the contribution is gamified by awarding leadership badges and honours to those who donate their time. Even though it might have some educational value in leadership, I don’t think you can get anything more out of it than you do at your work.

Even though Toastmasters seems to be mostly about public speaking, it teaches engineers valuable lessons in soft skills. It helps with your speaking and, to some extent, writing skills. However, the two invaluable skills are coming from the general audience and the evaluation parts. The general audience makes you pick subjects that anyone can understand and is intereted in, and the limited speech time (around 5-7 minutes) forces you to make it concise. It also teaches you how to be tactful and diplomatic in your evaluations, and still get your points across. They specifically encourage using the “[shit] sandwich technique”, where you enclose the rough parts of your feedback with pleasant fluff.

As usual, the time and effort spent on Toastmasters has diminishing returns. I feel like the optimal point of retiring for me would be after the first communication manual, but of course, your experience may be different. It’s taken about one hour of my time every week, and a couple of hours for each speech. The membership fee is very little compared to your time and its value. You can always attend their meetings as a guest and decide for yourself if it’s your cup of tea.

Competitive Strategy Online Course

2014-04-11T00:00:00+00:00

Massive open online courses (MOOCs) are a revolutionary way to bring education to the masses, and make the collective human knowledge accessible. You might have heard of Coursera, which is a great for-profit MOOC provider, whose courses have been offered for free so far. They charge for certain certificate courses, but if you just like to listen to video lectures or read the notes, it’s only for the price of your time.

I’ve been taking courses from Coursera for a while. The level of engagement is up to you. You can be as involved as a real student actually taking the course, attend study groups on the side, take the exams, and submit the assignments and project. You can also just skim the scripts, and (just like me) watch the video lectures as a passive way of consuming information. They have a broad catalog of courses from top universities around the world, so you’ll definitely find something that interests you.

A few days ago, I came across Competitive Strategy on Coursera. Tobias Kretschmer from a top German university is the instructor of this course, and judging by the first module of the course (out of six), he knows how to keep the audience interested and entertained. The course tries to use a few game-theoretic tools to analyze different strategies businesses can use to their advantage. As someone with a general interest in microeconomics or marketing, I quickly fell in love with it.

The first module introduced a few basic concepts from game theory, so if you already know about them, it may sound a bit boring. However, I’m looking forward to the upcoming modules to see how those abstract tools are employed in business strategy and marketing. If it piqued your interest, feel free to join; it’s free and open to new students at any time.

Is Adblocking Unethical?

2014-04-05T00:00:00+00:00

I came across an admittedly biased interview on CNET, where an executive VP of the Interactive Advertising Bureau (an online advertising industry advocacy group) was resorting to vitriolic ranting and name-calling against adblockers. It showed how adblockers are leaving a dent in their industry. It didn’t however argue why affecting their bottomline is unethical, and merely used the straw man of the collapse of the internet if the disruption continues.

I am personally an adblock user. That’s one of the first things I do when I set up a new machine; install Adblock and Ghostery. I usually whitelist the community-generated content providers that I frequent, and know won’t survive without the ads. It just feels right; just like when I tip my waiters as I know they’ll have difficulty without tips in the status quo. Am I robbing other websites of the attention to the ads they feel entitled to? Is it ethical?

We can look at this dilemma from two different angles; whether or not users are stealing money from the individual websites, and if adblocking is good for the internet as a whole. I disagree that refusing to look at adverts equals stealing. Embedding ads next to the actual content implies that by consuming the content, you are helping the provider make profit. Let me use an analogy.

The hat next to a street musician has a very similar implication; please pay if you enjoyed. You never feel obligated to spare change to anyone though (you might be guilt-tripped into it, but never forced). Some people like to help out the talented ones, and simply make them happy since the performance made them happy, but most don’t. If someone forced you to pay up during a street performance, blocked your view, or disrupted your experience otherwise, wouldn’t you be annoyed and just walk away? I skip talking about the creepy trackers.

The obligation to pay for publicly available art or entertainment has never been easy to formulate. It’s usually more about the consumers’ willing to pay than the providers’ enforcement. Sometimes, the publishers have had the technological means to force-fed ads to consumers in a very aggresive way (e.g. cable TV adverts), but it’s now the consumers that have the technological capability to strip the content of intrusive ads and trackers. If producers can’t earn enough money through intrusive advertising, they should find another way to monetize their content or spend their time and effort on something more lucrative. Sorry; the landscape is shifting and so should your business model.

Isn’t it bad though? Doesn’t it make the pie smaller for everyone? Maybe. CNET’s interview didn’t provide much relevant data, and it’s outside the scope of this blog to quantitatively analyze the market anyway. What I can predict is that if the advertising industry doesn’t find ways to make ads less intrusive and more interesting, and doesn’t dissuade people from actively blocking them, they will have a hard time. They may get into an arms race with adblockers, but that’s never a good idea for them. They may regulate or even criminalize adblocking (see piracy laws), but the current economy is not stable and is certainly going to change.

When advertising is not a viable business model any more, site owners may start putting their content behind paywalls, or come up with smarter monetization strategies. It means that the publicly available content may have lower quality, or websites will simply go out of business. You need to be either a hobbyist or a large corporation to be sustainable in the new economic balance. We may need to pay for good content like good old days of newspapers, or struggle to find them among too much noise. It’s going to be uncomfortable to go back there, but without appropriate planing of the industry, it seems inevitable.

There have been proposals like this to find a middle ground for acceptable advertising. The demise of the ads-for-content economy can be prevented if producers and consumers can come up with and agree on standards of what will be tolerated. Until that day, I believe the consumers’ revolt against online advertising is only a reaction to the their creepy, aggressive, and intrusive methods, and certainly not unethical. I’m afraid democratization of content creation and consumption might force businesses to actually listen to the consumers after all!

Packt, MongoDB, and Pentaho

2014-04-01T00:00:00+00:00

Last year, when I received an email asking me to review a book about MongoDB and Pentaho for free, I barely opened the email before marking it as spam; “an outsourcing shop looking for desperate freelance editors? No, thanks!” I’d never heard of Packt Publishing before, and they were asking me to donate my time for a commercial project!

I’d used MongoDB in Pentaho before, and knew it was a “NoSQL” implant to the relational database world of Pentaho. It piqued my interest however; I wanted to see how someone can write a whole book about a relationship that was still in its infancy, and (at least back when I used it) hardly had any real utility beside the basic operations. I was also curious about the process of writing, editing, and publishing an ebook, so I just bit the bullet; “I’m in!”

Overall, I probably spent 15 to 20 hours to read the 100 something pages of the book, and didn’t get to communicate directly with the author. I only exchanged emails with the coordinators in India. The book was surprisingly well written, and it covered every possible aspect of using MongoDB in Pentaho. At the end, I received a physical copy of the book as a token of appreciation, and was able to download one of their ebooks for free. It wasn’t all for nothing after all!

If you’re interested in the subject, and are immune to people’s advice against using MongoDB, I’d recommend having a look at the book (obviously without any monetary benefit to me). Otherwise, there are a lot of books and tutorials about the great open-source BI suite that is Pentaho, and many other choices of reliable NoSQL databases other than MongoDB. ElasticSearch seems to be an emergent contender in that space.

Hello World

2014-03-30T00:00:00+00:00

After hosting a single-page site/resume on Nearly Free Speech for a while, I decided to shop around for a more reliable host so I can start blogging. I don’t have a plan to write often, but this will be a platform to share ideas once in a while.

After looking around, Github Pages seemed to be one of the best options out there for a couple of reasons:

It is free
You can use Jekyll natively

The only catch is it’s only free if you use a public Github repository, and if you are a secretive type that may change your notes often or hide them, one can easily go through your commit history and find about your juicy secrets! Now I couldn’t care less about that aspect, so what you see here is currently hosted on a public repository.

As for Jekyll’s boilerplate and themes, I find Jekyll Bootstrap to be very helpful to set up a Jekyll site. I had to massage it a little bit, and add a paginated blog page, but it was straightforward overall. Of course, you can have a look at the source code here.

Suggestions are welcome. Please feel free to email them, until I decide whether or not it’s a good idea to use third-party commenting engines (e.g. Disqus).