There’s a few very good reasons why we may want to build PHP’s curl module using OpenSSL and not Apple’s Secure Transport, such as needing to use PEM format client certificates or wanting to use HTTP/2, for example.

Up until March 2018, this was pretty straightforward to do: you would brew install curl --with-openssl and brew install php72 --with-homebrew-curl and that was it. Slightly inconvenient, but easy. 👍

In their quest to “improve” things by rendering inconvenient but easy things into the downright impossible, the Homebrew maintainers moved the PHP formula from the homebrew-php tap to the homebrew-core tap.

“Sounds harmless,” you might think? Sure, except they didn’t simply move the formula as-is. They changed it in significant ways, including removing the ability to control how PHP’s modules are built. 😡 This means you no longer have the ability to control whether PHP’s curl module is built against the system-provided libcurl library which uses Apple’s Secure Transport, or Homebrew’s libcurl library built against OpenSSL, depending on your preference or needs.

This effectively prevented me from being able to upgrade to a newer PHP using Homebrew’s PHP formula. 😢

Checking StackOverflow, I’m apparently not alone. Since I had a personal need to get PHP 7 installed using this new version of the Homebrew PHP formula on my dev environment, I needed to solve this problem for myself.

Good news: I have a working solution. Let me tell you the story of my people …

I’ve modified the php.rb formula to build PHP against the Homebrew-installed libcurl which you’ll still need to install with brew install curl --with-openssl after installing Homebrew’s OpenSSL with brew install openssl.

build against homebrew curl, openssl · dossy/homebrew-core@b75fe28

To apply it, do this:

$ cd /usr/local/Homebrew/Library/Taps/homebrew/homebrew-core
$ curl -s https://github.com/dossy/homebrew-core/commit/b75fe286f79e2b89548c5ed1bbe1958313c5c103.patch | patch -p1

Depending on what changes the Homebrew folks make to the php.rb formula between now and when you go to apply this change, it may or may not apply cleanly. I may update the patch periodically, if my change doesn’t make it into the upstream official repository.

Updated 2018–11–07: I’ve created an updated patch against Homebrew’s current php.rb which is for PHP 7.2.11. Use this instead:

$ curl -s https://github.com/dossy/homebrew-core/commit/d0681b61.patch | patch -p1

Once you’ve applied the patch, you’ll need to force an install from source rather than using the precompiled “bottled” binary:

$ brew install php --build-from-source

Depending on your system, this could take a while. But, it should work. When it’s done, you can confirm whether it’s using the correct libcurl and openssl with this command:

$ /usr/local/bin/php -r "var_dump(phpversion(), curl_version()['ssl_version']);"
string(5) "7.2.6"
string(14) "OpenSSL/1.0.2o"

If it didn’t work, instead of OpenSSL/X.Y.Zn you’ll see SecureTransport or LibreSSL. If that happens, something went wrong. Crying at this point wouldn’t be inappropriate nor a terrible idea. Once you’ve regained your composure, double-check your work and if you still can’t get it to work, let me know and maybe I can help you.

For those of you who experienced success, congratulations! I hope this was helpful and saves you a bunch of time and aggravation. I know I sure would have appreciated it …

Installing PHP 7.2 using Homebrew on OSX using OpenSSL and not Apple's Secure Transport was originally published in This Old Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

First, let’s start with a quick quiz. Given the following SQL and pseudocode, how many rows do you expect will be affected?

/* Using MySQL 5.6.23 */

CREATE TABLE t (
    x VARCHAR(32),
    y INT
);

INSERT INTO t (x, y)
VALUES ('a', 1), ('b', 2), ('c', 3);

$value = 'b';

$statement = $db->prepare('UPDATE t SET y = 123 WHERE x = :value')
$statement->bind(':value', $value)
$statement->execute()

If you answered 1, then congratulations: you’re right. Easy, right?

So, what’s the issue with using boolean values?

Using the same SQL, but with this slight change in the pseudocode, how many rows do you expect will be affected?

$value = false;

$statement = $db->prepare('UPDATE t SET y = 123 WHERE x = :value')
$statement->bind(':value', $value)
$statement->execute()

If you answered 0, then you, like me, are wrong.

