Disable autocomplete / autofill in Chrome 51 for typeahead

So all the old insane tricks don't seem to work anymore, right? Well, I've seen one where you create a bunch of retarded hidden fields, but that's inelegant and adds too much complexity. So, based on something I found rarely mentioned, I manged to assemble this:

The type "search" makes it to where Chrome will not apply autocoplete or autofill, however some browsers like Firefox still will, so you also add the classic autocomplete="off".

It works with typeahead and Bootstrap 3 just fine, however if you have specific styles for input[type='text'] you'll have to include 'search' as well.

It's also a valid HTML5 element as well, and in HTML4 or (X)HTML 1.x most browsers will fail to text even though it says search, so it may not be valid, but it will work, and that's more important.

So, good luck, until Chrome changes this shit too and wants to punish developers. As they claim, turning off autocomplete isn't really a security feature, that's nonsense because I'm not using it for security.

They say that we should take advantage of autocomplete and autofill, but that logic doesn't seem to include the fact that maybe people other than Google have search suggestions, or even hidden values like numerical IDs which need to be applied when the item is selected — something autofill doesn't do and Google doesn't seem to give a fuck.

Google Chrome actually stealing mundane ideas from Opera?

A week or so ago, not sure when, Opera updated; nothing was really different, except the autosuggest / autofill items were now bold. I didn't think much of it, until Chrome updated, suddenly theirs were bold too.

What the…?

So, I went out looking for answers. One of the first things I noticed was since about May 4th, a lot of people were talking about Chrome's bold autofill lists; primarily asking how they could restyle that. I didn't find anyone talking about how Opera had done the same thing.

Granted, Opera is not really the most popular browser, and I use it for testing purposes primarily, but nevertheless this change really stands out to me. Not necessarily because one browser copied another, but because the copy is so fucking mundane and silly. Is there some massive benefit to bold auto-fill or bold auto-suggest items?

Is it so revolutionary that when Opera updated, some Google Chrome hacker said "HOLY SHIT, WE GOTTA DO THAT, RIGHT NOW, PUSH IT OUT ASAP! WE CAN'T BE LEFT BEHIND! THIS IS DISRUPTIVE!"?

I've tried to find out if there's any discussion from either company regarding this, but I sure can't find it. If anyone has any information, I'd sure like to know why this was done, because it's so goofy.

Exchange and PHP, a nightmare with a solution

OK that title is not very smooth or clever, but a project I worked on several years ago was syncing Microsoft Exchange with PHP. There's a lot out there not documented, primarily because there are several problems with PHP's implementation of XML and Microsoft's over-use of namespaces and so forth. However, with some serious hacking, I've come up with some solutions.

This was initially based on some code I had found online, however it was so long ago I have not been able to figure it out so I cannot provide proper attribution. Additionally, impersonation does work, and I've seen a lot of people have a problem with this as well.

The biggest thing is it requires a lot of manual XML to actually work, you can't build the objects and expect it to work correctly, it literally will not, primarily due to PHP's SOAP class.

The primary benefit of this code is to see how I hacked around dealing with PHP's issues when it came to trying to deal with the Exchange calendar and task system.

Feel free to reply with any fixes, updates, etc.

A few things to note:

  • When I created this, it was a hackfest with very little time, so the code is not my best work at all; I mean it uses globals for god sake, and improper OOP, improper usage of PSR, classes doing far too much, etc.
  • This code was built for PHP 5.2 – 5.4, and takes no advantage of PHP 7 or anything.
  • Yes, those two above mean I am embarrassed by the quality of this code, but hiding it isn't really useful to anyone, especially because I am not using it in my project any more.
  • This will not work out of box, because it was built specifically for my project, however because it was such a nightmare and other people are struggling, I'm sharing it. It should give you a good idea of where to start and how to deal with some hiccoughs.
  • I assume you've already got the basis down, and you've got messages.xsd, Services.wsdl, and types.xsd, and all the other stuff. Basically I am just assuming you've got it working, you're just running into problems actually doing anything useful.

Usage from my job which pull down basically everything first. This is because repeating calendar entries are only listed once, so you have to pre-grab and store everything in order to deal with it later. The most important aspects are storing the ID and change key so that you can properly manage it later. If someone edits a calendar entry, the change key will be "changed," so every once in a while, depending on your desire of accuracy, you may need to resync everything, unless you find a better way to do it (if so please share).

Here's the classes:

Is PHP out of fashion?

One thing I keep running into is the claim that "PHP is out of fashion," which I don't quite understand considering PHP is the most popular server-side language on the entire Internet, and many of the top websites in the world use it. Indeed, even on Twitter recently I had this conversation (edited for readability, see link for context):

