Heroku is quite the interesting topic these days. While there are many strong opinions about the platform itself, I feel the one thing they get right is deployment.
$ git push heroku master
That’s it. Dead simple.
Now there really isn’t any magic behind this, as Heroku harnesses the power of Git hooks. To mimic this behavior, you can use a post-receive hook, which is just a bash script that runs after the entire process is completed and can be used to update other services or notify users. The beauty is that this functionality can easily be replicated for deploying any of your sites.
For this example, let’s keep it simple and deploy a static blog to a single web server.
First order of business is to make sure you can easily SSH onto your server. So if you haven’t already, make sure your SSH public key is copied to your server:
[dan@local] $ ssh-copy-id username@server.org
Now, on your server, we want to create a bare Git repository. This will be the destination repository for when you perform a git push for deployment:
[dan@server] $ cd ~/git [dan@server] $ mkdir myblog.git [dan@server] $ cd myblog.git [dan@server] $ git init --bare
Next thing to do is setup our simple post-receive script. Let’s assume for the sake of this example that our blog is served on our web server from the following directory: /www/myblog.com. First create the hook in your git repository:
[dan@server] $ touch ~/git/myblog.git/.git/hooks/post-receieve
Then update the post-receive hook:
#!/bin/sh echo 'Deploying to Production...' GIT_WORK_TREE=/www/myblog.com git checkout -f echo 'Success!'
Ok, so here is where the magic happens. The GIT_WORK_TREE environment variable is used as a destination for your checked out source code, with any changes you might have made. Thus, we are performing a force checkout to the working tree directory (aka deployment)!
NOTE: One side benefit of the working tree approach is that you do not accidentally serve your .git directory!
Now that we have a new remote repository, let’s go ahead and add it to our local git repository:
[dan@local] $ git remote add production ssh://username@remote-server.org/~/git/myblog.git
The last thing left now is to deploy:
[dan@local] $ git push production master Counting objects: 9, done. Delta compression using up to 2 threads. Compressing objects: 100% (5/5), done. Writing objects: 100% (5/5), 455 bytes, done. Total 5 (delta 3), reused 0 (delta 0) remote: Deploying to Production... remote: Success! To ssh://username@remote-server.org/~/git/myblog.git 52056c4..1b5c293 master -> master
Now this is a very simple example of a deployment script. Feel free to get as crazy as you want…send emails, message chat rooms, call fabric tasks, etc! The sky is the limit, so get as creative as you’d like.
Feel free to fork my Gist to get yourself started!
I like to listen to records. I also like to listen to my records when I code. So recently, I said to myself, “How can I easily pipe audio between rooms in my house using my network and open source software?” The answer: FFmpeg!
For the unfamiliar, FFmpeg is a complete, cross-platform solution to record, convert and stream audio and video. If you have a task that falls into any of those categories, FFmpeg can do it like no other!
So without derailing this post and rambling on about my audio setup at home, all you have to know is I have a line level audio source plugged into the sound card’s Line In on one computer and I want to pipe that audio to any other computer in my house. So conceptually:
[Line Level Audio Source]---->[Computer A]====(Home Network)====>[Computer B]
Still with me? Ok good! The first thing I want to do is figure out what audio inputs FFmpeg can see:
Computer A:
ffmpeg.exe -list_devices true -f dshow -i dummy
Output:
D:\apps>ffmpeg.exe -list_devices true -f dshow -i dummy ffmpeg version N-44818-g13f0cd6 Copyright (c) 2000-2012 the FFmpeg developers built on Sep 27 2012 19:30:20 with gcc 4.7.1 (GCC) configuration: --enable-gpl --enable-version3 --disable-pthreads --enable-runtime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libass --enable-libcelt --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --enable-libmp3lame --enable-libnut --enable-libopenjpeg --enable-librtmp --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libutvideo --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enable-libxvid --enable-zlib libavutil 51. 73.101 / 51. 73.101 libavcodec 54. 59.100 / 54. 59.100 libavformat 54. 29.104 / 54. 29.104 libavdevice 54. 2.101 / 54. 2.101 libavfilter 3. 17.100 / 3. 17.100 libswscale 2. 1.101 / 2. 1.101 libswresample 0. 15.100 / 0. 15.100 libpostproc 52. 0.100 / 52. 0.100 [dshow @ 01ffc400] DirectShow video devices [dshow @ 01ffc400] "Rocketfish HD Webcam" [dshow @ 01ffc400] DirectShow audio devices [dshow @ 01ffc400] "Microphone (Rocketfish HD Webca" [dshow @ 01ffc400] "Digital Audio (S/PDIF) (High De" [dshow @ 01ffc400] "Line In (High Definition Audio " dummy: Immediate exit requested
And bingo! The second to last line is just what we want, so keep note of this!
[dshow @ 01ffc400] "Line In (High Definition Audio "
For this example, let’s assume Computer B’s IP address is 192.168.1.17, which is our streaming destination. So hit play on your audio source and fire off the following to begin streaming:
Computer A:
ffmpeg -f dshow -i audio="Line In (High Definition Audio " -acodec libmp3lame -ab 320000 -f rtp rtp://192.168.1.17:1234
Now, just set Computer B listening for audio:
Computer B:
ffplay 192.168.1.17:1234
BOOM! Point to point audio streaming using the power of FFmpeg in your own home!
References:
So you want to authenticate users using the Github API on your next Ruby and Rails project? Using Omniauth this is very easy to accomplish, however I set out to make it even easier by building a Rails skeleton for just this task!
First thing you want to do is create a new application on Github!
Set your Main and Callback URL accordingly! If you’re only doing local development for now, then you should be all set using both example URLs.
Now that your Github application is created, we need set some environment variables for the Client ID and Client Secret. You can do this on the command line or place both these values in your ~/.bashrc file.
$ export GITHUB_KEY="c6e53fab550fd8aa1523" $ export GITHUB_SECRET="a651c99cb4de311795f924a3209984f1d27628e0"
Now we need to clone the project from Github and get it up and running!
$ git clone git@github.com:notfunk/rails-github-skeleton.git $ cd rails-github-skeleton $ bundle install $ rake db:migrate $ rails s
Now just visit http://127.0.0.1:3000 in your browser and sign in! Happy hacking.
Django leverages Python’s ability to use decorators extensively. Decorators in Python are defined as:
A Python decorator is a specific change to the Python syntax that allows us to more conveniently alter functions and methods.
In layman’s terms, decorators allow us to dynamically alter functions without having to actually change the function itself. Sounds pretty neat? Well, you can read more about Python Decorators here and here.
The most common use of a decorator is the infamous login_required. This decorator is used in conjunction with a view that restricts access to authenticated users only.
from django.contrib.auth.decorators import login_required
from django.shortcuts import render
@login_required
def my_view(request):
return render(request, 'template.html')
This decorator is very useful, because I don’t have to actually change anything about my view to restrict access to it. However, what if you want to restrict a view to only authenticated users who are currently active? This can easily be accomplished with a custom decorator:
Thanks to the user_passes_test decorator that comes with Django, we can chain this together with the login_required to create our custom decorator.
To break it down further, we pass an anonymous function into the user_passes_test decorator that returns the value of is_active, which is a boolean that designates if the user is active. Next we set the login_url parameter, which will redirect to this URL if the user is not active. For further reference, check out the actual source for user_passes_test.
Now we just update our view to incorporate our new, reusable decorator.py package and decorator.
from django.shortcuts import render
from myapp.decorators import active_and_login_required
@active_and_login_required
def my_view(request):
return render(request, 'template.html')
If you are unfamiliar with HipChat, its a persistent chat room used for team collaboration. With its abundance of features, one that stands out is the ability to utilize the HipChat API to send notifications messages to your team rooms. Notifications are great for letting everyone on your team know an event of significance has occurred. Examples include commits to your source code repository, continuous integration results, or when an extremely angry user adds a new issue to the bug tracker.
While many web based services offer hooks to make sending notification message to HipChat easy (such as Github), what if you want to send a notification from an existing Bash script that you use everyday? Well you’re in luck, because the HipChat API makes this extremely easy to do using cURL!
NOTE: If you haven’t generated a HipChat API Token yet, learn to do so here.
NOTE: Make sure to change the parameters to fit your application and insert your authentication token!
HipChat API notification messages have some neat features, such as colors and notify. This makes it easy making it easy to instantly indicate to your team via HipChat if something erroneous has occurred (such as failed unit tests).
Be sure to check out the full HipChat API documentation for sending messages to rooms.
I’ve always had a fascination with Vim. For the unfamiliar, Vim is a text editor that disowns the mouse and challenges the user to put those 8th grade typing classes to good use. That’s right folks, you are now doing life on home row!
My fascination with Vim started back in college during my experimentation days. You know what I’m talking about. The long, carefree nights, trying anything put on the table, and always looking for the next, better distribution.
Wait. Distribution? I’m talking about experimenting with Linux! What did you think I was talking about?
Oops. Now that we’ve cleared that up, lets move on…
At this time, it was impossible for me to avoid command line editing, so it was necessary to learn the absolute, minimum basics of Vim to get by. This meant learning how to insert a change, save the file, and quit. However, I always did things the wrong way, like using the arrows keys for navigation. I know many of you just shuddered at the thought of inefficient cursor movement, but you have to understand where I (and most likely you) come from.
In the beginning, Vim felt completely foreign to me and understandably so. All my life, I’ve used a computer with a mouse. From accidentally deleting Notepad on Windows 3.1 (Oops!) to playing Quake 3 on Windows ME, a mouse has always been firmly in my grip. Thus, when I began my foray into the world of ones and zeros, I naturally gravitated towards text editors designed to be used with a keyboard and a mouse. Forgive me father, for I have sinned.
Even through all this, I never felt the desire to use Vim as my full time text editor. The challenge and associated fears of relearning a skill (editing text) that you’ve done one way for years can be a bit daunting. Moving from Notepad++ to TextMate isn’t a big deal, because your proficiency can translate easily between “modeless” text editors. However, this all gets thrown out the window once you step in the Vim world. Don’t be afraid children, it’s well worth it.
I felt that if I really wanted to learn Vim, I would have to go all in. This meant only using Vim both at home and at work. However, the latter would be a challenge for several reasons.
I work in a development environment that is difficult to change. To paint a picture, the majority of my development at work happens on a Windows box that is on an air gapped network. To top it off, I do not have administrative rights and it is against the rules for me to put or install any unauthorized software on my machine. So this means that I am basically stuck with whatever software is installed on my machine when it was given to me. Furthermore, the default and recommended text editor for my software team was Edit Plus. While these security restrictions are unavoidable when working for a DoD contractor, it can be extremely frustrating.
All hope was not lost. A few weeks ago, I finally decided it was time to jump into the deep end with Vim after being blown away by the devastating power of Vim demonstrated at Destroy All Software. With a little charm, patience, and just plain old asking nicely, I was able to get my system administrator to install Vim & gVim on my machine. Guess it pays being on the good side of your IT folks?
Now that the stage was finally set, it was time for me to actually get my hands dirty and learn Vim!
In my quest to understand the Vim way, I searched far and wide on the vast plains of the internet. Below are some of the most useful resources that I utilized:
- Vim Tutorial Videos – From novice to advanced, Derek Wyatt has produced a fantastic set of videos to learn Vim. This is my recommended starting point. Watching all the novice videos really helped me dive into Vim and get a strong, fundamental understand of the basics.
- Vimtutor – Vim ships with its own tutorial called Vimtutor. Vimtutor is essentially just a text file that opens in Vim and instructs you on Vim basics. However, it is useful because it forces you to use Vim to complete the tutorial and enables you to apply the knowledge from Derek’s videos. It is a solid and easy way to start getting hands on experience, which is key to learning Vim. I recommend this as a second step and takes roughly an hour to complete.
For further learning of Vim and it’s advanced features, I use the following resources on a daily basis:
- Vim Wiki – The name is pretty self explanatory, so stop wasting time and start reading!
- Stack Overflow – If you don’t know what Stack Overflow is, then you’ve been living under a rock. Its crowd sourced, question and answering done right. A ton of Vim questions have already been answered, so make sure you search first!
- My Vim Config – I used Derek Wyatt’s Vim Config as a starting baseline and customized it to my likings. Not going to lie, its pretty sexy.
Recommended:
The Twitter API utilizes a 3-legged OAuth authentication process where an authenticated Twitter user can authorize a Twitter-based application to interact with their account and data. This is useful for applications that desire this ability, however what about a Twitter application that doesn’t care about other users and just wants to get down and dirty with public Twitter data? Thankfully the Twitter API provides a relatively easy way to do this!
NOTE: This guide assumes you are already familiar with the Twitter Developers page and have already registered an application. If you are unfamiliar with either of these concepts, its time to do some reading! If you are unsure what type of authentication process is correct for your application, head on over to the Obtaining Access Tokens article.
If you haven’t already generated access tokens for your application, follow this guide. Now that you have your access tokens, we can get cooking!
Grab the latest version of the python-oauth2 library. If you’re using another language, there might be an OAuth2 library available here.
$ git clone https://github.com/brosner/python-oauth2.git |
Next, we’re gonna create a new python script called twitter.py.
Replace the following with your Twitter application OAuth values:
- YOUR_CONSUMER_KEY
- YOUR_CONSUMER_SECRET
- YOUR_ACCESS_TOKEN
- YOUR_ACCESS_TOKEN_SECRET
Now run the script and you should get the following output:
$ ./twitter.py Hourly => 350 Remaining => 350 |
If you got 350 for your hourly limit, then you’ve successfully authenticated using OAuth (150 is the hourly limit for unauthenticated API requests)!
Now just replace the rate_limit_url string with another Twitter Resource API URI and have fun!
UPDATE (02/08/2013): Facebook has deprecated the offline_access token, so this method no longer works! See this post on Stack Overflow to learn how to extend an access token to 60 days.
I’ve been working on a few scripts that performed some minor data collection using the Facebook Graph API as a data source. Ideally, I wanted this script to be able to run several times a day automatically, however Facebook grants access tokens that expire after 1-2 hours. Since I’m the only one that is going to run this script, I only needed access to my Facebook data and I didn’t want to have to re-authenticate every few hours. Luckily, Facebook provides a permission parameter to get a “long-lived” access token from Oauth called offline_access!
NOTE: If you’re unfamiliar with the Facebook API authentication process, I suggest you brush up before continuing!
Below is an example of the permission parameter you would pass to the Oauth dialog to let Facebook know you don’t want some wimpy access token, but one that will last much longer!
https://www.facebook.com/dialog/oauth?
client_id=YOUR_APP_ID&redirect_uri=YOUR_URL&scope=offline_access
Then just follow the rest of the Facebook authentication process normally and you should be set!
From the Facebook Permissions Reference:
offline_access – Enables your app to perform authorized requests on behalf of the user at any time. By default, most access tokens expire after a short time period to ensure applications only make requests on behalf of the user when the are actively using the application. This permission makes the access token returned by our OAuth endpoint long-lived.
However, if you’re feeling extra lazy, you could always generate an offline_access access token using the Graph API Explorer!
- Head on over to the Graph API Explorer
- Click the Get Access Token button
- Select the Extended Permissions tab
- Check the offline_access box
- Click the Get Access Token button!
Now just grab your newly generated access token and get to work!
I recently upgraded one of my laptops to Ubuntu 11.04 “Natty Narwhal” and I have had the pleasure opportunity to explore the new Unity user interface for GNOME. Immediately I was annoyed when I noticed that my keyboard shortcuts for switching workspaces (ALT+F1, ALT+F2, etc) were defaulted to several dedicated commands in the Unity shell. This was frustrating because the standard GNOME Keyboard Shortcuts were overlapping with these Unity based commands. So after a bit of digging on on the intertubes, here is how you can disable the ‘Run A Command (ALT+F2)’ in the Unity shell:
On a command line:
$ sudo apt-get install compizconfig-settings-manager $ ccsm & |
- Select ‘Category > Desktop > Ubuntu Unity Plugin’
- On the ‘Behavior’ tab, click the button to the right of the “Key to execute a command” text.
- Uncheck the ‘Enabled’ checkbox and click the ‘Ok’ button.
Batman relied heavy on his tool belt whenever he was in a pinch. So should you! Below is a list of some tools that I’ve found very useful when working on projects:
- toggl – Time tracking that works. Free and paid options available.
- Bitnami – Wide array of development stacks (think LAMP/WAMP) that are a cinch to deploy and allow you to get to work quickly.
- Smuxi – Irssi inspired, open source, GNOME-based, cross platform IRC client. Loving it.
- Geany – Linux text editor that is GTK2 based and offers basic features of an integrated development environment. Lightweight, tons of features, and clean.
- Rublar – a Ruby regular expression editor. Great for building and testing regular expressions.
Enjoy!
