Nimble in decision

The concept of decision entails a sense of finality. Often decisions feel like a Rodin sculpture: once for all perfectly cut. How terrible and scary is that? No wonder that many refrain from taking (major) decisions.

Can't we remove this sense of fate and rigidity from decisions and turn decision-making into a lighter thing?

Take smaller decisions

Does that decision feel too big? What could be a smaller decision in the same direction that is safe enough to take? Find it and take it. Breaking up a big decision in a series of small decisions often helps to move forward. "One Fear at a Time", as John Whitmore writes in Coaching for Performance.

Be it fear or decision, breaking it up in smaller pieces also allows you to adapt the course of action.

Embrace the imperfection of a decision

Make explicit the fact that the decision has been taken based on finite knowledge of a situation and thus corresponds to a local optimum. Finish any decision statement, with : " … until we know better".

Shouldn’t we wait then, to take better decisions? Sometimes yes. Gathering more info, giving it more thoughts is always an option. There however always comes the time when Pareto's Law kicks in, a point beyond which an imperfect decision will show greater ROI than a more perfect one.

Make it a pilot

A great question I make use of to ease my clients in taking virtuous yet still uncertain steps: "Is it safe enough to try?" Often it is. Often, this question eases the "fear of final decision".

So decide to try, before finally deciding– if you still believe that you will have to decide once for all.

Give it a revision date

Since a decision is made at a certain point in time in a certain context and based on finite knowledge, it seems only fair to review it later down the road, doesn't it? Fair and definitely smart. Even more in the case of a decision declared as a temporary one, like a pilot.

Define a revision date or install the license and/or duty to revise a decision when the need or new knowledge arises.

This works particularly well for any structural or strategic decision. Imagine how fit your organization would be if every agreement in it was due to be revised! Well, the distributed governance scheme of Holacracy makes it possible for anyone to trigger revision of the governance and Sociocracy 3.0 also advocates regularly reviewing agreements.

To go one step further down the road, I dream of an organizational system where decisions that are not revised get dropped, like an expiry date for anything decided, in order to keep organizational mass as low as possible.

Embrace exceptions to the decision

Just as a local optimum will make sense for most cases around, there will be exceptions. Let them be and shine on the light of the decision. No exception should be hidden, for hiding exceptions calls to rigidify the decision even more.

On the contrary, collecting exceptions to any decision seems to me like a good practice— I yet still have to find a domain where this happens. Every exception enriches the understanding of the decision, sharpens the scope and effects of the decision, and brings material for further revision of it.

That's all (for now) folks!

This list is not exhaustive, it simply exhausts my current thoughts on the topic. I yet decide here and now to share it with you as such. Definitely safe enough. And the digital medium gives me the license to revise it later down the road ;)

I hope this gives you a few concrete ways to take the next decision with a bit more joy and serenity.

Artwork: Stereophotography of the Grindelwald Glacier

Without User Consent: An Ethical Dilemma for WordPress Plugin Developers

I recently discovered that a popular WordPress plugin had enabled automatic updates without explicitly informing users. How did I find out? I received emails from each site where the plugin was installed informing me that an update had been completed.

But it gets better. Over a holiday break, a colleague asked me to look at a website that wasn’t loading properly. I turned on debugging to find that – you guessed it – this particular plugin was the culprit. The automatic update failed, and some key files were missing. Thankfully, manually uploading a fresh copy of the code fixed the issue.

The incident got me thinking about the ethics behind this move. Not just with a specific plugin author, but all WordPress theme and plugin developers as a whole. So, I reached out to others on the Advanced WordPress Facebook group to get some feedback. Should users have been notified that automatic updates were turned on?

There was some great discussion about the pros and cons of doing this. And Search Engine Journal examined the issue in an article as well. It turns out that a lot of web professionals weren’t thrilled with the idea of enabling this feature without prior notice.

With that, let’s take a closer look at this ethical dilemma faced by WordPress developers – and the development community as a whole. They are a bigger part of the job than you may think.

The Security Conundrum

One can make the case that the plugin authors were at least partially motivated by WordPress security. When a plugin has a security hole, it means websites are exposed until that exploit is patched. Historically, website owners (or their web designers) have been responsible for applying the updates.

