Instructions

Yes, Iced Coffee is THAT Easy

Chris Weber

With it being June in the Northeast, the heat has certainly picked up, and the Spring/Summer fever is in full swing.  One of my favorite parts about the warmer months is spending some time outside and enjoying my morning coffee, well, my morning iced coffee, it’s already hot enough out without a scalding mug in hand.  The only issue I had was that I needed to go out and get this liquid manna from somewhere, or it came out of a carton from the store.  Don’t get me wrong, I appreciate coffee shops as much as the next caffeine junkie, but I was also raised to take pride in my coffee brewing and currently safeguard a recipe that’s been perfected for over three generations of coffee brewers.  I also use a Keurig without batting an eye, so take from that what you will.  Regardless, I knew there must be a way for me to manufacture my own iced coffee, using grounds of my choosing, allowing me to save money and trips to stores while maintaining the pride of my brewing ancestry. Indeed there was, and damn was it easy.

 

TL;DR

Put grounds in water, let sit, strain, enjoy.

Instructions

 

Tools/Supplies

  • Container for steeping
  • Strainer/coffee filter/cheese cloth
  • Container for storing

Ingredients

  • Coffee grounds
  • Water
  • Anything else you want

Making iced coffee is a lot like making regular coffee, you can get it done with beans and water, but some people have their own tweaks and tricks.  I recommend starting off with a ratio of 1-1.5 cups of coffee to 4 cups of water and then tweaking it from there.  Simply add the two together in your steeping container, mix it up to make sure everything’s evenly disbursed, and refrigerate for 8-12 hours, again tweaking as needed.  I usually set this up at night, so that the fresh batch is ready in the morning, but maybe you want to do it throughout the day, so it’s ready for a grab-and-go in the morning.

Once your cold brew is ready, you then want to pour it out of the container and into the one you’ll store it in (I use a pitcher with a top, similar to something you keep lemonade in) and strain out all the grounds in the process.  I originally used a small strainer like this:

Small strainer

which worked well for most of the grounds but let some of the finer pieces through.  As I started making more at a time I started using a larger strainer with some finer mesh that succeeded in capturing more of the disposable grounds, but still was not perfect.  Others recommend using a coffee filter or cheese cloth as part of the process, but I’ve found I’m too impatient to wait for the coffee filter in the morning, and I didn’t have any cheese cloth.  The solution I arrived at which works well enough, is to just use the strainer as a best effort on the initial brew.  Everything that escapes it settles at the bottom of the container anyway, so it’s fine until you reach the end of the supply, at which point I use the strainer again when pouring the glass.  Most of the dregs remain at the bottom of the container and can be rinsed, and the strainer catches the few that would have made for a nasty surprise in my straw.  Anyway, once that’s done you can put a top of that and keep it refrigerated for awhile (haven’t had it last long enough to know how long it keeps!).

Drinking the iced coffee

Now that you’ve got the iced coffee, you have to drink it.  My personal strategy is put ice in a glass, pour in the coffee, then add cream and sugar to personal taste.  One thing I will note is that the cold brew has a higher coffee-water ratio than my normal cup of coffee, so it has a stronger taste, but the ice will actually dilute it a bit as it melts, so take that into consideration.  Others have suggested adding sweetened condensed milk or flavored syrups, but I haven’t ventured into making a syrup yet and the condensed milk didn’t really change the taste of mine enough to warrant the extra level of complexity. I’m sure there’s plenty of other ways to personalize your iced coffee, so feel free to let me know what you come up with!

Tunnels, of the SSH kind

Chris Weber

These days it seems like we all live in the the cloud.  Whether it’s your personal site, email, or photos to show your family at the next get-together, odds are you’re storing something, if not everything, up there.  It’s fantastic! But it’s not everything, and there’s plenty of times when you still need to be communicating with individual machines located anywhere from the same room to across the world.  For that, and so much more, there’s SSH.

Are you telling me to be quiet?

