Posts in the Mac Category

Scripted Server Startup for MDN and WPT

Published 1 year, 11 months past

A sizeable chunk of my work at Igalia so far involves editing and updating the Mozilla Developer Network (MDN), and a smaller chunk has me working on the Web Platform Tests (WPT).  In both cases, the content is stored in large public repositories (MDN, WPT) and contributors are encouraged to fork the repositories, clone them locally, and push updates via the fork as PRs (Pull Requests).  And while both repositories roll in localhost web server setups so you can preview your edits locally, each has its own.

As useful as these are, if you ignore the whole “auto-force a browser page reload every time the file is modified in any way whatsoever” thing that I’ve been trying very hard to keep from discouraging me from saving often, each has to be started in its own way, from within their respective repository directories, and it’s generally a lot more convenient to do so in a separate Terminal window.

I was getting tired of constantly opening a new Terminal window, cding into the correct place, remembering the exact invocation needed to launch the local server, and on and on, so I decided to make my life slightly easier with a few short scripts and aliases.  Maybe this will be useful to you as well.

First, I decided to keep things relatively simple.  Instead of writing a small program that would handle all server startups by parsing shell arguments and what have you, I wrote a couple of very similar shell scripts.  Here’s the script for launching MDN’s localhost:

#!/bin/bash
cd ~/repos/mdn/content/
yarn start

Then I added an alias to ~/.bashrc which employs a technique I swiped from this Stack Overflow answer.

alias mdn-server="open -a Terminal.app ~/bin/mdn-start.bsh"

Translated into English, that means “open the file ~/bin/mdn-start.bsh using the -application Terminal.app”.

Thus, when I type mdn-server in any command prompt, a new Terminal window will open and the shell script mdn-start.bsh will be run; the script switches into the needed directory and launches the localhost server using yarn, as per the MDN instructions.  What’s more, when I’m done working on MDN, I can switch to the window running the server, stop the server with ⌃C (control-C), and the Terminal window closes automatically.

I did something very similar for WPT, except in this case the alias reads:

alias wpt-server="open -a Terminal.app ~/bin/wpt-serve.bsh"

And the script to which it points reads:

#!/bin/bash
cd ~/repos/wpt/
./wpt serve

As I mentioned before, I chose to do it this way rather than writing a single alias (say, local-server) that would accept arguments (mdn, wpt, etc.) and fire off scripts accordingly, but that’s also an option and a viable one at that.

So that’s my little QoL (Quality of Life) upgrade to make working on MDN and WPT a little easier.  I hope it helps you in some way!

Preventing Commits to the master Branch in OS X Mojave

Published 3 years, 1 month past

What happened was, I was preparing to roll out new designs for the News section and event pages of An Event Apart, and I had each rollout in its own branch.  Somewhere in the process of bringing both into the master branch, I managed to create a merge conflict that rapidly led to more and more conflicts.  I very nearly had to take off and nuke the entire site from orbit, just to start over.  (A couple of branches, including dev, did have to get erased and re-pulled.)

Part of what made it worse was that at one point, I accidentally committed a quick edit to master, because I’d forgotten to check out the branch I was trying to edit, and my attempts to undo that mistake just compounded whatever other mistakes already existed.  Once all the dust settled and things were back into good shape, I said to myself, “Self, I bet there’s a way to prevent commits to the master branch, because git is second only to emacs in the number of things you can do to/with it.”  So I went looking, and yes, there is a way: add the following to your .git/hooks/pre-commit file.

#!/bin/sh

branch="$(git rev-parse --abbrev-ref HEAD)"

if [ "$branch" = "master" ]; then
  echo "You can't commit directly to master branch"
  exit 1
fi

I got that from this StackOverflow answer, and it was perfect for me, since I use the bash shell.  So I created the pre-commit file, made a trivial README.md edit, and tried to commit to master.  That’s when OS X Mojave’s Terminal spit back:

fatal: cannot exec '.git/hooks/pre-commit': Operation not permitted

Huh.  I mean, it prevented me from committing to master, but not in a useful way.  Once I verified that it happened in all branches, not just master, I knew there was trouble.

I checked permissions and all the rest, but I was still getting the error.  If I went into .git/hooks and ran the script from the command line by ./pre-commit, I got a slightly different error:

-bash: ./pre-commit: /bin/bash: bad interpreter: Operation not permitted

So I submitted my own StackOverflow question, detailing what I’d done and the file and directory permissions and all the rest.  I was stunned to find out the answer was that Mojave itself was blocking things, through its System Integrity Protection feature.  Why did this simple file trigger SIP?  I don’t know.

The fix, shared by both Jeff and Rich, was to go into .git/hooks and then type the following to check for SIP status:

xattr -l pre-commit

It showed a com.apple.quarantine value, so I then typed:

xattr -d com.apple.quarantine pre-commit

And that was it!  Now if I try to commit a change to the master branch, the commit is rejected and I get a warning message.  At that point, I can git stash the changes, check out the proper branch (or a new one), and then git stash pop to bring the changes into that branch, where I can commit them and then merge the changes in properly.

I may modify the script to reject commits to the dev branch as well, but I’m holding off on that for now, since the dev branch is often where merge conflicts are worked out before going to master.  Either way, at least I’ll be less likely to accidentally foul up master when I’m hip-deep in other problems.

Better PDF File Size Reduction in OS X

Published 13 years, 1 month past

One of the things you discover as a speaker and, especially, a conference organizer is this:  Keynote generates really frickin’ enormous PDFs.  Seriously.  Much like Miles O’Keefe, they’re huge.  We had one speaker last year whose lovingly crafted and beautifully designed 151-slide deck resulted in a 175MB PDF.

Now, hard drives and bandwidth may be cheap, but when you have four hundred plus attendees all trying to download the same 175MB PDF at the same time, the venue’s conference manager will drop by to find out what the bleeding eyestalks your attendees are doing and why it’s taking down the entire outbound pipe.  Not to mention the network will grind to a nearly complete halt.  Whatever you personally may think of net access at conferences, at this point, not providing net access is roughly akin to not providing functioning bathrooms.

So what’s the answer?  ShrinkIt is fine if the slides use lots of vectors and you’re running Snow Leopard.  If the slides use lots of bitmapped images, or you’re not on Snow Leopard, ShrinkIt can’t help you.

If the slides are image-heavy, then you can always load the PDF into Preview and then do a “Save As…” where you select the “Reduce File Size” Quartz filter.  That will indeed drastically shrink the file size — that 175MB PDF goes down to 13MB — but it can also make the slides look thoroughly awful.  That’s because the filter achieves its file size reduction by scaling all the images down by at least 50% and to no more than 512 pixels on a side, plus it uses aggressive JPEG compression.  So not only are the images infested with compression artifacts, they also tend to get that lovely up-scaling blur.  Bleah.

I Googled around a bit and found “Quality reduced file size in Mac OS X Preview” from early 2006.  There I discovered that anyone can create their own Quartz filters, which was the key I needed.  Thus armed with knowledge, I set about creating a filter that struck, in my estimation, a reasonable balance between image quality and file size reduction.  And I think I’ve found it.  That 175MB PDF gets taken down to 34MB with what I created.

If you’d like to experience this size reduction for yourself (and how’s that for an inversion of common spam tropes?) it’s pretty simple:

  1. Download and unzip Reduce File Size (75%).  Note that the “75%” relates to settings in the filter, not the amount of reduction you’ll get by using it.
  2. Drop the unzipped .qfilter file into ~/Library/Filters in Leopard/Snow Leopard or /Library/PDF Services in Lion.  (Apparently no ~ in Lion.)

Done.  The next time you need to reduce the size of a PDF, load it up in Preview, choose “Save As…”, and save it using the Quartz filter you just installed.

If you’re the hands-on type who’d rather set things up yourself, or you’re a paranoid type who doesn’t trust downloading zipped files from sites you don’t control (and I actually don’t blame you if you are), then you can manually create your own filter like so:

  1. Go to /Applications/Utilities and launch ColorSync Utility.
  2. Select the “Filters” icon in the application’s toolbar.
  3. Find the “Reduce File Size” filter and click on the little downward-arrow-in-gray-circle icon to the right.
  4. Choose “Duplicate Filter” in the menu.
  5. Use the twisty arrow to open the duplicated filter, then open each of “Image Sampling” and “Image Compression”.
  6. Under “Image Sampling”, set “Scale” to 75% and “Max” to 1280.
  7. Under “Image Compression”, move the arrow so it’s halfway between the rightmost marks.  You’ll have to eyeball it (unless you bust out xScope or a similar tool) but you should be able to get it fairly close to the halfway point.
  8. Rename the filter to whatever will help you remember its purpose.

