Kyle Fuller

Building a Corsi–Rosenthal Box

2025-04-08T00:00:00+01:00

A Corsi-Rosenthal box is a DIY air cleaner which outperforms commercially available options at a fraction of the cost.

Sourcing the parts to build a Corsi-Rosenthal box outside of North America has some challenges. The ubiquitous box fan typically used is non-existent, and standardised filters are not readily available.

After doing some research on potential options I had found Stefan Stojanovic's research and testing on the topic, along with build guide. This looked promising, however I quickly discovered it was not possible to source the fan used anymore, and I was unable to find another viable options.

Eventually I stumbled across some variants that use PC fans, originally aimed at reducing the power consumption of running the system. I discovered that in testing an array of PC fans has negligible performance difference than a box fan in a CR-box.

Eventually, I was able to put together a parts list to be able to construct the box with somewhat available parts found in the UK (and I imagine available in many countries).

#	Part	Price
6x	Arctic P14 Fans ¹	£41
6x	Generic 140mm fan guards	£12
1x	USB-C PD to 12v DC5521 Adapter ² ³	£8
1x	12v DC5521 to 3/4-pin fan adapter	£7
1x	3/4-pin fan splitter (1 -> 6 fans)	£5
1x	Ikea TRETAKT Smart Plug ⁴	£6
4x	3M Filtrete MPR 1900 (20x25x1) ⁵ ⁶	£140
		£215

While constructing the lid which contains the fan, I had found that a utility knife worked best to cut circular holes in cardboard. I used additional cardboard layers glued together to reinforce the lid to that it is able to hold the weight of 6 fans.

Overall, the CR-box meets expectations. I have previously built an air quality sensor which I am able to see that the CR-box is able to filter PM2.5 particulates effectively based on its measurements.

The blue dotted line indicates when the CR-box was deployed, on the 25th. When the box is operating the PM2.5's detected drop to less than 0.5 µg/m³, and build up over time when the system is off.

Arctic fans are relatively affordable and performant, used in the testing by Jim Rosenthal. ↩
USB-C PD allows using generic and efficient AC adapters. USB-C PD AC adapter and USB-C cable is not included in the parts list as I already had these. ↩
The selected fans operate at 12v at 0.15A each. Therefore the adapter needs to be able to drive over 10.8w. ↩
A smart plug will allow automatically running the CR box either on a schedule, or in reaction to the measured air quality. ↩
A MERV 13 filter appears to be more than sufficient for my use-case, if it was available a cheaper MERV 11 option may be better suited. ↩
To cut down on waste, washable/reusable options are available, such as K&N Lifetime series. I had not found any performance data in a CR-box, however will research further if/when the filters need replacing. Sourcing them may be challenging. ↩

Using Swift Package Manager with Carthage

2016-12-01T00:00:00+00:00

Some users of my libraries have asked how they can integrate these libraries into their applications using Carthage dependency manager.

Carthage requires libraries to provide an Xcode project or a binary framework. However, since many of my Swift libraries are cross-platform, I am not developing them in Xcode. In addition, distributing binary frameworks from Swift source is not recommended by Apple because the Swift ABI is not yet stable. Therefore the frameworks are tied to specific releases of Xcode.

"While distribution and use of 3rd-party binary frameworks is not recommended (as mentioned in a previous blog post), Swift supports construction and distribution of frameworks in source form." [source]

Since Swift Package Manager offers the ability to generate an Xcode project, it would allow Carthage to be able to build a Swift Package Manager dependency with Xcode.

This post provides instructions on how to generate Xcode projects with Swift Package Manager manually. In the future, I think it would be possible for Carthage to do this automatically with changes to Carthage if desired.

Note: These instructions should work for simple dependency graphs. If you have the same dependency resolved by Swift Package Manger and Carthage you may hit some problems.

Installing your dependencies

As the first step, you will need to add your Swift Package Manager dependency into your Cartfile.

For example, if we want to integrate Stencil and Commander we could use the following Cartfile:

github "kylef/Stencil" ~> 0.6.0
github "kylef/Commander" ~> 0.7.0

Then you can use Carthage to checkout and fetch the source of your dependencies.

$ carthage update

Once you have the source of your Swift Package Manager dependencies you can use Swift command line tool to generate an Xcode project for each dependency. The command line tool provides an generate-xcodeproj subcommand.

$ swift package generate-xcodeproj --help
OVERVIEW: Generates an Xcode project

OPTIONS:
  --enable-code-coverage   Enable code coverage in the generated project
  --output                 Path where the Xcode project should be generated
  --xcconfig-overrides     Path to xcconfig file

