My Derby app has been running stably for months, but I was nearing the end of my yearly Linode subscription and felt compelled to switch things up. Here’s what I discovered in my research.

Roll Your Own

I ran my app for quite some time on a small Linode. The benefits are obvious. You have total control over your setup. This means you can support websockets out of the gate. However, unless you’re a sysadmin wizard, you’re going to spend quite some time doing maintenance and initial setup. I finally found a solution that worked for me, but eventually decided to move towards greener pastures with a PaaS provider. There’s something nice about not worrying about infrastructure or deployment. I recommend everyone give being a sysadmin a try just to explore what it takes to run your own server. After about a year, I decided I didn’t want to maintain it myself any more. But the experience was worth it’s weight in gold.

Nodejitsu

Link

Brimming with hype off of hackathons and Hacker News, I was ecstatic to try out Nodejitsu. They promised websocket support out of the gate even when scaling horizontally with multiple drones (their cute name for extra processes). I tested it myself over many months before finally deciding to give it a production go. Although I really wanted to like nodejitsu, they made it very difficult. It would take 4-5 jitsu deploys every time I wanted to update my app due to obscure socket hangups. While they are very responsive in IRC, they often told me that large apps can cause these errors. Meanwhile my app is only about 300KB. Their web-panel, while slick, was unresponsive at times. I had a tough time logging in just to take a screenshot for this post.

While nodejitsu was one of the few to promise websocket support and have it actually work, their CPU seemed to be quite slow and therefore websocket’s speed suffered as a result. Unfortunately, I can’t recommend their service in its current iteration. There were just too many snags that I hit along the way.

Update: Since posting, Nodejitsu has made many improvements to their service. jitsu deploys actually work well and sites seem to hold up. But, my site has gone down twice with errors in the past few days. When entering IRC and asking why my site was down, the support blamed it on their router and said it would be reset in a few hours. Unfortunately, they could do nothing about it so here I was, sitting helpless while my sites were down for a few hours. That is unacceptable.

Yesterday, I was planning on launching a site on Nodejitsu and when I went to IRC for them to add an SSL certificate (something I’ve done before), they told me I couldn’t. When asked why, they said only business plans (another 40-50 bucks a month; something a student can’t afford) are allowed to use SSL. They never notified me of this change, just like they neglected to notify me for expected downtime.

Heroku

Link

Heroku doesn’t support websockets. Heroku is expensive. But, Heroku has been battle tested and can hold up to the heat. I’ve had a decent amount of experience with Heroku before giving them a go in a production environment and I have to say that the experience has been nothing but positive. No consistently obscure errors. No frills. It hosts my app, and it does it well. I was worried that xhr-polling would be consistently slower than websockets, but that’s turned out to be false. In fact, xhr-polling on Heroku was faster than websockets on Nodejitsu. I can’t explain why, but by comparing the two side-by-side it was blatantly true. I have yet to test out multiple dynos, but according to Tyler Renelle, his Derby app held up to about 1000 concurrent connections on a single Heroku dyno with xhr-polling enabled. This is more than acceptable to me for the time being.

Heroku is not perfect, but it’s a very good option for hosting a small node application that doesn’t need to handle thousands of concurrent users. Plus, you’re first dyno is always free. My app is currently running on Heroku and handling it swimmingly.

AppFog

Link

Much to my surprise, I’ve had a very positive experience with Appfog. I went in quite skeptical, but my app was up and running in minutes. They give you something that no one else is able to offer. 2GB of memory for free. Plus, you’re able to spread that across up to 8 instances of your application… all for free! So, 8 instances running at 256 MB each right out of the gate! My Linode was only giving me 512 MB for one instance and it cost over $200 a year. I have yet to use this in a production environment, but through my own load-testing AppFog has held up better than almost every other provider. On top of which, they recently acquired Nodester thereby explicitly promising to have websocket support soon. Also, their web-panel works surprisingly well and I haven’t had any major issues with it.

I’m really excited about AppFog and have been seriously considering moving my app there full-time. Once websocket support comes through the pipeline, I have a feeling this might be the place I end up. Watch out for them, they’re clearly not going away without a fight.

Modulus

Link

To be honest, I never heard of this provider before yesterday. My favorite bassist plays a 5 string Modulus bass so the name certainly jumped out at me. I decided to give them a quick try – and I was pleased! My app was up and running within minutes sans issues. Their design is by far the worst out of all the providers, but they’re young. It seems they’re focused on providing useful analytics and as much data as possible which is something any sysadmin can appreciate. I can’t recommend them yet, but since it’s free [for now] it can’t hurt to take a look. Watch out for these guys. They’re up to something.