Faizan Javed (‏@faizanj): A bigger issue – what is it with valley startups and PHP?
Tony Showoff ‏(@TonyShowoff): What do you mean? The polarisation of it, to where either it's evil or it's the only thing used?
Faizan Javed (‏@faizanj): the intense focus and controversy over an arguably out-of-fashion language.
Tony Showoff ‏(@TonyShowoff): Java is also "out of fashion" but still used, PHP is used by more web sites than any other language. I think it's inadequacy. A lot of things go in and out of fashion, but fashion doesn't reflect usefulness. Remember the coming p2p/push/xml/etc revolutions?
Faizan Javed (‏@faizanj): one can argue Cobol and Fortran are also still useful in their domains. But hip, cool and mainstream they are not.
Tony Showoff ‏(@TonyShowoff): So is hand looming one could say, but half of all internet sites don't use COBOL and half of looms aren't hand driven.

Like underwear, PHP is becoming cleaner, as if it's been washed with Tempa-Cheer on double rinse at high heat.

I think he does bring up a good point and question though. Are COBOL and Fortran fashionable at all since they still are in use, mostly in the realm of maintenance? Well, maybe, but I don't think so. As I tried to point out as best I could on Twitter, niche use cases are not the same thing as something being ubiquitous. Just as you can still find handloomers that doesn't mean machine looming is falling out of fashion, despite the rise in custom hand made items on etsy.com

I think people often confuse what's cool with what's in fashion and what's useful or available. This is less of a big deal in pop culture trends, but in the computer world it doesn't really make much sense. Sure, PHP may not be cool, I'm not sure if it ever was, but that doesn't change the fact that to this day when you want to find a web host, almost always they have PHP hosting available and not much, if anything else. Despite Python and Ruby becoming more hip, along with Erlang and the less useful other things which are some goofy spin off of another thing, they simply aren't available everywhere or ubiquitous.

So, in a sense, asking whether or not PHP is in fashion is sort of like asking whether or not underwear is in fashion. Sure it may be cool, or sexy, not to wear it, but for the most part you'll find it everywhere you look. Is that a bad analogy for PHP? Maybe, but reflecting PHP's problems over the years, I think it's pretty apt, but like underwear, PHP is becoming cleaner, as if it's been washed with Tempa-Cheer on double rinse at high heat.

But what about the numbers (click image for source information)?

stats-w3techs

php-trend-201301-netcraft

And finally, what about as far as community help goes? After all, a programming language's success and usability these days often relies on thriving communities. Well…

tiobe-community-stats

Uncool? Maybe, but no programming language has ever been cool. Out of fashion? I don't think so.

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 centre.
  • 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:

  1. 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
  2. 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 retarded expectations of what users can and should be able to do
  3. 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
  4. 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 Stackoverflow.

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

Hamburger Icon, the illogical and unnecessary name

Stolen from the BBC
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 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!" even if they don't understand what it's supposed to represent, they'll just associate it with menus.

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 the fuck 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.

Better Unicode support for MySQL (including emoji)

When it comes to character support I think the only thing that should ever be used is Unicode. That's right, I said it. However, when it comes to support in MySQL, things get a little bit murky.

I never had too much of an issue using plain ol' utf8_general_ci, however when trying to add language support for Gothic (tested because it's rare), I ran into a serious issue:

Source: brainstuck.com
Source: brainstuck.com

Son of a …

This issue is caused by the fact UTF-8 in MySQL isn't fully supported by utf8 the character set, it only supports a maximum of 3-byte characters. If you want something more realistic you're going to need to have at least MySQL 5.5.3 and you're going to have to use utf8mb4 not regular utf8. Yes, seriously.

Make sure you read through all this before trying anything, because there are edge issues, especially with indices (indexes) which you may need to consider.

Also back up your data first.

Updating Database

I'll be working under the assumption that you want your entire database to be utf8mb4, but if you don't then you'll have to adjust a bit, but seriously reconsider joining the 21st century if you're not using unicode. I'm also assuming you want case insensitive text, and if you don't, replace utf8mb4_unicode_ci with utf8mb4_bin — most people want case insensitive text in most cases.

Update the default character set and collation for your database:

Updating Tables

First we need to change the default character set, this way when you add new columns in the future, or whatever, you don't need to worry about adding all of the character set specification:

Updating Table Columns

Now, you can convert one column at a time, and this may be what you wish to do if you require different character sets for your CHAR, VARCHAR, and TEXT columns, here's how you do that:

Now obviously you're going to want to make sure that you're converting to the same column type and length, etc, the above is for example only and if you copy/paste it, you may screw up your column schema. Essentially you're just using ALTER TABLE CHANGE on the column in order to change the character set to utf8mb4 and collation to utf8mb4_unicode_ci.

If on the other hand you just want to change the entire the entire table at once, you can do:

Updating Table Indices

When changing the character type, you may run into this on InnoDB:

