V) Em G#+/B# C#m G#m F#m A F Dm 2 2 2 2 2 2 2 2 F#m B C#m A G#m C#m A B 2 2 2 1 1 2 1 1 Em G#+/B# C#m G#m F#m A F Dm 2 2 2 2 2 2 2 2 F#m B Dm C#m G#m A B 2 2 2 2 2 1 1 Em G#+/B# C#m G#m F#m A F Dm A 2 2 2 2 2 2 2 2 8 C) E B/D# G#m F#m G#m F#m C D 2 2 2 2 2 2 2 2 E B/D# G#m F#m G#m F#m C D 2 2 2 2 2 2 2 2 E C#m7 Amaj9 F#m9 4 4 4 4 E C#m7 Amaj9 F#m9 4 4 4 4 E C#m F#m7 C D 4 4 4 2 2
Character Encoding Bug of the Day
Today I had one of those bugs that starts out looking simple and keeps going deeper and deeper. Video service Kaltura has a plugin for Moodle, that just stopped working one day (no changes on the server).
- It’s throwing an exception because an expected element isn’t in the page.
- Oh, the element’s supposed to be delivered by XHR from the plugin.
- But the plugin’s code is generating correct markup…
- Why is Moodle’s function to serialize an array into a JS function call returning
null
for that markup? json_encode
is converting the markup string to null?- Because
json_encode
is choking on invalid UTF-8. - Because the markup has a right single quotation encoded in Windows-1252 :(
- And that string is coming from the Kaltura API.
So over 2 years ago someone named a video player Jim’s Test Player and over the weekend Kaltura’s API started returning that single quote in Windows-1252. We removed the quote from the name and the problem disappeared.
Simpler Masonry + Sortable Working Together
Since jQuery Masonry repositions elements purely by positioning, it does not play well with UI Sortable. People have posted complex solutions to this problem, but this simpler solution worked for me:
- Refresh masonry layout on Sortable’s start, change, and stop events
- While dragging, remove from the dragged item the class used to indicate it’s a masonry item
var $c = $('#my_container');
$c.masonry({
itemSelector: '.masonry-item'
});
$c.sortable({
start: function (e, ui) {
ui.item.removeClass('masonry-item');
$c.masonry('reload');
},
change: function (e, ui) {
$c.masonry('reload');
},
stop: function (e, ui) {
ui.item.addClass('masonry-item');
$c.masonry('reload');
}
});
GitHub: Please Syntax Highlight New Files
While syntax highlighting diffs in general would be difficult, it would be easy (and super useful) to apply it to new files.
(All I did to create the mockup below was to take the regular file view and apply background #DDFFDD. It could be that easy.)
Installing xhprof on XAMPP for OSX Lion
Directions adapted from Ben Buckman.
Download xhprof.
cd path/to/xhprof/.../extension # If you don't have autoconf... I didn't. sudo chmod o+w /usr/local/bin #(brew needs to write a symlink there) brew install autoconf sudo /Applications/XAMPP/xamppfiles/bin/phpize
Make sure you have a CLI C compiler. I installed one via XCode.
sudo MACOSX_DEPLOYMENT_TARGET=10.6 CFLAGS='-O3 -fno-common -arch i386 -arch x86_64' LDFLAGS='-O3 -arch i386 -arch x86_64' CXXFLAGS='-O3 -fno-common -arch i386 -arch x86_64' ./configure --with-php-config=/Applications/XAMPP/xamppfiles/bin/php-config-5.3.1 sudo make sudo make install sudo nano /Applications/XAMPP/xamppfiles/etc/php.ini
Add these lines to php.ini:
[xhprof] extension = xhprof.so xhprof.output_dir = "/Applications/XAMPP/xhprof-logs"
Restart Apache.
jQuery.Deferred() is pretty easy
I was using an asynchronous file uploader and, for usability, wanted to make sure the upload progress bar was displayed for at least a couple seconds before changing the view. The jQuery.Deferred object made this a breeze, eliminating a bunch of callback/isDone checking mess:
var uploadFinished = $.Deferred(), timerFinished = $.Deferred(); $.when(uploadFinished, timerFinished).done(function () { changeView(); }); // immediately after starting upload setTimeout(timerFinished.resolve, 2000); // in upload completed event handler uploadFinished.resolve();
The docs make the Deferred object a little more complicated than it really is. You don’t have to have to alter processes to return Deferred/Promise objects, you can just make them and pass them around as needed in a pinch.
“If You’re Feeling Sinister” Documentary!
Shared Server Development with PhpStorm
Working on a remote server—with or without multiple developers—is just asking for problems, but sometimes there’s no way around this. I’ve used several IDEs for this task and found that PhpStorm has several unique features that ease the pain considerably:
- It fingerprints remote content on download and re-verifies the remote content before auto-uploading. If someone else has edited that file, you get an option to merge/download/cancel. If the merge has conflicts you get a nice diff view to make manual decisions.
- It can check the server whenever you open a file. That way you can known right away remote changes have occurred before working.
- It keeps a history of all file changes and lets you revert to any or merge content from any of them into the current version. Even if you git commit frequently, this is a huge help sometimes. A coworker had accidentally overwritten one of the files I had recently changed and added his own code. When I realized this I just popped open Local History and merged my changes into the current file with a single click.
- It can generate a diff with remote over a file/directory tree. You then can decide per file whether to upload/download/delete/leave as is.
- It can auto-deploy changes made outside the IDE. I can set it so while PhpStorm is open, anything done to my local cache files (e.g. git checkout/some other operation) is deployed to remote.
PhpStorm basically nails remote development like it does most other areas.
Why not work on via remote file system (e.g. samba/sshfs)? With basic text editors you can kinda get away with this, but a true IDE needs to watch a lot of files, and if they’re remote…
Why not use an IDE on the remote server? I don’t know of any text-based IDE. Extremely good code editors, sure, but that difference matters.
Sparks “Sherlock Holmes”
The jam.
Cannabis criminalization helps law enforcement (perform unconstitutional searches)
Opponents of cannabis decriminalization often state we should keep it criminalized in order to help law enforcement catch bad guys, and indeed it serves as an important tool for justifying searches on individuals and premises. After all, these searches may turn up more harmful criminal activities or individuals with warrants. LEO’s will often admit that in many cases they are not really after the pot and may even ignore the offense if no other offenses are found.
From a public safety standpoint, allowing “I smelled marijuana” to serve as probable cause for search may on net improve safety, but we should reject this notion because these searches are basically unconstitutional. Cannabis use, after all, is not what most officers are really after; it’s a justification.
The Fourth Amendment was not created by accident; the power to search without cause can and often is abused by LEOs, and the especially militarized flavor of drug raids in the U.S. is often needlessly violent and deadly.
When cannabis is no longer criminalized, yes, searching individuals based on a hunch (without real cause) will be harder—the goal of the Bill of Rights was not to make policing easy—but consider if we had never criminalized cannabis and it had at least as many users as it currently does. Knowing what we now know about the mild harms of the drug, would we really choose to turn at least several million people into regular criminals in order to give LE the power to search them without cause and occasionally using violent SWAT raids?
No we would not and should not. If anything this “LE tool” argument is a reason to decriminalize.