“But, no row in the table has a value for x that equals false, so how can this be,” you ask?

Here is where you, and I, learn how wrong we are.

The answer is: type coercion (aka “implicit type conversion”).

More specifically, it has to do with MySQL’s BOOLEAN type, and how it’s implemented:

BOOL, BOOLEAN

These types are synonyms for TINYINT(1). A value of zero is considered false. Nonzero values are considered true:

Are you thoroughly confused now? Good, you should be. That was a mouthful of gibberish.

While the documentation is perfectly clear and succinctly explains the situation, it might be non-obvious as to why we observed what we saw.

(Oh, and don’t get me started about how “gibberish” is spelled wrong based on how it’s commonly pronounced: it should be spelled “jibberish.” But, anyway…)

Under the hood, MySQL implements BOOLEAN types as TINYINT(1) values, and more specifically, where TRUE is 1 and FALSE is 0. Okay, fine, but still, no value of x in our table was equal to 0 … or, were they? 😈

This is where type coercion comes into play: when comparing a string, in this case, our x which is defined as VARCHAR(32), with a BOOLEAN value, in other words, a TINYINT(1) value of 0, exactly what happens? Let’s see:

mysql> SELECT CAST('a' AS UNSIGNED) AS a,
              CAST('b' AS UNSIGNED) AS b,
              CAST('c' AS UNSIGNED) AS c;
+---+---+---+
| a | b | c |
+---+---+---+
| 0 | 0 | 0 |
+---+---+---+
1 row in set, 3 warnings (0.04 sec)

mysql> show warnings;
+---------+------+----------------------------------------+
| Level   | Code | Message                                |
+---------+------+----------------------------------------+
| Warning | 1292 | Truncated incorrect INTEGER value: 'a' |
| Warning | 1292 | Truncated incorrect INTEGER value: 'b' |
| Warning | 1292 | Truncated incorrect INTEGER value: 'c' |
+---------+------+----------------------------------------+
3 rows in set (0.04 sec)

Oh, damn. MySQL, in its effort to be helpful and “user friendly,” will quietly, but not silently, as evidenced by the warnings, transform our string values into integer 0 values. So, how many rows would be affected? All 3 of them!

mysql> UPDATE t SET y = 123 WHERE x = FALSE;
Query OK, 3 rows affected, 3 warnings (0.00 sec)
Rows matched: 3  Changed: 3  Warnings: 3

Interestingly enough, if we had made a similar “mistake” and used NULL instead of FALSE, the outcome would have been more in line with our expectations:

mysql> INSERT INTO t (x, y) VALUES (NULL, 4);
Query OK, 1 row affected (0.00 sec)

mysql> UPDATE t SET y = 123 WHERE x = NULL;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 0  Changed: 0  Warnings: 0

This is because, in SQL, nothing “equals” NULL. Values can be NULL, but NULL is never equal to anything, even NULL. To compare values to NULL, SQL provides the IS NULL and IS NOT NULL operators for this very purpose:

mysql> UPDATE t SET y = 123 WHERE x IS NULL;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> UPDATE t SET y = 123 WHERE x IS NOT NULL;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 3  Changed: 0  Warnings: 0

Conclusion

Even in strongly typed languages like SQL, conveniences like type coercion can create dangerous pitfalls. Imagine if that was a DELETE statement instead of an UPDATE statement — poof, there go all your rows where the key’s resulting type conversion results in a 0 value.

Have you been hurt by accidentally using a boolean value in a MySQL query and affected more rows than you intended? Share your stories in the comments below. It’s okay, you’re not alone.

Did you learn something from this post? Share it with your friends and colleagues who might benefit from it, too!

How using boolean values in SQL can lead to unintended results was originally published in This Old Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

I’ve been examining different unit testing framework options, and I decided to do a basic weigh-in: see how much each one “weighs” in bytes with all their dependencies. I chose five of the more popular options out there today: Jasmine, Jest, Karma, Mocha, TAP.

Here’s how I weighed them:

$ mkdir weigh-in
$ cd weigh-in/

$ npm_config_prefix=$(pwd) npm ls -g
/Users/dossy/Desktop/weigh-in/lib
└── (empty)

