Showing posts with label coding. Show all posts
Showing posts with label coding. Show all posts

Tuesday, June 05, 2012

Digging for Gems

I've been working on a project the last three weeks for a dev shop out of San Francisco. A lot of the work has been adding additional features to an already completed site, and it's been an enjoyable project. It's nice to see completed work, and I'm able to learn a lot when following someone else's code and picking up on new techniques I haven't seen before. For example, the Ruby if-statement on one line:
foo_bar.present? ? puts "foo" : puts "bar"
Beyond just exposing new syntax, this project has also turned up plenty of new gems to add to the toolbox. A few of my favorites:
  • friendly_id - take out the ugly Rails routes that include ids and instead use the blog posts' titles, for example
  • carrierwave - easy file uploads
  • rmagick - resize images
  • feedzirra - pull in a RSS feed and parse the data into blog titles, url, blog author, blog content, etc.
  • sanitize/htmlentities - strip out any html or harmful content
Working on this project, I've found that I continue to come across stuff in the code that puts me back in the Gemfile and researching the various gems. Which got me thinking - why can't I upload a Gemfile that then spits out a nicely organized list of the gems, a short summary of the gem, their github repos, their ruby gems page, and any railscasts tutorials that exist?

Thursday, May 10, 2012

Develop Detroit

Mike and I met at a startup event in downtown Detroit. A chance run in that will start happening here more and more as the community of like minded professionals, technologists, and entrepreneurs continues to grow in the city. He told me he was creating a 12 week program to teach iPhone and iPad app development. I told him about my Code Academy experience. And then we started working together.

Over the course of a month or so I built the Develop Detroit website using WordPress, and we started to promote it last week. Help us spread the word!

Twitter: @devdet
Facebook: www.facebook.com/devdet



Friday, May 04, 2012

Make Money as a Developer

This is a good article on how to start to make money as a developer. He says the number one problem is one of "personal branding." When you still feel like you're a newbie developer, learning on the fly, it's hard to muster up the courage to call yourself a developer. Get over it, he says. You're a developer. A new one, but certainly a developer.

Now start making money.


Thanks to Tom and Jin for the link and gif.

Tuesday, April 17, 2012

How to create a hover intent function with Google Maps

Last week I wanted to fire a piece of code (div scrolling) when the user's mouse was hovering over a Google maps polygon. I got that working pretty easily with a simple Google Maps listener with the 'mouseover' event. Unfortunately, that created a different problem - if the user moved the mouse quickly over the map and crossed over many polygons, the div scrolling code I had within the listener was fired too much.

I ended up finding a jQuery plugin, hoverintent,  that only makes the call when the user's mouse is hovering over the element for a specific amount of time. This would have certainly done the trick on a DOM element but it wasn't going to work on my map when the polygon wasn't a DOM element, it was an overlay on the Google maps object. An even easier solution (no plugin required) emerged.

Javascript has a setTimeout() method that you can use to execute code in the future. So, in  my case, I set a variable, timer, to the setTimeout() method and the code I wanted called; I checked for timer when the user had the mouse over an element, if the timer existed, I set it to null and used the clearTimeout method and then reset timer to the a new SetTimeout. I added another Google Maps listener for the event 'mouseout' of the polygon and set timer to null while using the clearTimeout(). In this way, the div scrolling only happened when the timer reached a certain time, in other words, when the user's mouse was hovering over a polygon for  a certain amount of time.

google.maps.event.addListener(polygon, 'mouseover', function(event) {

            if (timer) {
              clearTimeout(timer);
              timer = null;
            }
//set timer so animation of scrollbar only happens when mouse is within polygon for longer than 500 milliseconds
        timer = setTimeout(function() {
            $('#side_content').animate({ top: -$('#div').top }, 300);
        }, 500);
});

google.maps.event.addListener(polygon, 'mouseout', function(event) {
          if (timer) {
            clearTimeout(timer);
            timer = null;
          }
});

Wednesday, April 11, 2012

Changing redirect after Devise signin

We use Devise to manage user sign authorization and authentication. This solution offers a lot of stuff for free, such as password resets and account confirmations, but it's also a little hard to navigate at first since most of the functionality seems hidden from view. Read up a little bit though and you'll find just about every customization you desire is written about on the Devise wiki, with instructions on implementation.

Yesterday, I customized the redirect after a user signs in. Initially, devise is set up to redirect to the root_url after sign in, but it's easy enough to override it by adding a after_sign_in_path_for(resource) method in the application controller. Because our signin "page" is actually a small menu that sits on every page, I wanted the user to stay on the current page after signin rather than be redirected to a specific page. For example, if a user is using our map and decides to sign in, I want that user to stay on the map after signin, not be redirected to a different page. Seems easy enough, and although it took me a little while to figure out a solution, the implementation for this functionality isn't all that hard.

The key for me was learning about Rails' request.fullpath, which will return path the user is on. (There is also request.uri, request.url, request.path, request.host and a few others). So, on my sign in form, I added a variable that I set to the fullpath returned from request.fullpath, and passed that variable to the user sign in path as a params. With that, I have the current page the user is on and can redirect them there after successful sign in.

<% current_path = request.fullpath %>
 <%= form_for("user", :url => user_session_path(:current_page => current_url), :html => { :id => "signin_form" }) do |f| %>


