No auto-embed yet, but because I don’t really see the point, I’m sure it’s gonna be uuuge.
In my job, I work with a lot of meta-data. (If you’re not sure what meta-data is, go search the web & come back; I’ll wait here…)
I’m frequently annoyed at a lack of an icon for it. Unlike technologies like RSS, HTML5, and so on, meta-data is harder to visualize and define because it means many different things in many different applications.
In WordPress, meta-data traditionally refers to our arbitrary key-value storage system for primary objects like posts, comments, users, taxonomy terms, and so on. It also refers to the team of mostly-volunteer staff that help build & maintain wordpress.org and the surrounding galaxy of sites connected to it.
Right now, WordPress’s Meta team uses the
networking icon as it’s mark, which isn’t bad, but I don’ really think it’s right. It looks like this:
I was also working on a WordPress plugin for multisite blog-meta, and couldn’t find a suitable icon, so I decided to take a stab at one myself.
Of course, it’s likely a similar design exists somewhere for something else (and any similarities are accidental & coincidental) and I have a bad habit of thinking I’ve invented something only to learn someone on the web beat me to it.
I figure, it’s better to put something out into the world for scrutiny sooner, so here’s what I came up with in a pinch, and you can see it in action here:
All of the assets are up on Github, pull-requests encouraged. ❤️
P.S. Please don’t sue me if this icon is already a thing. I promise, I had no idea, and Google’s reverse image search came up empty, so maybe you should look into that instead of bothering lil’ol me.
Tone is more important than the words you use, until all you have is words. On the web, we’ve skirted tone for a long while with emoticons.
:) Thankfully, the wide adoption of Emoji is rescuing us from writing obscure combinations of syntactically invalid punctuation, and I think that’s a good thing.
If you read as much as I do, then you already know words like “just” & “that” unintentionally discredit your ideas and pitches; you know body language & confidence will win people over more than a lexicon of jargon; you know how hard it is to put biases aside and trust the data.
The data about written communication, is that we all suck at it.
Everyone, across the board, at both reading & writing, sucks at it, including me. I spend a lot of time, most of my professional career, not just thinking about social software, but how to improve both the value and the return-on-investment of the ways people socialize online. I think the answer, for me, is etiquette.
Different groups of people, teams, factions, etc… have an established rapport. They found communication styles & mechanisms that work well enough for them to have considered that problem solved-enough, so they can move onto solving bigger problems. When these patterns deviate outside of traditional or societal norms, is when it becomes increasingly difficult to break into those groups.
On a large scale, I can’t break into the Japanese WordPress User Group because I don’t speak a lick of Japanese. On a smaller scale, I can’t help my village planning commission make decisions because I don’t know any of the ordinances. At home, I can’t tell what Paul the dog is really thinking because he only understands a few dozen words and I don’t speak dog very well.
For teams of humans, working together to address intersecting needs, we’ve worked for thousands of years to lower the barrier of entry into these groups. Grunts turned into syllables, words, phrases, and sentences. We introduced syntactical structure to convey pauses, stops, and rests. But when the web exploded, we froze almost all written language because it’s now the web’s biggest dependency. We can’t delete “Q” from the English language entirely because
wp_enqueue_script wouldn’t work anymore.
All of this is to say, that we need to learn how to do better with what we have today, because there won’t be much new for the rest of our lives when it comes to written communication. To do that, means a few different things…
- Lurk. We all need to read, listen, & absorb. This includes understanding the general vibe of who is all involved, and deciding if it’s compatible with you.
- Respect. Groups of people have established processes. No one can change these easily, especially someone new & full of enthusiasm to rock everyone’s worlds.
- Decide. You need to choose where you think you fall in the pecking order, and make no mistake, there is a pecking order. Even flat organizations have a hidden social hierarchy. Understanding Social Dominance Theory will help you, here.
- Introduce. Once you have enough data from lurking, you can slowly start to apply what you’ve learned. Sometimes this means humor, sometimes strictly business, or other times it means only lurking and not getting involved at all.
- Pace. Now that you understand the social dynamic, and have decided where you think you belong in the group, it’s time to try to keep the pace. Traditionally, this is called “fitting in” but it’s important to earning the trust of your new acquaintances.
- Pass/fail. You’ll know pretty quickly whether any of your above efforts have resonated positively or negatively, and each interaction will echo through-out the group. Someone will mention you, one way or the other.
- Stay/bail. The level of joy you receive from any group of people should be the underlying motivator for driving your decision to stay or leave. If it’s rewarding, healthy, and fun, then stay. If it’s causing harm to yourself or others, my advice would be to consider anything else.
“Us vs. Them” is a real feeling, because we are – all of us – are constantly at odds with each other. In our base programming, we are animals, sizing each other up, and fighting for scraps. Sure; we are mostly domesticated animals, but during times of distress or high-anxiety, you can watch people become animals & treat other people that way too, and triggers could literally be anything from allergies to relationship issues to PTSD and on…
When it comes to WordPress’s leadership, or BuddyPress/bbPress, or really anything else, these same rules apply, but increasingly so because almost all of our communication is non-verbal. This means a million people may read your words and hear kindness in your written voice, but the one person you want to hear kindness may only hear rage, for reasons that may or may not have anything to do with anything you did or did not do. Phew!
My proposed solution, is etiquette. More pleases, more thank-you’s, more awareness of who is involved in what, who is in charge of what, who has earned what, and who the who’s are and what they want to be when they grow up. This means a base-level respect for everyone, regardless of your history or lack-there-of. It means reading your words back to yourself and trying to convey a smile without using
:) or 😀.
Ultimately, it means being patient, and taking the time to craft your words so they will sound like a well-intentioned contribution to your audience.
For slowing down, I’ll recommend you try switching your keyboard layout. In 2010, I switched to Dvorak – when my 100wpm plummeted to 20, those 20 words needed to matter most. Twitter’s 140 character limit maybe helps with being succinct, but I don’t know that length is as important as word-choice and knowing your audience.
Lastly, it helps to know yourself, and have a relatively clear idea of who the people around you think that you are, and how similar that is to who you think you are. If people think you’re always goofy, and you think you have something serious to offer, changing that perception is not going to be easy, and it may take a number of years to swing people around to accepting your style & approach for what it is.
I think if everyone has a bit more patience with each other, and we all take the time to consider the ripples we leave in people’s lives, we can communicate with written words in ways that don’t sink ships or hurt feelings. <3
Are you a software developer? I am, and everyday I’m embarrassed by my profession.
Every single day, I run across some website, app, video-game, program or plugin that is egregiously broken; embarrassingly broken; 5000-developers-with-six-figure-salaries-and-free-catered-lunches-and-still-can’t-get-it-right, broken.
Apps on my phone, tablet, computer, tv, and car, crash constantly, sometimes resulting in actual data loss. We shoved television behind a pay-wall in a cube that buffers and loads more than it presents anything. We broke copy & paste, because who would ever want to paste a password anywhere? Form fields do this shit where they want to autocomplete and autocorrect and autofill 3 different suggestions at once. We connected wrist-watches to the internet to draw doodles back and forth that don’t even send half the time. We hid mechanical engines behind electronics so complex there is noticeable lag driving performance cars. We connected entertainment systems to airplane diagnostic systems, so passengers can see how high up they are. We connect doors to the web to unlock them remotely, but firmware updates brick them and now you’re locked out of your house. We connect smoke detectors to the web and now the entire house & every connected device in it is beeping because you grilled a burger-patty, and the app on your phone to stop them isn’t responding.
Today’s software is a perpetual nightmare machine of non-stop frustrations.
Writing software is hard, mostly for reasons that don’t actually involve the software itself. I could go on about stakeholders, or how project managers are whatever. I could say that developers should be left alone to concentrate. I could say it’s nobody’s fault because it’s everybody’s fault. I could say all kinds of trite crap to poorly defend the people that populate the position I hold most dear, and currently the most fun job I think anyone could ever hope to perform.
I could say lots of things, but they’d all be lies.
The harsh truth is that many of you shouldn’t be writing software for production use, because you’re just not that good at it yet. You’re not experienced. You haven’t shipped anything. You don’t know how to recover from the damage you will inevitably cause.
You break people’s shit – constantly, anonymously, and without repercussion. You aren’t meticulous in your life, you don’t care about etiquette, so you won’t do your employer any better, and you certainly won’t care if any of your users complain on Twitter.
Sure; mistakes happen. We all overlook stuff. That’s how you learn, right? By repeating and improving and discovering what you missed the previous times. And there is more to discover everyday, because there are more & more design patterns and philosophies and dependencies and processes and teams and stakeholders and deadlines and Carl called in sick and no one understands what he even does here anymore but it’s suddenly critical to today’s problems and why is this line of code 500 characters long and who messed up all this whitespace and why can’t we all agree not to use ternaries and why does this class inherit from 5 other classes and on and on and on.
Software is eating the world, but… garbage in, garbage out. So, what can we do?
- Be meticulous. Someone will undoubtedly refer to you as OCD, or apply some other insulting derogatory bullshit label. Screw them; they suck at their job anyway.
- Pay attention, to everything. You are the Axel Foley of software development. Writing code and fixing bugs is target practice for your soul. Do it constantly, rearrange the pieces in your mind while you shower, and take everything in. This means watching, listening, learning, while writing less and solving more.
- Be vigilant. Everything around you is intricately balanced and ready to come crashing down at a misplaced semi-colon’s notice. I’m not joking. You can very easily cause millions of dollars in revenue losses by breaking just 1 dependency in a complex chain. Code is poetry, but it’s also contagious.
- Be respectful. Push your chair in. Hold the door for everyone. Smile at people, even when you’re grumpy. Someone has to maintain the terrible decisions you’ve made once you level-up & move-on, and that’s easier to do when you like the person who’s shadow you’re in.
- Contribute to open-source. This is where you earn your lumps; not behind closed doors, not in a sweet corporate environment, and not sitting at a desk sipping a mocha-latté. You need to jump up on stage, give your best performance, and embrace the tomatoes and boos, because you’re probably going to be terrible for your first few rounds.
- If it ain’t fun, it ain’t right. Once you stop feeling joy from the software you’re writing, it’s time to move onto something else. Sitting still and being complacent isn’t healthy, even if it feels pretty natural not to burn all those calories moving on to newer and more exciting endeavors.
- Make friends. Like, real ones. Ones that will come to your wedding from across the country. These are the people that will remind you how good you are when you need them to, and they’ll have your back when you’re not having fun anymore.
- Learn how to make soup. Not even kidding. Understanding how to make the best of what few ingredients you have is essential to writing good software. Embrace your constraints, and don’t be afraid of butter or salt because they’re universally delicious.
- Challenge authority constantly. Most people have no idea what they’re doing. They were asked or tasked with a problem, and either they follow the above methods or they pass the problem on to someone else. They’re in a holding pattern, until the next big thing happens to them, instead of making big things happen around them.
- Find mentors everywhere. Follow a person around that you want to be like, take bits of pieces of what works for them, and apply them to your life. Steal, plagiarize, and sample small enough traits until you’re an amalgamation of the hippest, funniest, most awesome people you’ve ever come across.
Then, after all of that, sit down and write the best ‘effing software anyone has ever used. ❤️
Imagine you’re a company, maybe even one as big, as innovative, and as reaching as Apple. Other technology companies have prototyped & released something ahead of you.
What can you do?
If you are anything like Apple, you use their head-start to your advantage, watching & learning from their expensive educations with an end-around in your playbook. You solve remaining problems from the complete opposite perspective, investing more on the fit & finish to put out a more polished product and winning over your competition in the long game.
According to our friend Elon Musk, Tesla automobiles have logged many hundreds of millions of miles worth of data – not just about the cars, but also driver feedback, situational logging, and environmental stimuli like what the onboard cameras are seeing & calculating.
With that many logged miles and that many cars already deployed, there’s no way anyone will be able to catch up to Tesla… without help.
There are rumors of loud engine noises in buildings known to be owned by Apple subsidiaries. The web has countless renderings of what an Apple branded automobile could look like.
All of that said, I (highly, highly) doubt anyone at Apple seriously explored the idea of a complete Apple Car until recently. More likely, a fork of iOS has been in the skunkworks, plugged in and listening to a variety of engines & motors, acting as the onboard diagnostics system for future iterations of existing maker’s platforms.
In the next 5 years, Apple will unveil the results of an amazingly ambitious R&D project – a “never been attempted before in the history of the world” type of project, as Apple likes to boast.
They’ll take what they learned from scaling iCloud & HealthKit, what they learned from producing and shipping over a billion iPhones, and what they learned about third-party integration via HomeKit – after crunching billions of data points provided by humans over the course of 10 years, they’ll confidently duplicate those same efforts with people-carriers by releasing carOS.
Apple is already using iPhone motion data – or lack there of – to predict traffic patterns, jams, and identify & alert people using Apple Maps that there is some type of anomaly ahead. Spooky, if not incredibly cool.
They’ll funnel & analyze the input & output of every engine already and soon-to-be in production going forward, and be able to both make real-time decisions & provide graphical output about what your car thinks, sees, and feels.
Apple mates hard with soft, so I doubt they’ll trust companies like Honda or Nissan with their secret sauces. You can’t have the hop if you don’t have the hip, and you can’t have a car anymore without it’s eyes & ears connected to the world around it.
Naturally, you can’t copy & paste in carOS 1.0 though. Apple exercises enormous self-control, omitting the obvious to slow-roll the essential so that the stubborn masses have time to casually catch-up to their speed.
Apple’s carOS efforts, from now until 2020, will moon-shot them around the competition without them ever having released their own car. They’ll sit idly by, researching, analyzing, privately blowing up all kinds of sweet motors & engines, until they’re ready to revolutionize the ways people are transported from A to B.
Hey, Siri. Remind KITT to pick-up the kids from band practice at 5:30pm.
OK. Searching the web for “Break me off a piece of that Kit-Kat bar.”
First, I needed to remove the old
apt repository and signing key. (This prevents
do-release-upgrade -d from stopping halfway through.)
cd /etc/apt/sources.list.d sudo rm maria*
Remove old key:
# List the keys sudo apt-key list # Remove the correct key, which is the second half of PUB STRING1/STRING2 sudo apt-key del STRING2
Second, I needed to add the new
apt repository and signing key:
# Probably is already installed sudo apt-get install software-properties-common # Get the key sudo apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8 # Add the xenial repository sudo add-apt-repository 'deb [arch=amd64,i386,ppc64el] http://mirrors.accretive-networks.net/mariadb/repo/10.1/ubuntu xenial main'
Now you are safe to run
do-release-upgrade -d without any halts!
You’ll probably want to backup your `my.cnf` file too. The upgrade process will ask you to keep or overwrite your old one, and neither of those options are usually very desirable if you have tuned your MariaDB configuration at all.
To get XDebug working with Laravel Valet & NetBeans, I needed to do the following:
- Install XDebug via Homebrew:
brew install homebrew/php/php70-xdebug
- Enter NetBeans’s Preferences > PHP > Debugging:
- Change the port from
(This is because Valet runs on 9000 by default.)
- Uncheck “Stop at first line”.
(This is because Valet is listening to all requests, and
server.phpwill get hit a bunch of times in the same page refresh.)
- Change the port from
- Add this bit to the end:
[xdebug] xdebug.remote_enable=on xdebug.idekey="netbeans-xdebug" xdebug.remote_port=9001
This turns on remote debugging, and tells XDebug to look for NetBeans’s IDE key.
- Restart Valet with
valet restartin your favorite terminal app.
brew services restart php70isn’t enough here; you need to restart Valet entirely.
Live debugging using XDebug will severely degrade Valet’s otherwise snappy performance. Composer will even tell you this:
You are running composer with xdebug enabled. This has a major impact on runtime performance. See https://getcomposer.org/xdebug
This is normal. XDebug is a hugely powerful realtime interpreter, debugger, and profiler, and it’s going to slow things down while it’s listening to all that PHP chug along. (You may be able to tune this a bit using all of XDebug’s extensive settings.)
If you’re worried about battery life, most IDE’s (like NetBeans) will let you turn debug sessions on and off. So debug, do your thing, find the bug, kill the bug, and turn it off.