Git again

git-logo

I’ve finally gotten around to using Git instead of Mercurial on a project. So far it has been uneventful. I still prefer Mercurial because it treats all OSes as first class citizens and because I think the CLI is cleaner. My workflow doesn’t require a lot of branching, but Git fans seem to think it really shines there. My main motivation for going Git on this project is to get some experience with what will likely become the defacto standard DVCS.

I am mostly using git-cola git gui as a GUI frontend. Ironically, git-cola—like Mercurial but unlike Git itself—is Python powered.

The best resource I’ve found so far for working with Git if you already know DVCS fundamentals is Spherical’s “Git for the lazy.” Entp’s “Version Control for Designers” is pretty good too.

Google Talk alternatives

google-talk-developers

Google Talk has been my preferred instant messaging service for years because it federates with other XMPP services. In other words, if someone wants to IM with you, she doesn’t need to sign up with Google; she can sign up with anyone who offers XMPP services or she can install an (open source) XMPP server on her own machine and connect with you with that.

All that is changing. A while back, Google limited XMPP federation, then reinstated it claiming it was done as an anti-spam measure. More recently, the huge Google Hangouts rollout finds XMPP federation at best being shoved to a back seat and at worst being entirely deprecated. Given that http://talk.google.com now redirects to http://www.google.com/hangouts/ it’s pretty clear that Google Talk is a deprecated service–so it’s hopeless to hang onto whatever federation Google Talk itself might provide. Federation lost.

Therefore, I will probably be shifting my default online presence from Google Talk to an account provided by someone offering unfettered XMPP service. Candidates include jabber.org (who I hope have solved their DDoS problems) and DuckDuckGo.

Getting good PDF output from KiCad in Linux

kicad-appicon-128
Update: Turns out SVG might be a better base than PostScript for this. See PDF output from KiCad in Linux from SVG.

I’ve tried to get decent PDF output from KiCad‘s Eeschema a few different ways, but what I’ve found to work most reliably is to first export to PostScript (File > Plot > Plot PostScript) and then use the ps2pdf command from ghostscript to convert to PDF. (The Arch wiki has a good writeup on ps2pdf.)

The biggest problems with this are:

  1. It’s a lot of typing to get the conversion to happen (the minutia of which you won’t have memorized).
  2. It leaves you with both a PostScript and a PDF of the document(s), one of which is likely to get out of sync with the other, which may or may not be in sync with the actual schematic, etc.

To help with this, I use the script below. I drop a copy of it into the root of my KiCad projects and edit the OPTIONS as needed for the project. Then whenever I want PDFs of my schematics, I export PostScript from Eeschema and then click on this script in my file manager. Note that running this script will destroy any *.ps files in the directory—that’s by design.

#!/bin/bash

# DESTRUCTIVELY convert all postscript files
# in working directory to PDF.
# Requires ghostscript.

# Mithat Konar 2013 [http://mithatkonar.com]

OPTIONS="-dOptimize=true -sPAPERSIZE=11x17"

FILES=$(ls -1 *.ps)

for file in $FILES
do
  ps2pdf $OPTIONS $file && rm $file
done

I’ve not tried the script on any PostScript files other than those produced by Eeschema, but I’ve got no reason to think it won’t work on other PS files as well.

Processing: Capture is a PImage

Ds8_roll

Something the documentation on Processing’s Capture class doesn’t mention is that Capture is derived from PImage. I went digging into the Capture source code to figure that out:

public class Capture extends PImage implements PConstants { ...

This means all the methods and fields available to PImage objects should also be available to Capture objects. This makes video processing a lot easier!