Kyle Slattery - Entries

Requiring SSL Using Route Constraints in Rails 3

Fri, 13 Aug 2010 13:31:00 -0400

The new router in Rails 3 makes it super easy to require SSL for certain routes. Just use the following in your config/routes.rb:

MyApp::Application.routes.draw do
  class SslConstraint
    def self.matches?(request)
      request.ssl?
    end
  end

  scope :constraints => SslConstraint do
    resources :payments
    # Other SSL routes go in here
  end
end

Now, this is a pretty simple example–you’ll likely want to also have routes to redirect if a user tries to access without SSL, but it definitely shows off the power of the new router.

Using Git Branches as Patches

Thu, 06 May 2010 00:29:00 -0400

At Viddler, we’re now using Git for projects, and it’s going really well so far. While we haven’t figured out the perfect workflow just yet, we’re doing some things I really like, and one of them is treating branches like patches.

Often, people think of Git branches as a full copy of the parent branch, but it’s better to treat them as a simple collection of new commits, to be applied to the parent branch later. This might not seem too revolutionary, but this small change in thinking can really improve your workflow.

For example, at Viddler we use Trac to manage tickets, and in Git. For each ticket in Trac, we create a branch, called something like 3241-fix-embed-codes. We have two permanent branches: dev, which reflects current development, and master, which is considered always production-ready. So, dev and master are going to have different code to reflect their reflective stability. To get started with a fix, we first create a feature branch from master:

git checkout -b 3241-fix-embed-codes master

This simply creates a new branch of master called 3241-fix-embed-codes and checks it out. When the ticket is completed and the code has been committed, the patch thinking really comes into play. Since this now needs to be tested in the dev environment, the branch first gets applied to the dev branch:

git checkout dev
git merge —no-ff 3241-fix-embed-codes

Using the —no-ff option on git merge is important for this patch mindset: it creates a separate commit for the merge itself, which allows you to git revert the entire thing (if necessary), rather than having to undo each individual commit within it.

Once we’ve decided this fix is read for production, it’s time to move the code over to master. Without the patch mindset, you might consider merging dev into master, but that means you’d be copying anything that’s applied to dev, some of which might not yet be ready. When you think of your feature branch as a patch, however, it’s easy to only apply the one you need. To apply this patch to master, just use a similar method as before:

git checkout master
git merge &#45;-no-ff 3241-fix-embed-codes

Now you’ve only moved the safe commits over, leaving any buggy code safely in dev.

This method may seem obvious, but the mindset has really changed the way I use Git, and I think it makes it a much more powerful tool, especially when you’re working across multiple environments (like production and staging). I’ve skipped over some additional considerations, like merging master/dev into your feature branch, but those are topics for a future post.

Introducing node-xml2object

Wed, 10 Feb 2010 21:47:00 -0500

Recently, I’ve been playing around with node.js, because, well, it’s really, really cool. I found myself wanting to parse XML into a Javascript object, but I couldn’t find any existing modules that did what I needed. So, I went ahead and made my own, node-xml2object. It’s dead simple to use, and I hope others find it as useful as I have. For example, imagine you have some XML like this:

<root>
  <videos total="2">
    <video id="1" length="20">
      <title>Video 1</title>
    </video>
    <video>
      <title>Video 2</title>
    </video>
  </videos>
</root>

Here’s how you would access it as an object, assuming the XML is stored in the variable xml:

var sys        = require('sys'),
    xml2object = require('./xml2object');

var response   = xml2object.parseString(xml);

response.addCallback(function(obj) {

  // To output a simple value, just use as an object
  // Since there are 2 video elements under <videos>, it's stored as an array
  sys.puts(obj.root.videos.video[1].title) // outputs "Video 2"

  // attr(key) returns the value for attribute with name "key"
  sys.puts(obj.root.videos.attr("total")) // outputs "2"

  // attrs() returns an object of all attributes
  sys.puts(obj.root.videos.video[0].attrs().id); // outputs "1"
});

Node-xml2object depends on the node-xml module, and the tests use ntest. Right now, I’m embedding them as Git submodules, but I’m planning on changing that in the near future, since it’s pretty messy this way. The source code is licensed under the MIT license, so feel free to use it however you’d like. I’m pretty happy with where it’s at now, but if anyone would like to fork it and improve things, go for it!

iPad Keyboard Fragmentation

Thu, 28 Jan 2010 23:54:00 -0500

As usual, I enjoyed reading John Gruber’s musings on the iPad. I was intrigued most, however, by his thoughts on the iPad’s support for hardware keyboards:

Having used the hardware keyboard yesterday, though, it is clearly a secondary form of input. You cannot even vaguely drive the iPad interface by keyboard alone. […] There are some glaring holes. For example, in iPad Mail, when you start typing in the To: field to address a message, and the iPhone-style autocomplete suggestion list appears under the field, you cannot select from it using the keyboard. You have to touch the screen. […] It just seems like it’s not finished yet.

What struck me as interesting is how similar this is to Android development’s biggest drawback: hardware fragmentation. Due to the vast array of Android devices, app developers have to consciously design their apps to support several different input methods. This may seem fairly trivial, but it is actually a fairly significant problem, especially for games and more complex UIs. In the Android Market, some games and applications just don’t work without a hardware keyboard, likely because the app developer didn’t take the time to consider touchscreen input. Apple seems to now be encountering this problem as well.

Maybe John’s right, and this is a rough edge that will be smoothed over when the device launches. But, there’s more to it than just fixing iPad Mail. What about the 140,000 apps in the App Store? They certainly weren’t built with any considerations of keyboard navigation, so the experience is likely to be sub-par, unless the developer has taken the time to support an input method that he or she might not even have access to (assuming he or she doesn’t own an iPad).

If keyboard support is solely intended for text input, as John suggests, a lot of users will be confused. Standard operations, such as tabbing between fields and navigating via arrow keys, are expected behavior when a user is given a keyboard. It would be frustrating to have that taken away. Certainly, Apple could fix this issue by the time the iPad hits the market, but for a platform that preaches ease-of-development due to the uniformity of its hardware, it’ll be interesting to see how it’s handled.

Three Weeks with Swype

Fri, 15 Jan 2010 21:26:00 -0500

Roughly three weeks ago, I stumbled across the Swype for Android preview. My first impressions were very positive, and over the last three weeks, I’ve been using Swype exclusively on my Droid. If you’re not familiar with Swype, it’s a new method of typing on a touchscreen device, from the inventor of T9. Instead of tapping out each letter, you just drag your finger across the keyboard, hitting each of the letters in the word in sequence. I recorded a short video showing its basic features:

What I Liked

What really surprised me about Swype was how quickly I was able to get the hang of it. When I watched demo videos, it seemed like it was overly-complicated, but once I used it myself, I couldn’t believe how simple it was. For some of the less intuitive features (such as capitalization, which requires you swipe above the keyboard), I had to run through the built-in tutorial, but after that, I could swipe very easily. One big perk with Swype is that it’s actually pretty easy to use without looking, once you get the hang of it. I found that I could type reasonably well without ever looking at my fingers, something I would have no chance of doing with the standard keyboard.

Drawbacks

My biggest gripe with Swype is it’s just nowhere near as polished as the built-in keyboard. For starters, it’s much more difficult to access symbols, and numbers are laid out pretty strangely. Also, there’s a complete lack on auto-completion for text fields that support it. For instance, if you’re typing the name of a contact in landscape view, the regular Android keyboard will have suggestions below the field that will allow you to select the person without typing their whole name. Swype does not seem to support this at all, which is really pretty annoying. In addition, it’s difficult to type out words normally, if they do not exist in the Swype dictionary. When tapping out letters, Swype tends to interpret your taps as swipes, adding unnecessary spaces between letters. Once you type an unknown word the first time, however, you never have to do it again, because it gets added to the dictionary, which is pretty nice.

In addition, I’ve found that the sensitivity of the keyboard can be a little strange when swiping quickly. Many times, it won’t recognize that you’ve stopped a word and started a new one (which is indicated by lifting your finger up), so it won’t recognize what you’re trying to input at all. In the options panel, there are ways to adjust the sensitivity, but I’d rather these settings were hidden away from users, because it seems like a bit of a cop-out. Swype should instead learn how you type, adjusting its algorithm as necessary.

Conclusions

While there certainly are some issues with the Swype build I used for this review, pretty much all of problems are fixable, and I’m excited to see what the final version turns out to be. They’ve got a really great concept that, with tweaking, could become the best way to input text on a touchscreen mobile device, especially for those who aren’t very adept with traditional on-screen keyboards. I’m not sure what Swype’s strategy is going be with regards to pricing: whether it will be a free app, or if you’ll have to pay for it. Personally, if they’re able to fix my issues above, I would be happy to pay $5-6 for it, and maybe even more, because it really is quite incredible. Even if you can type well with the standard keyboard, definitely give Swype a try.

