CASPAR.green

That's just, like, my opinion, man.

Top 4 Books, 2018

by Leave a Comment

The end-of-year clean out continues.

I’ve made a pile of books to take over to the library for donation to their weekly book sale.

I’ve read a lot of books this year. Now it’s time to make room on the shelf for next year’s reading. I’m only keeping the few that were so compelling that there’s a chance I’ll look back at them again. Those 4 are:

  • Sapiens. Yuval Noah Harari.
  • Being Mortal. Atul Gawande.
  • Thinking, Fast and Slow. Daniel Kahneman.
  • The Black Swan. Nassim Nicholas Taleb.

These 4, then, get my award for books of the year for 2018.

It’s Time for Arras to End

by Leave a Comment

With the coming of WP 5.0 and Gutenberg, and my new focus on moving in directions other than WordPress, it’s time to finally put the Arras WordPress theme to bed.

I realize that I did this once before, and then thought that I might resume. This time, however, the decision is certainly final.

To those who have been waiting for further updates, my apologies. You are welcome to fork the source code and attempt to continue on your own. That said, my recommendation to Arras users is to find an up-to-date, reliable theme that will serve you better into the future. There are plenty of them out there.

The 5 Stages of WordPress Grief

by Leave a Comment

The other day I posted that the direction WordPress has taken has saddened me and made me occasionally angry.

In a subsequent exchange on Twitter, I somehow attracted the attention of someone who was definitely angry. Very angry.

As I reflected on this further, I realized that what many in the WordPress space have been going through can be described by the classic Kubler-Ross model of grief. Also known as as the five stages of grief.

(One note about the so-called stages, before I go further. Since Kubler-Ross first published the theory, it’s been widely recognized that transition to one stage to the next isn’t always linear. More often than not, grieving persons move from one to any of the others, in different order, sometimes repeating certain stages.)

1. Denial

For a long while, most of 2016, this was where I was. The Gutenberg project had been announced. Work had begun. But it was not really on my radar, and when it was, it was far enough in the future that I could choose to ignore it.

I revisited this stage several times through 2017 and ’18 as well. I saw people in this stage right up to the very last moment, as recently as last week: “It’s not too late to convince those in charge (whoever they are) to change their minds about it.”

2. Anger

This is where I occasionally find myself, and where I’m encountering quite a few folks. Something we loved is lost. Anger is natural. Some people handle it better than others. In anger, some (like the fellow I encountered on Twitter) are lashing out at anyone and everyone they can find to blame. Some feel hurt and want to hurt back. That’s unfortunate.

As much as I disagree with and am occasionally angry about the way things have happened, I want to go on record that I’m not holding any personal grudges. I’ve said before, there are a lot of people who believe in the new direction of the WP project. A lot of people have put in a lot of hard work and effort to make what they believe is a good thing. People do what they think is right. I happen to disagree. I wish them well in their endeavors.

But I also stand by what I’ve publicly said before: WordPress, with this most recent release can no longer claim to be enterprise level software, and I will be much more cautious in my own use of it, and in my recommending it for others to use.

Anger need not always be destructive. As Kubler-Ross pointed out, it’s an essential thing to work through, a part of separation and self-definition, that when done well helps one to be stronger and more resilient in the long view.

3. Bargaining

Over the past few weeks, I’ve been here myself, and I’ve seen plenty of this back and forth over the interwebs. Given the realization that the loss is impending, or has already happened, we make deals to try to avoid what is inevitable. All the calls for “It’s not ready.” All the complaints about, “The timing is terrible.” All the offers of “If you will just add this feature (or remove that feature), I will accept it.” All bargaining.

The addition of the Classic Editor plugin and the Core team’s commitment to maintain it for 3 years was a grand bargain. Sometimes bargaining is useful. It bought some of us 3 years before the loss we are feeling becomes permanent. It is best ro remember, however, it only forestalls the inevitable. The day will come when the Classic Editor will be abandoned, and those who have remained in this stage will have to move… again.

4. Depression

I confess, I’ve spent quite a bit of time here as well. And still do. On the road for 4 hours one day recently, I found myself singing along with the Dixie Chicks: Hello, Mr. Heartache, I’ve been expecting you!

I’ve invested a lot in WordPress – not as a contributor, but as a promotor, as someone who learned the software through and through, wrote themes and plugins for it, and enthusiastically recommended it to clients I hoped it would serve long and well. For about 10 years, I was all-in. And, though no software is perfect, and no community of enthusiasts is perfect, I felt a part of something worthwhile and was invested in it.

Losing that is bound to make one feel blue. Even nostalgic. In these moments I can recognize that I learned a tremendous amount from WordPress. I benefitted from it educationally, emotionally, and financially. I made a lot of good friends, and I hope that those who are staying with WordPress even when I’m no longer as engaged in that community will remain friends. Acknowledging that is a good thing. Going on record as being grateful for the opportunities it gave me is appropriate here.

