My Swift equivalent of C macro DLog() with __PRETTY_FUNCTION__.

I did not see this exact thing out in the wild yet. It is cobbled together from unpopular Stack Overflow answers and highly informative blog posts.

func dLog(message: String, fullPath: String = __FILE__, line: Int = __LINE__, functionName: String = __FUNCTION__) {
    let filename = fullPath.lastPathComponent
    // Remove ".swift" from file name.
    let splitFilename = split(filename, {(c:Character)->Bool in return c=="."}, allowEmptySlices: false)
    let classGuess = splitFilename[0]
    // Remove "()" from function name.
    let splitFuncName = split(functionName, {(c:Character)->Bool in return c=="("}, allowEmptySlices: false)
    let funcName = splitFuncName[0]
    NSLog("%@", "[\(classGuess) \(funcName)] [Line \(line)] \(message)")

The output looks like this.

2014-11-19 18:55:05.887 SandboxApp[12433:287724] [SomeViewController viewDidLoad] [Line 27] dLog message test.

Note that the biggest flaw is the use of the file name instead of the class name. According to Swift docs there is no __CLASS__ special literal expression.

To make this global, I dropped it in the AppDelegate file outside of the AppDelegate class. There has got to be a better convention for global functions, but I am only burning one bridge at a time.

For bonus points, the Xcode autocomplete on the split() function crashed SourceKitService. I guess this means I'm cutting edge now.


GIMP script (Scheme) to scale multiple files at once (batch).

I made this back in January of this year, but I forgot to post it. I searched around briefly, but at the time, I found nothing that I could just drop in and use. So I had to write this.

It is written in Scheme. On my MacBook, I drop this script in ~/Library/Application Support/GIMP/2.8/scripts. Then from the GIMP menu bar select Filters | Script-Fu | Refresh Scripts. This script should then show up under the GIMP menu bar selection Image | Transform | Batch Scale By Factor.

There are a lot of reasons we would need to perform this a batch scale of images files, but mine was related to iOS development. Retina images must be twice the resolution of non-Retina images in order to look good. So I used Retina images as originals and then I had to scale everything to half that size for non-Retina.

The script does not overwrite the original files. It makes new files with "_.jpg" appended to the file name, even if the file name already ends in ".jpg". Which reminds me, this script saves all files as JPEGs, even if the originals are not. If you want different output, I'm sure you can figure out how to change it.

Hey, even though I wrote this to not overwrite the originals, I highly recommend that you never operate on originals. Make a copy of your originals in a temp directory and run the batch process on the copies.

(define (script-fu-scale-by-factor fileglob factor)
      (files (cadr (file-glob fileglob 0)))
    (do-scale-to files factor)

(define (do-scale-to files factor)
  (while (not (null? files))
        (file (car files))
        (image (car (gimp-file-load 1 file file)))
        (width (car(gimp-image-width image)))
        (height (car(gimp-image-height image)))
        (newfile (string-append file "_.jpg"))
        (drawable (car (gimp-image-get-active-layer image)))
      (gimp-image-scale image (* width factor) (* height factor))
      (gimp-file-save 1 image drawable newfile newfile)
    (set! files (cdr files))

  "script-fu-scale-by-factor"               ;func name
  "Batch Scale By Factor"                   ;menu label
  "Scale multiple images by given factor."  ;description
  "Jeffery Martin"                          ;author
  "Copyright 2014\
   Fluffy White Puppy Software"             ;copyright notice
  "2014-01-06"                              ;date created
  ""                                        ;image type that the script works on
  SF-STRING "fileglob" "/tmp/photos/image-*.jpg"
  SF-VALUE "factor" "0.5"

(script-fu-menu-register "script-fu-scale-by-factor" "<Image>/Image/Transform")

Here is what it looks like in operation. Original images files:

Here is the dialog when you run the script.

And the directory after the script run.

And notice that the image files are half the size because I input a scaling factor of 0.5 in the script dialog.


SOILD: new object oriented design principles.

Is your object oriented design soiled?


S = Slippery. The class should be so abstract that’s its responsibility – or even better responsibilities (plural) – should be hard to pin down.
O = Open. The class should be open…to everything! Public. Free as in beer. You get the idea.
I = Interface. Integrate your interface. Turn those fa├žades upside-down.
L = LISP. All braces in your code should be replaceable by parenthesis.
D = Dependency. See poem below.

No class is an Island, entire of itself; every class is a piece of the Code, a part of the main(); if a clod be washed away by the sea, The Bay Area is the less, as well as if Oakland were, as well as if an old warehouse of thy startup or the Apple Spaceship Campus were; any freed object diminishes the app, because the app is involved in the Framework; And therefore never send to know for whom the compiler warns; It warns for thee.

Hopefully, what I am about to write is obvious, but if not, please realize that this post is humor. I was making a joke about the SOLID OO programming design principles.


OS X display preferences and melatonin suppression from cool/blue/white light.

If you search around you will find enough scientific articles explaining how light with cool color temperatures (lots of blue wavelength) suppresses the human brain's production of melatonin. Melatonin, of course, is a hormone needed for a good night of sleep. This fact impacts those of us who may be in front of LCD screens just before or well after midnight.

One way to help with this is to switch your monitor's settings to a warm color temperature. I noticed that some folks are selling apps for OS X so that you can make this adjustment. Well, there is no reason to download or buy an app.

Go to System Preferences : Displays and select the Color tab. Then tap the Calibrate button to create a new profile. When it comes time to "Select a target white point" choose D50 Warm yellowish white. Save the profile with a memorable name, and then when you are coding after sunset, switch to the warm color temperature profile.


Cocoa documentation has an image that tickles me.

It is from the Cocoa Core Competencies document, in the section "Object Creation". I like explaining things by analogy, perhaps too much because my analogies do not always work. I think this one gets the point across. It is understandable across all modern computer-using Earth cultures. I like it. It is effective and well done.

However, I would display the resource picture as bills of currency and the allocation as the individual ingredients, and I would remove the dough mixer. The resource is the computer's memory, not your code pieces and data parts (ingredients). Allocation is when you claim some memory and fill it with your code and data (convert your currency into flour, salt, yeast, and water). The way the analogy is now, it doesn't emphasize enough the conversion of a homogenous limited resource (memory/money) into a useful item. In fact, it shows that your methods and instance variables (flour and yeast) are the resource, and they aren't.

I don't think my imagined changes would help a beginner understand OOD/OOP better. I just think it would make the analogy more accurate. Are computer engineering basics taught to computer programmers these days? If yes then perhaps a more accurate analogy would help after all.

Has anyone written a class that has an initWithTemperature: method?


Stop using icons.

I am writing this in the month of July in the year two thousand fourteen of Anno Domini / Common Era.

I was using Google Chrome 35.0.1916.153 and Mac OS X 10.9.4.

I clicked a link in Chrome pointing to a PDF file. The file displayed in a Chrome tab. I just wanted to save it locally. This floating toolbar was in the bottom right corner of the screen.

I recall the era of the 3½ inch floppy disk. As a teenager, I used 5¼ inch floppy disks to load programs into my Atari 800. In the 90s, we used Zip drives and later Jazz drives.

But come on! I had to hesitate far too long hovering over that button (with no tooltip) wondering if it meant what I hoped it meant. I was also anxious it would do something destructive and annoying to reverse.

I think my pause was due to two factors: I had not seen a floppy disk in so long that I was not sure if the silhouette matched one, and I was in disbelief that a modern UI designer would use this image to represent "save".

The only icons I recognize on that toolbar are zoom out and zoom in. I've got a crazy solution. Look at my Gmail message-level toolbar.


My image editor for Mac OS X is now Acorn.

I moved from Linux to OS X years ago, but I still kept going to GIMP for image editing. Keep in mind that only in the last year or so has GIMP become Cocoa-native. Prior to that it required an X11 runtime that was available as an installable extra from Apple.

Running GIMP inside X11 on OS X looked poor with the antiquated GTK+ widget set. The runtime situation made it impossible to directly Alt+Tab to GIMP; the X11 process would gain focus instead. The GIMP shortcut keys used Control instead of Command. There we other quirks I cannot remember now.

When GIMP become Cocoa-native, I was relieved. But a keyboard focus bug caused text entered into text fields to be interpreted as Alt+Key strokes, which are shortcut keys for menu items. Fine, so I disabled all shortcut keys in the app and did everything solely from touchpad clicks. In the next version, that bug got fixed but not the bug that fails to order files by name properly.

Yesterday, in GIMP, I was trying to figure out why I could not select a layer in the Layer dialog. I had already converted my floating selection to a new layer, so what could be the problem? GIMP hung as I poked around, and I had to force quit it. At that point, I decided to buy an image editor.

I had previously researched other image editors for Mac OS X, but the different choices were daunting. The review articles I had found were either outdated or incomplete (missing a prominent application). Finally, in a bogus article which I will not link to, several comments to that article recommended Acorn. I took a look at the feature list of Acorn, and I was impressed. It only cost $30, and I trust the crowd more than a self-appointed authority on those user-generated content repositories, so I bought it.

What a huge difference! I am still in the process of kicking myself for being so foolish as to not leave GIMP earlier. I rate GIMP's ease-of-use at 3 (out of 10). I rate Acorn's at 9 (because nothing is perfect). Exploring Acorn to figure out how to do something is fast, simple, and straightforward. I had to look up how to add to a selection, and the Acorn documentation is up-to-date and complete with good search results.

And that brings me to what really struck me about the difference. In GIMP I had seen the different selection method (add, subtract, union) mini-buttons before, but until Acorn it was all just so much clutter in my face that I never thought about what to do with those buttons. So suddenly, because of Acorn's superior UI design and full documentation, my skills as an editor of images have increased.

For those of you thinking I should use Photoshop, Photoshop Lightroom, or Photoshop Elements: just no, guys. I think I tried out Lightroom, and what a convoluted mess. The install was odd somehow. The look and feel was that wannabe nouveau Adobe Flex. It tried to take over my Mac by asking me about all my images and whatnot. And the UI was like advanced GIMP. I went running back to GIMP very quickly. The next time I tried to give Lightroom another chance my trail period had expired, and I decided it was not worth it to pursue again.

To those who might think this product review was unfair: I did not set out to write a product review when I started using PS Lightroom, Acorn, or GIMP. I'm just a guy who used GIMP on OS X for far too long, and I used the immense power of an inference engine that I keep stored in my skull, and the output I got from the input provided lead me to spend $30 on Acorn, and I'm very happy with that decision. In fact, I'm so pleased that I wrote this blog entry about it.