Gutenberg 12.2 Focuses on User Experience Improvements

Some Gutenberg plugin releases feel like heavy-hitters with new user-facing features. Others, such as today’s version 12.2 update, smooth over problems and create a more well-rounded experience.

Switching between the site editor and templates is smoother. The color picker is no longer a hot mess. And, border controls now use the tools panel approach of allowing users to enable or disable the options they want.

Contributors have made progress on updating the Comments Query Loop block, which will eventually be the backbone of displaying comments in block themes. One of the tallest hurdles was making nested comments work. With that now fixed, moving forward with other comment-related components should be less problematic. The latest release also introduced the Comments Pagination Numbers block for handling paginated comment lists.

View Templates Without a Page Reload

Site editor loaded with the Templates view pulled up in the WordPress admin.
Templates view in the site editor.

When Gutenberg 12.1 launched two weeks ago, I was happy to see the new and much improved slide-out panel in the site editor for viewing templates. My primary complaint: it was slow. Switching between the editor and template view required a page reload.

In the latest 12.2 release, this has all changed. Thanks to client-side routing in the site editor, the transition between the editor and templates feels fast and smooth.

Changes like this are one of the reasons I have welcomed the postponement of WordPress 5.9 until late January. Some of these little wrinkles needed ironing before showing the site editor to the world.

Improved Color Picker

WordPress block editor with the color options panel open for a paragraph. The color picker is popped up on the screen.
Color picker popup.

Gutenberg 12.2 introduces a much-improved color picker. The previous iteration was unwieldy, bulky to the point of being an annoyance. Users would have to scroll and scroll and scroll some more just to jump between changing a block’s text color and its link color. This was especially true if the theme showed both its colors and those from core.

The latest iteration tightens up the UI to the point where users can see the text, background, and link color options all at once. If they want to customize any of them, they can click on one to pull up the color picker popup.

Perhaps this change will open the door for other color options in the future, such as one for link hover/focus. It would have been far too messy in the old UI. However, the new minimalist design leaves ample room.

I would love to see the border-color control get the same treatment. However, there is a separate ticket that offers more fine-tuned control.

Font Size UI Change

Typography option open for a heading block in the WordPress block editor. It shows a horizontal list of numbered buttons (1 - 4).
Numbered-style font-size selector.

The font size control for supported blocks looks much different. It shows a list of numbered buttons for themes with five or fewer custom sizes. The font-size name appears when one is selected. Otherwise, it is simply a list of numbers with no context.

I have generally liked the progress made toward updating the block options UI. But, I am not a fan of this change. As a user, what do these numbers even mean? Is the “1” size small or medium? There is no way of knowing without testing it. Plus, the context will change from theme to theme. A UI change like this may have been OK on the back of a standardized naming scheme. However, that will be tough to implement after three years of usage.

In general, clicking a single button feels like a better experience than clicking a dropdown, followed by a second click of making a selection. I am just not sure that it works here. However, I am open to seeing where it goes upon further iteration.

There is also no visible way to clear the current selection and return to the default size. If the theme supports custom sizes, users can switch to the “Custom” field and clear it out. This is not obvious unless you stumble upon it. Users could also hit the “Reset All” button, but doing so resets all typography options.

The easiest way to avoid this UI change is for theme authors to register at least six custom font sizes. The option will automatically revert to its former dropdown select field. Fortunately, I have 13 in the theme I primarily work on, so it is a non-issue for me.

Block Template Part Hooks

Theme and plugin developers now have additional action hooks around the block template part system. These should be handy for debugging or other complex use cases.

  • render_block_core_template_part_post fires when a part is found from the database.
  • render_block_core_template_part_file fires when a part comes from a theme file.
  • render_block_core_template_part_none fires when no part is located.

7 Steps to Reduce Code Smell

I'm the founder of Tellspin, an on-call scheduler in Slack for DevOps and developers (https://tellspin.app). Helping workspaces reduce their contact footprint, resolve incidents faster, and regain deep focus.

Code smell is a way to describe code that hasn’t aged well and has the potential for a lot of issues. 

High-Performance Java Serialization to Different Formats

Java serialization is a popular mechanism where you are able to serialize and deserialize complex object graphs; for example where object A can contain a reference to object B, which in turn has a reference back to object A. The problem is that this rich functionality comes at a performance cost. However, if you do not need to serialize these types of recursive graphs, you can instead use an Open Source solution called Chronicle Wire. It has reduced complexity and uses tree-like structures which makes it very efficient. Moreover, it can be done in a lot of different formats with no need to change the coding. This article covers the basics of serialization and discusses some of the key advantages of Chronicle Wire.

Serialization and Deserialization