To generate Xcode projects for our example above, we can change into the source directories and invoke swift package generate-xcodeproj:

$ (cd Carthage/Checkouts/Stencil && swift package generate-xcodeproj)
$ (cd Carthage/Checkouts/Commander && swift package generate-xcodeproj)

Then you can use Carthage to build the dependencies.

$ carthage build
*** Building scheme "Commander" in Commander.xcodeproj
*** Building scheme "Stencil" in Stencil.xcodeproj

Finally, you can integrate your dependencies into your application using the instructions from Carthage on adding frameworks to an application.

For a macOS application, you would need to copy the frameworks that Carthage built (which can be located in Carthage/Builds/Mac) into the "Embedded Binaries" section of your Xcode project.

NOTE: You do not need to embed any of the dependencies testing frameworks into your application.

Automated CocoaPod releases with CI

2015-09-25T00:00:00+01:00

Using continuous integration (CI), we can automate releasing our CocoaPods to trunk. When someone tags a new release and runs git push, CI will publish the pod to CocoaPods trunk.

This guide walks you though settings this up on both Circle CI and Travis CI. If you are not using these CI providers, you should be able to follow a similar technique.

CocoaPods trunk Access Token

To release new or updates to existing pods you will need an access token for trunk. This is normally created using the pod trunk register command.

We're going to use this command to generate a unique token for our CI server to perform release. Using the following:

$ pod trunk register kyle@fuller.li --description='CI Automation'
[!] Please verify the session by clicking the link in the verification email that has been sent to kyle@fuller.li

NOTE: Remember to change my email address for the email address you use with CocoaPods.

The next step will be to go to your email and "verify" the session by following the link in your email.

Hi Kyle,

Please confirm your CocoaPods session by clicking the following link: https://trunk.cocoapods.org/sessions/verify/uniquehash

Once your session is verified, we can then grab the access token from CocoaPods to use in CI . CocoaPods stores the access token in the standard ~/.netrc file.

We can pull this out using the following:

$ grep -A2 'trunk.cocoapods.org' ~/.netrc
machine trunk.cocoapods.org
  login kyle@fuller.li
  password ef9bb4c41a4459ba92645a85b3c9cd88

You can see our token is ef9bb4c41a4459ba92645a85b3c9cd88, we now will need to configure our CI server and set the environmental variable COCOAPODS_TRUNK_TOKEN with the value of our token.

IMPORTANT: Once you have an access token for CI, you should run pod trunk register again so you are locally using a separate token from the CI service.

Circle CI

On Circle CI, the access token can be configured in the settings for your repository on their website.

Travis CI

Like Circle CI, you can also add the access token for CocoaPods trunk in the settings for your repository like follows:

IMPORTANT: Ensure that Display value in build log is not enabled.

You can also use the travis CLI tool to encrypt environmental variables in your .travis.yml file.

Running `pod trunk push` when new releases are tagged

The next step is to configure our CI process to push our pod when a new release is tagged.

Circle CI

For Circle CI, we can add a deployment section to run the pod trunk push command on new tags.

machine:
  xcode:
    version: "7.0"

deployment:
  release:
    tag: /.*/
    commands:
      - pod trunk push

Travis CI

Similarly on Travis CI, we can add a deploy section to run a custom script scripts/push.sh on new tags.

language: objective-c
osx_image: xcode7
deploy:
  provider: script
  script: ./scripts/push.sh
  on:
    tags: true

You will need to create a scripts/push.sh file in your repository and commit it so that Travis CI will configure rvm (ruby version manager), and then run pod trunk push on deployment.

#!/usr/bin/env bash

source ~/.rvm/scripts/rvm
rvm use default
pod trunk push

Pushing your Pod

That's it, now when you push new versions to your CI server they will automatically be released to CocoaPods trunk!

$ edit Stencil.podspec
# Update the version in the podspec
$ git add Stencil.podspec
$ git commit -m 'Release 1.0.0'
$ git tag 1.0.0
$ git push origin master --tags

Examples:

Stencil uses Circle CI for deployment
Commander uses Travis CI for deployment

Note on Security

It's important to note that we've uploaded an access token to our CI server. Using this token it's possible to publish new, or update your pods. Therefore it's extremely important to keep this token private and do not share it with anyone.

In the event that your trunk session has been compromised, you can invalidate any other sessions using the following:

$ pod trunk me clean-sessions --all

Migrating from OCUnit to XCTest

2014-04-09T00:00:00+01:00