or this on MyISAM:

Ah, CRAP!

Oh snippy snap, snap, there are solutions:

If you're using InnoDB on MySQL 5.6.3 or higher you can enable innodb_large_prefix in your MySQL config file (more information in manual here), but if you aren't you can take a few steps to work it out the old way:

  1. Make note of the conflicting index, it's going to likely be one which is something like VARCHAR(255) or an index across multiple columns which includes VARCHAR. Make note of the index name, type, and which column(s) it crosses.
  2. In my own scenario, I had a lot of columns which included some sort of VARCHAR(254) and ID which was binary(20).  Now it seems like 254+20 = 274, and hey that's less than 767 (or 1000) so what's the deal?Well, not so fast there, Professor.MySQL doesn't count literal bytes in VARCHAR when it comes to Unicode, rather potential Unicode bytes are themselves counted as a byte (wait, what?).So if the column is 254 and it's utf8 that means the actual potential length is literally (254 * 3) bytes, and with utf8mb4 it's (254 * 4). So really the length of the key you're trying to create is ((254 * 4) + 20).InnoDB only allows a maximum of 255 bytes for the column in an index with utf8 and 191 bytes for utf8mb4.So if you need the entire column indexed, you aren't going to want to change the character set for that column(s), and instead I recommend changing all others one by one (as seen in the Table Columns section) rather than trying to convert the entire table. However if you do not need the entire column to be index, and in certain cases I did not.Drop the index:

    Then recreate it with the offending column(s) limited to 191:

    or if across multiple columns (assuming mycolumnb is not utf8 for example):

As long as the indices are the same, and in the same column order, you should receive the same benefits for the indices without worrying about redoing your queries.

Additional Notes and Considerations

If a column is not being used for search and case insensitivity isn't an issue, instead of using CHAR or VARCHAR, I suggest using BINARY and VARBINARY. Not only is comparison vastly faster, but also there's less to worry about as far as character set issues go, i.e. they don't matter. Further also VARBINARY is literal length so the UTF-8 limitations described in the index section of this post do not apply, so you can get the full width for your index.

Additionally instead of using TEXT, use BLOB, for the same reasons, but also realise the same limitations apply, such as no fulltext searching.

In summation, if you don't need case sensitivity and you don't need fulltext search, consider BINARY, VARBINARY, and BLOB over CHAR, VARCHAR, and TEXT, it'll be a lot easier to deal with when it comes to Unicode.

You can learn more about this on my MySQL performance, using case insensitive columns post.

Database Connections

Depending on your programming language, you may need to specify when connecting which chartype to use (you can also, in most cases, specify this on configuration, see that section at the bottom), this usually can be done by sending this query  right after connection:

Configuration

You can edit your my.cnf (or my.ini on Windows) and make these changes to the appropriate sections of the configuration file (applicable to MySQL 5.6, older versions may need adjusted configuration):

So, what the hell is type casting anyway?

Casting is a way to take a liquid and mold it int… oh yeah

So casting is just a fancy way to refer to type conversion, that is where you change the "type" of a variable from one thing to another. For example changing a string to an integer.

How about some examples? Is that what you want?

OK, fine, you talked me into it. Here are some PHP examples:

So, who cares? What's the point?

