Half-Elf on Tech

Thoughts From a Professional Lesbian

Tag: development

  • Bad Replies to Bad Reviews

    Bad Replies to Bad Reviews

    My plugin brother, Pippin, wrote an awesome post about How to leave a good bad review. In it, he mentions a pretty common kind of email/review:

    Your crappy plugin doesn’t work. Waste of a download..

    Hmm.. I should buy pro!

    Fairly often, people get those as a review in the WordPress.org forums, and ask me (either as a plugin mod or a forum mod) to remove it. Most of the time, I don’t, and tell them that much.

    You see, the issue is not that you got a bad review. We all get them. The issue is how you handle the review. If you get a one-star review slamming your code, and you reply with a reasonable response, then you’ve taken care of the matter in a mature, adult, responsible way. If, instead, you call them names or email them, well then, we’re into the other world.

    If you’re demanding people remove a, single, one star review, in general I think you’re being childish. There are exceptions, where people are bitter and mean and everything falls into a hate-fest with slurs and pejoratives being slung around, and personal attacks galore, then you bet I’ll delete the thread. But you’ll probably get flagged for moderation too.

    Well. That escalated quickly.

    There’s a good way and a bad way to handle a bad review. The bad way comes in two main types: over reactions and under reactions. The unders, thats what you see from people like AT&T or Comcast, who pretty much ignore the complaints and use their power to delete them or shut them down. The overs are people who take their “Oh my god, this customer sucks!” to twitter and everything else, and generally make fools of themselves.

    When you’re asking me to delete a forum post that says “This plugin sucks, the author won’t refund me!” and you’ve made no attempt to handle the situation, I nearly always tell you to try first. “Hey, I’m sorry you’re upset. The no-refund policy was clearly stated on the order page, and I did attempt to work with you to resolve this, but you were asking for a major modification to the code that I didn’t feel comfortable with.” The rest of what I said, though, is gleaned from the paragraph long rant about how a three sentence review was hurting his ratings and no one was downloading his plugin anymore. Clearly because of one, erroneous, one star review.

    Go back to Pippin’s post. At the end, he shares an exchange with a very good ‘negative’ review, and a very good response. For the most part, that’s not what I see developers and the like doing. What I see is that knee-jerk reaction to an angry post, where hate feeds hate and suddenly you’re getting a bunch of bad reviews because you’ve been feeding the anger, and it’s a circle that ends with no one wanting to use your code because you’re mean.

    Recently, a developer who fell into that cycle got ‘busted’ making dupe accounts. Sock puppets, if you will. He used them to try and push his plugins, even though his main accounts were all closed. So we emailed him. We reached out and said “Hey, you know we know this is you. What’s really going on here, man?” And we started talking! He explained his side, we pointed out that the whole thing boiled down to how he’d been mistreating users, and if he could stop that, we were willing to re-enable his account and everything.

    The one thing we did not do was delete his old posts, where he’d kind of lost his mind. Those bad events in the past made him who he was, for better of worse, and whitewashing the past did not change it. There was one way to change it, and that was for him to stop acting like that and to move forward, being a better person.

    For that same reason, I probably won’t delete that bad review. How it changes your product is not in the deletion but in the handling. If you take the task at hand, rise up and approach it fairly and maturely, it says more about you than anything else. If you are reasonable, thoughtful, and fair, you will have a better result in your reviews than anything else I could do with that deleted. You see, I would sooner trust a product that has bad reviews and good responses, than a plugin that has no bad reviews at all. One is understandable, the other is unrealistic.

    And personally? I’d hand over that refund.

  • Review: Sitespeed.io

    Review: Sitespeed.io

    Let’s get this part out of the way first…

    92131-I-feel-the-need-for-speed-gif-26ny

    Like most people, I have a suite of websites I check when I’m trying to figure out how well a site does with regards to speed. Google PageSpeed Insights, ySlow, GTMetrix (which does both), Pingdom Website Speed Test, Bytecheck… The list goes on and on. We want as many checks as possible in understanding what’s causing sites to be slow and what is not.

    Sitespeed.io LogoWhen I added in nginx I wanted to test everything again, and as I made my way down my list I thought “Isn’t there a way to do this and go make a coffee?”

    Sitespeed.io analyzes my site while I make coffee. It’s Open Source. It’s forkable. It’s easy to install. Since I’m on a Mac, I used Homebrew (which I’ll post more about in two days) but you can git clone, or download the zip, however you like.

    Once installed, you run a sitespeed.io call:

    $ sitespeed.io -u https://halfelf.org
    

    This takes a little but creates a folder off your home directory: ~sitespeed-result/halfelf.org/2014-05-14-14-59/ and in there will (eventually) be a lot of files including an index.html. That one you open up in the browser. The scan definitely takes longer than a sitespeed check, but it’s also more in-depth in the ways I always wanted from sitespeed. Also since it’s HTML, I can toss it online and share with people.

    What I noted first was a ton of errors. Sad panda.

    phantomjs[88651:507] CoreText performance note: Client called CTFontCreateWithName() using name "Open Sans" and got font with PostScript name "OpenSans". For best performance, only use PostScript names when calling this API.

    It also had a lot of crashes, which was when I wondered if everything was on the right version. Again, checked in with Homebrew, upgraded phantom,js, and tried it again. This time no errors (yay!)

    But then the process finished and I looked at my score. 81.

    So I dug into the results and looked at first my home page.

    You have 2 javascripts in the critical path and 8 stylesheets using 0 extra domains

    […]

    This page has 8 external stylesheets. Try combining them into fewer requests.

    And it showed me what those were. Weirdly, I saw WP was calling jquery on it’s own, as well as the JS I minified and compressed with mod_pagespeed. Interested, I checked three other sites on my server, and they all have the same issue. It blows my mind that no other tool had pointed that out before. The stylesheets I knew were from my fonts. While I minified them all, I did not combine them because it made my font-icons break. I upgraded mod_pagespeed for Apache 2.4 and haven’t looked at that since, so I tried it again indeed, it worked now.

    I slowly worked my way down the list, noting things that I could easily fix. One thing that would ding me hard was my use of webfonts. Also not using a CDN still dinged me. Still, by using Sitespeed.io, I was able to see more exactly what was slowing my site down and why, and what I could sacrifice. Some things are going to be unavoidable (like “You are using an old version of JQuery: 1.11.0 …” ) and the multiple domains (google.com, wordpress.com, etc), but really the fact that I can narrow in with specific issues is perfect.

    There are a whole mess of options, like I can take screenshots with each page, restrict the scan to specific pages (or exclude others), check in mobile, test in specific browsers (note: this is more complicated!), and much more.

    So welcome, Sitespeed.io, you’re in my toolkit now!

  • Bad Browser Complacency

    Bad Browser Complacency

    Back in the day, you may have seen notices on browsers like “This site best viewed in Internet Explorer v4.” Since then, we’ve moved into the belief that a website should work on as many browsers as possible, and degrade nicely when it can’t. So imagine my surprise when I’m looking at photos online and I get a message saying I’m using an unsupported browser.

    I happened to be using Chrome on my iPad, so I clicked the link which took me to http://www.corbisimages.com/BadBrowser and I saw this:

    Bad Browser

    I was taken aback. Not that they say ‘IE 7 and up’ as it’s something I try to support as well. Frankly making sites look awesome on IE is about as easy and fun as a dental student doing your root canal. You’ll get there in the end, but it may hurt like hell.

    Now, Corbis has certainly one of the more out of date designs for a photo sites I regularly visit (there are 10), but it’s not the most egregious. Yes, there are worse ones. Still for a site to have an alert like this in 2014 and to omit Chrome is rather shocking. Someone remarked it looked like that site was designed circa 2003 and Chrome, if you didn’t know, only came out in 2008. So while I remember this new design for Corbis being rather recent (2012 or 2013, but that may have just been some tweaks), it’s clear they’ve not visited that page in at least six years.

    I talked to my family about web design at a recent brunch, stressing that I do not do website design per se, but I am happy to help them find people and upload their content. At that time, I pointed out that the trick to a website was to frequently update it and make it more modern. “It’s like the runway shows,” I replied. “What’s in this season was weird last season and may be out by next season. So making a site and never changing it is as smart as never updating your wardrobe.”

    Older fashion, not that good looking todayPeople judge by how things look. If someone only wears a black turtleneck and jeans (Steve Jobs), we create a specific mindview of them and it rarely changes. Someone who always wears avant-garde clothes that are nearly unwearable (Katy Perry), we create another. If that person always wears a suit jacket (Tim Gunn), we have yet another view. Neither is right or wrong, of course, and they all have their places.

    We update our wardrobes when we gain and lose weight, when we decide we want a change, when we feel different, when we have to change, when we want to. While I tease that Brian Gardner is never satisfied with a web design and is always changing, I’m often just as guilty of this as I don’t feel things fit forever. If I’m not afraid of changing my wardrobe, why would I be afraid of changing my website?

    And yet. We worry a lot more about the change of design, to the point that sites like Corbis haven’t significantly changed or adapted since 2002, when the site was born. Since then, 12 years have gone by, browsers have changed, security changed, and the viewing experience is wildly different. Corbis on a phone? Yeah not a great experience.

    When your site never changes with the times, never grows to adapt to it’s new audience, you lose respect in the world of the Internet. We have to keep up with the times, test and retest on as many browsers as humanly possible, and make sure that it all works. We can’t just say “Yes, this one design is good” and more so, we can’t say “This site works best on…” anymore.

    Unless you’re the sort to say “This jeans only work with turtlenecks.” Then, by all means, never change.

  • Very Voluminous Vagrants

    Very Voluminous Vagrants

    I finally sat down and installed Vagrant.

    Specifically I installed Varying Vagrant Vagrants. I read, like I do, and the directions were thankfully pretty clear for a change about what the prerequisites were, and I found myself with an install of Vagrant up and running within an hour. At this point I joked “Now what?”

    Vagrant is yet another tool you can use to create test websites. It’s a super-powerful command line tool one might use instead of DesktopServer or MAMP. Now, I love MAMP. While I find DesktopServer more ‘flexible’ in that I can spin up a client’s site really fast to check it, MAMP is even faster to boot when I just want to see one site and test a plugin on it, in part because I use MAMP No Password and run it on port 80 (which lets me use Multisite).

    But… Sometimes when I want to test, I want to test different configurations at once. Like I want to test on current (3.8.1) and trunk, and I probably want a Multisite Network as well. But Vagrant is way more than just a lot of different environments in one go. I mean, if that was all it was, I could edit my hosts file and make a couple extra sites in MAMP or DesktopServer and be done.

    What do you get?

    You get a lot with VVV, and if all that seems weird to you, it’s okay. The more I work on servers, the more I see a varity of weird setups and the more I want to mess with them for testing. This isn’t to say VVV is perfect. You can’t switch (easily) between PHP 5.2 and 5.3 and 5.4. There’s a whole discussion ticket on the matter.

    Vagrant makes multiple servers. Not PHP/Apache instances. Servers. They’re virtual, but let’s be honest, so is the server this site is running on. That means I can mess with the server, install extra features if I need to test a clash with PHP version or add ons or whatever, I can do so without blowing up my laptop (or a real server) pretty quickly. That means my plugins test site (on a live server) may not be needed anymore, which led me to the first actual thing I had to do with Vagrant: Make my own sites.

    My own sites!

    You get five ‘default’ sites when you use VVV:

    That’s four, I know. The fifth is “vvv.dev” which lists the other four sites. That’s pretty much what most of us need when testing. A local site, one on trunk, one using src, and one with grunt for those CSS/JS things.

    I needed more:

    Those all run stable. I though about naming them wordpress-something, but I needed the subdomains and it was easier to just make multisite.dev for that. I know what it is, and this is for me first. The way you do this is with Auto Site Setups, where Vagrant looks in your www folder and if it finds more folders with the right files, will build sites! Natually that means I made a little Github repo for this called VVV ASS. Because you’ve met me before, right?

    What do you do with it?

    Test all the things, really. Bang on plugins and code that isn’t right, make patches, and have a generally clean environment to play with. It’s also good for building on (core or plugins or themes).

    I’ve been struggling with PHP Unit Tests, as well. I understand them, but I don’t really grok them yet. While I dig the idea of unit tests, creating them is a little complicated to me. Suffice to say, I know WordPress on push day wants to unit test all the things, so I should get used to this.

    1. In terminal, navigate to your clone of the VVV repo.
    2. Run vagrant ssh to connect to the virtual machine.
    3. Run cd /srv/www/wordpress-develop and go into the folder.
    4. Run phpunit

    And there you go. What did all that do? A lot. Check out the Core Handbook on Automated Testing. Beyond that, I cannot tell you. Yet. Expect more on that later when I’ve gotten someone to explain it better.

    Do I have to use VVV?

    Nope! There’s VIP Quickstart, by Automattic (yes, that Automattic) which lets you bring up a WordPress.com-esque site. And there’s WP Vagrant which gives you more testing environments, so when you want to blow up core on PHP 5.2, you can do it easy as another vagrant up.

    Am I sold?

    Developer Ipstenu is sold. User Ipstenu still likes MAMP best. “Yes, I’ll fix your site” Ipstenu likes DesktopServer. Each has their own place. I’m so comfortable in CLI now, it’s more natural to use MAMP and VVV. DesktopServer comes in to play for me when I need to spin up a site specifically to test an existing site someone else broke.

  • You’re Wrong about Open Source Development

    You’re Wrong about Open Source Development

    We like to say that the ‘customer’ is always right. But when it comes to open-source products, the line between customer and developer is blurred. I joke that I’m not the owner of code, I’m the custodian, and by fielding questions from users and other developers, I turn that into a better product. There’s more and more calls for people like me by the way. A non-insignificant number of companies ask me “Is there someone else like you who would want to work for us?” because giving good support is hard, it’s a weird skill set, and it requires the ability to tell someone “I’m sorry, but that’s just not correct.”

    Yes, I tell people they’re wrong a lot. When I say it, I try to couch it in more friendly terms like “I understand why you’d think that, however because of XYZ the product chose to do ABC.” Or maybe even “That would be great, but historical support forces us to do that in a way that would remain backwards compatible. It would suck if we broke everyone going forward, right?” See the point here is that you’re not right but you’re not exactly wrong either, you’re just isolated in view.

    Well that escalated quicklyTunnel vision is something that happens to all of us. We look at the world from our perspective (yes, I was Captain Obvious there, I know), which means when most people remark that a project needs something, what they really mean is they need it. This is the part of passion that escalates into angry and vitriol remarkably fast, by the way, so if you’ve ever seen someone go from zero to abusive in three comments, that’s often what’s going on. They really want something to the point that they see red and can’t get out of their tunnel.

    Getting back to the rational world is hard, especially if you don’t really understand what it means to develop open source. You may think the developers are ignorant of their users, or out of touch, or don’t care. After all, if open source allows anyone to contribute, why doesn’t a project do everything?

    Well besides the fact that it can’t do everything, there are four main reasons a project doesn’t do things the way you it to. This doesn’t mean you’re right or wrong. Being wrong doesn’t mean you are wrong. It’s pretty hard to ever hear ‘wrong’ and not take it a little personally, though. Just keep in mind the reality that most Open Source developers are way more in touch with their users than people behind iOS or Microsoft Word. They just move at a different pace.

    Support

    The people who write the code have to support the people who don’t (or can’t). If they don’t want to support certain code, they shouldn’t have to. After all, what if they don’t feel confident that they can!? If you ask a developer to put in a feature they don’t use and don’t really understand, what happens when it breaks? I always tell people “You can’t support what you don’t know, and you can’t know what you don’t use.” This is why everyone who’s been through my WordPress training is pushed to actually use WordPress. Supporting something is so much easier if you use it. Thankfully all WordPress developers use the product every single day, so they know what it’s like.

    Complications

    The code is something everyone wants, but it’s too damn hard to code and remain backwards compatible, which is a huge deal for WordPress. A good example of this kind of thing would be WordPress Multisite’s shift from using /blogs.dir/ to /uploads/ for storing uploads. Doing this allowed us to dump MS Files and speed up WordPress because we’re no longer routing images through PHP (lots of benefits there). It came at the cost of losing the ‘hide’ effect of the /files/ URL, but you weren’t really fooling anyone about that anyway. Point being, we had to do this in a way that didn’t break everyone on an older design of WP! That took a lot of time!

    Time

    It takes a lot of time to get code right. So maybe they’re actually working on it, but it’s going to take a long time and it’s not done yet. Open Source moves at the speed of imagination and passion, so if a developer has the time and the itch, things get done. Some tasks are pure drudgery, which brings us to …

    Feelings

    This is Open Source (ala Sparta Meme)If you’re stuck between writing code you like to do a feature you want and writing code someone else wants and you don’t have an investment in, you’re probably going to do what you want. This is the reason that’s hardest to understand, and it’s the one most people call ‘unprofessional’ because it boils down to “Oh you don’t like something so you’re not doing it?” If this was iOS or MS Word, yeah, you’d get fired. But this is Open Source, and the rules are a little different here. We make what we make out of that same passion you have to see what you want to see.

    So … why not what I want?

    Because not yet. Maybe never. But WordPress was built to be extendable, not to be everything for everyone all the time. And that’s the beauty of it. But that’s another post altogether.

  • Electric Sass Boogaloo

    Electric Sass Boogaloo

    Poster to Breakin' 2 (electric boogaloo)One I mastered using Sass enough to feel confident with basic mixins, I decided to remove my _media.scss file and go at it with Chris Coyer’s methodology of Breakpoints.

    Instead of having a media file with all the special media calls, you can put the media section inside the Sass call. That stops that cognitive dissonance (for me at least) of hunting down where the heck I made that change. Since I was already using Tracy’s code, I was able to slip in breakpoints using her bp mixin, with a name. And thus:

    .site-intro {
        @include font-size(14px);
        line-height: 1.5;
        @include rem(letter-spacing, 1px);
        text-transform: uppercase;
        float: left;
        @include rem(margin-top, 20px);
        @include bp(small) { @include rem(margin-bottom, 15px); width: 100%; text-align: center;}
    }
    

    This is clearly a really simple example, but it means I can add all sorts of blocks and have it be together. It actually made my building of my css files really easy, since once I figured out what size I wanted things to be, I was able to build and ignore all the tricky maths, which as I learned recently, was really important for your REMs.

    Now that I was using includes, mixins, default settings, and breakins, it was time to reconsider how I made the css files. I installed sass on my laptops and servers. It required Ruby, but I’d installed that ages back trying out Jekyll (there’s no post about that yet for … reasons). Once Ruby was installed, Sass was this easy: gem install sass (you may or may not need to sudo that sandwich).

    Having Sass on my server means I can edit files in place (which … you wouldn’t do, right?) and when I’m done, run this:

    $ sass sass/style.scss style.css
    

    But it also means when I (properly) edit on my computer and push up, I can script with git hooks instead! I took my methodology from Nico Hagenburger and Steve Grunwell, but you can use just about anything. I like how they don’t include the complied css file in their builds, which keeps it cleaner. Then one could have another hook to push the files after, say, you tag a release. That one would copy the files up to your server (rsync anyone?) and thus you do it all locally, but magically it appears to the world.

    Breakdancing in Yoyogi, Tokyo, Japan.
    Breakdancing in Yoyogi, Tokyo, Japan. By Colin McMillen.

    Back to breakpoints though. So great, I can use it to make my math teh simples. What else can I do? I can change content, colors, font-families, or anything else you want to change on a size-defined basis. How do you break the points? Breakpoint SASS is possibly my new favorite website.

    For an end user who doesn’t really spend a lot of time with theme development, this buys even me a little time in my day. After I spent a weekend banging it out, I found my updates were easier, cleaner, and faster. Having the files separate is possibly the fastest thing. I edit a scss, check in the code to my git repo (because I am totally neurotic), test the compiled css, and I’m dancing in the streets.