You might think you were in luck when Xcode offered you an option to migrate to XCTest, but shortly after trying you will discover that this isn't a true migration. Xcode will only migrate your code, it will not update your project to be testable with XCTest. There are still some steps left and unfortunately Apple have not shared any documentation on how to do this.

Note

I have later discovered that it does work as expected, but only if you run the conversion from a project directly. If you try running the conversion from a workspace you will get the problems mentioned above. I have filed this as rdar://16581037 so Apple can fix this in the future. For now, you'll need to follow the below steps.

You can follow these steps to migrate your project to XCTest once you've migrated the code with the automatic converter:

Change the Wrapper Extension your project's test target in build settings from ocunit to xctest.
This is the scary part, you are going to need to manually edit your Xcode project by hand and replace the product type for your test target. Firstly, close Xcode and then open the project's project.pbxproj in your favourite text editor and search for the product type. You will need to change it from com.apple.product-type.bundle to com.apple.product-type.bundle.unit-test.
```
 productReference = 77DC06B215702EDB0001EF8C /* PalaverTests.xctest */
-productType = "com.apple.product-type.bundle";
+productType = "com.apple.product-type.bundle.unit-test";
```
Remove the OCUnit Run Script build phase from your project's test target.
Replace SenTestingKit framework with XCTest inside the test target's link with libraries build phase. Even better, you can clean up your project by enabling modules instead of adding XCTest.
For iOS, you may need to add the SDK's developer frameworks so the linker can find the XCTest framework for iOS when building the project.

You will need to add $(SDKROOT)/Developer/Library/Frameworks to the framework search paths for the test target.

Kiwi

If you are using Kiwi, be sure switch to the XCTest pod.

pod 'Kiwi/XCTest'

Memory Management with ARC

2013-10-24T00:00:00+01:00

This blog post accompanies a talk I recently gave at NSLondon, you can find the slides for this talk here. There will also be a video version of this out shortly, I will post a link once it's out on my Twitter.

ARC is a very powerful feature introduced in Xcode in 4.0, along with various run-time enhancements. With the introduction of ARC, a lot has changed under the hood. The Objective-C run-time has a completely new interface for using many of the old concepts such as autorelease pools. There is also a new interface for retaining and releasing objects.

This post will briefly explain these concepts, along with how they work in the runtime. It will include any common mistakes such as retain cycles, the dealloc problem and copy vs strong with blocks.

Retainable Object Pointers

Automatic Reference Counting (ARC) is a tool for managing retainable object pointers. This is any kind of pointer to an object which can handle the Objective-C machinery for sending the retain, release and autorelease messages.

These messages are not sent in the way they would have been done pre-ARC, but instead using the objc_retain, objc_release and objc_retainAutorelease functions.

Retainable types include id, Class and NSObject. Along with __attribute__((NSObject)).

__attribute__((NSObject)) is an attribute which allows you to declare that a typedef can support memory management by ARC. That the objc_retain, objc_release and objc_retainAutorelease function is supported with this type and that it can retain and release memory as expected.

dispatch_queue_t is a perfect example of this. Starting in iOS 6 and OS X 10.8, this type (and many other types) support memory management by ARC. Therefore you can use use these types with the strong property referencing.

@property (nonatomic, strong) dispatch_queue_t completionBlock;

Ownership Qualification

What gives ARC it's immense power, is the fact that you can mark different pieces of memory with qualifiers to indicate how it should be handled. Weather it be strongly holding them with the __strong qualifier or not doing any management at all with the __unsafe_unretained qualifier.

__unsafe_unretained

__unsafe_unretained is by far the most simple. It basically means that no memory management will be done. It can be used for both objects and scalar types such as int and BOOL.

__strong

The strong qualifier will strongly hold an object. It does so by retaining an object when one is set to a strong pointer. When this pointer is set to nil, the object is released.

For example, the following two piece of code will do nearly identical things.

// Without ARC
- (void)setName:(NSString *)name {
    [_name release];
    _name = name;
    [_name retain];
}

// With ARC
- (void)setName:(NSString *)name {
    _name = name;
}

__weak

Weak is an interesting qualification. It allows you to reference an object, when the object is deallocated the pointer will become nil. Instead of retaining an object, the object's retain count will not change with weak referencing.

Because weak objects can be released at any point of time, it's often important to create a strong reference to it. This allows you to keep it alive while it's in use.

Most of the work for weak referencing is done in the new run-time support in Objective-C, introduced in LLVM along with ARC.

