The eli4d Gazette – Issue 059: An Excellent Collection of Great Speeches & Neat Interview Question Site

An Excellent Collection of Great Speeches

I’ve been following James Clear‘s newsletter for a while. He has a ton of great content about habits, decisions, and living. In one of his emails, he mentioned that he’s been collecting some great speeches and having them transcribed.

These are really great speeches and may be worth your time:

30 Seconds of Interview (Questions and Answers)

I came across this neat interview questions site through a Syntax episode. It currently covers HTML, CSS, and JavaScript but it can easily be expanded.

You can find the actual site here:

Here is the source repository for the site:

Let me know if you have some interview question prep sites that you like.

Thoughts? Feedback? Let me know: @eli4d on Twitter

The eli4d Gazette – Issue 058: Git Flow Branching Model and Fatherhood & Side Projects

The Git Flow Branching Model

I’ve been working on a side project where I’m close to placing it in “production” (though it feels like it’s taking forever). I’ve been using Git and Bitbucket to save different project phases (I found a great explanation of Git and Github at

I wanted to follow a decent Git branching strategy, so I carefully reread Vincent Driessen‘s original 2010 article about it.

There have been many different implementations of the”Git Flow” approach. I prefer to use Git directly than using an abstraction layer on top of Git so that I can better understand what’s going on. I looked around, and Driessen’s article still stands as the most unambiguous step-by-step approach.

Fatherhood and Side Projects

I came across an interesting Hacker News thread that discusses the issues around programmatic side projects and fatherhood. Note that the actual project that is the origin for this post is not as important as the back and forth questions and responses.

My progress on a programmatic side project has been glacial (as mentioned above). For me, it’s more about accepting this and letting go of the “I should have been done with it six months ago” and being mindful of the present.

Thoughts? Feedback? Let me know: @eli4d on Twitter

The eli4d Gazette – Issue 057: Cool HTML/CSS/JS Tiny Editor and a Tiny Bite of Fan Fiction

Holy Cow – A 400 Byte Tiny HTML/CSS/JS Editor Demo

I came across this on a Hacker News thread. It’s an amazingly tiny HTML/CSS/JS editor. You can find the code on GitHub, but here’s the whole code that you can place in the browser URL (per usual disclaimer – don’t put this in your browser if you’re not comfortable with the code):

data:text/html,<body oninput="i.srcdoc=h.value+'<style>'+c.value+'</style>'+j.value+''"><style>textarea,iframe{width:100%;height:50%}body{margin:0}textarea{width:33.33%;font-size:18}</style><textarea placeholder=HTML id=h></textarea><textarea placeholder=CSS id=c></textarea><textarea placeholder=JS id=j></textarea><iframe id=i>

Fan Fiction

I never realized that there was a huge sub-culture around Fan Fiction. Episode 98 of the Imaginary Worlds podcast dives deeply into this world with Francesca Coppa.

The conversation around the evolution of fanfic in conjunction with the creation of is fascinating.

Thoughts? Feedback? Let me know: @eli4d on Twitter

An Open Letter to Vultr Regarding their Dishonest $2.50 Pricing Plan

Dear Vultr,

I’m writing to you to express my disappointment with your dishonest $2.50 pricing plan. I hope that you will take the steps to fix this problem.

I’ve written this letter in segments to hopefully clarify the sequence of events and how I came across this issue.

It began with a side project on Laravel

This all started with a podcast related side project that uses Laravel. I’ve been slowly plodding along on this scratch-my-own-itch project, and I’ve reached the stage of deployment and usage of an actual domain (whohoo). At this point, I decided to use Laravel Forge for the deployment of my project. My reasons for using Laravel Forge were:

  1. Support Laravel’s fantastic creator – Taylor Otwell
  2. Learn how to use a GUI based provisioning/deployment tool

It begins with a side project on Laravel

When I logged into Laravel Forge…

When I logged into Laravel Forge, I saw that I had quite a bit of choice for a Virtual Private Server (VPS) service. I’ve known about Digital Ocean, Linode, and AWS for quite a long time but I didn’t know about your offerings.

When I logged into Laravel Forge...

Which VPS service to use?

As I’ve mentioned – this is a hobby project, so I looked at some price comparisons looking for the least expensive plan.

If it’s a hobby project do I want to spend sixty dollars per year (i.e. $5 x 12 months ) or thirty dollars per year (\$2.50 x 12 months)...tough choice.

Which VPS service to use?

So I chose you Vultr….

Naturally I gravitated towards your service 💸 due the $2.50/month ($30/year) plan. It seemed perfect for my hobby project.

I didn’t need much performance, just some way to release my project to the world.

So I choose you Vultr....

So I went ahead and created an account on Vultr…

So I created an account on your service and purchased $10’s worth of time. After all, four months would be a great trial of my project. At this point, everything was very smooth – nice on-boarding, rapid capture of credit card. All systems were GO…or so they seemed.

Then I went to Laravel Forge and configured Vultr as a VPS option

I configured Vultr as a VPS option on Laravel Forge noticing that the Server Size was set to $5.

Then I went to Laravel Forge and configured Vultr as a VPS option

It was time to choose the $2.50 server size on Vultr from Forge’s options

So I went to the “Server Size” dropdown to choose the $2.50 option and lo and behold – there was no such option. This was strange…was there something wrong with Laravel Forge?

It was time to choose the $2.50 server size on Vultr from Forge's options

So I emailed Taylor…

So I emailed Taylor Otwell about the missing Vultr pricing tier, and within 5 minutes I received the following email response.

So I emailed Taylor...


My first thought was “wait…that doesn’t make any sense – Vultr’s pricing page shows no distinction between the $2.50 plan and any other plan besides performance – what did I miss?” So I went back and looked at your pricing page and indeed there was no mention whatsoever that API access was excluded for the $2.50 plan.

If you look at the screenshot of your pricing plans – do you see a difference besides benchmarks?


I decided to contact your support…

So I contacted your support (whose response was very fast…so good job on that), and I got a response from a friendly support person – Sean Mahoney (see below).

Nowhere on your pricing page do you indicate that the $2.50 plan is a “sandbox plan that is not available via API.”

I also didn’t feel that reassured seeing that one day you “may decide” to make this plan like every other plan and have API access.

When you look at Sean’s response and your representation of the $2.50 plan on your web page – doesn’t that strike you as being a bit dishonest? (no reflection of Sean of course – he was just doing his job in responding to the ticket)

So I decided to contact your support...

If I’m going to go with a $5 plan – why would I choose Vultr as my VPS provider?

If I’m forced to go with the $5 plan, then why would I go with your company and not a more established company like AWS, Digital Ocean or Linode? Additionally, if you go for the bait-and-switch approach on the $2.50 plan – what other surprises can I expect if I continue being your customer? For me, as a customer, this issue engenders a significant sense of distrust.

It saddens and disappoints me to have to stop using any services from your company. On the other hand, if the API usage issue was available with the $2.50 plan, then how likely would I stick with Vultr? I might have become a loyal customer singing your praises.

I don’t like to leave an open letter at this spot without providing some suggestions for improvement. So here goes.

If I'm going to go with a $5 plan - why would I go with Vultr?

Suggestion 1: The Band-Aid Approach – be honest and upfront about the “we don’t provide API access for the $2.50 plan”

My first suggestion to your company would be to update your pricing page to clearly indicate that the $2.50/mo plan does not include API access. I’ve mocked up a sample message below.

Suggestion 1: The Band-Aid Approach - be honest and upfront about the "we don't provide API access for the $2.50 plan"

Suggestion 2: The “all pricing plans have API access” removing the dishonest approach of the $2.50 plan

This one is simple, and it’s based on a message of consistency. Simply offer API access like you have on every other plan, so the $2.50 plan is different only in terms of storage/bandwidth/etc.. This approach does not require any UI changes on your pricing page. It’s the simplest and most honest approach. I would suggest this one over the first suggestion.

In conclusion…

In conclusion, I think that your current $2.50 plan is a bit of a sham. I would hope that you would take suggestion two and go for the honest approach. I’d appreciate a response regarding this issue.

Thank you for your time.



PS: I’m more than happy to update this post with a response from you regarding this issue.

The eli4d Gazette – Issue 056: Python’s former BDFL and the Apollo 11 Moon Landing

Python’s former BDFL

Human languages take millennia to develop, whereas programming languages can take less than a month for initial design. Human languages are evolutionary, and programming languages take on the preferences, principles, and beliefs of their designer.

If the programming language is successful in terms of adoption and usage, then the language moves from its (initial) one person design to evolution that is based on the opinions and preferences of many people in conjunction with the emergence of current trends and fads (including competing languages).

Many times, the language designer is throned as its BDFL – benevolent dictator for life. He or she gets to have final say on the evolution of the language…until they have enough.

Python was created by Guido Van Rossum in 1991. It’s been evolving for 27 years with Guido as its BDFL until last week.

Twenty-seven years is a very long time for a programming language to both survive and thrive. It’s also a long time to wrestle and dispute the various proposals for Python’s evolution.

Apollo 11 Old Style Re-broadcast

On a lighter note, I came across this charming page about the Apollo 11 moon landing (mentioned in a recent Studio Neat issue). While the date/time re-broadcast is over, you can see the Apollo 11 landing through some links to YouTube.

Thoughts? Feedback? Let me know: @eli4d on Twitter

The eli4d Gazette – Issue 055: The English Olympic Rowing Team Question and Book Inspiration

The English Olympic Rowing Team Question

I heard an interesting question on the Release Notes podcast (episode 268). The conversation was about the purpose and best use of mastermind groups (Ken Wallace did a great job in clarifying the answer).

Ken brings up the story of the English rowing team and how they end up winning the gold medal by singularly focusing on the question: “will this make the boat go faster?”. There’s a great YouTube video discussing this as well as a book.

I like the physicality of the question and how it is a concrete implementation of the “what’s the next physical/visible action?” question from the Getting Things Done methodology. The key point is that for whatever goal you’re pursuing, you need to constantly ask the question if what you’re doing right now is getting you closer (or further) from your goal.

Book Inspiration

Studio Neat’s newsletter had a reference to a musical map site. From this site, I found a literature map site – The way it works is that you enter an author that you like, and then you get a map of other writers whose writing is similar (in terms of distance on map). You can then click on any author on the generated map and see a new map with other related connections.

For example, I’m a big fan of Ryk Brown and his Frontier’s Series. Here’s his map: Ryk Brown map

Thoughts? Feedback? Let me know: @eli4d on Twitter

The eli4d Gazette – Issue 054: Dependency and Package Managers in Python and PHP

Python Environment and Package Installation

I saw a recent XKCD comic that describes the current state of setting up a Python development environment:

Python Environment

The excellent Explain XKCD site covers the point of the cartoon. The issue is the (ongoing) difficult transition from Python 2.x to Python 3.x and the reality that there is no defacto package installation tool. The messiness of Python’s development environment deeply contrasts with the cleanliness and beauty of the actual language.

One interesting and significant effort in approaching the above issue can be found through the PyPi package manager. A great FLOSS Weekly episode had an interview with one of the maintainers of the new PyPi covering its pros and cons.

PHP’s Composer and Package System

In the PHP world – Packgist site is the definite destination for third-party PHP packages. In conjunction with these packages, Composer is the defacto package/dependency management tool. It’s more than a package manager because it focuses on managing packages on a per project basis.

At its core Composer focuses on dependency management and the secondary result is that it also does package management. One problem that arises is the usage of Composer as a pure package installer across a system rather than just a project. As Composer’s documentation states:

By default it does not install anything globally. Thus, it is a dependency manager. however support a “global” project for convenience via the global command.

Composer’s “global” command installs packages in a common central project and this, in turn, can cause major headaches with projects that have packages installed in different locations.

Pantheon’s blog describes this issue (and its solution) really well:

One of the most commonly documented ways for a PHP command line tool to be installed is via the composer global require command. This command is easy to document and easy to run, which explains its popularity. Unfortunately, this convenient function has a darker side that can cause some pretty big problems. The root of the problem is that Composer, by design, manages dependencies on a per-project basis; however, the global command installs everything into a common central project. The upshot of this is that two distinct projects that were never intended to be combined must suddenly share dependencies. In this configuration, it is all-too-common to encounter dependency conflicts that never would have been observed had these applications been installed independently.

The current solution to this is a Pantheon created tool called Cgr. The blog article provides details on its usage and when to use Composer global.

Note: many thanks to the folks on the Poststatus Slack for discussing Composer’s issues and pointing to Cgr.