It’s also helpful to recognize here that nothing lasts forever. Sadness. Which leads to…

5. Acceptance

Acceptance can take 2 forms. One is a resolve that one might as well prepare for it. These are the ones that are signing up for the “How to make Gutenberg blocks” courses that are now popping up everywhere.

There’s another kind of acceptance, the kind I find myself moving into. This has happened. It is what it is. What can I take from this experience and move on?

“Learn Javascript deeply” seems to be one of those things. It’s a fact of the web, and even if WP implemented it in what I regard as a fatally flawed way, if I’m going to be in the web business, I need to know it. For a long time WordPress allowed me to skirt the necessity of it.

“Beware the silos” might be another. Even if the silo you happen to be in is a very large (approaching 35% of the web) one. Keeping your head buried in one hole too long blinds you to important things that are happening in the rest of the world.

Another reality that acceptance makes me aware of is that as big as it is, WordPress is still only 32% of the web (as it claims). Once you get beyond that silo you find that this number may not be as accurate as you once thought, and that even if it is, that still leaves 68% of the web that is doing something else, and most of it is getting along just fine, thank-you very much.

Part of acceptance is realizing that there are twice as many opportunities outside of WordPress as there are inside it. And, to make things even more interesting, one can note that WordPress is low-end on the pay scale for people who know what they’re doing. Part of its appeal, and part of the reason it has grown so rapidly is that it serves the long tail market of sites that are being built on a shoestring.

There are plenty of notable exceptions, yes. I’ve long pointed to them as proof that WordPress was viable in the enterprise web space. But I’ve always said, and still say, that if your bank is running its web operations on WordPress it’s time to find another bank. Now, even more-so.

Sure, we lost something. But we are not cut off from the future. For anyone looking to transition from the typical $2000 – $10000, one-off site build range toward larger projects, now is the perfect opportunity to make the change for those who have the skills. And for those who don’t, now is the perfect opportunity to get them. Start with Free Code Camp.

As I noted before, these stages don’t necessarily progress in order. I find myself moving between them, sometimes several times in the same day.

This post is my self-reflection and observations, shared with the intention that they might be helpful to anyone else who stumbles across it.

And to all my WordPress friends, be well and keep in touch.

Choose an IDE and Stick with It

by Leave a Comment

I’ve used the PHP Storm IDE for the last 4 years (give or take). All the cool kids seem to be transitioning to Microsoft Visual Studio now. I have to say, it looks pretty slick, from what I’ve seen of it, but I’ve not tried it yet myself. I’m looking forward to doing that, but not anytime soon.

For now, I’m happy with PHP Storm. It’s part of the Jetbrains IDE set, and for 2 years I’ve had the license for the whole set. Up to now I haven’t used many of the other IDEs in the set, but that’s changing.

Last year when I started looking into Python, and again this week as I’ve been delving more seriously into Javascript, I’ve appreciated having the companion pieces in the set. I downloaded WebStorm, and within 10 minutes was able to find my way around, run my code and debug.

Having a familiar interface to program in when exploring less familiar language has been a great help. Certainly a lot easier than debugging in the browser.

If you’re going to be doing serious programming, you owe it to yourself to find a tool (or set of tools) that help you. That means that you take some time to get familiar with them and configure them to fit your workflow. And, yes, it’s going to take some time and effort. Once you’ve done that, a good IDE setup will become invisible; it will feel like it’s not even there, so you can focus on your work, not your tools.

It says something for how well the tools work, when as I started exploring a new language in depth outside my familiar development environment I found myself trying to figure out as much “How can I edit this code?” as “What do I need to change in this code?” Returning to a familiar coding environment (for me, WebStorm) removed that first hurdle so I could get on with the second.

Whatever your tools, choose a set that works for you, and stick with it until it no longer stays out of your way. (That’s the indicator that you might need a change. Some people I know are still using VIM and are completely happy with it!) Some shiny new things that come along may be worth adding to your kit. You know them when you start feeling a pinch in your workflow: “I wish I didn’t always have to stop what I’m doing because…” At that point you find the tool that addresses that need. But switching from one to the next too frequently is a form of hiding from the more important work.

A Few Notes on Updating to WordPress 5.0

by Leave a Comment

I updated this blog to WordPress 5 yesterday.

A couple notes:

1. When I updated, even though the Classic Editor was installed and active in 4.9, the update disabled the plugin! Grrrrrr. So, first thing I had to do was go to Plugins and re-enable it.

2. There are new settings under Settings > Writing: “Default editor for all users” and “Allow users to switch editors”. Set them to the “Classic” and “No”, as shown. If you’re using Advanced Custom Fields you’ll get the white screen of death if you don’t. (Update: Updating the Classic Editor plugin to version 1.1 should clear up the ACF compatibility issue.)

New Settings for Writing

3. That said, even with the “Don’t allow users to switch” setting, the posts page will ignore it and offer users the option to edit posts in either editor, so (at least for now) it’s not a bullet-proof prevention to disallow what’s now called the “Block Editor”. (Update: again, updating to Classic Editor 1.1 seems to have cleared this problem as well.)