When setting a weak pointer, ARC will call id objc_storeWeak(id *object, id value) which simply adds the pointer (object) to the value object's table of weak references.

Now, when the object value is deallocated, it will iterate over every object in the weak referencing table and set those weak references to nil.

Alternatively, the objc_destroyWeak(id *object) function is used to delete this pointer from the object's weak reference table. This is normally called from an object's dealloc.

Because weak has to maintain this table of references, it adds the necessary overhead to do this. I have done some testing and it shows that weak referencing can take over three times as long as the normal strong referencing.

objc_arc_weak_unavailable

Using the objc_arc_weak_unavailable attribute, you can mark an object so that it cannot be used with the weak qualification. This may be handy for types which use __attribute__((NSObject)).

__autoreleasing

Autoreleasing has been around for a while, however it has changed a lot with the introduction of ARC. You can no longer use the NSAutoreleasePool class.

Instead, you can use the objc_autoreleaseReturnValue(id value) function to autorelease an object. This will retain the object and then return it. While it will also add it to the current release pool.

To drain the release pool the objc_autoreleasePoolPop(void *pool) function is called.

Blocks

I often see this question of strong vs copy for blocks and there is a lot of confusion about what you should be using.

In Apple's transitioning to ARC guide, they mention this:

Blocks "just work" when you pass blocks up the stack in ARC mode, such as in a return. You don’t have to call Block Copy any more. You still need to use [^{} copy] when passing "down" the stack into arrayWithObjects: and other methods that do a retain.

Blocks will be stored in the current stack, this means they are available in the local scope. If you use them outside, you must make a copy of the block. Otherwise ARC will retain these objects, and then when they go out of memory you'll have a pointer to something that has been released.

This is not normally a problem, often you will want to run a block from the current stack. However, sometimes you want to use them with properties and that might mean you will want to use it outside of the current stack. Therefore it is important to take a copy.

@property (nonatomic, copy) dispatch_block_t block;

You might also want to convert a block type to id for use in an array or something similar. You will also need to make a copy, for example:

dispatch_block_t block = ^{
    NSLog(@"Hello World!");
};

NSArray *blocks = [[NSArray alloc] initWithObject:[block copy]];

Retain Cycle

A retain cycle is an issue where you have a retain-able object which indirectly has a strong reference to itself. Usually using another block or object.

For example:

- (void)startOperation {
    NSOperation *operation = [[NSOperation alloc] init];

    [operation setCompletionBlock:^{
        NSLog(@"Completion for %@", operation);
    }];
}

The above example shows a completion block which has a strong reference to the operation. For the lifetime of this block, the operation will stay alive.

You will notice, that the operation strongly holds onto the completion block too. Which means that the completion block will be alive for the lifespan of the operation.

It's clear we have a problem, ARC won't ever be able to release this object.

The solution would be to use a weak reference to the operation:

- (void)startOperation {
    NSOperation *operation = [[NSOperation alloc] init];
    __weak NSOperation *weakOperation = operation;

    [operation setCompletionBlock:^{
        NSLog(@"Completion for %@", weakOperation);
    }];
}

The Deallocation Problem

One of the hardest problems with ARC comes to deallocating your objects safely. It's common to retain objects in the background. When a secondary thread has the last reference to an object. It will be responsible for deallocating the object.

When this object is one of the many UIKit objects, such as a view controller. This can cause a real problem if it's deallocated in the background. It's often very difficult to both debug, and to reproduce this issue since it's a race condition.

To help prevent this problem, you should always use __weak when referencing UIKit objects in the background.

Apple have described this problem on TN2109.

CoreFoundation

CoreFoundation objects are not subject to ARC. You still have to maintain these objects like you have done in the past.

CGRelease(stringRef);

Remember to be careful when using CG objects, especially if they are not owned by you. In the following example, we are retrieving a CGColor reference from UIColor. UIColor owns this reference, and is responsible for memory management.

UIColor *whiteColor = [UIColor whiteColor];
CGColorRef whiteRef = [whiteColor CGColor];

// Crash when using whiteRef

This example will result in ARC releasing UIColor after line 2 because it is no longer used. The whiteRef will now be a pointer to a piece of memory which may have been released at this stage.

Instead you should use the following code, which will retain this reference for ourself.

UIColor *whiteColor = [UIColor whiteColor];
CGColorRef whiteRef = CGRetain([whiteColor CGColor]);

// Use whiteRef

CGRelease(whiteRef);

Exceptions

By default, exceptions are not ARC safe. Conventionally, an exception in Objective-C represents an unrecoverable error. So ARC not being exception safe is perfectly fine and acceptable behaviour. However, there is still a way to enable it using the -fobjc-arc-exceptions compiler flag.

