So, a few years back, I consulted at NASA doing some work on a really cool system for storing and retrieving documentation on systems in flight. Basically, it was a very customized Bugzilla that winds up saving the American taxpayer millions of dollars every year. There’s a post I wrote at the time about how to print to PDF from Perl that is still the single most popular blog post I’ve ever written. It still gets traffic, and that tells me that the library is still terrible at telling you how to use it. Anyway, that’s not what I want to talk about today. Today, I’m advertising another application that arose from the same gig: a dummy SMTP/POP3 server.
Today I received the April newsletter from JetBrains, wherein they provide links to a bunch of Java news. Most of it is stuff that isn’t immediately interesting to me, but this time there was a swell one-two punch. One, Java 10 is out and Java 11 has been announced (what? 9 just came out, like, a few days ago, right?). Two, JavaFX is gonna be deprecated and won’t even ship with Java 11, so if you want to build a GUI app with Java you’d better dig out all your old broken-ass Swing/AWT tools and get happy about that.
Hey, JetBrains? Would it be too much to ask you to build a nice Maven packaging plugin for your interface builder stuff, and while you’re at it, can you update your UI builder plugin so it works, again? Sheesh.
Today I learned a couple of things that they don’t tell you in the official documentation or on Stack Overflow. If you want to display some information in a table and that information updates and you want to display those updates, then you have to hook things up the hard way, and not the way everyone tells you to do it.
Several days and a lot of testing later, I think I have the answer: don’t try to build a play-by-email service in Google AppEngine. The limitations imposed by the environment make it a bad place to do a lot of email traffic that requires anything other than text/plain or text/html. Because Google has defined javax.mail.Transport to use the AppEngine mail service, you can’t choose to connect to a different SMTP host; if you specify an external SMTP server (such as SendGrid or Pobox) in the Session, Google’s Transport implementation ignores it and still uses the AppEngine mail service. When you try to use a web API to send your message through SendGrid, that screws up the MIME headers and your message won’t validate (if it’s even readable) at the receiver’s end.
That said, I have finally figured out how to prepare and send a PGP signed MIME message such that it arrives and validates properly. Since nobody else has written that down on the web (that I could find), I’ll detail the recipe here.
I’ve been working on adding play-by-email support to my turn-based game server. The first problem I hit was that the PGP signatures on the server’s messages were invalid when I checked them on my email client. This led to lots of debugging and unit tests in my crypto utility. That’s not really wasted effort, but it also wasn’t the problem.
It turns out that even though the RFC limit on line length is 1000 characters and there are well-known implementation limits that are only slightly lower, there exists somewhere in the chain from Google AppEngine to Apple Mail some chunk of code that inserts newlines into lines that are much shorter. I didn’t do exhaustive testing, but it seems to happen before 80. The perfectly valid signatures were being rendered invalid because somebody was altering the message after the server signed it and handed it off to the transport agent.
The solution I chose was to use WordUtils from commons-text and to wrap the message at 70 characters before signing. This seems to work. It’s just kind of dumb that it’s necessary, but it’s a good reminder that the thing in your inbox may not actually be the thing sent to you by whomever, and that PGP signing your messages is a good idea even if you don’t encrypt them.
I’ve started developing a text-only client for Twitter. The impulse came from getting fed up with all the auto-playing promoted tweets that were clogging my timeline. I looked around and found a library to handle all the Twitter API calls and started coding. The example code was all a bit bare-bones, but mostly it was straightforward. The one thing so far that I think could use a bit more explanation is the login process, and that’s the point of this post. Continue reading
I have been having fun, recently, programming a couple of services that run in Google’s App Engine. One thing they do is maintain some data in that cloud’s version of a database, so one of the important aspects of the services is controlling just who, exactly, is allowed to see or modify the data. I’ve actually got a solution in place that means it all works just fine for me.