Half-Elf on Tech

Thoughts From a Professional Lesbian

Author: Ipstenu (Mika Epstein)

  • When to Code

    I used to say “Don’t hack core, make a plugin. Don’t make a plugin when you can edit your functions.php. Don’t edit functions if it’s a one-liner in your .htaccess.” The concept behind it was that people tend to over-complicate things by over-coding. I don’t say that much anymore, since I’ve found that plugins are more useful than functions a lot of the time, and really those are theme specific. But I maintain my basic argument that the simple way may be the best way.

    No software design is perfect, and much of picking the software you use comes down to personal preference, at the end of the day. I worked through Y2K in desktop-software, testing it and validating its usage. One of the many things I learned was that personal preference will kill you, and spending a lot of time customizing an interface to be perfect for you is time wasted. At work, I use the bog standard Windows XP install. I have no customization on my desktop, fonts or display, save to make the screen resolution something easy on my eyes. The rest of the time spent making it ‘pretty’ is wasted for the purpose of work. My desktop is my desktop. The software I install is as much customization as I ever get.

    I also don’t generally customize my fonts in applications. Again, this is time wasted, and minutia I will have to remember later on when I inevitably re-build my computer from scratch. The only ‘customization’ you should be doing is adding in that which is required to use the software (user name, server name, passwords). And all of those should be saved in a config file, call it a day. The exception to this rule is how I customized Putty, but again, I saved the configuration in a putty.reg file (I know, I know) and when I have to reinstall it, I re-load that. Anything I want to customize must be easy to re-apply, both technically and mentally. I don’t want to spend an hour farting around trying to remember ‘what was that setting…’

    Similarly, when I look at wanting to do something on a website, I take the time to determine if this is a one-off change for one moment, or something I want to repeat. I think about how the change is going to affect the overall workflow of my day-to-day functions. Will this improve everything or just make today easier. Can I apply it to many things, or is it specialized and localized. Most importantly, do I need to recode to do it, or can I utilize something that already exists.

    It’s not a factor of being lazy, though like everyone else in the world, I am. It’s a factor of reinventing the wheel. Many times I end up writing from scratch, but other times I’ll sit and think ‘You know, this works about 90% of what I want. I’ll just change it.’ Now, as a good little coder, I fork my code when I do that, or split entirely and make something with a new name. I don’t ever hack core. If I can’t do it in a hook (be that a function or a plugin) or a config tweak or a customization, then something’s wrong with what I’m trying to do. Or possibly the way I’m trying to do it.

    Sometimes I find the best solution is to accept the limitations and make it the best I can within them. That’s always a fair cop too. But I never presume there’s only one way. I’ll chase the rabbit down the hole, through the tunnel and out the other end multiple times, in order to come up with the best way, not just to fix the problem I’m having today, but to make sure I fix it for everything, without impacting anything, and that it’s the right solution for the long run.

    This process usually begins with writing down, in plain english, what I want to do. Then I study the source code to find out where to change it. At this point, I stop coding again, and go into the documentation. On WordPress I review the trac tickets related to this portion of code, and for vended software I actually read their documentation and support sites. You see, now I want to know if I can sort out why they do things this way.

    For example, if I wanted to make the new WordPress 3.1 admin bar show up for all users (like the BuddyBar on BuddyPress) and have the login option (like the WordPress Admin Bar on WordPress.com), I could do this via hacking the code easily. But. In reading JaneForShort and Nacin’s comments in trac and on IRC, I followed their logic as to why this isn’t available out of the box. After all, these guys have access to the code on WordPress.com, so they could have lifted it whole sale. While I can see value in having it available, it would include too many options for a first-round change in 3.1. Maybe this will start to slide over in 3.2, but for now, the idea is to get the world used to it, so your options are on-or-off, and that’s it. I then wrote a new plugin, pretty much a raw duplicate of the admin bar code, that disabled their admin bar and ran mine instead for tests.

    Perfect? No, but it lets me test what I want without hacking core. Right now, I can see exactly why you don’t show the bar for logged off users: it’s ugly. This is something I knew going in, though, because I took the time to understand why the code was done the way it was. Do I agree with it? Yes and no. I agree that, as a short term goal, it was better to fix what was in and add more later. I don’t think this should be the end of it all, and I’m sure it won’t be. Growth and change are inevitable in most things.

    The real decision is if I want to implement my code now, or wait till 3.1 is out and then posit it as a change on trac. In the end, I’m playing with it on my desktop instead of anything else. I want to see where the thought processes for 3.2 takes things, and I want the time to clean up my code. It might be a passing fancy right now for both me and WordPress. It might be something I go “Oh! Shiny!” and change my mind on. But I have the time because this is something to interest me and it’s not a need.

    That’s the real crux of the matter: wants versus needs.

    Knowing the difference between a want (like shiny flash graphics) and a need (readability) helps me determine if the change I want to make is worthwhile. Knowing how to look at my desires and separate them from the demands is imperative when you’re writing code or building a house. You may want all the cool bells and whistles, but you have to take the moment to strip them out and get to the basics. There are always basics to fall back on, and ignoring them due to the blindness of bling will hurt you in the long run. Don’t let your customer base pull you from that track either. Sure, they want all the features the competitor has, but pay attention to the downsides of that, and educate them. If they’re right? Of course you should listen, but it’s your job to teach the customer to have realistic expectations. Yes, you can remove the /blog/ stub from your MultiSite installation, but there are risks. Be aware that the shiny removal may not solve every problem you’re having.

    When do you code and when do you say ‘This is what it is’? There’s no right answer. But knowing how to think through it and apply your mind to the entire problem, not just the ‘this is what I want now’ but also the ‘and this is the big picture’ will help you in every aspect of your life. Listen to the wants, respond promptly to the needs. We would like a jacuzzi tub in the bathroom, but all we need is a shower. Don’t let the fancy spigots distract you.

  • Basic Troubleshooting Is Still a Must-Have Skill

    Basic Troubleshooting Is Still a Must-Have Skill

    How low is too low?

    I wish I could say that lately I’ve noticed people asking ‘dumber’ questions on support forums, and while I do firmly believe the world’s IQ drops significantly between Thanksgiving and New Years, that’s not the problem here. People aren’t getting dumber. The problem is that the better people get at making software, the lower the technical requirement becomes.

    Look at email. Back when it was elm or pine, you had to really know what you were doing to get in and send mails. Then we got a couple GUIs, and you could keep all your emails on a floppy disk (which we all had a million of, thanks to AOL), carrying them around from computer to computer, Mac or PC. Everything to do with computers has this curve: First only the hard core programmers can do anything. Then the tech-savvy users, who are usually friends of programmers, get in on it. Then the smart kids who play with stuff. Then their family. Then everyone. Then your grandmother.

    By the time your grandmother gets around to things, it’s easy to use, easy to understand and friendly. This is, inherently, a good thing! To make the transition from geek toy to something usable that will change the world, you must make the entry barrier low enough for anyone with a reasonable amount of brain-power to use it. Twitter’s a great example of this. It’s easy to sign up, easy to use, easy to understand. Like anything else, you can get overwhelmed by the data influx, but that’s true of all technology. The telephone, for example, suddenly brought in the ability to have your dinner interrupted. It brought change where everyone has a phone. Of course, now we all have cell phones, but the idea remains the same.

    So when I look at support forums and people are having trouble installing software on servers via FTP, I put my head in my hands. Sometimes this stuff is supposed to be hard. We can all use phones, but we can’t all fix phones or even build them. And that’s okay! We all have skills. Twitter would probably be something hellish to install on your own website, but to utilize their site? Not so bad! And again, that’s okay.

    If you want to host your own website, you’re going to have accept this fact: You will need to be a smart, technical savvy, person.

    There. I said it. Yes, you can totally be too uneducated to run a website. Here, I’ll go all the way! You CAN be too dumb for WordPress!

    But let me stress this one more time: IT’S TOTALLY OKAY TO BE TOO STUPID TO RUN YOUR OWN WEBSITE!

    See, people get hung up on this. They forget that there’s a huge difference between running a website and posting news to your site. The line between a webmaster and a blogger is blurry for a reason, and that’s what’s causing all these headaches. Back in the day, if you wanted to run your own site, you had to be a webmaster. Now? Not so much.

    A webmaster is generally someone who thinks ‘Oh, sure, FTP, SSH, and SQL, no problem.’ They may prefer something like phpMyAdmin versus command like mySQL calls, but the most important thing is that they’re comfortable troubleshooting. A webmaster is the person who looks at an error, immediately looks it up (if they don’t know it off the top of their head), goes to forums, skims posts, reads what others have tried, and is willing and able to try things like a reverse DNS check. A webmaster makes backups so, at worst, they’ve only lost a day of work.

    A blogger is a writer. A creator. Someone who can make content. A blogger looks at a sunset and creates a haiku. A blogger takes a photo of a naked man on a bicycle. A blogger tells you the drama of returning an unwanted present, or about how her son wants to wear a dress on Halloween.

    And still, every day, I see people who don’t understand .htaccess asking for help with errors on their websites. I see people who complain they can’t auto-update their site from the inside, because FTP is too hard. I see people complain the magic 5-minute WordPress install is too hard. And I think that, perhaps, we’ve lowered the bar too much. If we’re at the point where the non-technical people are complaining it’s too hard to do something that is, by it’s nature, a technical thing, then we have a problem.

    This problem is compounded by webhosts who, in order to make money, want to make it ‘easier’ for you to run a blog, so they have auto-installers. They lower the bar. Then we have web-apps (like WordPress) which let you install, from within the app, plugins and themes. This means that someone could create a site just like this one, without ever touching FTP or SSH. That also means when things go wrong, and they will, you’ve got someone stranded, crying that this ‘easy’ application sucks, you’re terrible, and whyyyyy meeeeee!

    Every single person who’s ever worked support just started nodding their head and reaching for a drink.

    So here’s the deal. Yes, you can become smart enough to run your own website, but before you jump into it, think about how long it took you to get comfortable with your computer. How long was it before you could email, link videos, and save MP3s? Do you know how to make folders in your email app? Do you know that emailing 200megs to someone will piss them off? Did you need a book, or someone to sit by you and teach you all this? Are you comfortable googling errors and applying fixes? More to the point, are you willing to get your hands dirty and make mistakes?

    If you want to run a website community, you may need to break down and hire someone to do the heavy tech lifting for you. Just like you would want to hire someone to create cool art, or decorate your house. Sometimes you just need to grab an expert. Remember you can’t get something for nothing. Either invest the time and money in learning, or in someone who already knows it all and can support it for you.

    Apropos of all of this, Google has a new site called Teach Parents Tech. Lowering the bar. Again.

  • My plugins are ready for 3.1

    My plugins are ready for 3.1

    I did a quick run through my plugins, and everything is ready for 3.1, even the tricky wicket of Register IP – MultiSite, which is now Version 1.0.

    New things:
    Register IP – MultiSite works for both 3.0.x and 3.1, single and multisite. The fix put in by the dev team means that the same actions will work for all site types! Yay!

    Disabler now lets you disable the 3.1 admin bar (thank you, Ozh!) but NOT as a default option. Remember, Disabler is meant to allow you to pick and choose what you want to disable. If you want a site-wide/mu-plugins type setup, you’ll want to use Ozh’s plugin Disable Admin Bar.

    Thoughts:
    I’m seriously tempted to ‘sunset’ Recently Registered since it’s fugly and doesn’t work right.

  • Unix One Liner – Writing to a file

    Unix One Liner – Writing to a file

    In 2010, I had to log into 100 odd accounts and edit the .profile file so that the line ‘cd ~’ was included. Sounds time consuming, doesn’t it? I couldn’t use a for-loop to log into the accounts, but since they were named ‘test001’ through ‘test100’ and they all had my sudo password saved, it was pretty easy to sort out what I needed. And by easy I mean I pled to Twitter and got stumped on ‘cat’ for a long time until, finally, I wondered if echo worked the way I thought it did.

    It does perplex me that ‘write’ doesn’t. I mean… it should, right? ‘write filename content’ but no. Not so much. And even echo doesn’t format the way I’d expected! It’s

    echo CONTENT >> FILENAME

    Oh Unix, I love you so.

    sudo su - test001
    echo "cd ~" >> .profile
    exit
    

    The trick was remembering that echo … echos. So if I’d use echo cd ~ >> .profile I would have ended up with cd /usr/home/account/ in my .profile, which I didn’t want. The other trick was remembering that the >> part means ‘Add to’ so if the file DID exist (it never did) it would add this to the end on a new line.

    So it only took me 5 minutes instead of the far longer way!

    sudo su - test001
    vi .profile
    a
    cd ~
    [esc]
    ZZ
    exit

    And yes, I did make a for-loop ‘for test001 through test100…’ though this ended up not working as well as I wanted it to, when I found some of the older accounts were named tst099 and test_100 for some reason. Ahh, scripting. You work so well when everyone else is consistent.

  • CAPTCHA Isn’t Accessible

    CAPTCHA Isn’t Accessible

    I’m just going to start this with a possibly startling fact. PWNtcha can break 90% of known CAPTCHA algorithms. If that doesn’t tell you why they’re totally useless, then I don’t know what will.

    It’s no secret that I detest and will not use CAPTCHA on any site I build. I have a math-test on one site where I get a lot, but that’s as far as I’m willing to get into that world. People often ask me why I hate it, and I tell them that it doesn’t work and it’s bad for accessibility. The fact that it doesn’t work is proven by PWNtcha pretty well, but the concept that it’s bad for accessibility seems to be lost on a lot of people.

    Screenshot from Star Trek episode 'Wink of an Eye' where Kirk is ordering dinner from the computer CAPTCHA stands for Completely Automated Public Turing test to Tell Computers and Humans Apart. In the begining, it was a great idea. The computer world had just started to try and make AI, and the first attempts at that on the Internet was to put little bots out that talked to people, asking and answering questions. That, in itself, is pretty damn cool, I agree. With working AI, we’re one step closer to ‘Computer, I’d like a bottle of Chateau Picard’s chardonnay, chilled to 68 degrees Fahrenheit, and play some Barry White at volume level 3.’ (illustrated to the right). AI is a great concept. But. What we actually got was people thinking ‘Wouldn’t it be cool if I made something that listened for key phrases and told them about my cool product?’ Basically, spam.

    An early defense against spam was that you had to enter a CAPTCHA code, which showed a picture with letters and numbers, and you entered those letters and numbers into a text field. The magic CAPTCHA verified they were the same and let you in. Pretty cool, right? Except that if there was a way for CAPTCHA to compare the image to the text you entered, then there had to be a way to reverse engineer that so a spam bot could read and enter the same code. Ever since then, it’s been an ongoing fight to make a better mousetrap.

    See, a human can easily read CAPTCHA like these:
    captcha examples that don't matter, suffice they're readable by most sighted people

    But the best ones, the ones that can’t be solved by computers, the ones that even PWNtcha says will last for a long time, are ones I look at and wince:
    captcha examples that don't matter, suffice they're totally unreadable by most sighted people

    Clearly if you make it good enough that a computer can’t crack it, you make it harder for a human to be able to understand it. In that one moment, anyone who has limited vision can’t access your site. Which means you’ve lost a visitor. If this is your business, you’ve lost revenue. And if you think there aren’t a lot of people that this will keep out of your site, think about how many people you know with some form of dyslexia. Think about how many people over the age of 40 (the age at which most of us need reading glasses) visit your site. Even if you run a trendy under-30 store, grammy may want to buy junior a new hip shirt. And don’t even pretend that older people don’t matter. Remember how long ago you were in College? Yeah, you’re getting older too, buddy.

    So they don’t work, they keep real people out of your site, and did I mention you probably don’t need it? I’ve been running ipstenu.org for a very long time (on Internet time – it’s been over a decade). I’ve had less than 20 spam posts show up on my site. None since I turned on comment approval (where I must approve your FIRST comment, but after that, you’re free to post). Akismet has caught about 50k spam posts. Bad Behavior’s caught even more (100k at last gasp) and only two ‘real’ people have ever complained about being caught (one had a virus, one had a bad firewall at school). Sure, if you’re Yahoo, you might need it, but did you know the ‘unreadable’ examples I used above were from Yahoo? Yeah. Google has a pretty basic, easy to read one, and so does Twitter. Facebook has too many, and they’re annoying. They actually probably don’t need them, either.

    Turn off your CAPTCHA. Your users will thank you.

    Continued Reading
    Inaccessibility of CAPTCHA – W3.Org
    It’s Official: Captchas Are Bad for Business – The ZURBlog
    Why you should never use a CAPTCHA – Online Aspect
    CAPTCHA Effectiveness – Coding Horror

  • Filtering Emails via cPanel

    Filtering Emails via cPanel

    Sometimes you get emails that you just don’t want to read. Maybe it’s a person you like who’s driving you batshit. Maybe it’s someone who’s actually harassing you. If you use Gmail, you can filter emails and they go into a folder or your trash-bin, and you don’t have to read them ever again! If you self-host, though, the steps are a little different.

    The first thing I do is make a new folder to hold these emails. I have some filters set up to auto-turf spam and viruses. But for people who harass me, I like to save their emails for review and reporting. Yes, I report them to the authorities when needed, and I save them so I can have their IP and routing info. Because of that, I have a built in folder on my email accounts for ‘Harassment.’

    Obviously you can teach your email client how to do this, and there are tutorials galore about how to get Mail.app, Thunderbird and Outlook to filter emails. But me, I like to have the filter happen before I open my email box, so I don’t have to even consider it.

    Once you’ve made the folder, go into cPanel and click on User Level Filtering. This allows you to make a filter per-email on your server. If you want to filter all emails for all emails on your account, there’s Account Level Filtering, which I use for the aforementioned spammers and virus senders. Also for all mail in non-English encoding. I’m hopelessly mono-lingual.

    Next, select the account you want to add the filter for. This one is pretty obvious, no?

    This screen will show you all your filters. I happen to have an existing one to filter someone’s constant requests for information. Since we want to create a new filter, click the Create a new Filter button.

    Now we’re getting started! Give the filter a useful name. I used ‘Harassment’ since I’m going to be adding in all the emails who harass me, and just dump them into one folder. The email I’ve added is one someone made up. It’s not real so don’t bother spamming it. There are a lot more options under the Rules section, but this one is pretty straightforward for me. I want all emails from jorjafox@gmail.com to be dumped into Harassment.

    Actions, which is just below the rules, is where you decide what happens. You can have multiple actions, the default of which is to discard the email. This means it gets deleted. You never see it. I don’t want this, I want to Deliver to Folder

    Once I’ve picked the action, I have to actually tell it which folder. This is where I pick Harassment.

    Put together, the whole thing looks like this:

    There are a lot more actions you can perform. One of them is NOT ‘Mark as Read’, which annoys me sometimes since my mail app will show my unread count, and I like to keep that low. I have no more than 10 emails, total, in my many inboxes at any one point in time, and the only ones unread are ones I have yet to answer or action (i.e. I have to do something before the email’s ‘done’). You can, however, add as many emails as you want. Just make sure you use OR and not AND for the emails.

    Once you’re happy with your settings, click activate and you’re done! Now that annoying person will be chump-dumped into a folder and stop cluttering your inbox!