You can enable a compiler option to handle exceptions properly with ARC. But you probably shouldn't do this!

Versioning with Xcode and git

2013-08-18T00:00:00+01:00

Wouldn't it be great if your iOS or OS X projects just take their version and build number automatically from git? Well, it can!

Using a script in your build phase, you can run a shell to determine the version number and inject this into the Info.plist of a build. It will never modify your local project, just the created build.

GIT_RELEASE_VERSION=$(git describe --tags --always --dirty)
COMMITS=$(git rev-list HEAD | wc -l)
COMMITS=$(($COMMITS))
defaults write "${BUILT_PRODUCTS_DIR}/${INFOPLIST_PATH%.*}" "CFBundleShortVersionString" "${GIT_RELEASE_VERSION#*v}"
defaults write "${BUILT_PRODUCTS_DIR}/${INFOPLIST_PATH%.*}" "CFBundleVersion" "${COMMITS}"

Once you have the build phase in place, your version number will be created using the last git tag. If the build was generated right after creating a git tag. Then the version will simply be the tag. If you have made a few commits after tagging, then you will will get a version number suffixed with the amount of commits since the last tag, and the current hash. The hash is important because it allows you to get back to that commit and find the exact code base from a version number.

I always create a new tag before releasing to the app store, so any released applications will have a nice clean version number such as 1.0 or 1.2. Any pre-release builds will often include the previous tag along with how many commits since this tag and the hash. These builds should look something like 1.2-52-g8bdae1d.

Adding the build phase to your project

To add this build phase to your Xcode project, go into your project file and select the target you want to use. Then hit Editor > Add Build Phase > Add Run Script Build Phase. Next, you will need to copy the above shell script into the newly created build phase.

Afterwards, your project should contain a phase looking like this:

There are two components to versioning. Firstly there is the version string which was described above. There is also a version number, this has to be a number which is always incremented on any build going to the app store.

If you have uncommitted files, the version string will be suffixed by -dirty to indicate it's dirty. You can disable this by removing --dirty from the first line in the build phase. However I find it useful to know if the build has uncommitted changes.

To conclude, here are some possible examples:

1.0 from a build directly from a tag.
1.0-dirty from a build directly from a tag, with uncommitted code.
1.0-2-g8bdae1d from a build on commit g8bdae which is 2 commits in front of the 1.0 tag.
g8bdae1d which would indicate that there are no tags.

How does BrowserID work?

2012-05-07T23:01:04+01:00

This article will explain how the cryptography behind BrowserID works, and lightly cover why BrowserID is a better alternative to OpenID.

A website will ask your browser for a BrowserID assertion via JavaScript. This will either use a native BrowserID API in your browser, or it will use the JavaScript implementation of BrowserID. This is known as the user agent.

navigator.id.get(gotAssertion);

For supporting browsers, the user agent will be supplied and the navigator.id.get method will exist. The user agent can be provided by either the browser, an extension to the browser, or via a JavaScript include on the website to use a JavaScript implementation.

<script src="https://browserid.org/include.js" type="text/javascript"></script>

This means that a browser or browser extension can provide their own implementation, or a JavaScript implementation can be used in unsupported browsers.

Out of the process, once the browser has an assertion. It will provide the assertion to the gotAssertion callback. The website can then provide this back to the web server to validate the assertion to confirm the user's identity.

What is an assertion?

An assertion is a string which holds a JSON structure including an identity assertion and an identity certificate. The assertion will be generated by the browser for an identity, the browser will need to get an identity certificate from a provider to ensure they own that identity. This identity can be used again and again until it expires.

Identity certificate

An identity certificate will look like the following:

{
    "iss": "kylefuller.co.uk",
    "exp": "1313971280961",
    "public-key": {
        ...
    },
    "principal": {
        "email": "inbox@kylefuller.co.uk"
    }
}

The "iss" field will include the domain of the issuer. The code checking the assertion should verify that is either the domain used in the email address, or a trusted fallback provider, such as browserid.org. This means that either the domain providing your email address or browserid.org can provide a valid identity certificate for your email.

The fallback provider will allow you to use that provider instead of your email provider in the situation that your email provider does not support BrowserID.

The above identity certificate signed by the issuer, and their certificate should be available over HTTPS at https://iss/.well-known/browserid.

The public key in the identity certificate is the public key of the user. This key can be generated by the browser so only the user will have control over it.

Identity assertion

