The Font Awesome icon pack has been free, but perhaps sensing that free was not a sustainable revenue model, the creators offered a series of subscription tiers for the upcoming version 5.
To raise some initial money, the creators turned to Kickstarter and offered early backers a discounted Pro membership. Their goal was to raise $30,000 to fund development of Font Awesome 5. The crowdfunding campaign ended early this morning, obliterating that goal. They raised over a million dollars. After reaching their initial goal, they set up several stretch goals after reaching certain fundraising milestones. Many of them are a little too technical for me to understand, but the last one in particular is that they pledged to open-source some of their frameworks. That’s pretty cool.
This however didn’t happen by accident. Raising funds of Kickstarter is now a cottage industry, and the guys at Font Awesome were very methodical in launching their campaign, even hiring a professional video production firm for their video.
The result is certainly impressive, and initially I thought they had produced it themselves: “What? These guys can make videos, too!?!” Knowing that they outsourced the video work—and that it cost them like $15,000—makes the Font Awesome guys seem a lot more human.
At the same time, though, their success shatters the myth that crowdfunding is a revolutionary way to raise funds. The Font Awesome campaign is extraordinary, being the most successful Kickstarter campaign to date. But it shows that to successfully raise funds, it helps that you already have funds.
As risky as it may sound to spend $15,000 on a three-minute video, it clearly helped Font Awesome raise a lot of funds. That’s not bad for something that started out as a free product.
Earlier this month, my web host since 2006 began experiencing extended outages. Normally, I wouldn’t care because I have been pretty inactive in posting to this site over the last few months. However, Downtown Host also hosts my professional site, at https://juanmonroy.com and because I post all my course syllabi on that site, uptime is very important, especially as midterm exams are nigh.
Back in the spring, I attended a workshop on Omeka as part of NYC Digital Humanities Week, and the presenter, Kimon Keramidas, recommended a web host built for academics, Reclaim Hosting. The latest outages forced my hand a bit: I signed up for Reclaim Hosting on Tuesday and began migrating my sites that day.
My professional site was really easy to migrate. Because that’s site is state-of-the-art for 1998 web sites, it consists of just static HTML content and some Apache server side includes. I just copied the files and changed the DNS record with Hover. Within ten minutes, the site on the new host was working as it always on the old. (The process was similarly easy for the East Village Softball Association, which I also maintain using equally antiquated web technologies.)
Less Easy Migration
Because this blog is hosted on WordPress, the process was more complex. Most of it worked according to this guide, but there were some hiccups, due to having a multisite installation. Without getting into too much detail, here’s the basic steps I took:
Downloaded the files from the WordPress installation from my old host.
Exported the MySQL database.
Uploaded the file to the juanomatic.net domain directory on my new host.
Created a new MySQL database and imported the old one.
Change the DNS records at Hover.
Reusing the existing wp-config.php file didn’t work. I had to start from scratch. Thankfully, WordPress figured out that I already had an installation running and made me run through a database configuration instead of reinstalling everything.
All of these steps basically got me back to where I was on Friday, except that the blog is now on a new host.
New, Same Old Site
So, after all that, I now have a couple of new websites, except that they should look like the old ones. But there are two distinct differences.
First, the sites seem to load a little faster, although that’s probably just a function of my imagination. After all this work, I might as well realize some improvement. The appearance to load faster might be that reward.
Second, the professional site and this blog now use HTTPS. The new host offered certificates from Let’s Encrypt, a free, automated, and open certificate authority that was launched to make securing web transmissions over HTTPS quick and easy. Now, transmissions sent between your browser and my sites are encrypted. A keen reader might have noticed a lock in the browser or that all the URLs in this post use https protocol instead of the insecure http. It’s very exciting.
Yes, I’m still alive! No, I haven’t abandoned this website.
With only three posts since Memorial Day weekend, I know it looks bad, but I will be posting again soon. The summer months, while certainly not boring or uneventful, did not find me with much to share with the world.
But summer is over, and I will be back to sharing again, including a few backdated posts.
When I dislocated my pinkie finger nearly three years ago, I had a little taste of the American Healthcare System. It was gross. A teammate walked me from Central Park to the emergency room at Mount Sinai–St. Luke’s Hospital. There, the attending physician…
ordered a sets of x-rays to determine whether my finger was broken. It was not.
yanked my finger back into place, which immediately straightened the digit and made it stop looking purple.
ordered another set of x-rays to make sure he didn’t break anything. He didn’t.
bandaged my cut.
administered an intravenous antibiotic to prevent any infection due to my open wound.
prescribed an oral antibiotic for even more protection against infection.
The bill for this treatment was over $6,000.
Once my health insurance reviewed the charges, the hospital immediately reduced the bill to about $2,500. (Imagine if I didn’t have healthcare insurance. Thanks, Obama!) The insurance covered most of it, and I was stuck with the co-pay and the deductible, which amounted to about $600. I eventually paid the bill over time through a hospital collection service’s website. I remember the website looking atrociously dated, but it was at least functional enough that I could save a few postage stamps and pay with my AMEX card.
Earlier today, I was helping a relative pay for an ambulance bill, and the website for paying the ambulance bill demonstrated to me that the hospital collection industry is due for an upstart competitor to enter this field. As of today, their website has four critical problems:
First, go to myambulancepayments.com/. Did you get a 404 error page? I did.
Silly, me! I neglected to prepend www to the URL. I should do that because this website predates the convention of not requiring www to connect to a website. I think that has been standard practice since about 1998.
Second, there’s a warning from Safari that my connection to the website is not secure.
It appears that their SSL certificate expired a few days ago, on February 5, 2016. Did they forget to pay their certificate authority? Ironic, isn’t?
I know what you’re thinking: “who uses Safari?” Perhaps I should fall in line and use Chrome.
Oh, my! That Chrome-generated error page looks even more alarmist that the Safari error page.
Third, though I’m advanced enough to recognize the risks and not enter any personal information, such as my name, address, or credit card information, I proceeded to site.
But, wait… why am I here in the first place???
Fourth, in my Safari installation, which doesn’t have Flash installed and doesn’t load any such content, I noticed some missing Flash content and a plea to install it.
Since Chrome still supports Flash, though maybe not for long, I see that the all-important Flash content is some propagandastic animation, reminding you that you should pay up because they saved your life.
At least, for the many, many people using a mobile device, none of which support Flash, they’ll be spared this visual reminder of the Hobson’s Choice that is the American Healthcare System:
Around 2003, I bought the domain name cinematologists.com for the Cinema Studies student association at NYU. I chose the domain name because film scholars used to call themselves “cinematologists,” in part to grant a pseudo-science legitimacy to the field. By the 1990s, when I started studying film, the name had long gone out of favor.
I used the domain name to stage a few websites for the annual student conference and a few symposia, such as Michael Bowen’s Confessions of a Vice Baron. The department renewed the registration over the years, but the newer crop of students who succeeded me preferred to use web 2.0 platforms such as Blogger, WordPress, Facebook, and even Tumblr. They never seemed to stick to one platform, and a few years ago, the registration for cinematologists.com expired.
I considered renewing it for myself to eventually use it for something film-studies related down the line, but I found that I am too late. A bunch of English scholars have launched their own Cinematologists podcast and host the companion website at http://www.cinematologists.com.
As a man of a certain age, I have been an active Internet user for over twenty years, beginning with email and USENET. I have also been using the graphical web since about late 1995 or early 1996, around the time I figured out how to set up a dialup SLIP connection at home. As someone initially intimidated by computers, getting my Quadra on the Internet via a phone line—without a commercial service like AOL, Prodigy, or Compuserve—was an initial step in becoming the lonely, over-inquisitive technophile that I am today.
Over that time, I have collected (and lost) a bunch of web bookmarks. We all have. In my days of doing desktop support, my users bemoaned getting a new computer because they feared losing their documents, which we diligently transferred, and their bookmarks, which we also migrated to their new browser.1 Each user’s bookmark collection was like a box of digital heirlooms.
Some of my own bookmarks are really, really old. They have migrated from one browser to another—Netscape to Internet Explorer to Safari—and outlasted about a half-dozen Macs, starting with a PowerMac G3. Over the weekend, I was typing some address in the Safari web location bar. After a few keystrokes, the auto-complete feature suggested something long-forgotten, though kinda-familiar: The Standpipe Gallery at http://standpipegallery.com. Don’t bother following that link because it’s dead. In fact, after clicking through my other bookmarks, especially those dating from when I still organized them into folders, very few sites still exist today. That was kinda depressing.
A fun resource, probably where I looked up the term “grass widow”
I’d go on, listing more of them, but I already feel old and sad enough without plunging any further. At one time, my bookmark collection, and the sites collected therein, meant something to me. They either provided some utility, some insight, or even a laugh, but now, years later, they’re gone. And had I not impulsively followed one of them, they would all have been forgotten, too.
There’s some truth to the claim that the Internet never forgets, a fact that makes me think twice before I post something here. But there’s something else that’s also true about us and our digital artifacts. Someday, we will all be dead. And once our domain registrations expire and our hosting plans don’t renew, our web sites will be dead, too. Just like us.
As for the Standpipe Gallery that initially piqued my curiosity and triggered this post, I figured out that it was a gallery founded by Alison Pierz, the wife of a grad-school colleague. Much like the website, the gallery no longer exists. However, there’s an “archive” available of the work shown there over the years. It survives as a Facebook page.
If I remember correctly, for a time, there was even some issue with browser lock-in. Your Netscape bookmarks would not easily transfer to Internet Explorer, or vice-versa, or maybe, I’m just making that up. ↩
If you’re a regular reader of this site, something might look a little different.
Because I wanted my sites to have nice type too, I subscribed to Typekit’s Personal package. For $25 per year, Typekit allowed me to select from a pool of webfonts and deploy them on two (2) websites. This package came with a limit of 50,000 page views per month, but this site doesn’t get anywhere near that much traffic. It was a great deal for a small and esoteric web operation like this one.
Earlier this week, Typekit announced that they were no longer offering the Personal plan for new customers. Instead, all Personal plan customers would continue to pay $25 per year but would receive all the fonts, not just a selection, and would be able to deploy on an unlimited (∞) number of sites. The only restriction that remains is the 50,000 monthly page views.
This is a big win for me since I now get to use any of Typekits webfonts, including ones that were only available on the $50 yearly plan. One of those fonts that had eluded me was Proxima Nova, among the most popular webfonts on the Internet.
As of Wednesday, the body font for this personal site (my “blog”) is Proxima Nova. It replaces Runda, a very nice and distinct font that I will continue to use as the body font on the professional site. The rest of the fonts remain the same: Adelle Sans for headings and Anonymous Pro for when the situation calls for a monospaced font.
And now that I’ve settle on that, I can at last seek out the difference between a font and a typeface. Do you know?
If you tried to reach this website or my other site since yesterday at 2:00 PM EST, you probably noticed that it was down.
It appears there was some issue with the IP address, 126.96.36.199, my web hosting provider had assigned me. They had to provide me a different one: 188.8.131.52. Things should have been A-OK after that, but since I use Hover (my domain name registrar) as my name server instead of Downtown Host, my web hosting provider, I had to manual change the DNS records to reflect the new IP address.
I know, I know…this might be the geekiest, most jargon-filled post I’ve ever written. But despite all this, I’m glad I am able to at least have an idea of how to fix my websites, even if I don’t understand what was wrong with the original IP address in the first place.
And now with the site back online, it’s time I start posting again. Welcome back!
After abandoning bloated learning management systems this semester, I recognized that my solution—a late–1990s style website with little more than static HTML—was not serving some of my students well. A good number of them use a mobile phone, usually an iPhone or some other Android device, instead of a computer or tablet, which is how I envisioned students accessing my syllabi.
Since I wasn’t using a content management system, such as WordPress or Drupal, I couldn’t just install a plugin to make the site mobile ready. However, I was able to use Bootstrap to create a responsive design.
My blog was a different matter. Since it’s powered by WordPress, I had to rewrite each template file to comply with Bootstrap. However, unlike the static site, I didn’t have to rewrite every page, such as the nearly 500 blog posts, because they’re all generated by WordPress. However, I had to add some functions to make the images and videos size properly.
Since I was doing all that work, I decided to tweak the site’s design. I moved the widgetized sidebar to the right, which is more like every other WordPress site on the web. I moved the navigation functions to a navbar that spans the width of the page. I also changed the fonts to Myriad Pro as the headline font, and an homage to Apple, and Runda as the body font. Redesigning each template file allowed me to finally add infinite scroll to the index and search pages.
What started as an attempt to make the site more accessible turned into a giant time suck, if you’ll pardon the expression. But unlike my many other time-consuming endeavors, I really like the results.
I can’t remember when I turned on two-step authentication for my Google accounts, but I’ve adopted it for every other account that supports it, including Twitter, Facebook, Dropbox, and WordPress. For those who are not familiar with two-step authentication, it is an extra layer of security that requires you to provide two keys: something you know and something you have in your possession. Accessing a protected account requires two steps, hence the name: entering your account password (something you know) and entering a random code from your phone (something you have).
Google Updates Authenticator
A popular and widely supported iPhone app for generating these codes is Google Authenticator. Earlier this week, Google updated Authenticator, which was a surprise to me. It hadn’t been updated in over a year and had an annoying bug that prevented you from editing your existing accounts. I feared Google had abandoned it because it also didn’t support the nearly-year-old 1136 x 640 iPhone 5 display.
As welcomed as the update was for me, it turned out to be a hot mess. When I updated the app, it deleted all of my existing accounts. Without those codes, I could not access them because I need both the account password and the Authenticator code to log in to those protected accounts. Once the app was wiped, I couldn’t get any of those precious codes.
And, of course, Google screws me yet again by deleting ALL of my two-step authentication tokens with its new update!
Fortunately, for me, it was more of an inconvenience than a disaster because I accessed my accounts using the emergency backup codes that I had safely stashed away.
WordPress and Google Authenticator Plug-In
There was however one account that doesn’t have emergency codes. It is the Google Authenticator plugin that adds two-step authentication for this self-hosted WordPress site. I’m unsure if you can add this plugin to hosted WordPress.com sites, but I suspect you cannot since there’s no plugin area for those hosted blogs.
To regain access to a self-hosted WordPress account that has been locked due to two-factor authentication, it requires you to have SFTP or SSH access to your web hosting account.
Log in to your SSH or SFTP account.
Navigate to the wp-content directory.
Create a directory called disabled or something else that won’t interfere with WordPress. This will be a temporary measure.
Navigate to the wp-content/plugins directory.
Rename (or move) the google-authenticator directory to the wp-content/disabled directory. Type something like… mv google-authenticator ../disabled
On your web browser, load your wp-admin page. You’ll see that you will not be prompted for a Google Authenticator code.
Using SSH or SFTP, move the google-authenticator directory back to the plugins directory. If you are still in the plugins folder, type something like… mv ../disabled/google-authenticator .
Delete the disabled directory. rm -rf disabled
With your web browser, go to your Dashboard and then to the Plugins area. Reactivate the Google Authenticator plugin.
On your Profile page, scan the barcode to add this WordPress account to your Google Authenticator app.
Or you could stop at step five, delete the plugin, and be done with two-step authentication altogether.