A common case of refactoring-gone-wrong is when refactoring becomes a large project in a branch that can never be merged because the refactoring project is never completed. The refactoring project is considered a separate project, and soon starts to feel like "The Big Rewrite That Always Fails" from programming literature.
The work happens in a branch because people actually fear the change. They want to see it before they believe it, and review every single part of it before it can be merged. This process may take months. Meanwhile, other developers keep making changes to the main branch, so merging the refactoring branch is going to be a very tedious, if not dangerous thing to do. A task that, on its own, can cause the failure of the refactoring project itself.
So can't we use a branch for refactoring? Of course we can. But it has to be a short-lived branch. How can you ensure that a branch is short-lived?
Following this set of rules is a great idea for any branch, not just refactoring branches. But it's even more important there, since the changes are likely to span many, and remote parts of the code base, which makes the risk of merge problems bigger.
What often happens is that we change a method in a way that requires updating all its clients. It takes a lot of time to do this work, and so we end up with either a very large commit, or a commit that just takes a lot of time to make, meaning that we don't follow the first rule of short-lived branches.
Something else that could happen is that we are just viciously updating code all around the code base, and we commit the changes because everything seems alright, but then our quality assurance tools tell us something is wrong. When we get the results back from CI, we add another commit that "Fixes tests" or "Makes PHPStan happy". When working with short-lived branches, ensure that everything is okay before committing (or set up a pre-commit hook so you can't forget to do this).
Creating small commits that pass all the tests, the result should indeed be that our branch can be merged at all times. This for me is closely aligned to a thought I always have in mind when programming: what if someone pulls the plug on this project today? I don't want my effort to be wasted, I don't want my branch to be deleted without merging. So when I work on something I always aim for it to be useful for the team, the company, its users, etc.
One way to make sure that you always add value to the project is to establish goals for which the following is true:
We'll take a closer look at refactoring goals in the next article.
Refactoring projects require short-lived branches, where every commit can be merged in the main branch immediately. You should be able to stop the refactoring project at any time, while still leaving the project in a better state.
Your design voice – or design style, if you will – is how you choose to relay information to your audience. That sounds simple, but for the uninitiated, it can be incredibly confusing.
I have a confession to make: when I started writing this article, I was stumped at how to best phrase my main idea. I had something important I needed to tell you wonderful readers, but I just wasn’t sure how to do it.
Then it hit me that I wasn’t approaching it in a writing voice I recognized as being “mine.” I was attempting to get too lofty with my idea (since it’s so important and all), and missing the point of my own message. How’s that for irony? In your face, Alanis Morissette.
I eventually decided to scrap what I was originally going to write about, and start over in my own personal style. I love telling stories, and I think that’s where I shine as a writer. Plus, I’m incredibly modest, as you can tell.
So, what is voice? What is personal style, and how can we creatives develop it? One thing’s for sure – it’s not just something for writers to think about. Creative professionals of all stripes struggle with developing their own unique way to express their ideas, especially with so many amazing people out there doing things we admire and are inspired by.
It can be hard sometimes to separate what you admire from who you are, but it’s certainly doable. The key is knowing how to interpret the feedback you get from others.
It’s entirely possible to say one thing dozens, and sometimes even hundreds of different ways. Typography is the best way to illustrate this point. A poster that doesn’t hold back with the chunky slab serifs is going to have a completely different emotional impact than one that uses a delicate, understated script – even if the message is exactly the same.
The design language you use will be different depending on who it is you’re trying to reach. I say language quite deliberately because I compare what we do for our clients as designers to what an interpreter does for two people who speak different languages.
Interpreters create commonality and facilitate conversation between two opposite forces, much the same way that a designer facilitates a communication between their client and their client’s audience. You take what your client has to say and tell it to their audience in a way that’s clear for both parties to understand.
When you develop your own personal design voice, you are effectively alienating those people who don’t care for your style, just like a baby’s brain closes itself off to all of the potential sounds a human being can make in favor of the particular set it learns from its parents.
When you’re born, you can effectively speak every language. But the more you learn and listen, the more certain words and sounds take precedence over the others.
By the time you can talk, you’re communicating in whatever your first language is, excluding all the others you could have learned instead. It’s impossible to try to learn every single language in the world, so why should you try to earn the approval of every single person with your design work? The best way you can use your own voice is to reach people who want to hear your specific message.
The world in general wants you to be bland and inoffensive, easy to understand and digest. But your niche audience wants the compelling visual narrative that only you can give them.
Without a doubt, the best way you can expand your own design fluency is by learning from others. Like I said, there’s a ton of exciting, creative work out there that inspires us all, and the argument has certainly been made many times that there’s “nothing new under the sun” in terms of ideas. But there comes a time when design inspiration can go too far and veer off into plain old copyright infringement.
In 2010, copyright representatives for Dutch author Dick Bruna successfully sued Japanese heavyweight Sanrio for copyright infringement over Sanrio’s white bunny character, Cathy.
Bruna, who created the white bunny character Miffy in 1955, said explicitly that Cathy was “a copy” of his famous children’s book bunny, who was very popular in Japan several decades before Sanrio began licensing their character designs. But Sanrio’s Cathy was pretty obviously done in Sanrio’s own style – the bunny character looks very much like their iconic Hello Kitty.
Was Sanrio merely designing in their signature style, or was it in fact a deliberate infringement on Bruna’s copyright? There are plenty of incidences of simultaneous design, when more than one person comes up with the exact same or a series of very similar ideas at around the same time. But as a general rule, unless you can prove in court that you were the original holder of a copyright, it’s not really a good idea to fall victim to that kind of unknowing.
Doing your research, involving yourself in the creative community, and making sure you know who your competition is are vital steps to maintaining your reputation as an original designer with an original voice.
As Albert Einstein said, “the secret to creativity is knowing how to hide your sources.” Being inspired means not being ignorant of what your peers are doing.
Remember, your main goal as a freelancer is getting repeat customers who respond well to your unique voice. If you’re telling your own stories and drawing from your own personal experiences, it’s virtually impossible to create designs that look just like everyone else’s.
You can’t help but be original when you’re being authentic.
The post Finding and Using Your Own Design Voice appeared first on Speckyboy Design Magazine.
WordPress 5.7 Beta 3 is now available for testing! 
This software is still in development, so it’s not recommended to run this version on a production site. Consider setting up a test site to play with it.
You can test the WordPress 5.7 Beta 3 in two ways:
Bleeding edge channel and the Beta/RC Only stream)The current target for final release is March 9, 2021. That’s just three weeks away, so your help is vital to making sure that the final release is as good as it can be.
Since Beta 2, 27 bugs have been fixed. Here is a summary of some of the included changes:
register_block_type_from_metadata function (#52301)paginate_links function (#44018)Watch the Make WordPress Core blog for 5.7-related developer notes in the coming weeks, which will break down these and other changes in greater detail.
So far, contributors have fixed 171 tickets in WordPress 5.7, including 64 new features and enhancements, and more bug fixes are on the way.
Do some testing!
Testing for bugs is a vital part of polishing the release during the beta stage and a great way to contribute. 
If you think you’ve found a bug, please post to the Alpha/Beta area in the support forums. We would love to hear from you! If you’re comfortable writing a reproducible bug report, file one on WordPress Trac. That’s also where you can find a list of known bugs.
Props to @audrasjb and @lukecarbis for your peer revisions.
Finish line ahead
Defects in focus
We are almost there…
Latest PECL Releases:
Since I've been writing a lot about decoupled application development it made sense that one of my readers asked the following question: "Why should we use a framework?" The quick answer is: because you need it. A summary of the reasons:
So, yes, you/we need a framework. At the same time you may want to write framework-decoupled code whenever possible.
Here's a summary of the reasons. If all of your code is coupled to the framework:
Pushing for a big and strong core of decoupled code, that isn't tied to the database technology, or a particular web framework, will give you a lot of freedom, and prevents all of the above problems. How to write decoupled code? There's no need to reinvent the wheel there either. You can rely on a catalog of design patterns, like:
None of these classes will use framework-specific things like:
For me good rules of thumb to test the "decoupledness" of my business logic are:
1 and 2 should be unconditionally true, 3 allows some room for coupling due to the age-old problem of mapping entities to their stored format. For instance, you can have some mapping logic in your entity (i.e. instructions for your ORM on how to save the entities). But at least there shouldn't be any service dependencies that are specific to your choice of persistence, e.g. you can't inject an EntityManagerInterface or use a QueryBuilder anywhere in your code classes. Also, calling methods should never trigger actual calls to a database, even if it's an Sqlite one.
If you do all of this, your framework will be like a layer wrapped around your decoupled core:
This layer contains all the technical stuff. This is where you find the acronyms: SQL, ORM, AMQP, HTTP, and so on. This is where we shouldn't do everything on our own. We leverage the power of many frameworks and libraries that save us from dealing with all the low-level concerns, so we can focus on business logic and user experience.
A framework should help you:
Truncated by Planet PHP, read more at the original (another 1854 bytes)