Recent blog posts
John Kawakami's blog
The technique here is cool. You can find out how much your eyeballs pivot, and how far apart the lenses need to be.
I got 65mm and 70mm.
Here's a Jasmine spec to instantiate an HTML5 widget and test a few of the method calls. These method calls cause changes in the DOM, and these tests verify that the changes happened.
This is a trick to write modules that are testable in a browser, without subjecting the test to Browserify. Why?
I want to develop without the compilation step. It's easier and faster to work in the browser. (This particular app is mostly DOM manipulation, so headless isn't important.) Once the module has settled down, it can be added to the library.
The rest of this note assumes you know the Jasmine sample test runner included with the distro.
I wrote the original experiment a couple years ago. It's a JS client that retrieves some json data from the la.indymedia.org server, and displays it. I ran out of time, and didn't finish it then.
Upon revisiting the code, I found it a little confusing. It was around 800 lines of jQuery-style JS.
Learning d3 events this afternoon. These are the notes I'm taking while I'm learning it. I hope it helps.
It's called d3.dispatch. d3.dispatch('eventname1','eventname2') returns an object that manages setting event handlers, and dispatching events. The event system isn't global (unlike in most frameworks, where the event system appears to be globally available)- it's contained entirely within the object.
We all take it for granted that most sites will have a user registration system, and way to log in. We're used to it, and most people are unaware of how complex it is.
So, how complex is it?
It's around 15 different steps or screens.
I've done it a dozen times, and I think that's about right.
I took a step away from Angular and jQuery style coding conventions and dropped back to the traditional JS-style OOP, mainly because I wanted to get familiar with regular JS programming using the MDN docs, and learn the new HTML5 calls (which aren't new anymore).
I ended up coding using an MVC style, and consequently, added an event handling system. It was easy-but-cheesy so I eneded up using Backbone's event system. (It makes me look more hip.)
BTW, here's one way to use Backbone events within traditional JS code:
This is a short snippet of code to do the popular "parallax" effect for headings. This code has two boxes. The second box helps you see how to deal with a box that's not at the top of the page.
There's not much to it. You make some boxes and set the background-position based on the window.scrollY value.
So, I'm doing wordpress programming, and one of the headaches is that they store serialized objects in the database with the update_option() and related functions.
This makes querying some data difficult. Here's an example of the data structure I was dealing with (it stores sidebar settings).
Array ( [wp_inactive_widgets] => Array ( ) [sidebar-1] => Array (  => search-2  => recent-posts-2  => recent-comments-2
This took forever to fix. I upgraded the computer two versions of Ubuntu ago, and ever since then, the front mic stopped working.
It could be the mic's wire or the mic, but even a standalone mic wasn't working. It worked OK with Audacity, which uses Alsa.
It turned out the problem was that the Sound control panel in Gnome didn't work. Somehow, the system decided to change the input from Analog to Digital SPDIF. I don't use SPDIF.
I've been modifying the wp-signup script a lot, and figured out a better pattern for doing these screens. This technique works more like "views and controllers", so it's one step closer to MVC.
WP doesn't have routes, but the wp-signup script has a paramter named "stage" that specifies the next state. It's effectively a route.
There are two types of stages: showing a form, or validating a form.
When you validate a form, you see if there are errors. If there are, you show the form, with error messages. If there are no errors, you commit the changes, and then show the next form.
I've answered this a couple times so I'm writing it down :)
DI is a way to separate services from the code that uses those services.
DI makes testing easier. It also allows the services to be replaced with alternatives - but this is less important than the testing.
DI is used in Angular, Zend Framework 2, Symfony and more frameworks.
DI is implemented as an array or dictionary of services with generic names. Services are created during startup, and registered.
Edge 2 looks nice. I'm kind of surprised I haven't heard of it before.
Also, while I'm keying up this tutorial series, it's dawning on me that it would be good to state that I'm aware that the "in" thing is moving away from apps with templates, and toward REST and real-time. I am learning Django because I started out with Django REST Framework - and the DRF material didn't really cover the various authentication, authorization, and general programming issues.
List comprehensions are a difficult-to-learn feature of Python that seem unnecessarily terse, but that's because the examples aren't that practical. It's really a powerful tool.
I was using Tweepy to get some tweets from the Twitter API, and it was a LOT of data. You'd think a 140 character string isn't that big, but Twitter delivers a lot of metadata. It's around 7K of metadata per tweet.
So, I had 15 tweets in a list, or around 100K worth of __str__ representing dozens of objects. How do you slice that up?
You use dir() to explore the properties of the different objects.
So, I started implementing the Django provided user login screens yesterday and it was requiring a ton of reading to get the different parts working. It seems so simple, from the outside, but all the configuration options made it seem more difficult than it really is.
In the attached file, a few of the old configs and views have been deleted, but I'm not going to cover that here. Just do diffs between the contents of the attached tgz files to see the differences.
Create a file in your global templates, templates/registration/login.html: