Panic Blog

I have a 1-year-old daughter named Violet.

For whatever reason, we began calling her Beep. Sometimes Beepy. Usually Beep. Rarely Violet. These things happen.

Yesterday, Ashur and Heather revealed to me a tiny little easter egg they snuck into our SSH app, Prompt 2.1…

With the right set of steps, you can switch the normally-white visual beep to be… violet.

Heather coded it up and Ashur made this graphic to reveal the secret:

Basically, I will know you are the deepest of Panic fan if you are rocking the purple flash. (Someday I’ll explain this to Violet. Probably her first question will be, “Wait, you called me what?”.)

There aren’t a lot of secrets in Panic apps, but I’ll never forget this one.

EditorConfig is a clever idea: a simple text file you can put anywhere in your code source that automatically changes settings in your favorite text editor.

For example, let’s say someone decided one project had to use space indentation (for Python?) even though everybody usually uses tabs. With EditorConfig, you can easily declare this setting in an .editorconfig file in the root of the project…

# top-most EditorConfig file
root = true
 
# 4 space indentation
[*]
indent_style = space
indent_size = 4

…or you could put this file in any folder in your project, and the editor will automatically pick it up. Then, you can easily check this file in to your source control system. Anyone who checks out your project — and uses a EditorConfig-capable editor — will automatically inherit the recommended editor settings.

We thought this was pretty cool, and so did our users, so we went ahead and built an EditorConfig plug-in for Coda 2.5. It currently supports everything except for the text encoding setting.

If that install link didn’t work, or you don’t want to install it right now, you can browse our plug-ins here.

When you’re ready, read up on the file format here. We hope you enjoy it!

Quite some time ago, we made a quick, free, handy tool called ShrinkIt®.

(Yes, we actually have a registered trademark on ShrinkIt®. Why not!)

ShrinkIt takes bloated Adobe-saved graphic PDFs, runs them through Apple’s PDF renderer, and saves them back out, making many of them smaller without any quality loss.

Note, though: it’s not really for long complex PDF documents or bitmap images. It’s generally for simple PDF symbols and glyphs you might use in your apps, where saving space is critical.

We’ve just updated ShrinkIt to version 1.3, and wanted to let you know!

ShrinkIt Release Notes:

• Processing is now threaded and significantly faster.
• It’s now properly signed with our Developer ID
• There’s a new icon
• And it’s now Retina-ready
• 1.3 — Fixed exception when dealing with Unicode file paths
• 1.3 — Added cool progress bar and gratuitous animation

Two important ShrinkIt instructions:

1. If a finished file is not smaller after being processed, it will not be saved.
2. Your original files are renamed with the prefix “_org_” just in case.

We hope it serves you well.

UPDATE 2/11: We bumped it to 1.3.
UPDATE 2/13: Aaaaaand 1.3.2 fixes some problems with 10.7 and 10.8.

Sometimes at Panic we build internal stuff that never sees the light of the outside world. This is one of those projects: an automatic in/out tracker for the Panic Team.

OK, sure, there’s not that many people that work here so it’s not a huge issue for our team, but it still seemed like something interesting to try. I originally hacked together an in/out tracker that used a combination of SNMP, ARP table lookups, and plain old port scanning to figure out who was theoretically “in”. It wasn’t so reliable and was eventually removed from our Status Board. What I didn’t know was that Apple would soon deliver a solution to our (not-so) mission-critical problem.

With the arrival of iBeacons in iOS 7, Apple was clearly moving into retail and public spaces in a whole new way. It was no longer enough to have an app for the store you are shopping in — the app could now react to your location within the store. iBeacons themselves typically do little more than broadcast an ID to notify your device that you’re near them. The idea is to spread these relatively cheap, dumb beacons around a space and then let iOS and a cloud service figure out what content the visitor should see.

Going further, iOS 8 adds a button to the lock screen when you’re in an area registered with Apple to provide indoor location tracking. That button launches the relevant app if you have it installed or takes you to the App Store if you don’t. Cool stuff.

With this new technology in-hand, it wasn’t too long before I put together a brand new office In/Out tracker called PunchClock. It uses a combination of a geo-fence and iBeacon tracking, plus a simple Sinatra backend hosted at Heroku. The part that took the longest to fine-tune was figuring out the right combination of polling to provide good location information without draining the battery.