$ npm init -y
Wrote to /Users/dossy/Desktop/weigh-in/package.json:

{
  "name": "weigh-in",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "description": ""
}

$ for i in jasmine jest karma mocha tap; do npm_config_prefix=$(pwd) npm i $i --no-save --no-package-lock; mv node_modules node_modules.$i; done
npm WARN weigh-in@1.0.0 No description
npm WARN weigh-in@1.0.0 No repository field.

+ jasmine@2.8.0
added 14 packages in 1.057s

> fsevents@1.1.2 install /Users/dossy/Desktop/weigh-in/node_modules/fsevents
> node install

[fsevents] Success: "/Users/dossy/Desktop/weigh-in/node_modules/fsevents/lib/binding/Release/node-v57-darwin-x64/fse.node" already installed
Pass --update-binary to reinstall or --build-from-source to recompile
npm WARN weigh-in@1.0.0 No description
npm WARN weigh-in@1.0.0 No repository field.

+ jest@21.2.1
added 486 packages in 40.777s

> fsevents@1.1.2 install /Users/dossy/Desktop/weigh-in/node_modules/fsevents
> node install

[fsevents] Success: "/Users/dossy/Desktop/weigh-in/node_modules/fsevents/lib/binding/Release/node-v57-darwin-x64/fse.node" already installed
Pass --update-binary to reinstall or --build-from-source to recompile
npm WARN weigh-in@1.0.0 No description
npm WARN weigh-in@1.0.0 No repository field.

+ karma@1.7.1
added 296 packages in 16.364s
npm WARN weigh-in@1.0.0 No description
npm WARN weigh-in@1.0.0 No repository field.

+ mocha@4.0.1
added 24 packages in 1.99s
npm WARN weigh-in@1.0.0 No description
npm WARN weigh-in@1.0.0 No repository field.

+ tap@10.7.2
added 338 packages in 17.905s

Any guesses as to how much each of these packages weigh? See if your guesses line up with their actual weights:

$ paste -d '#' <(du -s node_modules.*) <(du -sh node_modules.*) | sort -nk 1,1 | cut -d'#' -f2
856K node_modules.jasmine
2.2M node_modules.mocha
 34M node_modules.tap
 35M node_modules.karma
 54M node_modules.jest

Jasmine’s the lightest at 856 KB followed by Mocha at 2.2 MB, and Jest is the heaviest at 54 MB, with TAP and Karma a close second at 34 MB and 35 MB.

Obviously, weight is only one dimension to consider. But, I hope more people start making it part of their selection process. I know choosing between packages that provide similar functionality and capability, I will certainly favor the one that’s lighter.

JavaScript unit test framework weigh-in was originally published in This Old Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

So, earlier this evening I said I was going to start streaming, and rather than let procrastination get in the way, I decided to just pull the trigger before I changed my mind: I did my first live stream tonight.

I didn’t know what I was going to do, or even if I had everything set up right — the stream starts with me figuring out how to get my earbud’s mic audio working — but I think I managed to get it all working!

I was also incredibly lucky that someone decided to come check out the stream: thank you so much, will_50, for joining me this evening. You made it an incredibly rewarding experience for me, and I’m really looking forward to doing this again!

It’s late, I’m tired, but I wanted to get this out there to memorialize this event. I’m really looking forward to learning how to improve, both as a streamer and as a developer, through this process.

Come follow me on Twitch and watch me stream. I’d love to hear from you!

There’s a first time for everything was originally published in This Old Code on Medium, where people are continuing the conversation by highlighting and responding to this story.

I still think it was a good idea, but 2007 was definitely not the right time. Fast forward to today, 10 years later, and people are live-streaming all kinds of things, here on Facebook, on YouTube, and especially Twitch.

I think it’s finally time. I’m going to start live-streaming myself working on open source projects and basically any non-private/non-client work, and have a go at it. If you’re interested, head on over to my Twitch channel follow it to get notifications of when I’m streaming.

https://twitch.tv/dossy

Obviously, it’s going to be really rough in the beginning, but I’m really excited about being able to finally do this. Hope to see some of you there!

ThisOldCode.tv was originally published in This Old Code on Medium, where people are continuing the conversation by highlighting and responding to this story.