Author: Robert

  • will there be any christmas cheer?

    [et_pb_section fb_built=”1″ _builder_version=”4.7.4″ _module_preset=”default”][et_pb_row _builder_version=”4.7.4″ _module_preset=”default”][et_pb_column type=”4_4″ _builder_version=”4.7.4″ _module_preset=”default”][et_pb_testimonial author=”Everyone, all through 2020″ portrait_url=”https://peakzebra.com/wp-content/uploads/2020/12/woman-with-facemask-1.png” _builder_version=”4.7.4″ _module_preset=”default”]

    Well, that was weird.

    [/et_pb_testimonial][et_pb_text _builder_version=”4.7.4″ _module_preset=”default”]

    Now December is here and the question for some of us is, well,

     How Do Tech Companies Market in 2021?

     The simple answer is more content marketing. And yes, you might consider working with PeakZebra as you roll into the new year. Have a look at the services we offer.  

     But it’s tricky. It won’t be more of the same content marketing we used in 2020 and years prior. From where I sit, the new content marketing won’t be marketing. It will “just” be content. Meaning it will actually have content.  It will acknowledge that technical buyers are making buying decisions based on architecture, based on the details of what a product does, and based on how they plan to implement their overall security posture.

    “Story” May Matter Less Than You Think 

    It’s become a commonplace of marketing firms to talk about how “brand is storytelling” and “all marketing is storytelling” and so on. And storytelling is fine. It has it’s place in the scheme of things and, yes, if brand is a big part of what you do (not true of most security vendors, honestly), then yes, you need to tell a story about your brand. 

    What matters more, though, is that your content makes complex content more readily processed by the human brain. Consumer brand marketers tell you that, to take one example, shoes are a commodity and it’s the Nike swoosh that creates the value in the buyer’s eye. But you aren’t selling shoes. You aren’t trading in commodities. In fact, you believe that if your ideal customer really understands what’s advantageous about your security thing, they’ll pick it over competitors precisely because they get the concept, even if it’s nuanced, even if it’s complex, even if it’s hard to wrap their minds around.

    Of course they’ll get there faster if you make it easy for them to wrap those minds.

    Talk to Me Like I’m Smart

    I get hired a lot with the idea that I can unleash some SEO on some content and, wham, those pages will start ranking number one. But that’s not actually what works. I learned an important part of what works while working for a few years at TechTarget.com. What works is building up a body of work, all of it properly tuned for SEO. TechTarget gets that right, but part of why it works for them these days is that they enjoy significant incumbent advantage. They’ve been at it for twenty years and most of their sites have thousands or even tens of thousands of articles. 

    PeakZebra in 2021

    We’ll start with smart content and basic SEO block and tackle. We’ll make it performant, so that it scores near 100 on the Core Web Vitals metrics that Google will begin to use in ranking results in 2021.  For many clients, this will mean taking WordPress sites and relaunching them as statically generated sites using lightning-fast frameworks like Gatsby. 

    On WordPress and Gatsby sites alike, it will mean creating Pillar Blogs, not an abandonment of blogs as we know them, but given an order and a meaning beyond a reverse chronological scrolling list. Pillar Blogs are a happy mashup of the content blog and Pillar Pages. They can have chapters, tables of contents, interactive worksheets, and whereas you’ve used good SEO practice to link from new content back to older entries (you’ve done that, right?), a Pillar Blog will automatically populate future links from older content to your new additions. Miraculously, it still functions as a blog. 

     So did 2020 have a Christmas? 

    Honestly, I don’t know as I write this. The real world is out there and the death count is rising. I mean, sure, there will be a Christmas. (Did I mention that Pillar Blogs add a capability that executes verb tense changes as dates pass. After Christmas, this paragraph will read differently than it does as I write it. A small thing, but you know you could use it. There will be a Christmas, but it’s going to be quiet. It’s a period in which PeakZebra is focused on rolling out its own content and capabilities. 

     Want Some Goodness in 2021?

    Let’s be in touch.  

     

     

     

    [/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]

  • kebab case

    It’s a minor thing, but somehow I never until just today knew that when you name variables using hyphens between words, like some-variable or count-of-chickens, it’s called kebab case. And, duh, of course it is.

    I did already know, just so the record is clear, about camel case and snake case.

    It sounds like a developer’s version of rock, paper, scissors: kebab skewers snake, snake bites camel case, camel case crushes kebab. I’m not sure how to differentiate the hand signals for kebab and snake. Programming is hard.

  • embedding javascript in wordpress posts

    One thing I recently heard for the first time (because I’m not really all that immersed in the current world of WordPress development) is that the Gutenberg block system that new versions of WordPress use is implemented in JavaScript. And it would appear that all the client-side work on WordPress is in JavaScript where possible.

    This makes a lot of sense, frankly, only because the dominant language for browser experience tweaking has long been JavaScript and all the leading libraries and frameworks for client-side apps and UX are written with it.

    This leads us to the question of how to throw some JavaScript of our own into web pages on our WordPress sites. Not having needed to do anything like this in a WordPress environment (if ever… since I’ve tended to use WordPress on content publishing sites, I’ve never needed to roll up my sleeves like that.

    Three ways to add JavaScript to WordPress

    There’s more than one way to add your JavaScript, as you might already have suspected. What everybody adds in any discussion of this sort of thing is that there’s also a fourth way, the Way of Darkness, where you actually start mucking about in native WordPress files. This is a bad business you should avoid, if for no other reason than that it’s going to get overwritten by a WordPress update at some point. So, having set the Way of Darkness aside, that leaves us three ways.

    Just plunking it in

    You’ll also find warnings about this approach, which is simply to use the newfangled block editor system to throw in a block of HTML. In that block, you write HTML, which includes throwing in a <SCRIPT> tag, a bunch of JavaScript, and then the </SCRIPT> tag.

    Depending on what you’re trying to get done, I really fail to see what the problem is with doing it this way. It seems to work fine, it’s not going to bollocks up other JavaScript code running as part of WordPress (because you’re going to be careful about naming any variables you create in what is likely a global scope (I’m not actually quite sure that the code that runs in a page is running in an overall global scope, but I can’t think of any reason why it wouldn’t be).

    This is the approach I’m using right now to create an on-page tool that calculates potential ROI for keyword SEO campaigns. It’s self contained, any data that might need to be stored from one session to the next will be stored somewhere other than WordPress (written to the localStorage object, for instance), and, hey, it seems to work OK. Maybe I’ll learn firsthand why this is a bad idea, or someone will kindly comment with an explanation.

    Using a JavaScript plugin

    As you’d expect, there are multiple plugins.

  • What is json, we begin

    In the first epoch of my professional life, we scraped along without JSON files. So, while I knew that package.json was a file that kept cropping up in node.js, I wasn’t really clear on “what is JSON?” thing was all about, or even what the acronym stood for. So, OK, it stands for JavaScript Object Notation.

    Now we big, manly C programmers had a thing called a header file, a .h file. Boom. Same thing. Or, well, actually not. Let me start over.

    A JSON file is a file with a .json extension that contains a bunch of data represented in various kinds of JavaScript constructs, but it seems like most of the time what you see are objects with name-value pairs separated by commas. Like:

    {
  "foo": "bar,
  "rodentType": "mouse"
}

    The list of value pairs is an object, so you use your basic object declaration–you put things between curly braces, like so (this example borrowed from the Wikipedia entry on json:

    {
  "firstName": "John",
  "lastName": "Smith",
  "isAlive": true,
  "age": 27,
  "address": {
    "streetAddress": "21 2nd Street",
    "city": "New York",
    "state": "NY",
    "postalCode": "10021-3100"
  },
  "phoneNumbers": [
    {
      "type": "home",
      "number": "212 555-1234"
    },
    {
      "type": "office",
      "number": "646 555-4567"
    }
  ],
  "children": [],
  "spouse": null
}

    And you’ll note from the example that you can also have arrays, between square brackets.

    Indeed, the point of the JSON business, really, is to make it really simple to take an object that’s been set up in some JavaScript code, like for example an object that contains a bunch of to-do items, with each having a title property and a boolean flag, isDone, which is set true when the todo item has been done:

    0: {title: "Clean your room", isDone: false}
1: {title: "Do your homework", isDone: false}

    Let’s say this data is stored in an object variable called items. We’d like to be able to plop this into the localStorage object, which is a built in capability of the browser that writes the object to disk on the local computer.

    Backing up a little, remember that a JSON file is entirely text-based, so what we write to local storage must, even if it started life as an object, be a string. There’s a library for this (there’s a library for everything these days), aptly called JSON. Thus:

    let JSONstr = JSON.stringify(items)

    turns the items object into a string that looks like:

    [{"title":"sfdsf","isDone":false},{"title":"make breakfast","isDone":false}]

    This can then be written to local storage:

    localStorage.setItem('items', JSONstr )

    Which is cool, and which enables us to do this process in reverse, using localStorage.setItem( ‘items’) to retrieve this particular bit of data, after which we turn it from a string back into an array of objects by using JSON.parse( JSONstr). There is nothing the least bit fancy about this really–it’s just another case of programming taking a fairly mundane task (packing and unpacking a file in a particular format) and doing the work once to the benefit of all.

    A million years ago I remember being kind of thrilled to learn the strtok() function in the C language. It’s not nearly as smart as JSON, but enables you to break a string into pieces, where each piece is delimited by the specific character (or set of characters) you use in the function call. So, for instance, you could use a comma as the delimiter as a way to get at the pieces of a line extracted from a CSV (comma-separated values) file. You could suck a text file in line by line and then pull the line apart with successive calls to strtok().

    Parenthetically, this gets at what I loved about C, namely, that it uses pointers unapologetically, giving you full license to totally screw things up. In the case of strtok(), the function returns a pointer to a string. So, we hope, space was allocated to store whatever string is sitting at the location pointed to by the string variable we pass to strtok. That’s just basic hygiene in C. Let’s say the string is “Give me a wheel of oaken wood.” and it’s at address A. If we use a space (” “) as our delimiter, we’re going to be returned the address A. In other words, the return value points to the start of the first token, which is “Give”.

    But how do we know where the token ends? After all, a C string ends with a null. The null that ends the string we passed in is just after the period in “Give me a wheel of oaken wood.” But the strtok function actually changes the value of the string and puts a null where the space was after the word “Give”. Holy crap. We passed in a string that had seven words in it, but if we look at the string we passed in now, it is nothing more than “Give”.

    Meanwhile, strtok() has remembered–beyond the context of this particular call to the function–that the next token begins at the address A+the length of the token last returned. How can you not just love this crap? I’m being serious here, mind you. I think this is awesome. Anyway, if you have a loop where you run through all the tokens in the original string, you’ll be handed back a pointer that advances along the string at address A, all the while dropping nulls in at the ends of each token.

    You can see, probably, why people get into all sorts of trouble with C and why polite people are no longer allowed to code in the horrible, horrible language. But, hey, it’s the efficient way to do this sort of work. Most of the time, you don’t care if the string gets chopped up and it’s fastest to just poke through it in memory right where it stands. If you need an unaltered copy, then make one before you start tokenizing.

    Anyway, in C, you really have to fully understand what you’re doing with pointers and the like. There’s a power in that, but on the other hand there’s something to be said for the extreme ease of just plunking a whole object into local storage (regardless of how local storage is implemented) using two lines of code. And it’s pretty blissful that the stringify() function hides all the mickey-mouse details of scanning for square brackets and curly braces and so on. Which is possible, getting back to the subject at hand, because JSON is well-specified.

    In the interest of a full accounting, I should add that JSON is pretty much the same concept as YAML, which started life as the acronym Yet Another Markup Language. Apparently, it’s now properly “YAML ain’t markup language.” Using a name that is quasi-recursive might have been cute back when “GNU’s Not Unix” was coined, but this is just tired and dumb.

    That said, YAML is visually easier to read and–wonder of wonders–allows comments. Somehow, wretchedly, JSON does not. And it would be so damned easy… But if you are working in JavaScript and you have an object, then when you look at the object stored in a JSON file, it will look exactly (well, approximately exactly) the same as the object in .JS file. Which is handy.

  • A play.js detour

    Even in this age of contagion, I had a situation where it really made sense to fly out on a morning and back that evening. I decided to take the iPad instead of the notebook, and while I was at it, I decided to take a look at what the possibilities for coding on iPad these days.

    There are certainly more code options than there used to be (and I suspect we’ll see more and more as Apple slowly overlaps the iOS and MacOS domains. In any case, the tool that seemed closest to the Gatsbyjs stuff I’ve been doing lately was the Play.js app. There are other JavaScript app options and they may be great. Generally, they are free where Play.js costs five bucks. But Play.js is really pretty fascinating.

    As you can see in the screen shot above (a view of some sample code that comes with the app), the editor looks a lot like Visual Studio Code, which makes it immediately look friendly (assuming VSC is what you’re using). The app builds in a fairly impressive port of node.js as well as npm, along with support for react native.

    I’ve got some catching up to do on react native. I get the basic idea: it lets you write an iOS app in reactjs. So that’s cool, but how does that work? And I thought you still had to have a Mac to build an iOS app, so I guess what Play.js is doing is actually more of an emulated environment?

    If nothing else, it looks like Play.js provides a pretty decent editor that looks like VSC. Plus it has support for basic git functions, so you can work with code stored in online repositories. Nice.

  • An early agenda

    The past two years I’ve operated from the web site over at EmergingTechInsight.com. That was the web domain I hastily grabbed as I was exiting an editorial job I’d for a few years. Basically I needed a work address for future email to go to. When I worked with clients (which was what I proceeded to do), that was where the mail went but they dealt with me by name, as Robert, and that worked fine. 

    I still think people should work with me by name, but as things are growing and branching out just a bit, I decided to launch an actual business entity. That’s PeakZebra LLC, and now (at least theoretically), that’s where the mail goes. Truthfully, I haven’t really pushed existing clients to move over to the new address and name — no real reason to. (I didn’t have to give any thought to whether I wanted to try out a fresh email start with Hey.com–it didn’t exist yet).

    So let’s call it PeakZebra. PeakZebra is focused not only providing content and SEO for B2B-focused technology vendors, but also on more technical, web-app-driven aspects of digital marketing. It’s focused on rethinking online content in light of the current search-engine-driven universe and particularly in light of Google’s increasing focus on page speed and mobile performance. I don’t know that WordPress is likely to be competitive in this new world. It seems clear that companies that want an edge in Google rankings are going to need to clobber the metrics Google is focusing on. For that–for most companies, at least–the easiest path is going to be serverless, which here I’m equating with JAMstack, since the major early contendors in the space are focused largely on JavaScript. 

    The particular framework that seems to have the biggest uptake to date is Gatsby (or gatsbyjs) and you can definitely build a full-on pro web site with it. Sites built on Gatsby tend to be screamingly fast and there’s a compelling reason for that. On the one hand, the sites are statically generated, so that in theory the display is not waiting for some dynamic process to pull the guts out of a database and thread them together into a page. At the same time, they use React so that parts of the currently displayed page can reload without new, full HTML pages needing to download. So the pages can still be interactive, and indeed they can dynamically request services from servers as needed. (And yes, that gets us back to dynamic pages, in a way, but let’s talk that through in another entry). 

    So I’ll be writing about my particular journey through the JAMstack world in more or less real time. My intention was to do this on a Gatsby web site–eating my own dog food and all that. But… 

    I came to the sudden realization: I would probably be breaking my Gatsby sites for hours (heck, days) at a time. The point was to boldly learn lots and lots about JAMstack and Gatsby and all the other things… that would definitely entail lots of creative destruction. And what drove it home is that the Gatsby site I’ve been experimenting with, when copied up to a host service I use, sort of worked but sort of didn’t, then worked but didn’t show the changes when I made subsequent updates, then got just plain radically broken for the rest of the day. Like nothing at all showing in the browser kind of broken. 

    I think WordPress is in for some tougher sledding in the next year or two, but I know how to make it work and be pretty. I know how to do stupid tricks like fly-in animation. Etc. 

    So for the time being, most of my experimentation and research will be in the JAMstack world, but my writing about it will appear in WordPress, at least for the next few months. Actually, I also plan to do some mucking around in performance aspects of WordPress, but I’ll be doing that locally and on a hosted but completely safe-to-break site. I’ll link to that stuff as appropriate, but the writeups will be here. 

    At present, I’ve got a rather basic site running on Netlify (here) — it’s largely the product of a couple Gatsby video courses I’ve worked through in the past couple of weeks: Reed Barger’s The Gatsby Masterclass and Andrew Mead’s Great Gatsby Masterclass.

    The first of these links is behind a paywall at O’Reilly. One little luxury I’ve given myself for a few years now is a subscription to O’Reilly, which gives access to a pretty fantastic range of books (including plenty of stuff from outside O’Reilly), conference videos, instructional videos, and sandboxes where you can tackle specific tasks in a virtual environment. These days it’s $49 a month for individuals, which I’ll be the first to say is pretty spendy, but it’s still pretty rich if you’re trying to learn a lot of tech stuff from decent sources (and I’ll confess, one benefit to having been on board for several years is that I’m in a legacy plan that locked me in at an attractive annual price). 

    But I digress. Here’s an agenda for what I’ll be digging into and building in the next while. At this point I’m reluctant to put specific timelines on some of these items, because I know I’ll learn things that will change up the plan, but this is at least in the order I plan to do things:

    • Sort out some glitches I’ve encountered in loading Gatsby sites to “traditional” web hosting sites. I think most of it boils down to things that are solved with a bit of tweaking of the .htaccess file, but I’ve forgotten anything I ever knew about .htaccess files, so I guess it’s time to back up and really figure out what’s going on. 
    • Keep building my knowledge of WordPress internals so that I can compare options for optimizing WordPress (and building apps within it) in order to compare them with JAMstack alternatives. I suspect that there are going to be plenty of instances where an organization may be best off sticking to the WordPress they have, just optimized for better performance (on mobile in particular). Of course, there’s also always the option of using WordPress as the back end for a Gatsby (or other framework) static site. 
    • Figure out the quickest, most efficient way to do basic “pretty” design within Gatsby sites. I realize I’ve gotten used to having most things regarding design handed to me as part of WordPress. I get how CSS works (in fact, I wrote about it professionally a million years ago when it first emerged…poking around on the web, it was in May of 1997. I know this only because somebody’s old web page about CSS has a dead link the article). I get how it works in a general sense, but man oh man has it changed a bunch in the past 23 (for chrissakes!) years. So I need to dig back into that, get straight on my floating and grids and whatnot. 
    • I’m not nearly as rusty on JavaScript, but it’s also a place where I’ve got to get my chops back, particularly as regards the client-side microcosm that is Reactjs. 
    • Out of this will emerge a still-pretty version of this blog that moves from WordPress to, well, I’m pretty sure it will be Gatsby, but who knows, the world is migrating even as I’m figuring it out. But something JAMstack. 
    • And while I’m at it, I want to sort out the ecosystem of JAMstack and things adjacent, of which there are a shocking number. 
    • Figure out how to build a concept I’m calling a Pillar Blog. Definitely more on this to come. 

    I’ll flesh this out and put more structure to it as things progress, but there’s the basic shape of what I guess I’ll call Phase One.

  • Hello, world!

    What a brilliant thing it was to come up with “hello, world!”, which I think can be attributed to Brian Kernighan. He used the phrase in an example program internal to his lab in 1974, then he and Ritchie put it on the world map in 1978 with their introduction to the C computer language.

    When I started programming in 1986 or so, the book was still a perfectly good way to fundamentally learn about C, though in fact I started in Pascal, using Borland’s Turbo Pascal because it was cheap and it was so freaking cool (at the time, at the time).

    To me, having cut my teeth as a professional programmer in C, it’s fascinating to see how many of the prominent languages today look and act a lot like C, especially if you allow yourself to range forward to C++ in order to pick up object-oriented capabilities. As I write this, the PeakZebra site is running on WordPress, which is built using PHP. It probably really should be running on a JAMstack platform, but for the moment I am the proverbial bull in JAMstack’s ecosystem, at least as far as learning and trying things out are concerned. I’d be breaking the site pretty much every day. WordPress, on the other hand, I can basically set up and leave alone, except for adding new content.

    The logical place to go from here is the About page, or possibly the Services page, if you’re already confident that PeakZebra can help you.