As you can see from the values, the “75%” part of the filter’s name comes from the fact that two of the filter’s values are 75%.  In the original Reduce File Size filter, both are at 50%.  The maximum size of images in my version is also quite a bit bigger than the original’s — 1280 versus 512 — which means that the file size reductions won’t be the same as the original.

Of course, you now have the knowledge needed to fiddle with the filter to create your own optimal balance of quality and compression, whether you downloaded and installed the zip or set it up manually — either way, ColorSync Utility has what you need.  If anyone comes up with an even better combination of values, I’d love to hear about it in the comments.  In the meantime, share and enjoy!

Translations

Update 2 Aug 11: apparently there have been changes in Lion — here’s an Apple forum discussion of the problem.  There are two workarounds described in the thread: either to open and save files with ColorSync Utility itself, or to copy the filter to another folder in your Library (or install it there in the first place, above).

Update 27 Mar 12: edited the Lion install directory to remove an errant ~ .  Thanks to Brian Christiansen for catching the error!

Selectively Disabling Downloaded-File Warnings in Leopard

Published 14 years, 2 weeks past

One of the things that I’ve found mind-bendingly annoying about Leopard (besides its complete refusal to allow classic window management) is the “this file was downloaded from the internet, are you sure you want to open it?” dialog box.  Yes, damn it: I just downloaded the file with the express intent of opening it.  Stop bothering me.  Keep it up and I might mistake you for PC.

What’s even worse is that the dialog requires mouse input to get past.  It would be just within the limits of acceptability if the dialog buttons responded to keyboard input; if I could hit command-O or something to invoke “Open”, then I’d probably keep the safeguard in place, because I could just charge past it with a quick twitch of the fingers.  Since I can’t, I want it gone.  And of course there’s no “don’t ask me again” checkbox to tick.

After a plea on Twitter, I got pointers to a couple of ways to disable this annoyance (as well as a ton of “oh God, I hate that too; let me know if you find an answer!” replies).  The first way is done as a Folder Action.  For a variety of reasons, I’m not that thrilled by folder actions, so I gave it a pass.  The other approach is to write your own preference file.  Ah, much better!  (Why is this better?  I don’t know.  It just intuitively feel like the better approach to me.)

Now, one way is to just disable the warning for all public.item files—which is to say, every type of file.  I was tempted, but it turns out there’s a finer grain that can be applied:  listing specific file types to be ignored.  Better still!  That way I can switch this off for the file types that I download all the time, like HTML files, and keep the safeguard in place for file types I almost never download, like executable scripts.

Doing this means you need a list of OS X’s Uniform Type Identifiers, so I dug around to find that listing, which appears to have moved in the not-too-distant past.  Here’s the preference file I’ve put together with that listing as a guide.  This file lists all of the file types I don’t want to be nagged about. 


<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
   "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>LSRiskCategoryNeutral</key>
    <dict>
      <key>LSRiskCategoryContentTypes</key>
      <array>
        <string>public.text</string>
        <string>public.plain-text</string>
        <string>public.xml</string>
        <string>public.archive</string>
        <string>public.image</string>
        <string>public.audiovisual-content</string>
        <string>public.font</string>
      </array>
    </dict>
  </dict>
</plist>

I led with public.text because it encompasses not just regular text files, but HTML files as well; public.xml appears to cover XHTML, though I’m not 100% sure where those files fall.  public.audiovisual-content covers all audio and video files, as you might guess.  There are probably a few other types I’ll add over time, as I encounter enough resistance on certain types of files that I don’t need to be safeguarded.  I’ll probably never add public.script or public.executable to the list; personally, I prefer to be warned about that sort of stuff.

To make the magic happen, save the above file (or your own variation) as ~/Library/Preferences/com.apple.DownloadAssessment.plist.  Then log out of and back into your account.  Finito.

So if you’d like to get your Mac to be less of a nag about opening downloaded files, there’s how.  As the links above show, I’m standing on the shoulders of giants here, so my thanks to those who paved the way.  I hope that you will be able to benefit from both their work and my small additions thereto.