The identity assertion is the final piece in a BrowserID assertion. It will be signed by the browser's private key, so it will match the public key in the identity certificate which our provider has confirmed we own.

{
    "exp": 1320280579437,
    "aud": "https://demand-browserid.herokuapp.com"
}

The identity assertion provides an expiry and an audience. The identity assertion allows a website to confirm the assertion is meant for them, the audience should be the website that we want to sign-in to.

The relying party which the user is identifying to should check both the identity certificate and the identity assertion to check the certificates match, and that neither has expired. If these are valid assertions for our audience, then we can confirm the user owns the email address and in the identity certificate.

Why use BrowserID, whats wrong with OpenID?

There are many benefits of BrowserID over OpenID.

BrowserID is far simpler to use than OpenID for an average user. It is also quicker, since you do not need to type your OpenID into each site.
When you sign-in to a site using OpenID, your OpenID provider knows you are visiting that site. With BrowserID, your BrowserID provider is not aware of the site you are visiting since your assertion is created in the browser. You have already retrieved your identity certificate from the provider. Your privacy is protected with BrowserID.
BrowserID uses an email address, any existing site will already have your email address. This would allow a site to start using BrowserID without requiring you to provide any additional information.

Organising dotfiles in a git repository

2012-03-28T13:48:07+01:00

Organising dotfiles can be done in numerous ways. Many dotfile repositories often have their own clunky script to copy or symbolically link their dotfiles in place. I feel this is a dirty approach and I prefer my files to be easily manageable via the git command. I don't want to have to copy a file every time I change it.

Another approach I have seen done, is making your whole home directory a git repository. Unfortunately after using this solution you will come across a number of flaws, any repository in your home directory will now follow your ~/.gitignore. I also came into many problems when I was using Xcode which will try to git add projects into your dotfiles repository. Like symbolic linking all my dotfiles into place, this solution also felt clunky.

Git allows you to seperate the work tree and the git dir via environment variables or arguments to the git command. This allows us to store the bare git dir in ~/.files.git while still keeping our entire home directory as the work tree for git.

I settled for using a simple alias in my .zshrc which allows me to easily use git to manage my dotfiles. But, it is imporant to remember that the home directory will not be seen as a git repository unless you use this alias. You won't be able to accidentally use git commands thinking you were in another repo, (or accidentally git add a bunch of things in a mercurial repository).

Here is the alias I use:

$ alias home=git --work-tree=$HOME --git-dir=$HOME/.files.git

You can use this alias just as you would use the normal git command, this allows you to clone and init a repo. To clone a dotfiles repo, you can do:

$ home clone git://github.com/kylef/dotfiles.git

Monitoring InspIRCd with MRTG

2011-08-13T00:00:00+01:00

This guide will show you how to configure MRTG to show statistics from an InspIRCd IRC server, this will include user counts and channel counts. This guide assumes you already have InspIRCd and MRTG setup and working. ~~You can see an example of this working at Sector 5D.~~

InspIRCd config

First, you will need to configure InspIRCd to use the m_http and m_http_stats module. I configure InspIRCd to listen on localhost and port 8081 with SSL, but you could pick any port you want, just remember to change the $address variable inside inspircd-stats.sh later.

Note, the following config is for InspIRCd 2.0, if you use a older version you may need to change the bind line to a http line, please see the InspIRCd wiki for using a older version.

<module name="m_httpd.so">
<module name="m_httpd_stats.so">
<bind address="localhost" port="8081" type="httpd" ssl="gnutls">

Once you have placed this in your InspIRCd config, you can rehash or reload InspIRCd and then you will be able to connect to it over http(s) to retrive stats. Such as at https://localhost:8081/stats

Creating a script to gather the user or channel count on InspIRCd

The following script queries the InspIRCd m_httpd_stats module for the user or channel count. This depends on XMLStarlet (Debian package, Arch AUR Package), so please install this first.

#!/bin/sh

address="https://localhost:8081/stats"
count_type=$1

if [[ "$count_type" != "user"  && "$count_type" != "channel" ]]; then
  echo "Usage: $0 <user|channel>"
  exit 1
elif

count=$(wget -q -Y off -O - --no-check-certificate $address | xml sel -t -v "inspircdstats/general/${count_type}count")

echo $count
echo $count
echo "IRC $count_type"

This script will need to be available from the user which you run MRTG as. I have placed mine in /usr/local/bin/inspircd-stats.sh but you could place it somewhere like $HOME/bin/inspircd-stats.sh.

To download and install this to /usr/local/bin run the following:

