The eli4d Gazette – Issue 062: Fun Data Sets and Falling for Fake News

Interesting Data Sets

With the upcoming elections, there are lots of articles spouting lots of data. These are some interesting data sets that can be used with something like Python’s Pandas library and various visualization libraries like Plotly and D3.

Falling for Fake News

I came across a really interesting Washington Post article about fake news. The article talks about our human tendency to fall for fake news. While the article traces the origin of a fake video on Facebook, the larger point is how easily we all can fall for fake news/photos/videos. The problem is that we are not very good at telling fake media from real media, while the technology to produce fake information has significantly increased in sophistication and ease of use. This particular paragraph from the article is quite telling:

Even after decades of Photoshop and CG films, most of us are still not very good about challenging the authenticity of images — or telling the real from the fake. That includes me: In an online test made by software maker Autodesk called Fake or Foto, I correctly identified the authenticity of just 22 percent of their images. (You can test yourself here.)

I took the Autodesk fake photo test, and I also got 22 percent of the images correct. I’m stunned by this – I got one out of every four pictures correctly. How does this apply to read articles and posts on the web (not just Facebook but all other sources of information on the web)?

I’ve been struggling to figure out how to deal with this. With the upcoming U.S. midterm elections on November 6th, I wonder about this even more. The only thing I can come up with is the Russian proverb “Trust but verify”. If I want to trust a particularly new story, then I am obligated to verify its authenticity by checking other news sources such as actual newspaper sites with differing viewpoints (right, left, and middle). The obligation is on me to put the effort and investigate a news item that on first glance seems super-compelling and utterly true. In fact, the truer a news item feels, the more suspicious I need to become and the more verification it requires.

Yellow journalism is nothing new, but the rapid application of technology to make the news seem authentic is the biggest difference from the past.

Currently Reading

“The Second Ship (The Rho Agenda Book 1)”: I got this Richard Phillips recommendation from Steve Gibson’s science fiction reading guide (see the top link on https://www.grc.com/linkfarm.htm). It initially felt a little bit too YA, but then it took off like a rocket. It’s fun well-written scifi. A fun sentence from the book:

Fresh snow was fun and could sometimes get you an extra day off. Old snow made you feel as gray and dirty as it was.


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


The eli4d Gazette – Issue 061: The Best Password Generators in the Galaxy and Text Web Pages

Password Generators

For the weekly Zoom check-ins for my online Python class I’ve had to put passwords on the videos, and I found the best password generator in the universe (ok so I’m exaggerating):

https://www.dinopass.com/

Obviously, this is for lower security passwords, but they’re really fun. How can you go wrong with bluehen44, firstfork77, or sadland33? If you have kids, you might as well train them on some good password hygiene using this site.

The same site has stronger passwords if you click the “Another Strong password, please” button. But if you want a super strong random password, then you need to use GRC’s Perfect Passwords generator. Needless to say, you will need to use a password manager to remember these (1Password is my current favorite though DashLane is a close second).

Text Web Pages for People with Limited Bandwidth and Power

I came across an interesting article about how some news organization are providing text versions of their sites for people with limited bandwidth and power (like those folks in hurricanes). Removing JavaScript for this sort of use makes complete sense, and it also provides a good reminder about stepping back and thinking about the audience that is using your site.

Note: I think that NPR’s URL is great because it is easy to remember. It is another way that NPR makes it easy to not rely on other services to go to NPR’s text version of their site.


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


The eli4d Gazette – Issue 060: LinkedIn’s Site Reliability Engineering Group’s approach to Python CLI based Utilities through PEX and Shiv

I recently came across a neat article in LinkedIn’s blog. It was written by their Site Reliability Engineering group (SRE) which covered some interesting Command Line Interface (i.e., CLI) utility libraries related to Python.

I can see how the power of Python would be fantastic for CLI utilities. The problem is Python’s dependency management. The dependency issue is even more compounded for CLI utilities since a devops engineer would need to be able to bring over a utility to any server (assuming a consistent version of the operating system) without worrying about the utility’s dependencies. Such an issue would prevent a system admin from doing the needed work (whether emergency or planned). In SRE’s article they explain this eloquently:

At LinkedIn, we ship hundreds of command-line utilities to every machine in our data centers and to all of our employees’ workstations. The vast majority of these utilities are written in Python.

In addition to developing these command-line utilities, we have hundreds of supporting libraries that are constantly being iterated on, with new versions published daily. Because of the inherent problems present when dealing with such a huge and ever-changing dependency graph, we need to package the executables individually to avoid dependency conflicts. Initially, we took advantage of the great open source tool PEX. PEX elegantly solved the isolated packaging requirement we had by including all of a tool’s dependencies inside a single binary file that we could then distribute.

PEX was not sufficient for SRE’s usage, so they created their own dependency packager called shiv. It’s an interesting name choice. I initially thought it was a prison-made knife, but apparently the name was based on the word “shiver” although the documentation has a knife emoji. In their words:

Why shiv?

>The tool freezes a Python environment, so you can think of shiv as a shorter way of saying “shiver.”

PEX and Shiv are interesting utilities that bring the power of Python to the command line through one executable utility.


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


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: https://jamesclear.com/great-speeches

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: https://30secondsofinterviews.org/

Here is the source repository for the site: https://github.com/fejes713/30-seconds-of-interviews

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 https://blog.red-badger.com/blog/2016/11/29/gitgithub-in-plain-english).

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 https://archiveofourown.org/ 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...

Wait…what?

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?

Wait...what?

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.

Sincerely,

Eli

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