CrossView Fun With CSS

Written by Pete Corey on Nov 2, 2014.

I while ago I stumbled across the CrossView subreddit. I thought the text CrossView images that contained hidden messages were especially cool. So, I decided to try to create one using simple HTML/CSS. The process was really simple. Check out the codepen below, or view it in fullscreen to better see the effect:

See the Pen Cross View Text Test by Pete Corey (@pcorey) on CodePen.

The effect is created by moving specific words on the left text up a couple pixels, and words on the right side down. The greater the offset, the greater emphasis they’re given when crossviewed. For this font and text size, I found that a 4px span worked well.

This could easily be built into a web-based tool to generate text crossview images. I may work on that in the future if there is any interest in that kind of thing.

Laravel Queue's Sleep Contributes to its Timeout

Written by Pete Corey on Oct 23, 2014.

Once again, I was tinkering with my Laravel queues today and I ran into an interesting issue. I have a queue listener running with the following command:

php artisan queue:listen --env=stage --queue="slow-queue"

The jobs that slow-queue processes are infrequent and aren’t very important, so I decided to have the listener sleep for one minute between job checks:

php artisan queue:listen --sleep 60 --env=stage --queue="slow-queue”

I restarted my supervisor daemon and waited a few minutes to verify that everything was working correctly. Unfortunately, everything was not working correctly. All of the jobs being processed by the slow-queue listener were failing with a ProcessTimedOutException:

[2014-10-23 09:51:27] stage.ERROR: exception 'Symfony\Component\Process\Exception\ProcessTimedOutException' with message 'The process ""/usr/bin/php" artisan queue:work  --queue="slow-queue" --delay=0 --memory=128 --sleep=60 --tries=0 --env=stage" exceeded the timeout of 60 seconds.' in /www/
Stack trace:
#0 /www/ Symfony\Component\Process\Process->checkTimeout()
#1 /www/ Symfony\Component\Process\Process->wait()
#2 /www/ Symfony\Component\Process\Process->run(Object(Closure))

My first thought was that the sleep time must be contributing toward the job processes’ timeout counter (which defaults to 60 seconds). To test this thought, I increased the timeout on the listen command to 61 and tried running the jobs again:

php artisan queue:listen --sleep 60 --timeout 61 --env=stage --queue="slow-queue"

Sure enough, it looked like the jobs were completing successfully. As a quick fix to this issue I increased the timeout for slow-queue to 2 minutes:

php artisan queue:listen --sleep 60 --timeout 120 --env=stage --queue="slow-queue"

It seems very strange to me that the sleep time specified in the queue listener would contribute towards it’s timeout time. In my mind, sleep would cause the listen process to wait the specified number of seconds to check for a new job. If there is a new job, that job process would start and its timeout counter would start.

I may be completely misunderstanding what’s happening here, but I went ahead and opened a github issue to either get it fixed or get an answer.

Laravel 4.2 Command "Queue:Restart" is Not Defined

Written by Pete Corey on Oct 15, 2014.

I’m currently working a client project using Laravel 4.2. The project uses 4 separate queues for a variety of tasks. Today I noticed that the queues were eating up an unhealthy amount of resources. After reading through the docs, I noticed that this CPU consumption was most likely being caused by spinning up the laraval framework for every job processed. By using the --daemon flag, introduced in 4.2, you can keep the framework loaded in memory and prevent unncessary work by bringing it up and down for each job. Awesome!

After switching to queue:work --daemon ... I noticed an immediate drop in CPU consumption! But, because I read the docs, I knew that I could expect the DB connections in the in-memory framework to cut out. I quickly refactored my jobs to call DB::reconnect(); prior to doing any database work. I pushed the change and went about my business.

A few hours later, I noticed my logs being flodded with exceptions coming from my job classes: MySQL server has gone away. Strange, those jobs should have been re-establishing their DB connection every time they were fired. After re-reading the docs, I realized that the in-memory framework didn’t have the change I previously pushed because I never restarted the daemon jobs… I tried to run php artisan queue:restart and was greeted with the following error:

  Command "queue:restart" is not defined.  
  Did you mean one of these?               

Huh? I was running Laravel 4.2, and the docs clearly said that this command should be available in 4.2. I started digging through the framework source, and sure enough, the command did not exist. I tried googling for solutions in vain, until I found a page for a package called Laravel 4 Down Safe. A line at the very bottom of the page caught my eye:

Requires Laravel v4.2.5, and uses the ./artisan queue:restart command to trigger a daemon worker restart.

Maybe the restart command was introduced in version 4.2.5? I checked my minor version, and sure enough I was using 4.2.0. I changed my laravel version in composer.json from "laravel/framework": "4.2" to "laravel/framework": "4.2.5" and ran a composer update. After that finished, I tried to run queue:restart and it worked! After restarting the daemons, they correctly re-established their database connections.

The moral of the story is that instead of using explicit minor versions, always grab the latest: "laravel/framework": "4.2.*". Also, RTFM.