Post pobrano z: Mētis

Kelly Sutton writes about programming, working with teams and the relationship to the Greek word Mētis:

Mētis is typically translated into English as “cunning” or “cunning intelligence.” While not wrong, this translation fails to do justice to the range of knowledge and skills represented by mētis. Broadly understood, mētis represents a wide array of practical skills and acquired intelligence in responding to a constantly changing natural and human environment.

Kelly continues:

In some ways, mētis is at direct odds with processes that need a majority of the design up-front. Instead, it prefers an evolutionary design. This system of organization and building can be maddening to an organization looking to suss out structure. The question of “When will Project X ship?” seems to be always met with weasel words and hedges.

A more effective question—although equally infuriating to the non-engineering members of the company—would be “When will our understanding of the problem increase an order of magnitude, and when will that understanding be built into the product?”

Direct Link to Article — Permalink

Mētis is a post from CSS-Tricks

Post pobrano z: Gutenberg

I’ve only just been catching up with the news about Gutenberg, the name for a revamp of the WordPress editor. You can use it right now, as it’s being built as a plugin first, with the idea that eventually it goes into core. The repo has better information.

It seems to me this is the most major change to the WordPress editor in WordPress history. It also seems particularly relevant here as we were just talking about content blocks and how different CMS’s handle them. That’s exactly what Gutenberg is: a content block editor.

Rather than the content area being a glorified <textarea> (perhaps one of the most valid criticisms of WordPress), the content area becomes a wrapper for whatever different „blocks” you want to put there. Blocks are things like headings, text, lists, and images. They are also more elaborate things like galleries and embeds. Crucially, blocks are extensible and really could be anything. Like a [shortcode], I imagine.

Some images from Brian Jackson’s Diving Into the New Gutenberg WordPress Editor help drive it home:

As with any big software change, it’s controversial (even polarizing). I received an email from someone effectively warning me about it.

The consensus is this UI upgrade could either move WP into the future or alienate millions of WP site owners and kill WordPress.

I tend to think WordPress is 2-BIG-2-DIE, so probably the former.

I also think piecing together block types is a generic and smart abstraction for a CMS to make. Gutenberg seems to be handling it in a healthy way. The blocks are simply wrapped in specially formatted <!-- wp:core/text --> <!-- /wp:core/text --> to designate a block, so that the content highly compatible. A WordPress site without Gutenberg won’t have any trouble with it, nor porting it elsewhere.

Plus the content is still treated in templates as one big chunk:

To ensure we keep a key component of WordPress’ strength intact, the source of truth for the content should remain in post_content, where the bulk of the post data needs to be present in a way that is accessible and portable.

So regardless of how you structure it in the editor, it’s stored as a chunk in the database and barfed out in templates with one command. That makes it perhaps less flexible than you might want from a templating perspective, but scopes down this change to a paleteable level and remains very WordPress-y.

It seems a lot of the controversy stems from either who moved my cheese sentiments or what it does and doesn’t support at this second. I don’t put much stock in either, as people tend to find the cheese fairly quickly and this still under what seems to be heavy active development.

A big support worry is custom meta boxes. Joost de Valk:

Fact remains that, if you test Gutenberg right now, you’ll see that Yoast SEO is not on the page, anywhere. Nor, for that matter, are all the other plugins you might use like Advanced Custom Fields or CMB2. All of these plugins use so-called meta boxes, the boxes below and to the side of the current editor.

The fact that the Gutenberg team is considering changing meta boxes is, in our eyes, a big mistake. This would mean that many, many plugins would not work anymore the minute Gutenberg comes out. Lots and lots of custom built integrations would stop working. Hundreds of thousands of hours of development time would have to be, at least partly, redone. All of this while, for most sites, the current editor works just fine.

That does sound like a big deal. I wonder how easy baby stepping into Gutenberg will be. For example, enabling it for standard posts and pages while leaving it off for custom post types where you are more likely to need custom meta boxes (or some combination like that).