For anyone who says TL;DR to the Wikipedia article, SSH is one of the most simple and secure (if you’re doing it right) ways to communicate between networked devices. Clients are usually available by default on Unix based systems (Linux, Mac, and even the Chromebook I’m editing from) and can be easily obtained for the other popular OSes (Windows, Android, iOS). At the other end, SSH server software is a staple of most, if not all, servers out there, although it may not be enabled by default, so keep that in mind when you decide to tinker.

How I started using SSH

I stumbled upon SSH shortly after stumbling upon Linux.  Since then, it’s only become more valuable for both work and play as I learn additional features of SSH and how to leverage them.  Due to its secure nature, it can be used to encrypt traffic, transfer files, launch remote applications, and even help turn your tablet into a second screen!  And while there are plenty of apps and other ways to do these things, few have the same availability as SSH, especially when dealing with a University or campus network, and potentially even some ISPs.  But today I just want to focus on one aspect of SSH, and that’s tunneling.  There’s 3 kinds, two of which I’m familiar with, and one that has become incredibly useful as my development workflow has changed.

1. When you want it locally, but it’s remote

One thing I’ve found incredibly difficult about SSH tunnels is keeping the syntax and function of each kind straight in my head.  My main use for a Local tunnel is when the resources I need are not accessible to me locally, but I want them to be.  For example, you’re working on an application locally, complete with a local database instance.  You want to move to testing with a more populated database, maybe even your production one, but unfortunately it’s a pain to switch them in your code (at least until that refactor you have planned…).  This is where the “local” version can help, by creating a tunnel to the remote database.  Here’s the syntax:

ssh -L <local host>:<local port>:<remote host>:<remote port> <user>@<ssh server>

Taking a closer look at the command:

  • ssh is the command to execute SSH
  • -L signifies we want a “Local” tunnel
  • <local host> is the host of the computer you will be accessing the resources on, in my examples it’s always your own computer, so this will be localhost
  • <local port> is a port of your choosing to access the resources on, note that this can’t be just any port depending on your permissions, so it’s best to choose an ephemeral port for testing at first
  • <remote host> is the hostname/IP address of the remote resources you’re looking to get at
  • <remote port> is similarly the associated port of those remote resources
  • <user>@<ssh server> finally, this is the machine you have ssh access to, which must also have access to the remote resources you are targeting (note, they CAN be the same machine, and in my cases most often are)

So there’s quite a number of pieces here, so let’s tie it in with the example, say your remote database is at 192.168.1.5:3306, you also have ssh access to it with your user name ‘bob‘ and your application is set up to use a database at localhost:9876.  In this case, your command would be:

ssh -L localhost:9876:192.168.1.5:3306 bob@192.168.1.5

After a successful connection, any data sent to localhost:9876 will be sent through the tunnel to 192.168.1.5:3306, and vice versa.  Note that the remote IP and port are evaluated on the ssh server’s side, so since the ssh server and database server are one in the same, this is also a valid command:

ssh -L localhost:9876:localhost:3306 bob@192.168.1.5

which is where most of my confusion with this syntax comes from… Another great use case for this may help you to remember the nuance.  In this case the remote resource we want to get at is a website, say cnn.com, port 80.  Most likely you don’t have ssh access to cnn.com, so you’ll remember that you have to put cnn.com:80 for the remote information and the ssh server separately, as seen here:

ssh -L localhost:9987:cnn.com:80 bob@192.168.1.5

By navigating to http://localhost:9987, you should see the same information as http://cnn.com.  Note however, that with increased use of CDNs and distributed server environments, you may have trouble accessing certain sites if they see that there’s some discrepancy with the requests, YMMV.

2. I have it here, but I want it to be remote

