So I’ve been working on a project recently where I needed a simple predicate builder. Basically I needed a way to allow users to build a somewhat complex search using a GUI. And since we are using AngularJS on this project, here’s a quick article about how I did it.
So there’s this program out there called Calibre which, despite it’s pretty terrible UI, is pretty much the gold standard for managing eBooks. Seriously, it’s such a great program whose only fault is its terrible engineer UI.
One of the nice things that Calibre includes is a built-in web server that can serve books via OPDS. If you have an OPDS-compatible reader (I use Marvin), you can browse and download from your library directly on your device, basically creating your own private eBook cloud.
But, this presents a little bit of an issue. Namely, I don’t want all of my books to be publicly available, while still providing a subset of my library for visitors to browse and use. But I still want to be able to access them myself from my “private reserve collection.”
Fortunately, with a little bit of work, you can do that under Calibre.
I’m obsessed with pretty URLs. I admit it. I love looking at a properly formatted URL that just looks nice.
I’m slowly converting our internal media library over to Plex now that it is available on the new AppleTV. In doing that, I noticed that the Plex web interface serves, by default, serves from port 32400. So the URL ends up looking somthing like this:
http://172.16.104.4:32400/web/index.html
Twitch.
I’m a big fan of Laravel and I’ve really enjoyed building things on it. So I’m going to walk you through a quick lesson in getting a dev environment set up.
PHP’s PHAR archives (PHp ARchives, get it?) are a neat development. They’re a way to distribute an entire PHP application as a single archived file that can be executed directly by the PHP intepreter without unarchving them before execution. They’re broadly equivalent to Java’s JAR files and they’re super useful for writing small utilities in PHP.
It’s been a crazy week. Apparently my last post struck a nerve. :)
Those of my longtime readers will know that I very rarely if ever mention anything on this blog other than my ramblings on tech. But today is a very different day and I feel compelled to write about this. So I’ll ask for a mulligan. And, as always, my views here do not represent anything or anyone other than me.
Apple has launched a new Photos App for OS X, along with the ability to upload your entire library to iCloud. And with prices that are so cheap, there’s almost no reason not to. $3.99 a month is cheap insurance to know that every photo I’ve ever taken of my family won’t be wiped out in a tornado.
But with this comes a problem - namely, how do you upload a 150 gigabytes of photos over a 5 megabit network connection? Well, you wait a really long time for it to upload. Which is fine, really, because I’m not in any particular hurry to finish. But, once I started the upload, I noticed that surfing the web became pretty much impossible because the upload to iCloud was saturating my upstream bandwidth.
So I was confronted with an interesting bug this week, and I wanted to share it with everyone so maybe it will save you some time. Put simply, NSAttributedString with NSHTMLTextDocumentType is slow. Dog slow. So obscenely slow that it should probably never, ever be used.
So I recently was working on a site and wanted to use CSS3 columns. But I really like how the grid system works in Bootstrap, and wanted to be able to define columns in a similar way (i.e. have different number of columns depending on the screen size). Not finding any pre-cooked versions, I decided to write my own.
Strictly speaking, you don’t need Bootstrap for this to work. But I did re-use Bootstrap’s grid variables so that it breaks along the same lines that Bootstrap’s grid does. It’s also worth noting that, natively, the columns will collapse on their own if you specify a width. This method just gives you a bit more control.