JJJ's Blog

  • WordPress
  • GitHub
  • Twitter/X
  • Reputation

    Yesterday, I tweeted about the recent Volkswagen debacle:

    https://twitter.com/JJJ/status/646492412098031616

    It got me thinking about the WordPress community, who the major players are, and where I might fit into it all on any given day.

    I’ll start with Automattic and work my way across from there. Full disclosure, if you didn’t know, I worked at Automattic for a few years, so some of my observations are based on internal influences from a company half the size with a different CEO, and 4 of Matt Mullenweg’s hairstyles ago.

    Automattic, is a powerhouse. They have enormous momentum that’s intimidating to compete with even when you’re trying to carve your own niche. Interested in e-commerce? Woo. Hosting? WordPress.com. The cloud? Jetpack. Backups? VaultPress. Together they’ve solved a number of small problems in huge ways, and are uniquely qualified to do so with Matt at the helm and millions in the bank.

    If you’ve read The Year Without Pants then you got a decent (if bland) idea of how the sausage is made, but my not being a part of Scott’s retelling is a metaphor for my experience at Automattic. I didn’t really bond with the team like I’d hoped, and it was the second time I had attempted to replace Andy Peatling (the first being leading the BuddyPress project) and by this time I had already felt like my reputation was in a downward trajectory.

    Ironically, my experience at 10up was pretty similar. A position opened up and I was asked to follow the enormous footsteps of two beloved engineers. I failed to gel with a company made entirely of friends from the WordPress community, I never found my stride, and I still had wandering thoughts of BuddyPress & bbPress on my mind. 10up is an agency’s agency. They move fast, work hard, and aren’t afraid to kindly cut the anchor and sail on if something is dragging behind. Needless to say, I couldn’t hang.

    The folks at WebDevStudios are doing awesome stuff with BuddyPress, but inside the WordPress community I’ve heard people say some surprisingly negative things about them. Code quality being bad, they’re unprofessional, etc… I don’t see it, I haven’t seen it yet, but if it’s true, these criticisms aren’t unique to WDS. I’ve seen worse code and experienced less professionalism from other hugely successful businesses. If those are WDS’s only problems, they are the company to bet on. They’ve doubled in size since last year, and aren’t showing any signs of slowing down.

    My friends at HumanMade have a reputation for contributing huge amounts of time & effort to pushing WordPress as a platform farther than even the folks at Automattic have been able to pull off. I think this is accurate; they’re a talented bunch of engineers that love WordPress but aren’t consumed by it, which pays off by allowing them to influence it’s direction gently and with outside perspectives.

    CrowdFavorite is, well, a favorite of mine. They’re an agency that’s known for going after and catching the whales, and being coy (in a good way) with the stories of how they caught them. From my perspective, they’re the agency that goes their own way and likes to challenge the WordPress status-quo, which is to say I like them a lot.

    Pippin Williamson and his team have a reputation for their enormous momentum and huge earning potential if they maintain their current pace. Output, output, and more output. It’s intimidating, and inspirational, and having known Pippin a long time, I’m both happy for him and proud of what he’s accomplishing.

    There are a bunch of other businesses, agencies, and independent WordPress developers out there, so it’s difficult to cite examples without injecting my own biases or forgetting some really influential people. Envato, Alley, Voce, Range, Reaktiv, WPEngine, Pagely, XWP, and on and on…

    And me? Some days I feel like my ideas are far-fetched & silly, or the entire WordPress core team is against me, or they feel like I’m working against them even though I’m trying to work a few steps ahead without being a distraction. The rest of my days are spent working on my own little corner of the internet trying to mop up what’s left of the mess of my own career, since I’m back where I started 5 years ago with some added experience & perspective, and maybe a chip on either of my shoulders about it all if I’m being totally honest.

    It reminds me a bit of an article about Jonathan Blow in The Atlantic in 2012, who earned a funny reputation in the video game industry, and once he had the zeroes in his bank account to prove his voice had value, his voice suddenly did have value. The same voice, but being backed by currency gave it breadth and range.

    In many ways, his opinions of his industry are not dissimilar to mine with WordPress (though when given the opportunity I try maybe to be a bit less brash to the people pouring their hearts into their passions with their own foibles and comeuppances.)

    There are a lot of similarities between the independent game scene and what’s going on with WordPress right now. There are huge, major players taking on and solving massive problems at a scale that no 1 individual can compete with anymore, but that also means there’s opportunity for someone to identify one specific sharp snaggy corner and file it away so no one hurts themselves on it again. I hope Flox achieves that with it’s offerings; I hope we manage to produce something widely popular so I can afford to relax for a while; I hope to earn a better reputation than I feel like I have with my colleagues and friends through cool & valuable output.

    Reputations are usually accurate, and surprisingly fickle. One person or company can devote their entire focus to something and lose it instantly, while another can have questionable ethics and still manage relative success. My point, I guess, is that reputations are earned one way or the other.

    It’s scary, and rewarding, but it’s easy to get caught up in the distraction, politics, and bureaucracy of it all, and accidentally live up to people’s perceptions of who they think you are instead of who you know you are and what you’re capable of achieving.

    Focus less on reputation, and more on ethical output, and you’ll be just fine.

    JJJ

    September 23, 2015
    Opinion, Software
  • January thoughts, BuddyPress 2.2

    With each new software release that I’m fortunate enough to contribute to, I usually take some time (or lots of time) to reflect on a few different things that I think are critical to the project and myself:

    • What went right?
    • What went wrong?
    • What did I learn?
    • What can I do better?

    With BuddyPress 2.2 imminent, here’s a brain-dump of my random and unrelated thoughts for January 2015, in no particular order:

    • Significant improvements have been made to cache-coverage, but many more are necessary, and some of our existing implementations are not ideal.
    • User statuses are pretty messy. A user’s status is a numeric value in the users database table, and there is no API in WordPress for interacting with it. Just like post statuses, anyone concerned with workflow (or activation flow in this case) is pretty much on their own.
    • The Member Type API is sweet, and I’m excited to see how developers use it. Hopefully I get to use it myself soon.
    • It seems like each ticket takes longer to test, confirm, fix, patch, and push.
    • How strictly do we enforce cache coverage, unit-test overage, inline documentation coverage, and all of the other nuances? I fear we are over-complicating each others lives with anti-progress and slowly forgetting what made BuddyPress fun to work on in the first place.
    • I need to write more unit tests.
    • I need to increase cache coverage.
    • I need to write more inline documenta… Ehh… maybe I’m okay here.
    • I sure wish PHPUnit were faster and easier to run. Netbeans has decent integration, but I haven’t figured out how to efficiently implement it into my workflow.
    • It’s been really great not juggling immense client and customer expectations in January, thanks to the funders of my recent IndieGogo campaign.
    • The old BuddyPress Default and Legacy templates are starting to look really out-of-date to me now. I wish we didn’t have so many templates to style and that creating themes was easier.
    • I continue to struggle with the cost of switching contexts during the day, between writing code, impromptu meetings, and random pings. Working nights used to help with this, and I need to come up with a healthy plan to improve my ability to come back to things once I switch away from them. I feel like I used to be better at this when I was younger.
    • That squirrel outside my window is looking pretty well fed considering it’s January.
    • I bought too much Lego over Christmas.
    • I need to take more small breaks and be more physically active during the day.
    • I need to prioritize blogging.
    • I need a nap, and it’s only 11am.
    • BuddyPress 2.2 is going to be sweet.
    • Boone did a really good job juggling both WordPress and BuddyPress core development. Note: be more like Boone, at least in this capacity (I don’t think I can eat that much pizza anymore.)
    • I’m excited for a vacation my wife and I are planning in March to celebrate our wedding anniversary. It will probably be much needed by then.
    • I broke my ankle 1 year ago, and it’s still not quite right. Likely won’t ever be the same I suppose. Guess I’ll never play the piano again.
    • Penny (our new rescue puppy) tested positive for heart-worm. Poor thing. Hopefully it’s not too bad and we get her all fixed up.
    • You are great. <3

    JJJ

    January 24, 2015
    BuddyPress, Software, Crowd Funding
  • Monument Valley Gallery

    JJJ

    November 17, 2014
    Software
  • OS X Yosemite Sam

    I’ll probably regret making this, but here we go…

    osx-yosemite-sam

    Yosemite Sam from: http://wallpapers-junction.com/Cartoons/Yosemite-Sam-Cartoon-Wallpapers.html

    Yosemite from: http://en.wikipedia.org/wiki/Tunnel_View

    JJJ

    June 2, 2014
    Software
    Apple
  • Responsive Design is a Hack

    Responsive design has become a quick-and-dirty way to say “Hey! We looked at this on not-just-a-PC!” Our users deserve so much better — something that intentionally works with the ever-increasing array of input methods. Keyboards, cursors, touch, voice, & motion; the digital world has never been simultaneously as accessible and as overtly complicated as it is today.

    Netflix does a pretty good job at wrangling the chaos, designing experiences around the input method, reducing touches and navigational elements on more simple devices and taking advantage of all available screen real-estate to maximize an interfaces usefulness.

    Maybe we’ll call it “Input Aware” or “Device Aware” design — I guess I don’t really care about the name as much as distinguishing the approach from the myriad of responsive hacks and shims floating aimlessly around our collective github toolboxes.

    I was recently reminded of the spectrum of media-types available to the CSS2.1 media spec, which largely got me thinking about how bad we are at utilizing them:

    • all — Suitable for all devices.
    • braille — Intended for braille tactile feedback devices.
    • embossed — Intended for paged braille printers.
    • handheld — Intended for handheld devices (typically small screen, limited bandwidth).
    • print — Intended for paged material and for documents viewed on screen in print preview mode. Please consult the section on paged media for information about formatting issues that are specific to paged media.
    • projection — Intended for projected presentations, for example projectors. Please consult the section on paged media for information about formatting issues that are specific to paged media.
    • screen — Intended primarily for color computer screens.
    • speech — Intended for speech synthesizers. Note: CSS2 had a similar media type called ‘aural’ for this purpose. See the appendix on aural style sheets for details.
    • tty — Intended for media using a fixed-pitch character grid (such as teletypes, terminals, or portable devices with limited display capabilities). Authors should not use pixel units with the “tty” media type.
    • tv — Intended for television-type devices (low resolution, color, limited-scrollability screens, sound available).

    CSS2.1 even comes with a handy media-groups spec to pair media-types to devices based on their anticipated attributes:

    Media Types Media Groups
    continuous/paged visual/audio/speech/tactile grid/bitmap interactive/static
    braille continuous tactile grid both
    embossed paged tactile grid static
    handheld both visual, audio, speech both both
    print paged visual bitmap static
    projection paged visual bitmap interactive
    screen continuous visual, audio bitmap both
    speech continuous speech N/A both
    tty continuous visual grid both
    tv both visual, audio bitmap both

    Typical responsive design approaches target the screen type (and maybe print) which is accidentally celebrating doing-responsive-design-wrong. To correctly respond to different devices, we need to target more than max-width and min-width in the screen media-type, and let browsers and rendering engines on our televisions and refrigerators do their jobs.

    Unfortunately for me, the software libraries I live most of my life in right now (WordPress, BuddyPress, and bbPress) are all pretty bad at this. The WordPress iOS app is a crippled version of WordPress’s relatively fantastic interface; WordPress itself barely functions on small screens and touch devices; BuddyPress & bbPress do the bare minimum to inherit surrounding styling, but don’t own the experience or set a great example in this regard as much as they might in others.

    The greater tech community needs to target more input devices, intentionally design better experiences, and stop patting ourselves on our backs for doing the bare minimum of design.

    Sure… it’s an iterative process, and yes… we’re all working hard and putting in the long hours together to improve the digital world around us, but it’s a great time to lift up our heads, unsquint our eyes, and design for the world around us instead of for ourselves.

    JJJ

    May 27, 2014
    CSS, Rants
    design, media types, Responsive
  • Netbeans menu on Mavericks Beta 6

    If you use Netbeans on Mavericks, and updated to Beta 6 (Build 13A558) you may have noticed your menu bar items fail to appear, looking something like this:

    Netbeans no Menu

    This comes from the default Java menu bar nib files being accidently removed from the build: /System/Library/Frameworks/JavaVM.framework/Versions/A/Resources/*.lproj/DefaultApp.nib

    The workaround is to install the full Java SE 6 JDK from http://support.apple.com/kb/DL1572. This reinstalls the Java SDK in the correct locations, and will be deleted on the next Mavericks update (so there’s no harm in this temporary fix.)

    JJJ

    August 23, 2013
    Netbeans, Uncategorized
    Mavericks, Menu
  • OS X Archive Utility Hanging

    OS X Archive Utility Hanging

    Recently, my Archive Utility started hanging every once in a while, when trying to open pretty small ZIP files (often under 1 MB.) The answer for me is annoying, but simple:

    Kill the appleeventsd process.

    JJJ

    February 12, 2013
    Software, Uncategorized
    archive utility, macOS, zip
  • View . files and directories in Netbeans

    By default, Netbeans keeps dot files and directories hidden from the project tree. If you want to show them, never fear — there is a way.

    Preferences > Miscellaneous > Files > Ignored Files Pattern

    ^(CVS|SCCS|vssver.?.scc|#.*#|%.*%|_svn)$|~$|^.(?!htaccess$)$

    Basically, remove the .* at the end of the regular expression, and you’re good to go.

    JJJ

    January 2, 2013
    Netbeans, Software
  • SLASH Architecture – My approach to building WordPress plugins

    I’ve fallen into a routine when building WordPress plugins; a few general rules are:

    • Avoid creating new PHP globals.
    • Avoid executing PHP code in the global scope.
    • Generous use of Actions and Filters.

    I’ve decided to name the pattern I use Slash, which stands for:

    • Singletons
    • Loaders
    • Actions
    • Screens
    • Handlers

    Singletons

    I didn’t love singletons in PHP at first, and I’m still not convinced they are ideal, but they work well at avoiding yet-another-WordPress-related Global variable. bbPress is a good example.

    The benefit of using PHP singleton’s in WordPress is they don’t create an additional PHP global to worry about getting stomped. They also allow your plugin to always exist in memory, without another plugin being able to unset it, while still working like a traditional PHP class.

    Loaders

    These are basically bootstrap functions. Their only responsibility is to jumpstart a singleton, and put it in a place for easy access. See the bbpress() function in the above bbPress link. Loaders allow you to reference your Singleton without needing to use a global variable, or pass an instance around into functions and method calls. Used like: bbpress()->foo = 'bar';

    Actions

    By hooking everything into WordPress core actions, bbPress never runs any code inline in the global scope, other than the above loader function. Also, bbPress comes with it’s own sub-actions to piggyback WordPress’s, making writing bbPress specific plugins safe and simple.

    • Actions
    • Sub-Actions

    This also includes WordPress Filters. The major difference with Filters is that they are generally more risky to use; you have to assume other plugins are already using them, and those same plugins aren’t designed to handle whatever you’re trying to do too.

    Screens

    Derived from BuddyPress, screens are basically “Views” if you’re familiar with MVC. They are how we output markup to the browser from inside PHP, WordPress, and our plugins. Screens can be modular (again, see bbPress) allowing them to work with shortcodes, widgets, and template parts. Screens typically contain all of the translatable strings and HTML markup, and sanitize any variables for output.

    Handlers

    Handlers are the equivalent of controllers in MVC. They are responsible for containing the logic that comes from requests like forms, AJAX, JSON, XML-RPC, etc… They “handle” whatever the request is, performing capability checks, validating input data, and also checking for nonces.

    Why not use MVC?

    Honestly? No reason. Slash isn’t intended to compete or replace anything, and like anything else it’s constantly evolved over time to become what it is today, and will likely change tomorrow too. MVC and other architectures work really well, and Slash is just an approach that’s worked well for me. Putting a name on the routine should help it grow, or educate me on better approaches.

    It’s also worth noting that Slash isn’t really anything new, but rather an assembly of separate methodologies combined into a single process that helps me translate my thoughts into code.

    The best way to see the Slash approach in action is to browse through the BuddyPress and bbPress codebases. If you’re an experienced developer, I’m always looking for feedback. If you’re just starting out, maybe give the Slash approach a try. Take what’s in bbPress and remix it for your own use, and let me know how it goes.

    JJJ

    December 12, 2012
    BuddyPress, bbPress, Software, WordPress
    slash, mvc
  • WordPress as an Environment

    As WordPress has matured over the past few years, my perspective has shifted to think of it as the environment I develop in. I no longer really associate myself as being a PHP developer, a front-end or back-end developer, an architect, or a designer.

    This both scares and delights me.

    To be a good WordPress developer, it helps to understand how all of the skills come together to create the perspectives I just mentioned, and how they apply specifically to WordPress — far beyond the conventions of everyone’s favorite PHP stack.

    • Front-end WordPress development requires knowledge of WordPress’s theme options, template tags, template hierarchy, theme hierarchy, and action order.
    • Back-end WordPress development requires knowledge of WordPress’s object cache, action order, what filters to use when and why, when to use custom tables, and having a plan to scale beyond WordPress’s built in table schema.
    • Architecting for WordPress requires extensive knowledge of WordPress’s action order, WordPress’s included functions and APIs, the WordPress coding standards, and liberal use of phpdoc and inline documentation.
    • Designing WordPress themes requires an intimate knowledge of what WordPress is actually designed to do, and then being able to think outside of that box to create visually stunning sites that push WordPress to it’s limits.

    Because of this, it’s safe to say WordPress is our environment now, and PHP is just the platform it runs on. WordPress is popular and complex enough now where it’s a great time to specialize on one area, and become the go-to person in that area. Taking this a step further, focusing on individual plugins or themes is actually where we are today.

    Part of what makes being a WordPress developer so fun is being able to load-up a new installation and start creating new and amazing things in a matter of seconds. As WordPress evolves with smarter warnings, sandboxing of plugin activations, and doing_it_wrong() notices, we’re watching WordPress shape-shift from a bunch of PHP scripts on a server, into the environment we create, live inside of, build enhancements for, all while individually influencing it’s direction.

    It’s at this point, WordPress and it’s community of contributors deserve much more recognition and thanks than they usually get.

    Building an environment, is hard to do.

    “WordPress as an Environment” is what comes next; a future where WordPress shields us from annoying things it can detect and protect us from, both as users and developers; an environment where WordPress can detect two plugins are trying to perform the same action, and safely prevent conflicts; one where several posts of different types will be allowed to have the same slug without colliding with each other. More over, I can’t wait until WordPress allows plugins to register template parts, so completely theme-agnostic features can be built with no additional effort. (BuddyPress, bbPress, Shopp, and WP eCommerce are making huge strides here.)

    When you think of WordPress as an Environment, you realize how much we depend on WordPress core to protect us from ourselves and each other. A future where the correct safeguards are in place to help us not shoot our own feet or get caught in cross-fire is one I hugely look forward to.

    JJJ

    August 14, 2012
    Software, WordPress
Previous Page
1 … 3 4 5 6 7
Next Page

Proudly Powered by WordPress