Remote port forwarding is the killer accessory for my toolchain that I mentioned earlier.  And similar to its name, it does the opposite of local port forwarding.  In this case, you have a resource locally that you would like to make available remotely.  In my case, it’s usually a prototype of a webapp function that I’m messing around with.  I want to show it off to some people and get some feedback, but the team isn’t co-located, so walking around with my laptop is a no-go.  Instead, I can set up a remote port forward to a development machine, send them a link, and they can view it right on my machine.  This way neither of us need to mess with firewall settings, and there’s no need for any special deployments or the time that comes with them.  For remote forwarding, the syntax is as follows:

ssh -R <local host>:<local port>:<remote host>:<remote port> <user>@<ssh server>

As you can see, most of the syntax remains the same, except now there’s a -R to indicate remote port forwarding, the local fields designate the resource you’re accessing, and the remote fields are where others will access the resource.

An important difference here is that by default, the ssh server config doesn’t allow a user to “bind” to interfaces except the loopback address, so you can set everything up correctly and no one will be able to see it.  To get around this, you should specify GatewayPorts yes in the ssh server configuration and restart the ssh server program (my suggestion would be to set this up under a MatchUser section so that this functionality is only available to specified ids).

So once you’ve made that change, say you had a demo site you wanted to show to a client to get some feedback about color shades.  You have the site running locally at localhost:9080 and also have a server at colordemo.com, and you want to make the demo available on port 9090, your command would resemble the following:

ssh -R localhost:9080:colordemo.com:9090 bob@colordemo.com

Now your client can access the demo on your machine by going to colordemo.com:9090, and when they ask you to tweak a couple hex values, you can make those changes, ask them to refresh, and they’ll see it.  They can get instant feedback, and you can keep using your favorite editor to make changes, and no need to wait for a build/deploy.

3. A SOCKS Proxy

The final kind of port forwarding is a dynamic forward. This allows requests to be made by the client, but forwarded to the server who then resolves the requests, returning the information via the secure tunnel.  This allows for things like an impromptu SOCKS proxy, and admittedly I’m not sure what else.  I don’t have much experience with these, so rather than guess, I’ll leave it to you to search out a more informative search for those.

Final Thoughts

So that’s a not so short and sweet low-down on SSH port forwards, but hopefully some of the additional details helps you to understand and remember the syntax for each version.  If this sort of thing interests you, I really recommend getting acquainted with SSH in general, including how to utilize the “escape character” to kill frozen sessions, add in port forwards on the fly, and a couple other useful tricks.  Then there’s fun stuff you can do such as modify the message users see when they SSH into a machine (may I recommend including some ascii art?) which helps keep things fun when you’re in a mostly text world of the terminal.  And finally, if videos are more your thing, there’s a great video that details port forwarding and a WHOLE lot more about ssh called “The Black Magic Of SSH / SSH Can Do That?” which can be found on Vimeo. Thanks!

Emacs on Android, because why not?

Chris Weber

For those of you familiar with a terminal, whether it be from back in the MS-DOS days, because you need to manage some headless machines for a job, or you just like to toy around with Linux, I would hope you’ve heard of Emacs.  For those of you who don’t (or are die-hard vi fans), it’s a pretty impressive piece of software which some say can almost replace your entire operating system due to its already large feature set and extensibility.  Personally the feature I find the most useful (and also confusing to learn) is the “kill-ring” which allows you to keep multiple text snippets for pasting at once (in Emacs this is called “”).  However, great as Emacs is, it can’t really compete with today’s tasks of rich-text email, Instagram photos, Google Drive and other cloud storage, etc.  But just like there will always be a place for the command line, I’m sure Emacs will continue to live on as an older, but still effective application for some specific purposes.  So if that’s the case, then why not install it on your phone?  While the use may be questionable, the difficulty level is low, and the fun & educational factors should outweigh it.

So here’s what we’ll need:

TerminalIDE is an app which I’ve always had some mixed feelings about.  It hasn’t seen development in awhile, but luckily works well for our purposes right now.  What sets it apart from some other terminal applications is that the Unix applications have all been recompiled to work locally within the app, thus it works even on phones that are not rooted.  The flip side of this is that the app is quite large in size (so if you’re limited on space you might have to pass this one by) and the native applications within TerminalIDE are not able to do DNS resolution, so any network activity must use IP addresses (or be preceded by a call to jping to get the IP).