The node.js ecosystem is young and growing. There really isn’t a proper solution yet and, quite frankly, that sucks. But, the future is bright. I can’t wait to see what 2013 has for us in the land of node.

I would recommend using Heroku if you’re small or don’t have to support websockets. Keep your eyes on AppFog and Modulus. If you really want to scale a large websocket application, you’re probably looking at rolling your own solution using some sort of VPS/Dedicated provider. Good luck and Happy New Year!

Mark Zuckerberg has made it obvious that he wants to intertwine Facebook with your life. The timeline is meant to be your life’s story. I personally am not as fond of the timeline as I believe not many people want to reminisce their awkward social past in high school, but I get the point. Also, I don’t think it’s aesthetically pleasing to read as your eyes have to dart back and forth across two columns. Over a few years, once we’ve amassed content day in and day out, we’ll be able to see the places we’ve been, the people we’ve met, and the things we’ve accomplished.

For the past few months, Facebook has ingrained itself into many notable blogs and applications (e.g. Spotify). When you read an article, it is automatically posted into your timeline.

I for one, believe that nothing should ever be automatically posted to your timeline without direct consent. Just because I read an article does not mean that I endorse said article. Therefore, I never give access to these “social reader” applications for that very reason. Now, here’s the real problem. If I see an article that my friend has read that I’m interested in, I click on it. Instead of the article loading up like one would expect, it forces me to give that app access to my timeline and my personal information. There is no reason why I should have to give any application my information just to read an article that is open to the free web. It is very frustrating to click on a link, only to be harassed into giving up my privacy.

Sure, I can block the app from sharing with my friends, but I have no way of blocking it from getting access to my information. Here’s what Yahoo requires from me just to read a simple article.

THIS APP WILL RECEIVE:

• Your basic info
• Your e-mail address (*****@***.edu)
• Your birthday
• Your likes
• This app will share videos you watched, articles you read and other activity on Facebook.

Why? Why!? Why do I have to give up all of my information just to read an article. Now instead of me reading your article and possibly generating you revenue, I get frustrated and never even reach the website. Please fix this.

Apple quickly (to my delight) emailed me back and credited my account with the funds even though this was an ”exception to the iTunes Store Terms and Conditions, which state that all sales are final.” I changed my password and went to sleep satisfied.

All was well today, until about 15 minutes ago. I received an email saying: $27.52 had been charged to my Apple account. The thieves had gotten back in. I attempted to login, but the password had been changed again. I rushed to change the password, yet again. After emailing Apple support saying I had been hacked again, I went off to Google to see if anyone else was getting repeatedly hacked.

Well, it appears people are getting hacked all the time. The only thing most users that were hacked had in common, was that they all had some sort of gift card in their account. Many had only gift card money taken, but some seemed to have Paypal funds stolen and credit cards charged. Either way, it seems these are happening directly on Apple’s server which means Apple itself is getting hacked and passwords are being altered. All of the charges are for overseas in-app purchases which means these aren’t people snooping on my wifi (might I add that I’m on a highly secure University campus wifi). Hopefully Apple will patch this hole quickly. As for now, I’ve gone ahead and told Apple to freeze my account. You might want to do the same.

Wikipedia:

CBS Laboratories head research scientist Peter Goldmark led Columbia’s team to develop a phonograph record that would hold at least 20 minutes per side. Research began in 1941, was suspended during World War II, and then resumed in 1945… When initially introduced, 12-inch LPs played for a maximum of 45 minutes, divided over two sides. However, in 1952, Columbia Records began to bring out extended-play LPs that played for as long as 52 minutes, or 26 minutes per side. These were used mainly for the original cast albums of some Broadway musicals…[These records] remained rare, however, because of mastering limitations, and most LPs continued to be issued with a 30- to 45-minute playing time throughout the lifetime of their production. However, some albums would eventually exceed even the 52-minute limitation, with single albums going to as long as ninety minutes in the case of Arthur Fiedler’s 1976 LP 90 Minutes with Arthur Fiedler and the Boston Pops, made by Radio Shack. However, such records had to be cut with much narrower spacing between the grooves, which allowed for a much smaller amount of dynamic range on the records, and meant that playing the record with a worn needle could damage the record. It also resulted in a much quieter sound.^[1] Spoken word and comedy albums, not having a wide range of musical instrumentation to reproduce, can be cut with much narrower spacing between the grooves; for example, The Comic Strip, released by Springtime Records in 1981, has a side A lasting 38:04 and a side B lasting 31:08, for a total of 69:12.