sudo mkdir -p /usr/local/bin
sudo wget https://raw.github.com/gist/1042604/b19a4cfd91b6956063d962c977f3d5f8e3318d7d/inspircd-stats.sh -O /usr/local/bin/inspircd-stats.sh
sudo chmod+x /usr/local/bin/inspircd-stats.sh

Now you have this inspircd-stats.sh script, you can use it to get the user and channel count as follows:

/usr/local/bin/inspircd-stats.sh user
/usr/local/bin/inspircd-stats.sh channel

MRTG Config

You will need to add the following to your mrtg config file, this could be located at /etc/mrtg.cfg, but this depends on how you setup mrtg.

# For IRC Users:
Target[irc.users]: `/usr/local/bin/inspircd-stats.sh user`
Title[irc.users]: IRC Users
PageTop[irc.users]: <h1>IRC Users</h1>
MaxBytes[irc.users]: 10000000000
ShortLegend[irc.users]: users
YLegend[irc.users]: Users
LegendI[irc.users]: Users
LegendO[irc.users]:
Legend1[irc.users]: Users
Legend2[irc.users]:
Options[irc.users]: growright,nopercent,gauge

# For IRC Channels:
Target[irc.channels]: `/usr/local/bin/inspircd-stats.sh channel`
Title[irc.channels]: IRC Channels
PageTop[irc.channels]: <h1>IRC Channels</h1>
MaxBytes[irc.channels]: 10000000000
ShortLegend[irc.channels]: channels
YLegend[irc.channels]: Channels
LegendI[irc.channels]: Channels
LegendO[irc.channels]:
Legend1[irc.channels]: Channels
Legend2[irc.channels]:
Options[irc.channels]: growright,nopercent,gauge

Now, you can run your MRTG command for your config or wait for the MRTG cron and it should show up your InspIRCd stats.

Pre-populating data in the admin panel

2009-07-01T00:00:00+01:00

I have always found it awkward working with sites and user's in django admin panel. James Bennet from b-list.org explained his way of doing it on his blog, but I found his way a bit limiting, I still want superusers to be able to change the author of a post.

After looking around in the source code for ModelAdmin I found two method's, one of which was not documented. These were formfield_for_manytomany and formfield_for_foreignkey. These methods allow us to supply our own FormField, which could have initial data. These methods also get passed the HttpRequest, which contains the user. So we can fill in author of a blog post and the current site.

In this post I will quickly show you how to use this method to fill in current data based upon the request inside the admin.

My model

Here is a model from which the rest of the article will work from.

from django.db import models
from django.contrib.sites.models import Site
from django.contrib.auth.models import User

class Post(models.Model):
    title = models.CharField(max_length=255)
    content = models.TextField(blank=True)

    sites = models.ManyToManyField(Site)
    author = models.ForeignKey(User)

As you can see, the author is a ForeignKey field, and sites is a ManyToMany field. The methods we use to set the default reflects this. We use formfield_for_foreignkey to set the default user.

Here is my ModelAdmin class

class PostAdmin(admin.ModelAdmin):
    fieldsets = (
    (None, {
        'fields': ('title', 'content',)
    }),
    ('Advanced options', {
        'classes': ('collapse',),
        'fields': ('author', 'sites',)
    })
)

admin.site.register(Post, PostAdmin)

Selecting the current site

To select the current site, what we will do is create a method called formfield_for_manytomany inside our PostAdmin class. This method will be called each time the admin panel goes to draw a ManyToMany field in a Post. So all we do is set the initial value to the current site. But it is important to remember that the field may be something else, so it is important to check if it is the sites field.

def formfield_for_manytomany(self, db_field, request, **kwargs):
    if db_field.name == 'sites':
        kwargs['initial'] = [Site.objects.get_current()]
        return db_field.formfield(**kwargs)

    return super(PostAdmin, self).formfield_for_manytomany(db_field, request, **kwargs)

Selecting the current user

This is very similar to selecting the current site, instead we create a method called formfield_for_foreignkey for ForeignKey's instead of ManyToMany fields.

def formfield_for_foreignkey(self, db_field, request, **kwargs):
    if db_field.name == 'author':
        kwargs['initial'] = request.user.id
        return db_field.formfield(**kwargs)

    return super(PostAdmin, self).formfield_for_foreignkey(db_field, request, **kwargs)

Now that we have selected the current user, it would be nice to only let superusers use this field, but I couldn't find a way to only show this for certain users. So instead we will just disallow normal user's from saving the post as another user.

I dont think it is possible to optionally hide the author field from a user, so what I have done was to disallow a non superuser from editing the post's author.

