tonyshowoff – Page 2 – Tony Showoff

Quora, where incompetence is fine so long as you have good grammar

I get Quora summary emails despite not being a Quora user, and sometimes I see very interesting questions, and more often than not very incompetent answers… rather, incompetent answers written very well so they sound like they could be correct. Here's one example:

Well, as most of you know, YouTube was never written in PHP, and they could've gained this much by just looking up YouTube on Wikipedia. I think the second part of the question is an interesting one, however the answer is dog shit.

Primarily because it's a question of scalability with two different types of platforms. Sure, Twitter and Facebook seem similar enough. They're both web sites full of assholes bragging about themselves (myself included) and old guys and oily nice guys trying to pick up strange, but their problems are completely different.

So, this is a classic thing of "anything is faster/better than PHP so therefore if it used PHP it would've failed," which is totally stupid and based on nonsense.

Twitter works in ever changing content where historical entries are rarely retrieved, Facebook does pretty much the opposite. I suggest looking up the histories of both how Twitter and Facebook have dealt with scalability on websites like highscalability.com and also YouTube has tons of videos where their engineers have discussed it. Note that you could only listen to information provided by actual Twitter and Facebook insiders, not random morons who think they've got it all figured out, that's why I'm not listing it all here myself.

YouTube could've survived the volume, because it survived with Python, which is slower than PHP in a lot of ways, but I think any actual developers reading this, whether or not they love or hate Python or PHP, know that YouTube's bottlenecks are database and bandwidth, not their code backend. And there's plenty of videos on YouTube of developers from there stating this very fact too.

So, this is a classic thing of "anything is faster/better than PHP so therefore if it used PHP it would've failed," which is totally stupid and based on nonsense. Sure, PHP used to really suck, especially in the days YouTube launched, but that has nothing to do with their success or failure.

But oh it gets worse:

Facebook's HHVM still couldn't be enough? Well, Raphael Costa claims to have 15 years in enterprise software, and I believe it, because it would explain why most enterprise software systems are garbage, because their engineers are incompetent.

Let's just point out why this is nonsensical garbage:

Facebook used PHP and expanded with it beyond the popularity of YouTube, and yet YouTube couldn't have used it?
Facebook is more popular than YouTube, so this makes no damn sense at all. I guess I said that already.
Facebook also serves video.
Most importantly: serving video literally has not a fucking thing to do with the language you run on the backend, because you're serving them as flat files or from CDNs. This is true in the case of both YouTube and Facebook, and also your major online porn video sites.

Yet, his post gets the most upvotes, and he is considered authoritative. This is just one example of Quora really being no better than Yahoo answers, especially nowadays. I've never used Quora or contributed, and this is pretty much why.

Should you trim passwords?

A question I see asked from time to time is whether or not web sites should trim passwords on account creation and login. More often than not the typical responses show both a complete lack of understanding of what "trim" even means from people who should know better, and a lack of understanding that not every user is Dade Murphy after he just got in from grindin' some serious hand rails. Though not everyone has their head up their ass or argues from a position of complete ignorance.

So consider:

Trim means to remove white space from the beginning and end of a string, not the center.
Even if you don't email passwords or display them anywhere, users will still copy/paste them to each other and various places and often this will add a space or \n to the end of the string.

A few things are clear to me based on my experience and reading what others had to say about it:

People who are against trimming passwords either don't know what trim means, or think everyone else understands and uses simple security protocols like not saving passwords in word processors
People who are against trimming passwords probably have never had to deal with real users or customers, and probably are some shitty wanna be Richard Stallman with more than slightly high expectations of what users can and should be able to do
Users should be allowed to have spaces within the string itself, but not on either end, in order to save your support people (and possibly yourself) a lot of headaches
People who are against it assume that if there's a space it's because a user intended it, but how many people actually put spaces at the end of passwords? Basically fucking nobody.

So it's simple: users should be able to use any characters they want in a password, but the password should be trimmed at both create and login. There's also no reason to warn people that passwords are trimmed, again because nobody understands what the fuck this means, even apparently technical people. We know from massive lists of cracked and leaked plain text passwords that nobody uses spaces at the end of passwords, not even keyboard cowboys who give bad advice on Stack Overflow.

Trim away my friends, don't listen to people who probably don't even have clients.

Vi vs Emacs, nope they're both terrible and obsolete