Once we had reliable In/Out data, I thought it would be interesting to allow you to be notified (in a hopefully non-creepy way) the moment someone entered or left the office. The final notable feature of PunchClock is the ability to send push messages to everyone marked as “In” — mainly in case you get locked out of the office, or locked in the bathroom. Neven did some nice UI, Cabel made a couple of tiny notification sounds, and the app was complete.

While Apple’s iBeacon technology continues to be rolled out in big box stores and sports stadiums, there’s no reason you can’t put it to use in your own home or office now.

We’re making PunchClock available on Github so you can create your own In/Out tracker. The backend provides JSON data to the app as well as a DIY panel for Status Board.

To be honest, you’re going to have to be pretty technically-capable to set up your own instance of PunchClock. This isn’t a shipping retail product, and it’s not for the faint of heart. But if you’re a coder and you’re ready for a fun night of hacking, we’d love to see what you do with it. We’ll try to do our best to explain the process in the README for the app and backend.

PunchClock was fun for us, and we hope it’s fun for you.

We’ve been doing significant testing lately with video out using various iOS devices for an upcoming project. In doing so, we waded right in the middle of a strange video out mystery. It’s time to unravel that mystery. (Chung-chung!)

Mystery #1: 1600 × 900 Resolution, Tops

When we turn on “Video Mirroring” to send out an image through the Lightning AV Adapter, the system tells us that the maximum and optimum resolution we can do is 1600 × 900:

“Hang on, that’s not 1080p!”, you’re saying to yourself. That’s exactly what we said!

When we plug in the old Dock Connector AV Adapter, the system gives us the 1920 x 1080:

So that’s a bummer. Questionably, Apple’s iPad mini tech specs claim “up to 1080p” video out support, but we can’t figure out how that’s possible. Maybe they mean that the adapter upscales the 1600 × 900 image to 1080p?

Mystery #2: MPEG Artifacts

When you plug a device into a television, you expect a clean, crisp signal — a mirror of what you see on the screen. Right?

But not with the Lightning Digital AV Adapter:

Not exactly the cleanest text in the universe! Look at all that edge garbage. (We don’t get these artifacts with the old AV adapter.)

Theory

We thought we were going insane. This is just an AV adapter! Why are these things happening! Limited resolution. Lag. MPEG artifacts. Hang on, these are the same things we experience when we stream video from an iOS device to an Apple TV…

You got it. After some good Twitter leads, and a little digging, we had our theory:

Is the Lightning Digital AV Adapter basically a small AirPlay-like receiver?

I don’t mean AirPlay the network protocol, but rather AirPlay the video compression system. It must somehow set up a connection with the very iOS device it’s plugged into. It’s in no way passing raw HDMI out from the device, but rather presenting said stream upscaled to 1080p.

“But wait”, you might be saying. “You mean to tell me there’s enough electronics in that tiny plug to support AirPlay streaming and decoding?”

It seems unlikely, doesn’t it? So out came the hacksaw.

You would not believe how incredibly tiny those components are on the left. Smaller than anything we’ve seen, electronics-wise. What could all of those resistors be for?

Let’s flip it over:

Your eyes don’t deceive you — that tiny chip says ARM. And the H9TKNNN2GD part number on there points towards RAM — 2Gb worth.

In short: it appears the Lightning Digital AV Adapter has a SoC CPU. 

So, AirPlay (or AirPlay-like MPEG streaming) makes a lot more sense now.

Conclusion

There’s a lot more going on in this adapter than we expected: indeed, we think the Lightning Digital AV Adapter outputs video by using AirPlay (or similar MPEG streaming). Are we off base? Let us know!

There are a lot of questions. What OS does it boot? @jmreid thinks the adapter copies over a “mini iOS” (!) from the device and boots it in a few seconds every time it’s connected, which would explain the fairly lengthy startup time for video out. Why do this crazy thing at all? All we can figure is that the small number of Lightning pins prevented them from doing raw HDMI period, and the elegance of the adapter trumped the need for traditional video out, so someone had to think seriously out of the box. Or maybe they want get as much functionality out of the iPad as possible to reduce cost and complexity.

The bad news? By streaming internally, the quality is poor, and it’s not 1080p. We long for raw, untouched HDMI-out.

The good news? If someone complains that this insignificant plug costs $50, tell them it’s a tiny computer!

UPDATE 3/2: This anonymous comment — if you believe it — confirms nearly all of our theories and adds much-needed backstory. Very interesting! Thanks, whoever you are. Our nerd-brains appreciate it.

PS: If you’re wondering why we’re obsessed with clean iOS video out, we’ll post some status on that soon!