Blog

Using a CSS Inliner with Laravel

Posted on: 2020-11-29 09:23:15

Here are some notes from my use of the Laravel CSS Inliner plugin. Mainly stemming from problems we had with the responsive CSS getting blown away by the inliner.

Ah, a blog again.

Posted on: 2018-06-12 19:13:43

I rebuilt this blog in Laravel 5 about 2 years ago as an experiment. Never launched it.

Now I have things to say, so here it comes again.

Notes on setting up Lockr on Acquia Dev Desktop

Posted on: 2017-09-01 11:01:14

Have been playing around with Lockr on Drupal 7 and want to play around with it locally and so I fall back to Acquia Dev Desktop.

Just as a note, as of the writing of this blog post, Acquia Dev Desktop ships with an invalid openssl.cnf location, so you have to provide one.

I found this out when I started getting this message while trying to create a certificate locally:

RuntimeException: Could not create private key. in Lockr\SiteClient->createCert() (line 37 of /Users/nvahalik/tmp/lockr/src/Lockr/SiteClient.php).

Bummer. Anyway. The fix is simple. Just add the following to your settings.php or local.settings.php (if you're on a Mac):

putenv("OPENSSL_CONF=/private/etc/ssl/openssl.cnf");

And if you're using Lockr, make sure this patch is applied. The patch is needed due to this bug in PHP.

Once you've done that you should be ready to lock and roll!

An open letter to Dries: What are our values?

Posted on: 2017-03-30 23:57:21

An open letter to Dries Buytaert in response to the happenings with Larry Garfield and the Drupal project's values.

Yield, Generators, and Iterators in Node.js

Posted on: 2017-03-09 12:57:32

Although I love Drupal, lately some of my projects have had me delve into learning new technologies and Stacks. The one I've spent more time with lately is Node.js.

One reason for this is that I've actually known JavaScript longer than I've known PHP. I started doing JavaScript about 21 years ago... (that feels like a lifetime ago). Anyhoo, I digress.

I tried playing around with Koa last night and it seems really slick. However I was trying to map my mind around this whole yield thing as well as how yield and Generators work together with yield to fundamentally change the way Javascript works.

So it finally dawned on me last night after reading some great articles:

That given this code:

var b = function* () {
  yield 1;
  return 4;
}

let c = b();
console.log(c.next()) // { value: 1, done: false }
console.log(c.next()) // { value: 4, done: true }

That in a sense you could rewrite it as:

var a = function () { return 1; }
var b = function () { return 4; }

console.log(a()) // 1
console.log(b()) // 4

Whenever a yield is encountered, it sort-of slices up the function and returns control back to the caller. The next time .next() is called, the yield expression is resolved and execution picks up where it left off.

Just had to write some thoughts down so I could process them.

Perceived value and my favorite mobile game

Posted on: 2017-02-13 09:53:02

A few weeks ago I started playing Hill Climb Racing 2. It's a fun, addictive game and, best of all, it's free to play. You actually don't have to spend any money (though you do have to watch ads) but if you're patient, you can unlock everything without paying a single penny!

Recently, I figured I'd splurge and pay $4.99 for one of their little "deals" in the game where you get a deal with a custom decal and a heaping helping of these little things called Gems aka 💎.

Now, in the game, you buy vehicle upgrades with coins. You earn coins while driving, doing tricks, going longer and longer distances in the adventure levels, and winning cup races. You also earn 2-5 💎 every 6 hours through a "free reward" treasure box and a few more every day or two as you win 10 races by completing and winning cups. Anyway, over the course of a few weeks, you could potentially save a hundred or more gems.

Now gems in the game can only be used for two things: opening treasure boxes (which you get when you win a cup) or purchasing coins. You can't actually purchase coins, but you can purchase gems, which, in turn, can be exchanged for coins.

Now, initially when I did my initial splurge, I opted to "buy" (er, maybe convert) 1000💎 into coins. I got 130,000 coin out of the deal. Not bad, I thought to myself. That's 130 coin for every 💎.

But then I got to thinking... what would I get if I spent more? Here's the available conversions in the game:

💎	Coins	C/💎
100	10,000	100
200	22,000	110
500	60,000	120
1000	130,000	130
2000	280,000	140
5000	750,000	250

Now, I know what you're probably thinking right now... man.. I should really opt for that 5000💎 deal where you can get 250C/💎, right? I mean that really is the better deal!

Well, a few moments ago remember I mentioned that you can use 💎 for 2 things. One is for buying coins, and the other is for unlocking treasure chests. Well, what happens if you only spent your 💎 unlocking treasure chests? Well...

💎	Coins	C/💎
12	7,000	375
24	13,000	~540
48	?	?
96	70,000	~730

So with a little patience, it's actually a much better deal to unlock the chests. Sure, it can feel good to get "the best deal" but is it really the best deal? Not really...

Acquia's Access Log File Format

Posted on: 2016-11-18 22:37:06

I needed to parse some logs and I wanted to know what Acquia's Log file format was. Here it is:

LogFormat "%{X-AH-Client-IP}i %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\" vhost=%v host=%{Host}i hosting_site= pid=%P request_time=%D forwarded_for=\"%{X-Forwarded-For}i\" request_id=\"%{X-Request-Id}i\" "`

Here's a link to the LogFormat reference.

Key tidbits:

request_time is in microseconds. Not milliseconds. So divide that sucker by 1,000,000.

Also, request_id will correlate requests across different log files (e.g. drupal-watchdog-<date> and/or drupal-requests-<date>.

Building Kick SaaS Installation Profiles

Posted on: 2016-09-16 20:36:21

So back in April of this year, I gave a talk at Texas Camp entitled Building Kick SaaS Installation Profiles.

The slides are over there, but I'm uploading a local copy of them here—just in case!

Note: no audio is available, but the slides might be pretty handy!

How to monitor any text file import

Posted on: 2016-07-08 15:18:51

So as I was sitting here just now waiting for an 80+ MB import to process over an SSH connection, I began wondering to myself if there was some way to monitor the progress of an import. Percentage—or even throughput—of the file being sent over the pipe.

Turns out that there is a way!

Enter the command pv.

pv allows a user to see the progress of data through a pipeline, by giving information such as time elapsed, percentage completed (with progress bar), current throughput rate, total data transferred, and ETA.

Uh. Yes, please.

If you're running GNU/Linux, you probably already have this installed. On a Mac it's available via Homebrew.

brew install pv

Once installed, you use it to send your text files to commands that are expecting things through stdin like so:

$ pv some-db.sql | mysql -uroot 8f00b204e9800998ecf8427e
83.2MiB 0:00:25 [3.28MiB/s] [==================================================================>] 100%

Never worry about where your imports are again!

Taking a look at output buffering in PHP

Posted on: 2016-06-26 23:19:43

Output buffering in PHP isn't new. It was introduced in PHP 4 and for the most part, it's one of those things that unless you're not using a CMS or a framework, you'll never really need to mess with it much.

However, today I was playing around with doing client-side redirections in JavaScript and wanted to see first-hand how they worked. Modern browsers begin parsing the HTML before it is completely delivered and once the <script> tag is parsed, it is executed immediately.

So if we have a <script> tag just inside of our <head>, then that script tag will get executed as soon as it is done, regardless of the rest of the content in the delivered HTML file.

Anyway, to play around with this, I used this little bit of code:

<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01//EN\">
<html>
  <head>
    <title>Redirect test</title>
  </head>
  <body>
    <script>location.href=\"https://google.com/\"</script>
    <?php
      flush();
      sleep(10);
    ?>
  </body>
</html>

However, it did not work as intended.

I tried several different things trying to get it to work, but it wasn't until I added echo str_pad('', 64 * 1024).\"\\n\"; before the sleep that it actually worked:

<!DOCTYPE html PUBLIC \"-//W3C//DTD HTML 4.01//EN\">
<html>
  <head>
    <title></title>
  </head>
  <body>
    <script>location.href=\"https://google.com/\"</script>
    <?php
      echo str_pad('', 64 * 1024).\"\\n\";
      sleep(10);
    ?>
  </body>
</html>

So, why did it need another 64k worth of stuff in order to have the intended effect? Well, the answer, of course, is buffering!

Yet another buffer!

I'm using Acquia DevDesktop for local development. It uses PHP's standard buffer size of 4096. No big deal there. I trying backing down the str_pad() to that and it still wouldn't send the data.

Ultimately, what I discovered was that FastCGI has a FcgidOutputBufferSize directive and it's value is actually set to—get this—65536.

So ultimately what was happening was that PHP's buffer was getting sent, but only to the handler (that'd be FastCGI) and then FastCGI was buffering the output itself.

It's also worth noting that using mod_deflate has it's own internal buffer (set by the DeflateBufferSize directive). I had it disabled for my test—and I'm not 100% sure of the impact that it might have.

One other quick note about flush(): As far as I can tell, each buffer will capture data until it gets full. Once it gets full, it will send it's data on to the next buffer. Say for a moment you have a sleep() call in your code that suspends execution. How long will it take for a the first byte to get delivered?

Buffer	6K	11K	16K
PHP, 4K	2K	3K	0
FastCGI, 8K	4K	8K	8K
Sent to browser	0	0	8K

In other words, the first buffer (PHP's) fills up and then sends it's data over to the next buffer (FastCGI's). FastCGI won't send it's buffer to the user until PHP delivers enough content to fill up it's own buffer so that it needs to empty it's buffer to start filling it up again.

It's something to keep in mind. And again, if Apache or something else is doing extra caching, you'll need to ensure you either bypass those buffers or send enough data so that buffers get flushed.