Serialization is about encoding java objects into bytes, for example, we have an object. Let’s say our object holds our application state, if we were to shut down our application we would lose the state, we want to first store our application's state to disk, so we serialize our java state object. This will convert the object into bytes, which can be easily stored.  Likewise, If we want to send the data stored in our java object, over the network, we first have to serialize the object, before it can be written to the TCP/IP buffer. Deserialization is the opposite of serialization, where we start with a byte and recreate an object instance. 

Best Practices for Transforming Data in Snowflake

The death of the star-schema is not exaggerated. Gone are the days of all-encompassing data warehouse models and the 24-month projects to build them.

We live in a highly disruptive, event-driven world. New analytics are required almost daily to understand how our customers, business, and markets shift. A modern data stack using the speed, flexibility, and scalability of Snowflake needs to allow an organization to “model as you go” to answer critical business questions on the fly.

Software Development Trends for 2022: Remote Work Is Here to Stay

In March 2020, the working world changed forever. By April 2020, about half of all companies reported that more than 80% of their employees worked from home because of Covid-19. Most never went back to the office—remote work is here to stay.

Forced to take life online, technology became of primal importance. Digital transformation is now a basic requirement for any organization wanting to keep up. Technology workers, already in high demand before, are now even more sought after to help build a world where we all rely on technology for the most basic activities.

WordPress Contributors Discuss the Possibility of 4 Major Releases in 2022

Last week, WordPress Executive Director Josepha Haden Chomphosy opened a discussion on how many releases the project will aim for in 2022.

“Given that we have a release in January already, I wonder if we might be able to use 2022 to attempt four releases,” Haden Chomphosy said. She proposed three different release schedules:

  • Quarterly releases: January, April, July, October
  • Trimester-ly releases: January, May, September
  • Known release and then evenly spaced targets?: January, May, August, November

When she brought it up in the #core Slack channel, a few contributors said they would like to see the project move towards more frequent releases. They were optimistic that it can be done, since a January release is already on the schedule.

Responses to the post on make.wordpress.org were markedly different. A few commented that they would be comfortable with a quarterly releases as long as they avoid major holidays. Several participants in the conversation have urged WordPress to slow down to two or three releases. Others suggested WordPress simply wait to release new features until they are ready, with no schedule. This particular suggestion makes it difficult for various stakeholders, like hosting companies, agencies, and WordPress product businesses, to plan effectively.

In 2021, WordPress released version 5.7 in March and 5.8 in July. A third major release planned for December was postponed due to critical blockers and decreased volunteer availability. A jump to four releases next year seems overly ambitious without a change in processes.

“Is it realistic to plan four releases for 2022 right after three releases per year plan was not fulfilled?” Oleg Kharchenko asked in the comments. “I don’t get what’s the benefit of having more releases just for the sake of number. It looks good in business reports but it has no real value for WordPress users as frequent releases lead to half-baked features which are hard to use.

“Also plugin and theme authors will have to put more time into testing instead of their product development. Finally, there are many tickets on Trac with ‘early’ keyword which are punted for years just because everybody is too busy to find time to include these tickets in the upcoming release, making the release schedule tighter would worsen this situation even more.”

Jessica Lyschik, a developer and an active member of the German WordPress community, said she would prefer two releases for the future.

“As several people already mentioned, planning more releases did not work out in the past, so why should it work now?” Lyschik asked. “5.9 got postponed to have refined features included so it can be actually used. The complexity of the new features is huge and trying to split that up in smaller releases is not something I see to work in the future.”

The roadmap for 2021 originally planned for four major releases but was scaled back to three in February. At that time Haden Chomphosy cited a lack of automation and the necessary personnel to execute the plan without risking contributor burnout and update fatigue.

WordPress core committer John Blackbourn commented on the discussion, urging Haden Chomphosy to elaborate on why she is proposing the potential of more frequent releases. He also requested she summarize the original list of challenges and needed changes and the progress that has been made towards improving them.

In a post titled “Why I Voted to Delay WordPress 5.9,” Anne McCarthy explained a few of the factors and blockers that caused the release to be postponed to January 2022.

“What I’d like to understand better is what are we going to do to make sure this doesn’t happen again?” WordPress 5.9 release lead Matt Mullenweg commented. “There could always be more polish, more bugs fixed, and I would challenge you to pick a year in the past decade that didn’t have its share of human issues. I’d like us to really understand and agree what went wrong, particularly in the first months of 5.9, and what we’re starting now to make sure 6.0 is effortlessly on time.”

McCarthy responded, citing the following reasons:

  • lack of contingency plans around the interrelated features
  • lack of clarity around scope for various individual features (particularly the browsing feature)
  • lack of a comprehensive check in early enough ahead of feature freeze
  • a need for more decision makers who have a high level view of where the work is headed