A Geotagged Vacation

Sat, 09 Jan 2010 10:44:00 -0500

Over the holidays, my family and I took a three-day trip to Chicago, and because I had left my charger for my Canon Powershot G9 at home, I was stuck taking pictures with my Droid’s built-in camera. I thought it would turn out to be a disappointing endeavor, but it actually got me really excited about the future of internet connected cameras.

My least favorite part of photography has always been all of the work afterwards to get it online. I have to take out the SD card, copy the files to my computer, edit them, and then post them to Flickr. When I was taking photos with my Droid in Chicago, I loved how easy it was to instantly post photos online. Using Twidroid, I was able to easily upload photos to yFrog, tweet the link, and have it all geotagged, almost instantly. It allowed me to share what I was doing with my friends as I was doing it, something I could never do with my G9.

The quality of the photos certainly isn’t anywhere near what I could accomplish with a better camera, but that really didn’t bother me too much. As the quality of phone cameras improves, this will become less and less of an issue. Since I had a limited amount of time in the city, I was more concerned with sharing snapshots of where I was (like at the “Bean”) than with creating works of art. On a longer trip, where I have the ability to take my time and set up shots, I’m sure I would want to have a nicer camera along, but for a quick 2.5-day trip to Chicago, my phone worked pretty well.

There are certainly areas where this method of taking photos could improve, however. Like I said before, the quality of the camera is a drawback, but it was one I was willing to accept. Beyond that, I was a little disappointed by the geotagging abilities of Twidroid. If I took a picture of something inside (like the Apollo 8 command module, cool!), the coordinates would be way off, since it couldn’t get a good GPS signal. I would have preferred to be able to pick the Museum of Science and Industry as my location, rather than relying on what the GPS picked out for me. This is something that appears it would be relatively simple to fix. The Google Maps 4 Twidroid source code is available online, so I might try and update it myself to use places (using Google’s local search API or something similar), or at the very least it could allow you to check back into a previous location. I am also hoping Twitter releases more features related to geotagging on their site. Right now, coordinates are only visible through the API, so unless you’re viewing my tweets in a geo-enabled Twitter client, you won’t see my location.

I certainly could use a service such as Brightkite to fix some of the issues above, but I really want to stick to just using Twitter. It’s become clear to me that Brightkite really isn’t pushing the envelope any more as a service, and there really is little incentive to post there. I definitely agree with Colin Devroe that their future should be to act as a Twitter client, rather than as their own community, since I really don’t see them being very successful otherwise.

Clearly, the future is bright for geotagging, and I can’t wait for the day when I can have a high-quality camera in my pocket that allows me to do everything my Droid does on vacation. While I’m not someone who likes broadcasting my location constantly, it’s a nice ability to have while travelling, to both share your trip with others, and to be able to look back at what you did. Hopefully the tools will continue to improve, and they’ll be more and more universal, because I think this is something everyone could enjoy.

Easy Deploys to Multiple Environments with Capistrano

Thu, 10 Dec 2009 15:17:00 -0500

At Viddler, we’re switching to using Git and Capistrano for our internal projects, and I was tasked with setting up the system to deploy our code to both staging and production environments. Capistrano doesn’t have built-in environment switching, but it’s dead simple to add it yourself.

The key to getting this to work is to utilize Capistrano’s ability to chain tasks–if you run cap task1 task2, it will run the two commands in the order you listed them. Variables are shared between the tasks, so if you set a variable in task1, task2 will be able to access it. To get multiple environments working, you just create tasks to set environment variables, which you call before the actual task you want to run.

The first step is to figure out which variables you need to change, and then move them into their own tasks. Here’s an example of the tasks we added:

desc "Run on staging server"
task :staging do
  server "staging.myserver.com", :app, :web, :db, :primary => true
end

desc "Run on production server"
task :production do
  server "myserver.com", :app, :web, :db, :primary => true
end

Now, if you want to deploy to staging, just run cap staging deploy, and for production run cap production deploy. Easy.

The Perfect Git Workflow for a One Person Project

Thu, 30 Jul 2009 14:41:00 -0400

A few months ago, I started investigating Git, and I fell in love with how much easier it made managing my code. I’m managing the source code to this site with Git, and along the way I’ve come up with a pretty good workflow for myself. The basic steps are:

