If you’ve ever profiled code in Python, you’ve probably used the
cProfile module. While the cProfile module is quite powerful, I find it
involves a lot of boilerplate code to get it setup and configured before
you can get useful information out of it. Being a fan of the KISS
principle, I want an easy and unobtrusive way to profile my code. Thus, I find
myself using the line_profiler module due to it’s simplicity and superior
I’m a big fan of tools that are simple to use, yet powerful in nature. Being
both efficient and productive are important qualities in my daily workflow, so
check out the article to learn more!
So you just thought of the next killer Hubot script and you want to share
it with the world? Well if you haven’t been paying attention, you should know
that the hubot-scripts community has changed their contributing policy:
It’s now preferred that if you are able to, you should release your script as
part of a npm package built for Hubot.
And it’s a good change, because this now allows scripts to be distributed and
versioned as individual NPM packages. This also means that individual scripts
can easily declare dependencies, which is a big improvement.
If you’re familiar with the process for creating a NPM package, then
you’re off to a good start. We’re going to be using yeoman and the
generator-hubot-script to generate all the boilerplate necessary for
quickly creating a NPM package for our Hubot script.
NOTE: The generated boilerplate is based on the hubot-example repository.
Now let’s ago head and install yeoman and the generator-hubot-script using
$ npm install -g yo generator-hubot-script
Secondly, let’s go ahead and create a directory for our script. For the sake of
this example, we’re gonna assume we created a script called
foobar.coffee, so we want to appropriately namespace our package with
the name hubot-foobar:
$ mkdir hubot-foobar
$ cd hubot-foobar
$ yo hubot-script:foobar
Follow the prompts and wait until the NPM install completes. Now let’s
initialize the directory as a Git repository and commit our initial files:
After recently attending Velocity in NYC, I started to think more about why
performance always seems to be an afterthought with developers. As I pondered
this thought, I kept coming back to the following question:
How hard is it to get a perfect PageSpeed Insights score?
If you’d like to know the answer, then head on over to the Appneta Blog and
checkout the new blog post I wrote where I explore this topic in more detail.
I recently wrote a blog post on the Appneta Blog about client side latency
for users on the web.
So while the effects of poor performance is obvious, it makes one wonder about the relationship between client latency and the “perception of speed”. After all, the user can trigger many state change events (page load, submit a form, interact with a visualization, etc) and all these events have an associated latency to the client. However, are certain types of latency more noticable to the user then others?
This is an area that web developers need to think about closely, and it’s
important because it could have an impact on your user engagement and user
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 firstname.lastname@example.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:
#!/bin/shecho'Deploying to Production...'GIT_WORK_TREE=/www/myblog.com git checkout -f
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://email@example.com/~/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...
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.
Although there are many unique characteristics for each software development methodology, one thing is consistent: the goal of progress. Everyone wants to know how a particular project or task is coming along and when it’s going to be complete. So even if you don’t believe in due dates and delivering to a schedule, it’s still useful to know and to be able to communicate your current progress to others .
To aid us on our never-ending quest to know just how awesome we really are, we’ve developed Burndown, an open source tool to assist in tracking progress of a Github milestone!
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:
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!
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.
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.
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:
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.