“Personally, I’d love to see the Go/No Go meeting overhauled to be less aspirational and more concrete as to where things stand as I think that’ll set the tone early enough in the release cycle to avoid some of these problems again,” McCarthy said.

A few of these challenges with 5.9 correspond to the items Haden Chomphosy identified in February as needing to change in order to make WordPress releases easier and more frequent: better testing, more seasoned core developers available with time focused on core, better handoff in design/dev iterations, and shifts in collective philosophies towards continuous development.

In the absence of a comprehensive 5.9 retrospective, it may be difficult to plan the next year’s release schedule based on the reality of what contributors experienced most recently. Moving to four major releases will be a tough sell after closing out a year where WordPress could not post three major releases. It will require significant changes to how the work is scoped and managed as it is in process. The topic will be up for discussion again during today’s weekly core dev chat at 20:00 UTC.

eBPF: Observability with Zero Code Instrumentation [Video]

Current observability practice is largely based on manual instrumentation, which requires adding code in relevant points in the user’s business logic code to generate telemetry data. This can become quite burdensome and create a barrier to entry for many wishing to implement observability in their environment. This is especially true in Kubernetes environments and microservices architecture.

eBPF is an exciting technology for Linux kernel-level instrumentation, which bears the promise of no-code instrumentation and easier observability into Kubernetes environments (alongside other benefits for networking and security).

Five Ways to Integrate API Testing into the DevOps Pipeline

So, you’ve decided to publish an API! Perhaps your API will make it easier for customers to discover and purchase your products. Or maybe it will expose readings from air quality sensors in remote locations. Regardless of your domain, you are ready to take advantage of the growing API economy in order to add value to your business. 

Developer’s Guide to Building Notification Systems: Part 4 – Observability and Analytics

This is the fourth and final post in our series on how you, the developer, can build or improve your company’s notification system. It follows the first post about identifying user requirements, the second about designing with scalability and reliability in mind, and the third about setting up routing and preferences. In this piece, we will learn about using observability and analytics to set your system and company up for success.

Developing an application can often feel like you're building in the dark. Even after development, gathering and organizing performance data is invaluable for ongoing maintenance. This is where observability comes in—it’s the ability to monitor your application’s operation and understand what it’s doing. With close monitoring, observability is a superpower that allows developers to use various data points to foresee potential errors or outages and make informed decisions to prevent these from occurring.

347: Using Notion

Rachel and Chris dig into the many, many ways in which we use Notion at CodePen. Heads up, Notion has sponsored a couple of episodes of CodePen Radio lately, but not this. It’s just a tool we heavily use and this podcast is all about that sort of thing. Heck, this podcast itself was planned in a calendar database on Notion, which deals with dates, publication status, sponsors, and all sorts of stuff. And it’s probably one of the least involved Notion setups we have. Much more involved is stuff like project planning and our individual structures for our company-public weeknotes.

Time Jumps

  • 00:28 Topic introduction
  • 01:21 Tools we’re using for CodePen
  • 04:51 Getting buy in from the team
  • 07:57 What is Notion?
  • 10:55 Multiple views of the same data
  • 13:58 What does CodePen actually use Notion for?
  • 20:04 Sponsor: Jetpack Backups
  • 21:27 Second brain storage
  • 23:44 Roles and permissions in Notion
  • 31:14 Other features of Notion
  • 36:37 Fav Notion recent feature

Sponsor: Jetpack Backups

The big news from Jetpack is that all backups are realtime now. Realtime backups are awesome. Anything that happens on your site, it’s backed up immediately. That makes backups extremely useful as there is no risk you have to miss three-quarters of a day of content, purchase, comments or anything else because all you have is daily backups.

The post 347: Using Notion appeared first on CodePen Blog.

How To Move IBM App Connect Enterprise to Containers – Part 2(a)

Scenario 2(a): Deploy a Simple Toolkit Message Flow Onto Red Hat OpenShift Using the Command Line Interface (CLI)

In Scenario 1 we took a simple flow from IBM Integration Bus and demonstrated we could get it running in IBM App Connect Enterprise on an isolated Docker container. This was a good start, but of course, in a real production environment, we would need more than just an isolated container. We would want to be able to create multiple copies of the container in order to provide high availability and to scale up when the incoming workload increases. We would also need to be able to automatically spread the workload across all those container replicas. 

This and much more is what is provided by a container orchestration platform, and the most commonly used platform today is of course Kubernetes. In this scenario, we’re going to take that same simple flow and deploy it onto Kubernetes and demonstrate some of these orchestration platform features