Branch
Commit
Rebase
Merge
Deploy

Let’s go through each one to see how it all works together.

Branch

With SVN, I found myself hating branching–it was always a complicated procedure, and I could never remember how to do it. In Git it’s as easy as git checkout -b <branch-name>, and you’re ready to go. Once you have a branch, you can modify it however you want, and you don’t have to worry about interfering with the master branch. In order to keep your master branch bug free, commit only to branches, not to master itself.

In addition to creating new branches for major features, I always have a few branches around that I pop into for certain things:

“design” - any changes I want to make to the design go here
“optimize” - optimizations to the site
“bugfixes” - a place to work on minor bugfixes

Having these branches allows me to make small fixes to the site, and if it turns out it’s more than just a small fix, it doesn’t interfere with anything else.

Commit

In the Subversion world, it’s a pretty common practice to make very large commits, consisting of many changes. With Git, you should constantly be committing. By making many commits, you make it easier to find bugs you may have introduced, and it makes it a lot easier to track your progress. If you don’t like the thought of wading through long lists of commits in your logs, don’t worry–before bringing it over to the master branch, you can consolidate things with interactive rebasing, but while you’re hacking away on a branch, it really is advantageous to have many small commits.

Rebase

Rebasing is one of the harder things to grasp when you’re first learning about Git. For in-depth coverage of the topic, check out the Rebasing page in the Git Community Book. In a nutshell, doing git rebase master takes any commits to master and inserts them into your current branch, so you can then make sure your new code still works, and it’s a lot less hazardous than doing a merge. Rebasing your branch before putting into master is really important because it allows you to deal with any merge issues before the code goes to your main branch. To rebase, just run git rebase master.

Merge

After rebasing the branch, it’s safe to merge it into master. Since I’ve already dealt with any merge issues with the previous step, it’s as simple as checking out the master branch and running git merge <branch-name>

Deploy

I use Capistrano to deploy my code, so I’m constantly typing git push followed by cap deploy to deploy changes to my server. To make it easier, I just put both commands into one git alias:

deploy = !git push && cap deploy

Now I just need to run git deploy and it automatically pushes all of my changes to the remote Git repository and then deploys the site using Capistrano. Here’s some more information about Git aliases.

Useful tools

Though I primarily use Git through the command line, I really like using GitX to visualize branches. To host my repositories on my server, I use Gitosis, though if I had a few more projects, I’d dole out the money for a paid account at GitHub.

Have a great Git workflow? Think mine’s terrible? Let me know in the comments!

4 Easy Frontend Optimizations for Your Site

Sat, 04 Jul 2009 06:29:00 -0400

Over the past few weeks, I’ve been tweaking the site a bit to help speed up page loads. After running YSlow and Page Speed, it seemed like the slowest aspects of my site weren’t necessarily happening behind the scenes with my Ruby code, but rather on the frontend with images, Javascript, and CSS. Below, I’ve listed four ways you can squeeze more speed out of your site without even touching backend code.

Gzip your files

One of the first things I did to speed up my site was to start using mod_deflate to gzip compress data from my site before it’s even sent to the viewer’s browser. Basically what happens is after my Rails app returns the HTML for the page, Apache then compresses it and sends the compressed version to the user. Enabling this brought my front page size down to 6KB from around 22KB, a 73% improvement! You should enable this on all of your plaintext files, such as external CSS and Javascript files, as well as any HTML that’s being sent to the browser–essentially as many files as you can get away with.

For more information, make sure to read Paul Stamatiou’s excellent post on mod_deflate, where he goes through the steps of gzipping your site on Apache.

Set a far future expires header for images, stylesheets, and JS

When your browser wants to fetch a file, it first checks to see if it’s stored in its local cache, and if it has a new enough version of the file, it will display that instead of taking the time to download it from the server. The problem is, how does your browser know if the cached version is “new enough”? The trick is to use the Expires header for any files you know aren’t going to change very often (such as images, stylesheets, and javascript). I did this on all of my photos, and it has made a huge difference–after turning on the header, my bandwidth usage went down by 70%, since browsers were no longer re-requesting images they already had.

For how to set a far future expires header with Apache, check out Christian Johansen’s tutorial on the subject.

Load Javascript Libraries from Google