For anyone clever enough to notice that there’s an Emacs app for Android, I’m sure you’ll also notice how ineffective/buggy it is, thus the reason for this post.

The data files are the same ones used by the Emacs Android app, but independent of the less-than-useful terminal emulator.  By joining the two, we can create a functional instance of Emacs to fool around with.

First, start by installing TerminalIDE and placing the Emacs files in an accessible location on your device.  If you know where the home folder within TerminalIDE is, and you can place them there then that’s great, otherwise, the Downloads folder works just as well (yes if you wanted you could do this whole process from just your phone).

Issue the following commands to decompress the Emacs binary and make it executable:

unlzma emacs.lzma
chmod 755 emacs

Next we need to create the directory for Emacs to work in.  For our purposes (and in being consistent with Android applications) this will be an ’emacs’ directory placed within ‘sdcard’:

mkdir sdcard/emacs

Now we must move the other downloaded files to this new directory and extract them:

mv etc.tlzma sdcard/emacs/etc.tar.lzma
mv lisp.tlzma sdcard/emacs/lisp.tar.lzma
cd sdcard/emacs
unlzma etc.tar.lzma
unlzma lisp.tar.lzma
tar xvf etc.tar
tar xvf lisp.tar
rm etc.tar
rm lisp.tar

At this point Emacs should be ready to go, this can be checked by going back to your home directory and executing it:

cd
./emacs

And that’s it!  If Emacs fails to load, it could be because there seems to be a minimum screen width.  On my Moto X (2014) loading in landscape worked (with about 4 usable lines in the editor) but portrait would not work until reducing the text size in the TerminalIDE options.

Usability?

So here’s the question: is it really usable?  Well you definitely need a full-featured keyboard.  This can be accomplished in at least three ways:

  • Install a third-party keyboard such as Hacker’s Keyboard
  • Attach an external keyboard via USB OTG or Bluetooth
  • Use telnet or ssh to access it from another machine with a full keyboard (details available within the TerminalIDE app)

After fiddling with the first option, I can say that it does indeed work, but I wouldn’t call it efficient or particularly enjoyable (except for when I played a decent game of Emacs Tetris!).  I think this option would be nice to have in your back pocket (or front pocket, or purse, wherever you keep your device) just in case you absolutely need to use Emacs at the drop of a hat.  The second option is a bit more enticing, it allows you to type like you normally would, leaving only the tiny screen to stand in your way of ultimate Emacs exploitation.  For this I wonder if utilizing screen mirroring via Miracast or Chromecast would make for a decent setup (somewhat reminds me of the “Could companies issue only one device and have it do everything?” question raised by the Ubuntu Phone).  As far as the last option goes, at that point I don’t see the use.  If you have another machine with a full-keyboard then why aren’t you just using Emacs on that (I’m sure someone playing devil’s advocate could come up with something…)?

So is it usable? Yes, but there’s a reason GUIs were invented and screens became touch-enabled, and I think that for most of us, embracing these things will allow for a much more pleasant experience.  However, there will always be a place for terminals and robust applications to run on them, and here’s just one example of how you can keep one within arm’s reach, for whatever you dream up.

Screenshot_2014-11-11-18-29-41Productivity at its finest

UPDATE: With the release of Android 5.0 “Lollipop” the need for Android executables to be Position Independent (PIE) is enforced. As such, the method outlined above will no longer work. In addition, a bug in TerminalIDE causes it to crash when the Google Keyboard is toggled, this behavior is not exhibited using Hackers keyboard or the built in TerminalIDE keyboard, however there doesn’t seem to be any active development on either projects at this time.

Special thanks to David Megginson for the instructions that inspired this post, and for all the people who have contributed to the development and use of GNU Emacs.