In any case, the standard 45-minute playing time of the LP was a significant improvement over that of the previous dominant format, the 78 rpm single, which was generally limited to three to four minutes. At around 14 minutes per side for 10-inch and 23 minutes per side for 12-inch, LPs provided a measured time to enjoy a recording before having to flip discs.

Some record turntables, called record changers, could play a stack of records piled on a specially designed spindle and arm arrangement. Because of this, many multiple-record sets were released in what’s called “automatic sequence.”

---

[1] (Other notably long albums included the UK version of The Rolling Stones’ Aftermath, with both sides exceeding 26 minutes in length; Genesis’ Duke, with both sides exceeding 27 minutes; Bob Dylan’s 1976 album Desire, with side two being just shy of thirty minutes; Brian Eno’s 1975 album Discreet Music, whose A-side exceeded 30 minutes; Miles Davis’ 1972 album Get Up with It, totalling 124:15 over four sides; Todd Rundgren’s 1975 album Initiation, totaling 67:32 over two sides, as well as his band Utopia’s 1974 self-titled debut, totaling 59:17 over two sides, and his 1973 album A Wizard, A True Star, whose second side nearly reaches thirty minutes; and La Monte Young’s Dream House 78’ 17”, whose two sides were each just under 40 minutes (the running time of the album is indeed 78:17))

The blue link indicates an externally linked post

Jekyll uses YAML Front Matter as a way of storing variables on posts such as title, date, and more. We are going to add our own custom variable: link.

Here’s an example of what a YAML Header looks like:

---
layout: post
title: "Phish Video of the Week: 1997-11-22"
date: 2011-11-25 01:54
comments: true
categories: 
---