application_controller

def after_sign_in_path_for(resource)
 params[:current_page] || super
end


Sunday, April 08, 2012

Learning Javascript

Though we're using Rails as our framework, Picket Report's code base is only 45% Ruby and 55% Javascript. I didn't have much experience with Javascript until the past month or so, and though the syntax is a little cumbersome at first, I've started to enjoy using the language, particularly creating and handling Javascript objects.

Most APIs that I've dealt with so far respond with JSON objects, but it wasn't until the last two or three weeks that I got more comfortable understanding how get to what I wanted within a response. Part of it was learning how to use console.debug() and thus being able to actually see the object and how it was structured, but most of my improvement can be chalked up to learning some basic Javascript - looping, if/then statements, creating objects for later use, etc.

A basic example from this past week. I created a marker ID object that kept track of each google maps marker on my map as well as a string of html content I wanted to appear in a map popup/infowindow when the user clicked on a marker. I organized the object by marker ID so that I could easily find that marker at a later point. I couldn't have done this a couple of weeks ago, and when it came together it was a nice reminder of how much I've learned and a big aha moment that seemed to open up a sense of possibility...


 markerIDObject[marker.__gm_id] = {};
 markerIDObject[marker.__gm_id].marker = marker;
 markerIDObject[marker.__gm_id].content = contentString;


 this.neighborhoodShowInfoWindowBounce = function(marker_id) {
    showInfoWindow(markerIDObject[marker_id].marker, markerIDObject[marker_id].content);
    markerBounce(markerIDObject[marker_id].marker);
  }


Friday, March 16, 2012

Coding!

While in Code Academy, we were really encouraged to blog at least once weekly about what we were learning. It was a nice marketing tool for them but it also served as a great way to track my progress and improve my understanding of general concepts. It was a worthwhile exercise and something I intend to try to keep up with now that I'm working on this stuff full time, improving my skill set and expanding my toolbox. The first 6 weeks have been awesome; I'm learning a lot.

Javascript - Though we use Ruby on Rails as our framework, the mapping feature is largely built in Javascript. Besides a few jQuery effects I managed to get working during Code Academy, I didn't have much experience with Javascript and even trying to read through our .js files was difficult at first. But over the last two weeks, I really feel like I've been starting to pick it up.

I'm updating our map using the Google Maps API which I've found to be a great way to start to learn. They have a ton of examples on how to build your requests and handle the responses, and if you can start to follow those, you're half way there. It's been fun figuring this out - I'm looking forward to using CoffeeScript next.

Chargify - It wasn't planned but I've ended up getting a lot of experience with different payment processors. I've used PayPal, Stripe, and now Chargify. We use Chargify to handle our subscription service to the Picket Report widget, and I found the API pretty easy to handle. It took me a while to handle the errors that Chargify sends back (turns out to just be an Active Record resource if you're working with the Chargify gem...you can use the .errors method and print them easily). Stripe is still the easiest and most elegant solution I've found, but it's nice to get some experience with a number of them. My main takeaway - avoid PayPal.

CSS - I spent the first month developing the front end of our site. I've picked up a lot of awesome tricks on styling and can handle the jQuery effects pretty easily at this point. It's this CSS/front end area that I think I've improved upon the most and feel pretty comfortable now saying that I can do just about anything I'd like to do in terms of making something look a certain way. This is a pretty sweet improvement over the Rails scaffolding CSS!

Friday, December 16, 2011

Code Academy: Week 11


Until this week, I haven't felt comfortable saying this:
I'm a software developer.
Despite being a part of Code Academy and learning the skills of a developer, to call myself one always felt wrong, like I was a poser faking it in a field I knew very little about. And though I'm no where close to where I want to be in terms of my ability as a developer, a couple of things happened this past week that gave me enough confidence where it finally feels natural to call myself what I've become over the last 11 weeks: a developer.
  • On Wednesday I went to a Chicago meetup put on by a company called Heroku. I've been using Heroku to deploy the applications I'm building and they organized an evening session to talk more about their product and to show off some demonstrations on how to use it. About 30 developers were in attendance (maybe half of them Rubyists) and there wasn't any moment that I felt out of place or in over my head. In fact, they had a live coding demonstration of an email/signup app that they deployed to Heroku and as a few of the audience members watched in amazement at the speed with which he was able to code and deploy, my thoughts were generally something like - "that's easy." I could have gotten up in front of a room full of Chicago developers and offered some of them new skills related to the software craft. A poser developer couldn't do that.
  • A fellow Code Academy student sent me an email this week about stripe.com, a payment processing service similar to Paypal. He had just implemented it on his site, found it to be very easy and seamless, and knew I had been struggling with Paypal. He recommended I check it out. If you go to the homepage the first thing you'll see is "Payments for Developers." 11 weeks ago this service wouldn't have been for me, I wasn't a developer, but I'm happy to report that after spending about 2 hours this week working on implementation, I got Stripe hooked up to my site without too much trouble. I was able to follow along with their code tutorials, make a few customizations needed for my site, and perhaps most tellingly, appreciate their product from a developer's point of view. Their homepage headline made sense...because I'm a developer.

Learn how to code!

This internet thing might be around for a while.

The Rise of Developer Economics
The one absolutely solid place to store your capital today — if you know how to do it –  is in software developers’ wallets.