Users can choose to use Block Editor, even with "Switch Editor" disabled

Version 5

by Leave a Comment

WordPress 5 is scheduled for release today.

Earlier this week, one client asked if her site would break. (She’d gotten an email from some marketing guru about it.) I told her that I’m pretty sure things were going to be alright.

I have outfitted all the sites I currently work on with the Classic Editor plugin, so I don’t expect any problems. So far, the plugin has negated any noticeable effects from the Gutenberg fiasco.

On the one hand, I’m saddened (and at times a little angry) about the way the changes to the WP project have unfolded. On the other hand, the world will not end tomorrow. Like the world holding it’s breath for the Y2K computer crashes that never happened. There will be some oddities here and there — is my prediction. But, indeed my confidence in the leadership of the project has been broken.

What remains to be seen is whether the project itself is broken. I hope not, but I suspect that a few years from now this will be the time the online world will point back to and say, “That was the beginning of the end of the WordPress empire.”

Proactive Service

by Leave a Comment

Two different clients. Same day.

Each did something that was a little over their head that resulted in something going haywire.

In both cases, the clients didn’t even know anything had gone wrong. But I could see the signs. I knew. And, eventually they would have noticed.

Both of these incidents turned out to be opportunities to proactively contact someone, to let them know they had a problem, and at the same time to help them solve it before it became a bigger problem. More than that, to help them solve the problem they knew they had to begin with, the one that caused them to wander into the deep end where they got into trouble.

I’m pretty sure they both had a better day than they would have otherwise.

And I had a good day, too.

It’s kinda nice when you have a day with those kinds of problems.

Free Code Camp

by Leave a Comment

Here’s another great resource for anyone who wants to start learning to code:

Free Code Camp.

They have 6 completely free 300-hour courses (and you get real certificates for completing them) that take you from the very basics of HTML and CSS (the backbone structure of web pages), through Javascript, data structures, APIs and microservices, and online security. All complete with exercises, practice projects, and job interview practice scenarios.

The courses are self-guided, but thorough, and there is community help to get through them when you’re stuck.

By the time you get through all the certificates, you even have a public portfolio of work to show off.

If you’re looking to get into the website programming field, don’t have money for night school, but an hour or so per night, this might be for you.

100 Days of Code

by Leave a Comment

I started the 100 Days of Code.

It’s a project I’ve thought about doing for a while now. It’s always seemed like a good idea, but until now I’ve put it off.

Why? Because it’s a commitment to code for 1 hour on a real project for something other than client work. To work on something that isn’t what I’ve done before, and to do it publicly, out in the open, where everyone can see. On the upside, that means that everyone will see when I’m making progress. On the downside, that means everyone gets to see my mistakes!

That’s scares me.

But at this point, I think it’s what I need in order to push myself to the next level.

Sometimes the thing I most need to do is the thing I’m most afraid to do.

How Do You Bootstrap Your App?

by Leave a Comment

Most of my programming over the past decade has been within the context of WordPress. Before that I had started out with “vanilla” PHP. That was before PHP had any object oriented capabilities.

Returning to non-WordPress PHP after all this time has forced me to rethink some pretty basic stuff. For instance, What’s the best way to launch an app if you’re writing one from scratch?

When you have a framework, all that is taken care of for you. And you might wonder why anyone would even care. Most of the time you’re going to use a framework rather than build absolutely everything from the ground up.

And yet, inquiring minds want to know.

Other languages, Java for example, have a Main class that provides for initiation. In PHP, we can start wherever. Point a web browser to index.php and include whatever else you need. Looking over various tutorials for “projects to learn PHP”, most of what I find is either long outdated or still jumps from one file to another, piecemeal. Need to process a form that adds a todo? Send the request to add-todo.php.

It’s no wonder PHP still has a reputation for being for amateurs, given the advice I’m finding over internet searches. (And yet, here I am still wondering how to launch an app, absent a framework!)

I rather like the way the CakePHP framework resolves the issue. Assuming an app that’s running over an HTTP connection, the web root index loads the Composer autoloader, binds the app to the framework server, and calls the server’s method to render whatever the app sends to the server for a response. It’s an elegant little piece of code:

...

require dirname(__DIR__) . '/vendor/autoload.php';

use App\Application;
use Cake\Http\Server;

$server = new Server(new Application(dirname(__DIR__) . '/config'));

$server->emit($server->run());

Without the framework, it seems possible to do a similar thing, creating your own Main class, in the way other OOP languages might do it:

<?php
// index.php

use MyApp\Main;

require dirname(__DIR__) . '/vendor/autoload.php';

$config = include './path/to/configfile.php';
$app    = new Main($config);
$app->run();

I’m curious. If you’ve written an app from scratch, or if you work with one that doesn’t rely on a framework for bootstrapping, how do you go about it?

Or, if you work in a language other than PHP, how does that language handle application launch?