We’ll manually add our own variable in. Let’s call it link.`

---
layout: post
title: "Phish Video of the Week: 1997-11-22"
date: 2011-11-25 01:54
comments: true
categories: 
link: http://blog.phish.net/1322194271/video-of-the-week-1997-11-22
--- 

Now let’s head over to the templating system. Open the article.html file in your /source/_includes folder.

Replace (inside of {% if index %}):

1
2
3

<h1 class="entry-title"><a href="{{ root_url }}{{ post.url }}">{% if site.titlecase %}{{ post.title | titlecase }}{% else %}{{ post.title }}{% endif %}</a></h1>
{% else %}
<h1 class="entry-title">{% if site.titlecase %}{{ page.title | titlecase }}{% else %}{{ page.title }}{% endif %}</h1>

With:

1
2
3
4
5
6
7
8
9
10
11

{% if post.link %}
      <h1 class="entry-title"><a href="{{ post.link }}" class="link">{% if site.titlecase %}{{ post.title | titlecase }}{% else %}{{ post.title }}{% endif %}</a></h1>
  {% else %}
      <h1 class="entry-title"><a href="{{ post.url }}">{% if site.titlecase %}{{ post.title | titlecase }}{% else %}{{ post.title }}{% endif %}</a></h1>
  {% endif %}
{% else %}
{% if page.link %}
  <h1 class="entry-title"><a href="{{ page.link }}" class="link">{% if site.titlecase %}{{ page.title | titlecase }}{% else %}{{ page.title }}{% endif %}</a></h1>
{% else %}
  <h1 class="entry-title"><a href="{{ page.url }}">{% if site.titlecase %}{{ page.title | titlecase }}{% else %}{{ page.title }}{% endif %}</a></h1>
{% endif %}

Don’t worry, I’ll walk you through what were doing here.

We first check if we are on the index page. This doesn’t matter all too much, but Jekyll’s objects are different for the index and the article pages. On the index, we use the post variable, and on the article, we use the page variable. In order to access the link variable, we must use post.link or page.link respectively.

The first group of code will output this HTML:

<h1 class="entry-title"><a href="http://saewitz.com/2011/11/25/phish-video-of-the-week-1997-11-22">Phish Video of the Week: 1997-11-22</a></h1>

The second will output this:

<h1 class="entry-title"><a href="http://blog.phish.net/1322194271/video-of-the-week-1997-11-22" class="link">Phish Video of the Week: 1997-11-22</a></h1>

See the difference? The first just throws out a normal link to the post, while the second gives us a link to an external post (with our post’s title) and adds the class link.

If you’d like to style that, just add the article h1 a.link to your CSS file. Feel free to use whatever stylings you like.

1
2
3
4

article header h1 a.link {
  color: #147ed9;
  border: none;
}

I suggest adding a permalink button to the date line, to allow people to link to your post. If you’d like a tutorial on that, please let me know.

If you have any problems, post in the comments below.

That’s it, enjoy!

Here’s my solution:

1. Create a file named new_post somewhere outside of your blog’s directory¹ and paste the following in

1
2
3
4
5
6
7
8
9

#! /bin/sh

if [ "$1" ]
then  
  cd ~/Desktop/Blog #set this to your blog directory
  rake new_post["$*"]
else  
  echo "Please enter a post title: ./new_post TITLE"
fi

2. Set the directory (on line 5) to match your blog’s directory

3. Open your ~/.bash_profile and add the following line

1

export PATH="$PATH:~/Scripts" #set to your script's directory

This will allow any script in your Scripts directory to be called from any directory. If you don’t want to add that directory to the $PATH variable, just use: alias newpost='~/path/to/newpost' and remove the export PATH line.

4. To run, just type source ~/.bash_profile and then newpost "Octopress and Jekyll Tips and Tricks" (quotes optional)

I also automate the blog push to git² from any directory.

1. Create a file called blog_push and paste the following in

1
2
3
4
5
6
7
8
9
10
11
12

#! /bin/sh

if [ -m "$1" ]
then
  cd ~/Desktop/Blog #set to your blog directory
  rake generate
  git add .
  git commit -m "$*"
  git push
else
  echo "No commit message entered: ./blog_push COMMIT_MESSAGE"
fi

• Note: You may have to modify the git push to suit your specific needs. Use whatever push command you normally use

2. Set the directory (on line 5) to match your blog’s directory

3. Open your ~/.bash_profile and add the following line

1

export PATH="$PATH:~/Scripts" #set to your script's directory

• Note: If you already set the $PATH to that directory, then you don’t need to do it again

4. To run, just type source ~/.bash_profile and then blogpush "New Post: Octopress and Jekyll Tips and Tricks" (quotes optional)

1. I use a scripts directory to store all of my bash scripts in my home directory.
2. This won’t work with RSync. It is for Git based (Github, Heroku) blogs.

Today I whipped up something that I’ve wanted for a long time in Espresso. Now that Espresso 2 has javascript actions this is a possibility! Read below to find out more.

FrenchPress.sugar

A javascript action that beautifies javascript files into formatted code:

• Uses the library from jsbeautifier.org

• To run use Actions->Javascript menu or press Control + Alt + Arrow Up

• This will not fix syntactically incorrect documents

• This is beta software, please backup your code in advance. You may undo the action by pressing command+z (or Edit->Undo)

Installation

Requires Espresso 2.0

The easiest way to install FrenchPress.sugar currently is directly from GitHub:

cd ~/Library/Application\ Support/Espresso/Sugars
git clone git://github.com/switz213/FrenchPress.sugar

https://github.com/switz213/FrenchPress.sugar

Relaunch Espresso, and a new Javascript submenu will be available in your Actions menu.

Development

FrenchPress.sugar is written entirely in XML and JavaScript using Espresso’s JavaScript API! Feel free to mess around with the code or fork it on github!

You may email me if you have any feedback, requests, or run across any problems.

hi@danielsaewitz.com

Changelog

1.0:

• Initial release
• Beautify Javascript using menu or key-combo (Control + Alt + Arrow Up)
• Will automatically match your Espresso tab settings (# of spaces, spaces or tabs)

Thanks to:

Ian Beck

This could not have been completed without the Handy.sugar source code

JS Beautifier

Written by Einar Lielmanis
http://jsbeautifier.org/

Originally converted to javascript by Vital

“End braces on own line” added by Chris J. Shull

MIT License

Copyright (c) 2011 Daniel Saewitz

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

Stay awhile and listen.

$ whoami

Daniel Saewitz

This is a window into my mind.

I’ve been bouncing around the popular blogging solutions trying to find the right one. I believe I have met my match.

Here’s what I was looking for:

• Simple
• Lightweight
• Fast
• Customizable
• Markdown support

I started with Wordpress, etc. all the way down the blogosphere daisychain to Tumblr. While all were good, none were great. Each had some solid features, and each had some not so solid features. They were all too bloated and slow.

Static Site Generator

I started looking in to what is known as a Static Site Generator. This principal behind the SSG is that there is no dynamically loaded content. Everything is static. This means that when the user goes to any page, they are served an html file. No slow, server-side php. Nothing for the server to do. It just loads the content and goes away.

It’s a directory of markdown files. The header of those files include some settings, such as date, title, layout, and more. Once a command line function is called, the html files are generated from the markdown files. The files are then pushed out on git to heroku, which manages the website.¹

The site is currently running a taste of Jekyll known as Octopress.

1. It is also important to know that not all SSGs are blogging engines.