Of course, not everyone applies updates regularly. That’s why WordPress 5.5 introduced an auto-update feature. It allows website owners to opt into updates for their themes and plugins. Minor versions of WordPress core have automatically updated for years, and WordPress 5.6 allowed major versions to do the same.

Now, your entire site can be on auto-pilot. This functionality can be a great way to limit exposure to exploits. But the usefulness of this feature isn’t really the question. It’s the implementation.

If plugin or theme authors can simply turn on this feature without informing users, it’s an accident waiting to happen. The scenario I experienced is but a minor example. Imagine if someone used this to push malicious code out to millions of sites that readily applied it. Even if it’s not likely, it’s still possible.

Does that make turning on auto-updates by default worth the risks? Or, does it outweigh the security risks of not doing so?

Make Users Aware of Changes

There are plenty of justifications for turning on auto-updates and letting users discover it on their own (or perhaps never). A common refrain is that most people don’t pay attention and therefore it’s better to protect them. Or maybe a plugin has a dependency that requires lockstep updates.

Maybe that makes sense in some cases. But I’d still argue that the ethical thing to do is to tell users about these types of changes. Or, at least make an honest effort to do so.

The WordPress notification UI is littered with messages about Black Friday sales and new features. Why not use it to communicate something important? Even if it gets lost in the clutter, at least a plugin author can say they tried.

Taking it a step further, clearly announcing such a change in an official blog post, social media or support forum would also be helpful. Any channel of communication that connects developers to users is game.

The Better Option? Let Users Decide

I believe that one of the biggest lessons to come out of this situation is that turning on a potentially-breaking feature without notice is bad for customer relations. And, despite the good intentions of a developer, some people are going to take issue with the practice – quite loudly.

It’s reminiscent of the time Apple included a U2 album in everyone’s iTunes account. What was supposed to be an act of benevolence was met with, well, rage in some cases.

For WordPress plugin and theme authors, the better path may be to encourage automatic updates. Use those same channels to advocate for the feature, rather than forcing users to opt-out. That builds trust as opposed to suspicion.

Will as many people use the feature? Probably not. But the psychology at play here will make you look better in the eyes of the people who use your product. They’ll be more likely to stick with you and make future purchases.

Very few things are certain in life. But you can usually count on users to tell you what they think of your decisions. Therefore, it’s important to listen and learn.

The post Without User Consent: An Ethical Dilemma for WordPress Plugin Developers appeared first on Speckyboy Design Magazine.

Community News: Latest PECL Releases (01.12.2021)

Latest PECL Releases:

• igbinary 3.2.2RC1
  * Update php version check to allow igbinary to be statically built in PHP 8.0+
  • Fix bug in out of memory error handling in __sleep, slightly speed up serializing with __sleep.
  • Continue serializing remaining properties if a missing property name is returned from __sleep.
  • Speed up serializing by optimizing for the case where there is no memory manager override. When there is a memory manager override, only use that for allocating the string to return. (benchmarks/serialize-scalar-int.b.php showed a speedup from 0.22 to 0.18 seconds for repeated serialization of a single scalar, and from 0.186 to 0.180 seconds for benchmarks/serialize-stringarray.b.php for an array of strings)
  • Speed up unserializing arrays in php 7.2-8.0 by adding optimized code for finding the hash bucket of a string/integer key of an array, or creating a placeholder if it does not already exist.
• vld 0.17.1
  - Added support for PHP 8.0.
