Category Archives: Uncategorized

Set Background Colour with AngularJS

From the “I can’t believe I had to look it up” department:

One can use ngStyle to programmatically set the background colour of an element. This is arbitrary ugly code that demonstrates the concept:

[html light=”true”]
<span ng-style="{background: item.color}">

The “gotcha” is if one wishes to only use this on a certain page, one must reset the colour when the controller’s $scope is destroyed:

$scope.$on("$destroy", function(){
    $("body").css(‘background-color’, ‘white’);

Initializing Objects with $.extend()

If jQuery is available, $.extend() can be useful “quick and dirty” method for initializing an object with defaults, while allowing for the caller to provide values to override the defaults.

The advantage is simplicity. One disadvantage is that there is no checking of arguments. The particular situation will drive the relative importance of each.


AngularJS ngLocale Error

AngularJS, like all frameworks has its warts. Its documentation is spartan but adequate for most purposed.

When AngularJS encounters an error, it tends to cough up a messy hairball of unhelpful information.

For example,

[$injector:nomod] Module ‘ngLocale’ is not available! You either misspelled the module name or forgot to load it. If registering a module ensure that you specify the dependencies as the second argument.$injector/nomod?p0=ngLocale

By all rights I read this as a failure to load ngLocale. It took me some backtracking to determine that the cause of the error has nothing to do with ngLocale.

The Cause

I simply attempted to use a service that exists in a module that hasn’t been loaded. Adding the module to the application module’s dependency list resolved the error.

My druthers would be an error along the line of “Dependency ‘foo’ not found.”


Installing Django on CentOS

These are notes for what I did to get Django working on CentOS.

Activate EPEL.

Use the appropriate version, of course. I used:

[bash light=”true”]
$ sudo rpm -Uhv

Install Prerequisites

  1. Install Apache.
    1. Ensure it’s working, including ensuring the firewall lets traffic through.
  2. Install MySQL
  3. Install revision control or however you pull software, e.g. git.
    1. Create a non-priviledged user, if that’s you install your software.
    2. Ensure Apache can access the software directory.

Install Django

[bash light=”true”]
$ sudo yum install python Django mod_python MySQL-python

Test Django

[python light=”true”]
$ python
Python 2.6.6 (r266:84292, Feb 22 2013, 00:00:18)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import django
>>> print django.get_version()

Install and Test the Software

I create a separate user for managing the code via git.
Put the code somewhere appropriate, e.g. /opt.

  1. The address tells Django to accept external connections.
  2. Ensure the test port is open on the firewall.

[bash light=”true”]
$ cd /opt/foo
$ python runserver

Attempt to connect to your application. Ensure, for example, that the settings allow database access.

Running Django from Apache WSGI

Create an Apache WSGI file.

[bash light=”true”]
$ cd /opt/foo
$ mkdir apache
$ vim apache/django.wsgi

and fill the file with something like:

import os
import sys


os.environ[‘DJANGO_SETTINGS_MODULE’] = ‘foo.settings’

import django.core.handlers.wsgi
application = django.core.handlers.wsgi.WSGIHandler()


Inside of the Apache virtual host:

<VirtualHost *:80>

WSGIScriptAlias / /opt/foo/apache/django.wsgi

# Alias /robots.txt /opt/foo/static/robots.txt
# Alias /favicon.ico /opt/foo/static/favicon.ico
Alias /static/admin/ /usr/lib/python2.6/site-packages/django/contrib/admin/media/
Alias /static/ /opt/foo/static/

<Directory /opt/foo>
Order allow,deny
Allow from all

<Directory /opt/food/static>
Order deny,allow
Allow from all

Restart the Apache server.

Test to ensure that you can connect.


A big shout out to ITek Blog’s article Installing Python / Django on Centos 6.3 is Easy!.

Remote control via ssh keys

These are some notes on remotely controlling a machine with ssh keys.

On a couple of remote testing machines I wanted to automatically pull the latest updates from git and restart the dæmon. The ~/.ssh/authorized_keys file is normally used “plain” with keys to allow login.

It is, however, possible to run a command when a certain key logs in, instead of dropping to a console. This makes it possible to remotely update and restart a dæmon from a script.

Take, for example, the line

command="/usr/local/bin/update-foo-from-git",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa AAAAB3NzaC1yc2EAAA...

This directs ssh that when this particular key is authenticated, forwarding is disabled and the script /usr/local/bin/update-foo-from-git is run as the logged in user.

If the script needs to touch something that requires higher privileges, sudo can be configured to allow that user to execute that script as a different user. For example the line

myuser   ALL= NOPASSWD: /usr/local/bin/update-foo-from-git

could be added to /etc/sudoers, and the line in .ssh/authorized_keys would then look like

command="/usr/bin/sudo /usr/local/bin/update-from-git",no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-rsa AAAAB3NzaC1yc2EAAA...

and the script could, for example, restart a system dæmon.