Update [13 Mar 09]: Potentially very bad news, folks.  I just tried this on my 10.5.6 machine and it failed utterly.  As did the Folder Action approach.  Older versions of Leopard apparently didn’t have this problem.  Anyone else seeing the same kind of thing on their machines?  If either way is still working for you under 10.5.6, can you tell us which one it is in the comments?  Thanks.

Update [18 Mar 09]: Great news, folks.  Ben Millett kindly sent me a copy of his working-under-10.5.6 file and I tried it out, and it worked!  The difference seems to be that the version I was using was encoded as “Unicode™ (UTF-8, no BOM)” whereas the encoding of the file Ben sent me is “Western (Mac OS Roman)” (both according to BBEdit).  So if your copy doesn’t work, check the file encoding.  Next I’m going to experiment with adding file extensions, and will report back if I meet with success.

The Lazy or the Tiger?

Published 17 years, 2 months past

So I’ve been putting off upgrading from Panther to Tiger for quite some time now.  My base reason is that I’ve been really, really busy, but the other reason is that I kept hearing that it wasn’t worth it.  Now, I’m used to the 10.x.0 version of any major OS X release being unstable and the source of many complaints, but it’s up to 10.4.4 now.  That seems like enough time to work out the kinks.

Plus, I have to use Tiger if I want to play with the Mac version of Google Earth.  So there’s that.

Admittedly, I do have Tiger installed on a partition of an external drive, and I’ve played around with it a little bit.  Still, that’s a very far cry from upgrading my laptop’s hard drive from Panther to Tiger.  I know that any major OS upgrade will mean time and energy spent on managing the transition, including re-installing or upgrading some third-party software.  That’s where the “I’ve been busy” thing comes back into play.  It’s a lot easier to take the lazy route: the system I have now works, so why mess with it?  Then again, that same attitude would have kept me in the Classic OS if I’d let it.  At some point, you have to upgrade.

So I put it to the crowd: is Tiger (now) worth taking the plunge?

Full Freight

Published 17 years, 3 months past

I recently wrote that the font Freight Micro had broken Unicode references.  It turns out that I was basing my comments on a beta version of the font without realizing it.  The designer of the Freight family was good enough to provide me with a copy of the final version of the font, which I tested, and I’m delighted to report that it does not suffer from the same problem.

So my deepest apologies for any misinformation I may have spread. If you see anyone referencing my previous post on this topic, please point them to this one.  Thank you.

  • Full Freight was published on .
  • It was assigned to the Mac category.
  • There have been no replies.

Pencilled In

Published 17 years, 3 months past

A followup to my previous post: thanks to the nearly impossible to find Character Palette (and thanks to Todd Dominey for instructions on how to enable and use it), I was able to determine the problem and restore my editing pencils.  It turns out that a beta copy of the font “Freight” was what caused the problem.  This beta copy of Freight was for some reason convinced that Unicode 9999 is the reference to a Z-caron instead of a pencil symbol.  It didn’t do this for 9998 or 10000.  Just 9999.

So I removed “beta Freight”, and the pencils returned.  Thanks to everyone who helped me out!

Update: there’s more to the story, namely that the copy of Freight in question was a beta, and not the final release, and the final release doesn’t have the problem that bit me.  I’ve edited this post to reflect that fact.

Pencilled Out

Published 17 years, 3 months past

Pretty much nobody but me ever sees this, but when I’m logged into meyerweb’s copy of WordPress (basically, all the time) I see a little pencil icon next to entries and comments.  It’s the “click here to edit this” link, and I generate it using the following markup: 

<a href="[...]">&#9999;</a>

Ah, Unicode.

The problem is that at some point in the recent past, my OS X 10.3.9 laptop started rendering that character as a Z with a set of rabbit ears on top, whereas my OS X 10.3.9 desktop machine still shows the pencil.  I can only assume this is due to a recent software installation on the laptop, possibly one that stuck in a badly structured font or something.  Or else an update messed up the Unicode pointers.

Whatever the cause might be, does anyone out there know if there’s a way for me to figure out what font is being used to generate the funky Z, or how I might otherwise be able to track down and destroy it and get the pencils back?  Because it’s driving me frickin’ crazy.

Update: the problem is now fixed, as described in the followup entry.

Browse the Archive

Earlier Entries