On this site, I make fairly heavy use of custom meta boxes (even just classic custom fields), as well as using my own HTML in the editor, so Gutenberg won’t be something I can hop on quickly. Which makes me wonder if there will always be a „classic” editor or if the new editor will be mandatory at a certain point release.

Yet more controversy came from the React licensing stuff. That went essentially like:

1. Matt Mullenweg: we’re gonna switch away from React (which Gutenberg uses) because licencing.
2. React: You’re all wrong but we give up. It’s MIT now.
3. Matt Mullenweg: That’s good, but the talk now is allowing people to use whatever New JavaScript lib they want.

I’ve never heard of „framework-agnostic” block rendering, but apparently, it’s a thing. Or maybe it’s not? Omar Reiss:

With the new Gutenberg editor we’re changing the way the WordPress admin is being built. Where we now render the interface with PHP, we will start rendering more and more on the client side with JavaScript. After the editor, this is likely to become true for most of the admin. That means that if you want to integrate with the admin interface, you’ll have to integrate with the JavaScript that renders the interface. If WordPress chooses Vue, you’ll have to feed WordPress Vue components to render. If WordPress chooses React, you’ll have to feed WordPress React components to render. These things don’t go together. React doesn’t render Vue components or vice versa. There is no library that does both. If WordPress uses a particular framework, everyone will have to start using that framework in order to be able to integrate.

That’s a tricky situation right there. Before the React license change, I bet a nickel they’d go Vue. After, I suspect they’ll stick with React. Their own Calypso is all React in addition to what already exists for Gutenberg, so it seems like a continuity bonus.

This will be a fun tech story to follow! Sites like Post Status will likely be covering it closer than I’ll be able to.

Gutenberg is a post from CSS-Tricks

Post pobrano z: Exploring Data with Serverless and Vue: Automatically Update GitHub Files With Serverless Functions

I work on a large team with amazing people like Simona Cotin, John Papa, Jessie Frazelle, Burke Holland, and Paige Bailey. We all speak a lot, as it’s part of a developer advocate’s job, and we’re also frequently asked where we’ll be speaking. For the most part, we each manage our own sites where we list all of this speaking, but that’s not a very good experience for people trying to explore, so I made a demo that makes it easy to see who’s speaking, at which conferences, when, with links to all of this information. Just for fun, I made use of three.js so that you can quickly visualize how many places we’re all visiting.

You can check out the live demo here, or explore the code on GitHub.

In this tutorial, I’ll run through how we set up the globe by making use of a Serverless function that gets geolocation data from Google for all of our speaking locations. I’ll also run through how we’re going to use Vuex (which is basically Vue’s version of Redux) to store all of this data and output it to the table and globe, and how we’ll use computed properties in Vue to make sorting through that table super performant and slick.

Serverless Functions

What the heck?

Recently I tweeted that „Serverless is an actually interesting thing with the most clickbaity title.” I’m going to stand by that here and say that the first thing anyone will tell you is that serverless is a misnomer because you’re actually still using servers. This is true. So why call it serverless? The promise of serverless is to spend less time setting up and maintaining a server. You’re essentially letting the service handle maintenance and scaling for you, and you boil what you need down to functions that state: when this request comes in, run this code. For this reason, sometimes people refer to them as functions as a service, or FaaS.

Is this useful? You bet! I love not having to babysit a server when it’s unnecessary, and the payment scales automatically as well, which means you’re not paying for anything you’re not using.

Is FaaS the right thing to use all the time? Eh, not exactly. It’s really useful if you’d like to manage small executions. Serverless functions can retrieve data, they can send email notifications, they can even do things like crop images on the fly. But for anything where you have processes that might hold up resources or a ton of computation, being able to communicate with a server as you normally do might actually be more efficient.

Our demo here is a good example of something we’d want to use serverless for, though. We’re mostly just maintaining and updating a single JSON file. We’ll have all of our initial speaker data, and we need to get geolocation data from Google to create our globe. We can have it all work triggered with GitHub commits, too. Let’s dig in.

Creating the Serverless Function

We’re going to start with a big JSON file that I outputted from a spreadsheet of my coworker’s speaking engagements. That file has everything I need in order to make the table, but for the globe I’m going to use this webgl-globe from Google data arts that I’ll modify. You can see in the readme that eventually I’ll format my data to extract the years, but I’ll also need the latitude and longitude of every location we’re visiting

var data = [
    [
    'seriesA', [ latitude, longitude, magnitude, latitude, longitude, magnitude, ... ]
    ],
    [
    'seriesB', [ latitude, longitude, magnitude, latitude, longitude, magnitude, ... ]
    ]
];

Eventually, I’ll also have to reduce the duplicated instances per year to make the magnitude, but we’ll tackle that modification of our data within Vue in the second part of this series.

To get started, if you haven’t already, create a free Azure trial account. Then go to the portal: ms.portal.azure.com

Inside, you’ll see a sidebar that has a lot of options. At the top it will say new. Click that.

Next, we’ll select function app from the list and fill in the new name of our function. This will give us some options. You can see that it will already pick up our resource group, subscription, and create a storage account. It will also use the location data from the resource group so, happily, it’s pretty easy to populate, as you can see in the GIF below.

The defaults are probably pretty good for your needs. As you can see in the GIF above, it will autofill most of the fields just from the App name. You may want to change your location based on where most of your traffic is coming from, or from a midpoint (i.e. if you have a lot of traffic both in San Francisco and New York), it might be best to choose a location in the middle of the United States.

The hosting plan can be Consumption (the default) or App Service Plan. I choose Consumption because resources are added or subtracted dynamically, which the magic of this whole serverless thing. If you’d like a higher level of control or detail, you’d probably want the App Service plan, but keep in mind that this means you’ll be manually scaling and adding resources, so it’s extra work on your part.

You’ll be taken to a screen that shows you a lot of information about your function. Check to see that everything is in order, and then click the functions plus sign on the sidebar.

From there you’ll be able to pick a template, we’re going to page down a bit and pick GitHub Webhook – JavaScript from the options given.

Selecting this will bring you to a page with an `index.js` file. You’ll be able to enter code if you like, but they give us some default code to run an initial test to see everything’s working properly. Before we create our function, let’s first test it out to see that everything looks ok.

We’ll hit the save and run buttons at the top, and here’s what we get back. You can see the output gives us a comment, we get a status of 200 OK in green, and we get some logs that validate our GitHub webhook successfully triggered.

Pretty nice! Now here’s the fun part: let’s write our own function.

Writing our First Serverless Function

In our case, we have the location data for all of the speeches, which we need for our table, but in order to make the JSON for our globe, we will need one more bit of data: we need latitude and longitude for all of the speaking events. The JSON file will be read by our Vuex central store, and we can pass out the parts that need to be read to each component.

The file that I used for the serverless function is stored in my github repo, you can explore the whole file here, but let’s also walk through it a bit:

The first thing I’ll mention is that I’ve populated these variables with config options for the purposes of this tutorial because I don’t want to give you all my private info. I mean, it’s great, we’re friends and all, but I just met you.

// GitHub configuration is read from process.env
let GH_USER = process.env.GH_USER;
let GH_KEY = process.env.GH_KEY;
let GH_REPO = process.env.GH_REPO;
let GH_FILE = process.env.GH_FILE;

In a real world scenario, I could just drop in the data:

// GitHub configuration is read from process.env
let GH_USER = sdras;

… and so on. In order to use these environment variables (in case you’d also like to store them and keep them private), you can use them like I did above, and go to your function in the dashboard. There you will see an area called Configured Features. Click application settings and you’ll be taken to a page with a table where you can enter this information.

Working with our dataset