Well, depending on what you're wanting to do, it's important to change the type, and this is especially true in languages where there is no dynamic typing (like C#) and it's still useful in languages with dynamic typing like PHP, because it allows for one to avoid potential issues with mathematics, concatenation, etc. Aside from math related things, in PHP I use (int) a lot to clean up variables for SQL queries for both safety and also so MySQL doesn't have to convert the types itself.

You can learn more about type casting in PHP specifically and why it's a great way to do certain things here: Casting int faster than intval in PHP.

Let them learn COBOL / PHP isn't evil

I received this in my inbox earlier:

What programming languages should a modern-day programmer have in his/her arsenal? (Quora)

OK, fine, now I'm forced to evangelize for PHP, this puts me in a really painful position, but since I'm apparently the only person

Give me some of those Valley trends, baby
Give me some of those Valley trends, baby

reading this who can think for myself instead of freebasing whatever the Valley tells me to use, here we go…

The general theme seems to be to either learn a pretty hardcore language like C or C++ which won't benefit most people right away these days, since there's almost no excuse to make classic applications anymore. I think if anything it will discourage some people from learning to program since they have to spend a lot of time learning to clean up garbage, compiling, debugging, etc. Way to ruin their fun by making them spend all that time on a language better suited for drivers than web or phone apps.

Promoting Java is also a thing for some reason, I thought we were trying to kill this language? It's still used by a lot of places, but so is COBOL. In fact there's still a ton of places that use COBOL, so why not promote it? Probably because it doesn't come with a hipster mustache and a really tall bicycle.

If it's about job security, automatically Python and Ruby were a terrible suggestion, same with Erlang. You might as well be one of those skinny guys promoting Lisp.

A huge one though is promoting Python (and sometimes Ruby), blindly suggesting it's the best way to go without consideration for how huge of a pain in the ass it is to start a project. The syntax of the language(s) is very easy and the language itself quite powerful, but also slower than other options, harder to get going, and not widely supported. Starting a project in Python is about as difficult as starting a car by putting the engine in the car first. Turnkey? Hell no. You can get used to it, take some shortcuts, etc, but really for a new person, it's a nightmare.

It's really a hipster language, and Monty Python isn't funny, I'm just saying, it really isn't, I mean, seriously.

That's unrelated to this topic, but since Python is named after it, I felt it was important for me to communicate that it's just … knights who say Ni? yeah, fucking falling over laughing. Monty Python films had a few snicker moments here and there, but it was mostly diarrhea (or diarrheoa). I liked Flying Circus much better, why don't many people talk about that?

Yes, I've seen all of the popular films, and no I didn't laugh. I didn't go into expecting it to be about as funny as a hernia operation either. I had thought they would be funny since that's what people were saying, and after wasting about six hours of my life I realized: holy shit, I didn't laugh once. No, I mean that literally, I didn't laugh one time. A few smiles, sure, but not much else.

Anyway, where was I? Oh yeah, terrible ideas…

Some other promotions for assembly, as if it's 1977 or something.

In general though there was a lot of PHP hate spread through the entire thread, mostly that it was bad, but nobody ever saying why, it just is. That's a lot of bullshit. It's because PHP is widely used, widely available, and despite their claims PHP has made a massive amount of headway over the last few years, and is only getting better.

Much of the complaints about PHP people have are true.. if you've fallen out of a time machine from 2004. Hating PHP is like hating MySQL, it's just easier to ignore the last decade and pretend nothing ever changes, then go on to promote your slower, less widely available, much cooler alternatives of Python and PostgreSQL.

It's just the toxic runoff coming from the Valley of essentially acting like Pookie for anything cool coming out of the Valley, Bay Area, etc. And hey, I've lived in the Bay Area, so that makes me an authority on everything there.

I don't mind the C# suggestion, I don't like the platform limitations. Yeah there's mono, but seriously, yeah, who cares. C# has a lot of things like static typing that I wish PHP had, but Hack from Facebook does add a lot of those features right back into PHP and many of those will be moved into core PHP over the next couple of years.

The blinding hatred of PHP out there causes people to promote things in a manner which can slow newcomers down. PHP sure isn't perfect and there are of things I'd change about PHP, but it's faster, extremely powerful, and most importantly easy as hell to get going.

I'm of the mind though if we're going to want to stop people from learning to program, then yes, let's promote Python, Ruby, Erlang (what the fuck are you promoting this for, do people making small sites really need message queues? Don't be an asshole.), and while we're at it Java. Languages which can be easy at face value, easy in syntax, but a pain in the ass to get going and deal with, not to mention slower. Except Java and Erlang, those can be pretty fast.

So reasons not to learn PHP?

  1. It's not really cool
  2. It's not the steam punk of languages like Python, so you don't get a stupid ass top hat with goggles and proclaim you're awesome
  3. It's making headway faster than most languages, some of which aren't even changing or improving at all any more.
  4. It's widely available, i.e. essentially everywhere, so you're not held hostage by host availability
  5. It will help you learn C-style syntax which you can more easily pass on to other languages like JavaScript (also used on the web), plus countless other languages like C, C++, Java, C#, etc

Python and Ruby aren't bad to have in your arsenal, but blindly suggesting them first, when C-style languages is king is just ridiculous. Meanwhile the most popular web language being PHP, which is a C-style language, oh no, don't use that, it's bad just because it's bad, I mean, no reasons listed here, it just is.

Anyway, now a choice, spend 10 seconds starting a PHP project or spend half an hour setting up a Python environment and prepping shit just to get coding, and I mean really coding, throwing things directly to the interpreter isn't how you make real projects, it's how you demonstrate the language without making it obvious how much of a pain in the ass it is.

I'll use the language best suited for the situation, I'm not going to blindly dislike something because a broader community of self-deluded permanent man-children hate it.

My choices of languages:

  • PHP
  • JavaScript / node.js
  • Ruby
  • C#

My choice of languages in 2004:

  • Perl
  • C++
  • PHP

My choice of languages in 1997:

  • Perl
  • C++
  • Visual Basic

Nope, shit never changes, I'll just use Python forever and tell everyone that's all I've ever loved.

I hope you can appreciate the irony of blind hatred and ignorance of modern PHP meanwhile essentially doing the same thing with Python. That's my point, when it's turned around, it's obvious how idiotic you look.