Earlier this month Linux Magazine carried an op-ed titled "The End of the Editor Wars," (more discussion) discussing the age old argument of vi vs Emacs, or really vim vs Emacs these days.

I've been using Linux and Unix for at least a couple of decades and it's an argument I've never understood, because both editors are total garbage, but especially vi. There are so many alternative, better editors to choose from.

If we only talk about the editor wars in the sense of vi(m) vs Emacs then certainly vi has won, and I think there's some fairly straight forward reasons for that:

vi comes on everything remotely POSIX or Unix compliant
Some people pride themselves on the overly complex nature of vi(m) over other editors, you can even find people swearing that vi(m) with tons of weird extras is superior to a full IDE such as PhpStorm or Visual Studio. I guess this can be true in the same way that hang-gliding is faster than super sonic air travel. In short, and I say this with the up most level of offence: these people are liars, morons, or delusional. There's no way it can possibly be true.
Emacs, in my experience, was always more bigger with people more apt to use Lisp, and nobody but supervirgins and beardos use Lisp. ((((know(((what((((((()()))))I((((((((((((mean?

The entire vi vs Emacs argument is really like two slow kids jumping off the short bus, then proceeding to beat the hell out of each other in the Waffle House parking lot over the who is the heavy weight champion of the world.

One may win, but they're both still retarded.

There are tons of editors which do way better at everything in comparison, to either, but especially to vi, as vi does everything in the worst way possible.

In other words yes, vi won, but they're both still crap.

Even today distros like Ubuntu override things like visudo to load into nano, *not* into vi. I think this is wonderful and I pray for a day an easy editor replaces it completely, maybe even easy editor from the BSD universe, that works fine too.

Vi comes from a time when there were limited keys on a keyboard, and instead of using escape and control to manage the program (used in a limited way, escape especially in that it brings up command mode), they devised a brutally complex and illogical system for editing which persists to this day, it is truly for the masochistic and pretentious.

Knowing the basics of vi in that knowing how to do basic editing and also how to escape+qw! or wq is important if you're a sysadmin, but unnecessary for everyone else, and as soon as you can install any other text editor, you should, and most people do.

I understand personal preference exists, but it says a lot about someone's personality in that they'd honestly say vim is better than a real IDE on X and they can work "faster" with it. That can only be an absolute lie or a delusion on a David Berkowitz level. The dog is barking at the vi masochists and it's saying "hold on to a turd and call it gold, after all, you'll gain +100 nerd points in the valley."

Hamburger Icon, the illogical and unnecessary name

Stolen from the BBC

You may know the menu icon or navicon, sometimes called "bars", on your smart phone or tablet. When you click it or touch it, you get a menu, ta-da, pretty great.

Except lately I've seen some people, including some people I respect, call it the "hamburger" icon. This is pushed further by the media, and in fact it mostly seems to be a media thing since, well you know how reporters often run out of things to talk about…

The BBC carried this article: Hamburger icon: How these three lines mystify most people.

Are people really mystified by a standard icon seen everywhere? Somehow I doubt it.

Here's why it concerns me:

Standards are important in computing, especially when interacting with regular, "non-technical" people. Having a clear and understandable name for things makes sense. People need to connect words to actions, and if someone says "hamburger icon" instead of the more obvious "menu icon" then we've sacrificed logic to be cute.

It's always been a menu icon since it was invented, and in fact originally the cutesy name was "air vent icon," which makes more sense than hamburger, speaking of…

Here's why it makes no damn sense:

It doesn't look like a fucking hamburger! If it were a hamburger, the top and bottom lines would be wider to signify a bun, but they're all equal. It seems like a really big stretch and attempt to try to apply a name to something that does not need another god damn name.

I always thought it looked like a gripper, as one can often see on the bottom of remote controls to make sliding the battery panel off, as well as many other places. This makes sense too with smart devices, because people use their fingers on them.

Other things it looks more like: a deck of cards, a list of items, an air vent, a stack of items… Would you say the StackOverflow icon looks like someone assembling a hamburger?

Plus when I click it, no matter what, I will never get hamburgers.

Here's what we should do instead:

I don't use the term "navicon", because it seems silly to me, but so does "favicon," and that seems like a good name for technical people and development, but not regular people.

Consider the fact that people, after playing with their phones, tablets, or a web site will see it brings up a menu and they will think "oh, it's a menu icon," and it always brings up a menu wherever they see it. I don't think they'll naturally say "oh it's a hamburger, no duh, of course, as it looks nothing like a hamburger! And just like in real life, touching a hamburger brings up a menu!" even if they don't understand what it's supposed to represent, they'll just associate it with menus.

You use a menu to get a hamburger, you don't use a hamburger to get a menu, unless you're yelling at a waiter from Hamburg, Germany.

So when I say menu icon, they'll know what to click.

The best thing to do is to just not repeat this weird ass thing, it's so trivial and unnecessary.

So if it's so trivial why do I care?

Because I don't want to make interacting with users even more complicated by giving illogical, goofy names to them to be cute. We don't need to set precedent with this, otherwise what's next, calling bullets "M&Ms" because they're both round?

Want to make a list, click the M&Ms icon…

See what I mean, what's the difference? Oh yeah, bullets look more like M&Ms than the menu icon looks like a hamburger.

PHP 7 replacement for xdebug tracing

I started working with PHP 7.0.0-dev and, at least at the time I wrote this, xdebug and Zend debugger are not currently compatible with it, because of the extension API changes. If you need something better than a simple NOTICE or ERROR, then this will probably work for you.

The code is fairly clean, but could use some improvements, and if you have any suggestions or insights, please comment.

Some Notes

Some really nice debugging classes and so forth exist (like kint), but they're huge and do way more than I need them to, and also most won't easily mimic xdebug, if at all.
It does not work as well or provide as much detail as xdebug's stack tracing, but it's pretty close and may work for most people.
It doesn't provide remote debugging or anything like that, obviously
The code, ironically, does not take advantage of any improves made within PHP 7, so it can be used with older versions, but I've only tested it with 5.5 and 5.6

Instructions

I put the code at the top of my entry point (index.php for me) before any other code (autoloader, etc). Of course if you don't have an entry point, you can probably put it in some other global file if you want, such as a config file.

I also put it in the condition of "if (PHP_MAJOR_VERSION == 7) {…}", just in case I test my app with other versions as well.

/* @version 1.0.0 - Just in case I update it here.
 * @license MIT/X11
 * @authors @tonyshowoff
 */
function mojoDebugger($level, $error, $file, $line, $context) {
   $levels = [E_ERROR => 'Error',
              E_WARNING => 'Warning',
              E_PARSE => 'Parse Error',
              E_NOTICE => 'Notice',
              E_CORE_ERROR => 'Core Error',
              E_CORE_WARNING => 'Core Warning',
              E_COMPILE_ERROR => 'Compile Error',
              E_COMPILE_WARNING => 'Compile Warning',
              E_USER_ERROR => 'User Error',
              E_USER_WARNING => 'User Warning',
              E_USER_NOTICE => 'User Notice',
              E_STRICT => 'Strict Notice',
              E_RECOVERABLE_ERROR => 'Recoverable Error'];

   $level = (isset($levels[$level]) ? $levels[$level] : 'Unknown Level [number ' . $level . ']');
   $error = (empty($error) ? 'Unknown error' : $error);
   $file = (empty($file) ? '[unknown file]' : $file);
   $line = (empty($line) ? '0 or unknown' : $line);

   echo $level . ': ' . $error . ' in ' . $file . ' on line ' . $line . "\n\n";

   echo "Backtrace:\n";

   $backtrace = debug_backtrace();
   array_shift($backtrace); // No need to report the debugger itself
   $backtrace = array_reverse($backtrace, True);

   foreach($backtrace as $call => $info) {
      echo "\t" . $call . '. ';

      $func = (empty($info['function']) ? '' : $info['function']);

      if (empty($info['args'])) {
         echo $func . '() ';
      } else {
         $info['args'] = print_r($info['args'], 1);
         $info['args'] = str_replace(["\n", "\t"], '', $info['args']);
         $info['args'] = substr($info['args'], 6);
         $info['args'] = substr($info['args'], 0, -1);
         $info['args'] = trim(str_replace('    ', ' ', $info['args']));
         echo $func . '(' . (strlen($info['args']) > 128 ? substr($info['args'], 0, 128) . '...' : $info['args']) . ') ';
      }

      echo (empty($info['file']) ? '[unknown file]' : $info['file']);
      echo (empty($info['line']) ? ':0 or unknown' : ':' . $info['line']);
      echo "\n";
   }
}

set_error_handler('mojoDebugger', E_ALL | E_WARNING | E_NOTICE | E_STRICT | E_PARSE);