First, we’ll retrieve the original JSON file from GitHub and decode/parse it. We’re going to use a method that gets the file from a GitHub response and base64 encodes it (more information on that here).

module.exports = function(context, data) {
 // Make the context available globally
 gContext = context;

 getGithubJson(githubFilename(), (data, err) => {
   if (!err) {
     // No error; base64 decode and JSON parse the data from the Github response
     let content = JSON.parse(
       new Buffer(data.content, 'base64').toString('ascii')
     );

Then we’ll retrieve the geo-information for each item in the original data, if it went well, we’ll push it back up to GitHub, otherwise, it will error. We’ll have two errors: one for a general error, and another for if we get a correct response but there is a geo error, so we can tell them apart. You’ll note that we’re using gContext.log to output to our portal console.

getGeo(makeIterator(content), (updatedContent, err) => {
       if (!err) {
         // we need to base64 encode the JSON to embed it into the PUT (dear god, why)
         let updatedContentB64 = new Buffer(
           JSON.stringify(updatedContent, null, 2)
         ).toString('base64');
         let pushData = {
           path: GH_FILE,
           message: 'Looked up locations, beep boop.',
           content: updatedContentB64,
           sha: data.sha
         };
         putGithubJson(githubFilename(), pushData, err => {
           context.log('All done!');
           context.done();
         });
       } else {
         gContext.log('All done with get Geo error: ' + err);
         context.done();
       }
     });
   } else {
     gContext.log('All done with error: ' + err);
     context.done();
   }
 });
};

Great! Now, given an array of entries (wrapped in an iterator), we’ll walk over each of them and populate the latitude and longitude, using Google Maps API. Note that we also cache locations to try and save some API calls.

function getGeo(itr, cb) {
 let curr = itr.next();
 if (curr.done) {
   // All done processing- pass the (now-populated) entries to the next callback
   cb(curr.data);
   return;
 }

 let location = curr.value.Location;

Now let’s check the cache to see if we’ve already looked up this location:

 if (location in GEO_CACHE) {
   gContext.log(
     'Cached ' +
       location +
       ' -> ' +
       GEO_CACHE[location].lat +
       ' ' +
       GEO_CACHE[location].long
   );
   curr.value.Latitude = GEO_CACHE[location].lat;
   curr.value.Longitude = GEO_CACHE[location].long;
   getGeo(itr, cb);
   return;
 }

Then if there’s nothing found in cache, we’ll do a lookup and cache the result, or let ourselves know that we didn’t find anything:

 getGoogleJson(location, (data, err) => {
   if (err) {
     gContext.log('Error on ' + location + ' :' + err);
   } else {
     if (data.results.length > 0) {
       let info = {
         lat: data.results[0].geometry.location.lat,
         long: data.results[0].geometry.location.lng
       };
       GEO_CACHE[location] = info;
       curr.value.Latitude = info.lat;
       curr.value.Longitude = info.long;
       gContext.log(location + ' -> ' + info.lat + ' ' + info.long);
     } else {
       gContext.log(
         "Didn't find anything for " + location + ' ::' + JSON.stringify(data)
       );
     }
   }
   setTimeout(() => getGeo(itr, cb), 1000);
 });
}

We’ve made use of some helper functions along the way that help get Google JSON, and get and put GitHub JSON.

Now if we run this function in the portal, we’ll see our output:

It works! Our serverless function updates our JSON file with all of the new data. I really like that I can work with backend services without stepping outside of JavaScript, which is familiar to me. We need only git pull and we can use this file as the state in our Vuex central store. This will allow us to populate the table, which we’ll tackle the next part of our series, and we’ll also use that to update our globe. If you’d like to play around with a serverless function and see it in action for yourself, you can create one with a free trial account.

Stay tuned for the next installment!

Exploring Data with Serverless and Vue: Automatically Update GitHub Files With Serverless Functions is a post from CSS-Tricks