Nowadays, just about every site is using a javascript library of some sort, whether it’s Prototype, jQuery, or something else. Since the library might not change from site to site, why not leverage that to cut down on download times? Google has done the work for you, with their AJAX Libraries API, which provides you with a CDN-hosted version (what is a CDN?) of popular JS libraries, so they’re super fast, and once your browser downloads the library for the first time, it will be retrieved from cache for any site that uses the same file.

There are 2 ways to use Google’s hosted libraries, via the API listed on their page or just by including the file. For instance, I’m including jQuery 1.3.1 with this code:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

I’m not sure exactly how much faster this has made my site, but it definitely keeps bandwidth usage down and makes the user experience much quicker.

Defer Loading of Stat-tracking Javascript

I’ve always run two separate stat tracking scripts on this site: Google Analytics and Mint, but recently, I really started to notice they were slowing down page loading time (especially with Mint). To combat this, I decided to defer loading the scripts until after the page has finished, so as to ensure they don’t impact the user experience negatively. To do this, I just used jQuery’s $.getScript() function like this:

$(document).ready(function() {
  var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
  $.getScript(gaJsHost + 'google-analytics.com/ga.js', function() {
    var pageTracker = _gat._getTracker("GOOGLE TRACKING CODE");
    pageTracker._initData();
    pageTracker._trackPageview();
  });
  $.getScript('http://path/to/mint/?js');
});

Just customize it to point at your stat tracking scripts, and you’re ready to go. One caveat with this–it may impact your stats, because scripts won’t be loaded until the page finishes rendering, meaning if someone clicks off the page before them, it might not register their visit. I haven’t had enough time to see if my decision to defer loading has affected my stats, but I’m guessing it would have at least a minor impact.

Anything else?

Is there anything else you’ve done for your site that’s really lowered your loading times? Let me know in the comments!

Sass Without the Hass(le)

Fri, 19 Jun 2009 06:16:00 -0400

For a recent project, I decided to try out Sass, a “meta-language on top of CSS,” which allows to do all sorts of neat things like use variables, do math, and have mixins. The only problem: since you’re not writing CSS, it has to be compiled whenever you want to view your page, which can be pretty annoying if you’re just working on a static template (which I was).

At first, I was using the standard command: sass input.sass output.css, but that became too tiresome, and I was struck with an idea–what if I just created a server solely for serving the compiled CSS file? Using Sinatra, I was able to make a dead easy way to use Sass while working on a static template. Follow along to see how you can do this yourself.

First, make sure you’ve got the haml and sinatra gems installed:

gem install haml sinatra

Now, in your development directory, create a file called app.rb and paste the following code:

require 'rubygems'
require 'sinatra'
require 'haml'

get '/style.css' do
  headers 'Content-Type' => 'text/css; charset=utf-8'
  sass :style
end

Now, create a views/ directory in that same folder, and drop a style.sass file in there. This is where you’ll be writing your Sass. Now, you need to start up your Sinatra server, and to do that, just run the following command:

ruby app.rb

Now, if you go to http://localhost:4567/style.css, you’ll see your compiled CSS, and every time you update your Sass file, the code is recompiled. Just change the CSS <link> tag in your HTML template to point to the style.css file, and you’re ready to go!

Improving on Related Entries

Mon, 13 Apr 2009 18:02:00 -0400

A little while back, I posted about how I was determining related entries for my site. That method worked, but once I redid my site and added my 250+ Flickr photos, it started to really slow down when finding related photos, because of the increase in tags and posts. The real issue was that I was doing most of the work in Ruby, when it really should have been done with SQL. So, I decided to rewrite it.

Note: If you haven’t looked at my previous entry on the subject, you might want to take a look at it, just for the general idea of what I’m trying to accomplish. Essentially, I’m trying to find related posts by comparing tags. Here’s my new Post#related code:

def related(limit=5)  
  return [] if tags.empty?

  join_array = tags.collect {|tag| "posts_tags.id = #{tag.id}"}

  tags_join = "AND (#{join_array.join(' OR ')})"

  self.class.find(:all,
                  :joins => "INNER JOIN taggings posts_taggings ON posts_taggings.taggable_id = posts.id" +
                            "INNER JOIN tags posts_tags ON posts_tags.id = posts_taggings.tag_id #{tags_join}",
                  :conditions => ["posts.id != ?", id], :group => "posts.id",
                  :order => "COUNT(*) DESC",
                  :limit => limit)
end