• swoole 4.6.1
  Enhancement --- + Added --enable-thread-context option (#3970) (@matyhtf) + Strict session_id, check the connection activity (#3993) (@matyhtf) * Optimized CURLOPT_PROXY, support user, pass and scheme (swoole/library#87) (sy-records)

  Fixed

  • Fixed minimal PHP version (#3979) (@remicollet)
  • Fixed pecl install missing enable-swoole-json and enable-swoole-curl options (#3980) (@sy-records)
  • Fixed openssl thread safety issue (swoole/swoole-src@b516d69) (@matyhtf)
  • Fixed enableSSL coredump (#3990) (@huanghantao)

  Kernel

  • Optimized ipc writev, avoid coredump how event data is null (#3994) (@matyhtf)
• swoole 4.5.11
  Enhancement --- * Optimize table (#3959) (@matyhtf) * Enhancement CURLOPT_PROXY (swoole/library#87) (@sy-records)

  Fixed

  • Clear all columns when incr and decr (#3956) (@matyhtf)
  • Fixed compile error (49fea171) (@matyhtf)
  • Fixed fread bugs (#3972) (@matyhtf)
  • Fixed openssl thread safety issue (7ee2c1a0) (@matyhtf)
  • Fixed Invalid argument supplied for foreach (swoole/library#80) (@sy-records)
  • Fixed trigger_error param error (swoole/library#86) (@sy-records)
• PKCS11 0.1.1
  - Added a lot of new test cases - Refactored some Object related functions
• maxminddb 1.9.0
  * The `maxminddb` extension is now buildable on Windows. Pull request by Jan Ehrhardt. GitHub #115.
• gRPC 1.35.0RC1
  - gRPC Core 1.35.0 update - Removed zend_hash_destroy() from postfork handler #24891
• yac 2.3.0
  - PHP8 Supported
• yaf 3.3.0
  - PHP8 Supported - Fixed issue #508 (Route::addConfig take action as module wrongly) - Fixed issue #509 (getViewpath return NULL) - Fixed issue #513 (supports of custom camel MVC name) - Fixed issue #518 (setRediect not working)
• swoole 4.6.0
  Backward compatibility Break --- * Removed the maximum limit of session id, never repeat (#3879) (@matyhtf) * Disabled unsafe function when use Coroutine, including pcntl_fork/pcntl_wait/pcntl_waitpid/pcntl_sigtimedwait (#3880) (@matyhtf) * Enabled coroutine hook by default (#3903) (@matyhtf)

  Remove

  • No longer support PHP-7.1 (swoole/swoole-src@4a963df) (swoole/swoole-src@9de8d9e) (@matyhtf)

  Deprecated

  • Marked the Event::rshutdown() as deprecated, please use Coroutine::run instead (#3881) (@matyhtf)

  New APIs

  • Supported setPriority/getPriority (#3876) (@matyhtf)
  • Supported native-curl hook (#3863) (@matyhtf) (@huanghantao)
  • Supported object style callback parameters for Server, off by default (#3888) (@matyhtf)
  • Supported ext-sockets hook (#3898) (@matyhtf)
  • Supported duplicate header (#3905) (@matyhtf)
  • Supported SSL sni (#3908) (@matyhtf)
  • Supported hook stdio (#3924) (@matyhtf)
  • Supported capture_peer_cert option for stream_socket (#3930) (@matyhtf)
  • Added HttpRequest::create/parse/isCompleted (#3938) (@matyhtf)
  • Added HttpResponse::isWritable (swoole/swoole-src@db56827) (@matyhtf)

  Enhancement

  • All time accuracy of Server changed from int to double (#3882) (@matyhtf)
  • Added poll EINTR check for swoole_client_select (#3909) (@shiguangqi)
  • Added coroutine deadlock detect (#3911) (@matyhtf)
  • Supported closing the connection in another process with server base mode (#3916) (@matyhtf)
  • Optimized send to worker from master, reduced memory copy (#3910) (@huanghantao) (@matyhtf)

  Fixed

  • Pop Coroutine::Channel data when channel is closed (swoole/swoole-src@960431d) (@matyhtf)
  • Fixed memory error when use JIT (#3907) (@twose)
  • Fixed port->set() dtls compile error (#3947) (@Yurunsoft)
  • Fixed connection_list error (#3948) (@sy-records)
  • Fixed ssl verify (#3954) (@matyhtf)
  • Clear all columns when incr and decr (#3956) (@matyhtf) (@sy-records)
  • Fixed failed to compile with LibreSSL 2.7.5 (#3962) (@matyhtf)
  • Fixed undefined constant CURLOPT_HEADEROPT and CURLOPT_PROXYHEADER

  Kernel

  • Ignored SIGPIPE signal by default (swoole/swoole-src@9647678) (@matyhtf)
  • Supported running php and c coroutines at same time (swoole/swoole-src@c94bfd8) (@matyhtf)
  • Added TEST(coroutine_base, get_elapsed) (#3961) (@luolaifa000)
  • Added TEST(coroutine_base, get_init_msec) (#3964) (@luffluo)

Oops! Dealing with Your Freelance Mistakes

Among the harshest realities of being a freelance web designer (and a human) is that we’re bound to make mistakes. None of us can escape that fact. Therefore, we may as well accept it.

Still, there are major differences in the severity of the mistakes we make. A small misspelling isn’t quite the same as bringing down an entire website with a buggy piece of code. The same goes for the construction worker who merely forgot to install a light bulb, rather than failed to shore up that wall. Some are easier to correct and, thus, more easily forgiven.

Then there is the way we handle a given faux pas. Do we own up to it? Do we pretend it never happened? How do we react when a client calls us out?

Learning to deal with mistakes is part of the secret to long-term success for web designers. And, as someone who has made more than their fair share of mess-ups, I can attest to what works and what doesn’t.

Here are a few lessons I’ve learned about making things right again.

The Web Designer Toolbox

Unlimited Downloads: 1,000,000+ Web Templates, Themes, Plugins, Design Assets, and much more!

Web Templates

2,000+ Templates

Newsletter Templates

270+ Templates

Dashboard Templates

150+ Templates

WordPress Themes

1,200+ Themes

WordPress Plugins

550+ Plugins

Mockup Templates

8,200+ Templates

Start Downloading Now!

First, Understand What Happened

The funny thing about mistakes is that we don’t always immediately recognize them. It may be hours, days, weeks or months before one makes itself known to you. Therefore, its origins may be difficult to figure out.

When it’s something simple like a misspelled word, you’ll likely be able to track down what happened (Side Note: It’s always a good idea to proofread what a client sends you). But other issues can be much harder to trace. You may have to pore over code or user logs to get the necessary clues.

Why is it important to gain an understanding of what happened? For one, this information can help prevent a similar event in the future. That’s why we talk about learning from our mistakes, after all.

On the other side of the coin, it’s also worth knowing just whose mistake it was. In some instances, you may be the culprit. But clients and software vendors may also be to blame.

To be clear, it’s not really about assigning blame to someone. Rather, the idea is to simply understand the problem. That way, you can take preventative measures. It’s also useful in the event you have to defend yourself against an accusation.

Best of all, you’ll sleep better knowing exactly what went wrong. This type of knowledge is crucial for getting some peace of mind.

To Report a Mistake…or Not

Honesty is generally the best policy. And, let’s face it, there are certain mistakes that you couldn’t hide if you wanted to. A mishap that causes a site to go down isn’t so easy to sweep under the rug.

That aside, not every single mistake is worth reporting. This is particularly the case when the issue and impact are relatively small.

Consider an update to an eCommerce website where you’ve posted the wrong product image. If you immediately discovered the mix-up and rectified it, you probably don’t have to worry about letting your client know.

Of course, the bigger the impact, the more compelling a case for filing a report. If it’s something that a customer may have noticed or has the potential to hurt sales, that information should be shared.

It’s also worth considering both your own conscience and your client’s personality. Some people want to be informed about every step (good or bad), while others aren’t so concerned. At the same time, you might find yourself wanting to tell every detail just to make sure things are out in the open.

Ultimately, this is a judgement call – choose wisely!

Dealing with the Aftermath

Cleaning up after a mistake can be a multifaceted process. What’s involved really depends on the type of issue and the impact it has had on your project.

First and foremost is rectifying the design and technical aspects. Hopefully it’s something you can fix-up without too much trouble. At the very least, you should have backups of all key files on hand. This will allow you to revert to a previous version should the situation call for it.

The scariest part can often be discussing the issue with your client. No one likes to get called out. But, in my experience, most people are both understanding and forgiving. You just need to give them a chance.

The best approach is to calmly explain what happened in layman’s terms. You don’t have to go into every last detail unless your client asks. A general overview will usually be enough.

From there, mention any steps you can take to ensure the mistake doesn’t happen again. Sometimes a client has a role to play as well. For example, if their request wasn’t immediately clear and you changed the wrong thing – let them know. Better communication (not to mention asking questions) is often the best way to avoid mishaps.

Overall, this is an area where a strong designer-client relationship can make a difference. Mutual respect and trust enable you to work through these inevitable ups and downs.

Take Charge of Your Mistakes

Perhaps the biggest lesson here is to take charge of whatever situation you find yourself in. This will demonstrate both character and competence. Clients will respect you for it and you’ll gain some inner peace as well.

When you’re in a position to impact a project (positively or otherwise), a certain amount of leadership is required. Therefore, stand up and take the appropriate actions when you make a mistake. By rising to the challenge, you’ll gain the confidence you need to keep moving forward.

The post Oops! Dealing with Your Freelance Mistakes appeared first on Speckyboy Design Magazine.

Xdebug Update: December 2020

Truncated by Planet PHP, read more at the original (another 629 bytes)

Letter to a young Scrum Master

Yes, it's a terrifying role

So that's it, you have passed the certification for Scrum Master and it is time for you to join the team and play the role. You are terrified, and I understand why. After all, you're lucky we've spared some budget for this role and you'd better make the team perform better right away so your position is maintained. All eyes on you. If you don't make it, we give it all back to the almighty Project Manager. In the spotlight of all these expectations, here is an invitation to take a step back and relativize.

It's not about you, it's about the team

Most importantly, it is not about you, and will never be. It is about the team. So do not carry its destiny upon your shoulders. All you will ever do is serve them and hold a mirror to them. That's it. You have to walk with them, not ahead of them. Your angle is the one of curiosity: "Oh, have you noticed that? What do you think about it?". Naive is powerful, because it blows away all preconceptions. You can, over and over, invite your team to look at the status quo with a fresh angle, which may inspire them to take action, or try new things (and follow up on them). If you've managed that, your job is done.

Start from where the team is

It is also a bad idea to go in with an upfront plan of how you want to "change how things are run". Chances are there are many assumptions in your head, which may be completely off. Instead of bulldozing your way into the team, blasting and criticizing whatever is present, I urge you to think that whatever is in place has been put in place by professionals. The way the team functions today is how it has best overcome problems so far, so respect that. I'll quote the Kanban principle: "Start from where you are". And from then, lead the team to experiment, little by little. It may come a long way.

Don't wait to be ready

The polar opposite of this attitude is also very tempting. It is to remain paralyzed. "I don't feel ready". Who does? While it is certainly a good thing to attend a course and obtain a certification, there are enough books, articles and conferences on Scrum and Agile to fill several lifetimes. For the benefit of your team, don't wait until you've read them all. Practice is going to be your teacher. The best there is. Just like the team, you are going to do the best you can, day after day, and for sure it's not going to be perfect...

Look for criticism

... So there will be criticism. That is great news. If nobody says anything, that means everybody thinks you're beyond the point of recovery and it's not even worth it anymore to give feedback. Constructive criticism is your ally in doing a better job for your team. I even advise you to actively seek feedback. There are retrospective activities tailored just for that, such as "Build Your Own Scrum Master". Make it a game for the team. That way, you show that though you take the role seriously, you certainly do not take yourself seriously.

About today

So, what about today? Day One? Well, two postures I've previously written about are always available: The Servant and The Mechanic. As a servant, there's probably a hand you can lend to the team right now. Ask around, and remember, a chore is not a chore. It's a chance to lead by example. If you pull your finger out for your teammates, you'll not only shine but you'll also inspire them to do it more as well. As a process mechanic, have a look at the team's Scrum. How is the next sprint coming along? Is the backlog prioritized? If you have chosen User Stories to express needs, are there enough of them in a ready state? What does "Ready" mean for your team? Those are great conversation starters. Dive in. And if anything's off, investigate, don't blame.

Get accompanied on the journey

Sure, all of this is still a handful. But you don't have to go it alone. There is a tremendous global community of practice and many local ones too. Don't be afraid to check out scrum.org forums, browse meetup.com for groups near you – or far away from you, as remote work has made the world even flatter than before. If there are several Scrum Masters in your organization, hook up with them, set up weekly coffees to exchange your war stories. And if you feel like getting accompaniment on your journey, don't hesitate to reach out. Whether it is me or one of my colleagues from the Liip coaching team, it would be with pleasure to walk along with you.