Disallowing a user from changing another post

def has_change_permission(self, request, obj=None):
    has_class_permission = super(PostAdmin, self).has_change_permission(request, obj)

    if not has_class_permission:
        return False

    if obj is not None and not request.user.is_superuser and request.user.id != obj.author.id:
        return False

This snippet was not written by myself, but by James Bennet from b-list.org.

Only let the user view their own posts

Another measure to limit the possibilities of the user can be to let the user only view their own posts. To do this we just change the queryset to filter posts where the author is themselves. We still want superusers to see all posts, so only filter it for normal users.

def queryset(self, request):
    if request.user.is_superuser:
        return Post.objects.all()
    return Post.objects.filter(author=request.user)

To see a complete example of this you can view the source code for lithium.

How to install irssi on Dreamhost

2009-02-24T00:00:00+00:00

This was a useful guide I wrote back on my old website. I was trying to install irssi, and I couldn't remember how I installed it last time. Luckily it was available on archive.org's WayBackMachine. I have updated this guide to glib-2.19.8 and irssi-0.8.15.

To install irssi, you can eigher follow the next 7 steps and install from source.

Every command on this page should be entered into a SSH Prompt on DreamHost

SSH into your Dreamhost server (for me, this is titan.dreamhost.com, you can find your server inside panel)

Create the necessary directories:

mkdir -p bin lib tmp
chmod 700 bin lib tmp

Adding lines to your ~/.bash_profile

echo "export PATH=$PATH:$HOME/bin" >> ~/.bash_profile
echo "export PKG_CONFIG_PATH=$HOME/lib/pkgconfig" >> ~/.bash_profile
echo "export LD_LIBRARY_PATH=$HOME/lib:/usr/local/lib:$LD_LIBRARY_PATH" >> ~/.bash_profile

Activate the new changes

source ~/.bash_profile

Download, untar, and install glib

cd ~/tmp
wget ftp://ftp.gtk.org/pub/glib/2.19/glib-2.19.8.tar.gz
tar -xvzf glib-2.19.8.tar.gz
cd glib-2.19.8
./configure --prefix=$HOME
make
make install

Download and install irssi

cd ~/tmp
wget http://irssi.org/files/irssi-0.8.15.tar.gz
tar -xvvzf irssi-0.8.15.tar.gz
cd irssi-0.8.15
./configure --prefix=$HOME
make
make install

Clean up

rm -rf ~/tmp/glib-2.19.8.tar.gz ~/tmp/glib-2.19.8 ~/tmp/irssi-0.8.15.tar.gz ~/tmp/irssi-0.8.15

Once you have installed it, simply type irssi to run it.

I asked Dreamhost if they would allow the use of a terminal application running all the time. Here is their response:

You won’t be in “trouble” for running an irc program (no servers) on our servers. However if the system becomes unstable, it would likely be one of the first processes killed by our admins as our servers are meant for hosting web pages only. In general , we just don’t want users running bots or their own server daemons on our servers.”

Kyle Fuller

Building a Corsi–Rosenthal Box

Using Swift Package Manager with Carthage

Installing your dependencies

Automated CocoaPod releases with CI

CocoaPods trunk Access Token

Circle CI

Travis CI

Running pod trunk push when new releases are tagged

Circle CI

Travis CI

Pushing your Pod

Note on Security

Migrating from OCUnit to XCTest

Kiwi

Memory Management with ARC

Retainable Object Pointers

Ownership Qualification

__unsafe_unretained

__strong

__weak

objc_arc_weak_unavailable

__autoreleasing

Blocks

Retain Cycle

The Deallocation Problem

CoreFoundation

Exceptions

Versioning with Xcode and git

Adding the build phase to your project

How does BrowserID work?

What is an assertion?

Identity certificate

Identity assertion

Why use BrowserID, whats wrong with OpenID?

Organising dotfiles in a git repository

Monitoring InspIRCd with MRTG

InspIRCd config

Creating a script to gather the user or channel count on InspIRCd

MRTG Config

Pre-populating data in the admin panel

My model

Here is my ModelAdmin class

Selecting the current site

Selecting the current user

Disallowing a user from changing another post

Only let the user view their own posts

How to install irssi on Dreamhost

SSH into your Dreamhost server (for me, this is titan.dreamhost.com, you can find your server inside panel)

Create the necessary directories:

Adding lines to your ~/.bash_profile

Activate the new changes

Download, untar, and install glib

Download and install irssi

Clean up

Running `pod trunk push` when new releases are tagged