You can see, as I mentioned, that all the work is being done in the SQL now. I first create a list of tags from the current post, which I then feed into the query to search for other posts with similar tags. The SQL instructs the database to search for any posts with any of these tags, and then orders them based on how many tags match between the 2 posts. The SQL ended up being fairly complicated, with a lot of joins, but it’s now a whole lot faster, because I’m not creating a lot of overhead by dealing with the computation in Ruby. If you’re interested, here’s an example related entry query:

SELECT `posts`.* FROM `posts`
INNER JOIN taggings posts_taggings ON posts_taggings.taggable_id = posts.id
INNER JOIN tags posts_tags ON posts_tags.id = posts_taggings.tag_id
    AND (posts_tags.id = 695
        OR posts_tags.id = 192
        OR posts_tags.id = 195)
WHERE (posts.id != 4322) AND ( (`posts`.`type` = 'FlickrPhoto' ) )
GROUP BY posts.id
ORDER BY COUNT(*) DESC
LIMIT 5

How to Take Better Photos

Sun, 05 Apr 2009 10:53:00 -0400

I’ve been into photography for a while now, and while I definitely don’t consider myself an expert on any level, I’ve come across a lot of tips over the years that have really helped to improve my photos. I’ve collected together a few of my favorite ones below, in the hopes they’ll help someone else.

Constrain yourself

Peeling Paint and Window, taken with my 50mm lens

Next time you go out to take some photos, give yourself a constraint. For example, maybe just bring one lens, or choose just one focal length to shoot at (a prime lens works perfectly for this). When I went to Italy, I brought 2 lenses, one of which appeared to be broken when I got there, so I had to spend the week using only my 50mm lens. This actually turned out to be a blessing in disguise, as I ended up with some of my favorite photos I’ve ever taken. Another great exercise in constraints is to place a piece of paper on the ground, and then take 50 photos without taking your feet off the paper. Really, you’re just trying to get yourself to look at the world in a different way.

Take your camera everywhere

A lot of great photos come about because someone was in the right spot at the right time. However, in order to capture the moment, you have to have a camera to do it with. If you’re not carrying your camera with you everywhere, you’re probably missing out on a lot of opportunities. One of the best things I ever did was purchase a point and shoot camera that fit in my pocket–now I can carry it wherever I go, ready for the unexpected.

Stop worrying about equipment

Weeping Lily, taken on a tiny point and shoot!

So many times, I’ve caught myself saying, “I would love to take that photo, but my camera’s not good enough.” This is stupid. Ansel Adams didn’t have a fancy 20 megapixel DSLR, and he took photos better than most people can even dream of. Instead, work with what you have–it’s the thought behind the photo, not the camera, that truly matters. I’ve taken great photos with tiny little point and shoot cameras, and I’ve taken horrible photos with my big DSLR. The sooner you realize your equipment doesn’t matter, the better.

Ask for critique

This photo of my sister became a whole lot better after having it critiqued on Flickr.

Some of the best photography experiences I’ve had were when I’ve had my photos critiqued by others, and when I’ve critiqued others. Having someone else take a look at your work can be incredibly helpful, as they’ll often notice things you never saw yourself, and critiquing other people’s photos can help you find new techniques and approaches to photography. If you have a group of friends that are all into photography, maybe you can meet every so often and swap shots. Or, join a site like Flickr, and start commenting on photos by other users. Soon enough, they’ll be commenting back on yours, and you’ll start seeing your photos in a whole new light.

Take lots of photos

Memory cards are cheap, so why skimp on photos? I’ve found that the more photos I take, the better I become at photography. But it’s not just about taking lots of photos, it’s about going back and seeing what your mistakes were and learning from them. If you aren’t taking a whole bunch of photos, you’re not going to learn from your mistakes, because you won’t be making them.

Don’t think about Photoshop

This photo, Dreaming, was weak from the start, and my attempts to save it really didn’t do much.

For a while, I was really into Photoshop–nearly every photo I took was manipulated in some way to make it better, and I started to even think about how I was going to process an image before I even pressed the shutter button. This is bad. Focus on making your photos as perfect as possible before they get to your computer, and you’ll end up with a much nicer finished product. That’s not to say you shouldn’t tweak photos afterwards, but you just have to remember that taking an amazing photo isn’t about what filters you use, but rather about how you compose the image in the viewfinder.

Hopefully these tips are helpful, and if you have any to share, make sure to leave comments below!