Apply To All Jobs on AngelList

TL;DR: Copy and Paste this code snippet into AngelList Jobs page to apply to all jobs.

$('a.interested-button').each(function(_, button) {$(button).click()})

AngelList is a useful resource for startups, investors, and individuals looking for startup jobs. For this post, I fall into the latter category. As part of my recent job search, I perused the jobs section of AngelList, and I even expressed that I was interested in a few startups. As I went through this job search process, I asked if there was an easier way to go about this.

AngelList Jobs

My solution was to apply to all the jobs within a given search. The first thing I noticed was that a user must click on an “Yes, I’m interested” button. When I examined the source code closer within Google Chrome’s Inspector, I realized that the “Yes, I’m Interested” buttons had a class of .interested-button and that each startup item had its own button already rendered to the page.

interested-button

The actual solution took only one line of jQuery to implement:

$('a.interested-button').each(function(_, button) {$(button).click()})

The End You scroll to the bottom until you have all the search results loaded onto the page and you see “The End”

Apply all using the script in the console

Apply script with the console

Expressed Interest Now you’ve successfully applied to all the jobs within a given AngelList jobs search by pasting the above snippet into the console.

One Catch Add note to show interest There is one catch however. You will not be able to apply to jobs that require a note as part of you showing your interest in the job. For a bulk apply all, this seems like a small problem. Pareto’s Principle applies here.

This being said, I do believe that a more targeted approach to job searching is more effective. A strategy where you find a handful of companies you are interested and you express interest via a warm connection or at the very least a direct email to someone within the organization with hiring authorization. You could use a tool like DirectContact to find these individuals’ email addresses

A Fix In case someone at AngelList is reading this, here is one possible solution to prevent this script from working in the future. Instead of POSTing a user is interested directly from an .interested-button click, require a user to have opened the startup job description. This way a boolean variable must be toggled before an interest is POSTed.

Possible Email Ruby Gem

PossibleEmail Gem on GitHub PossibleEmail on RubyGems

This is a continuation of my projects relating to using the undocumented Rapportive API. My previous project, Find Anyone’s email: A Ruby script, was a popular project that spurred an issue on Github requesting the script to be written as a gem. After some work, here is the final product.

There were a few motivations in making this gem. When I first released the find-any-email script, I always thought of it as a proof-of-concept instead of the end all be all. Not only did it feel like a hack, but I thought about how easy and interesting it would be to integrate the functionality into a web app if the script was converted into a gem. Another motivation I had going into this project was to improve on my RSpec specification writing. I recently finished reading through the RSpec Book, and I wanted to practice writing specs for this project. If you actually take a look at the gem’s source code, then you might notice there are 75 tests for the gem. Those 75 tests were the result of going through TDD process of Red-Green-Refactor numerous times.

I’m interested to see how this gem would be used in other people’s projects. I was actually considering of creating a sort of SaaS product around the gem or an iPhone app. It seems that these types of email-mining things are of value to some people specifically sales and business people. I actually have something up that I built a few months ago, DirectContact, but I put it on the shelf at the moment. The ideas still seems to have value for people, so I might pick it back up after finishing another project. It gets a bit old thinking about a fairly simple idea after you’ve been thinking about it for awhile.

I would like to tip my hat to Jordan Wright for being a big inspiration for this gem after he wrote his python library Rapportive

CS139P Red and Black Playing Card Suits

I am currently going through Stanford’s CS139P iPhone Application Development Course for iOS 7. I came upon the problem of having my suits only showing black for diamonds, spades, hearts, and clubs.

I started to look at other repos on GitHub of the same project, and I saw I had the same exact thing as the working solution. I then tried to copy validSuits class method in PlayingCard.m directly into my own project, and that fixed it. The problem might have been with choosing the wrong special character from the special character panel. After some looking around in the various tabs, I found the correctly colored suits and I was able apply them again.

+ (NSArray *) validSuits
{
    return @[@"♦️", @"♠️", @"♣️", @"♥️"];
}

You can copy the above class method into the PlayingCard.m to have red and black Playing Card suits.

I tried searching online, but there were no solutions to this problem. Hopefully the search engines indexes this page for others running into the same problem.

When your Backbone JS View Events not Firing

This is a direct copy of this file on GitHub. I’m reproducing here because I think it is a great checklist that actually solved my problem when my view events were not firing.

I’ve been using backbone.js to > develop some javascript-heavy application recently.

I find it quite common for new comers to come into the following > problem: why ain’t my view events firing?

By “view events” I mean a events hash like the following in a > Backbone View class declaration.

class Mine.Views.TasksNew extends Backbone.View
  events:
    "click #preview_button":"parse"
    
  constructor:(options)->
    super(options)
    
  parse:(e)->
    alert 'clicked'

  ...

When your events are not firing, the following is a useful > checklist to go through.

  1. Maybe you have in the previous class declaration something like “el:\$(‘#myelement’)” and expecting the View to be bound to that specific element. But be cautious! The class declaration may be executed before the page is fully loaded. (This is common since I have seen most people put the class declaration before everything else). Please try to move “el:\$(‘#myelement’)” to the spot where you instantiate the View class and maybe the problem could be solved.

  2. Maybe your “el” is too restrictive. You should be know that the objects mentioned in the events hash are restricted inside the el element.

  3. Be aware of the order inside "click #preview_button":"parse"! It’s event followed by selector followed by handler. Did you reversed the order?

  4. Trace down the code using firebug,etc. The code of backbone.js is well readable.

This checklist incorporated the bad things that has happened to me > that makes my events not firing. Hope it helps you!

My specific problem was solved after hitting the second item on the checklist. “el” was too restrictive. I had el: '#posts', so my events were being restricted to within the #posts div. I changed the el to el: '#posts', and that solved my problem of the events not being fired. I’m sure this checklist would come in handy one day.

The difference between -> and => in CoffeeScript

I had this following code:

@collection.each (post) ->
  $(@el).append @template(post.attributes)
@

I was running in an issue where @el and @template were returning Uncaught TypeError: undefined is not a function. I even created a StackOverflow question about it.

I got the template to render by using jQuery directly like so,

$('#posts').append _template.( $('#home-post-template').html() ).

So this told me that the el or template was not within the scope of the each function. I remembered I was originally referencing one of Buzzstarter’s Backbone files and I had => instead of the -> I had now. Just trying things, I switched out -> for =>. Now it was working. Of course I couldn’t switch it out without understanding why it made a difference. So to the CoffeeScript documentation about the fat-arrow. It basically passes another function passing the outer context of this into an argument. This can be better illustrated with the conversion of CoffeeScript to normal Javascript

Old CoffeeScript

    @collection.each (post) ->
      $(@el).append(@template(post.attributes))
    @

Javascript Equivalent

    this.collection.each(function(post) {
      return $(this.el).append(this.template(post.attributes));
    });
    return this;

New CoffeeScript

    @collection.each (post) =>
      $(@el).append(@template(post.attributes))
    @

Javascript Equivalent

    this.collection.each((function(_this) {
      return function(post) {
        return $(_this.el).append(_this.template(post.attributes));
      };
    })(this));
    return this;

Once I saw the Javascript of the CoffeeScript with =>, it was painfully obvious what I was doing wrong and how => solved the problem. This error was due to my unfamiliarity to CoffeeScript, but Js2Coffee is quite useful in learning the differences.

New Appreciation for Programming

I recently started a new internship at Buzzstarter working with a team of experienced developers. One of the benefits of this internship is to view how good code is written. My first two weeks involved viewing their application’s source code and using similar techniques to build an introduction project.

A specific instance of seeing good code was when I saw a class method called enum.

  def self.enum(options)
    options.each do |attr, values|
      values_method = attr.to_s.pluralize

      class_eval <<-RUBY, __FILE__, __LINE__ + 1
        def self.#{values_method}
          #{values}
        end

        def #{attr}
          self.class.#{values_method}[read_attribute(:#{attr})]
        end

        def #{attr}=(value)
          idx = self.class.#{values_method}.index(value.to_sym)
          raise 'Enum not found' unless idx

          write_attribute(:#{attr}, idx)
        end
      RUBY
    end
  end

The method uses a bit of meta-programming, or at least that’s what I think this is doing, to write attributes to the database. The difference is that the values being written to the database are integer values instead of strings. As it was explained to me, this is a feature MySQL has, but PostgreSQL does not have. This allows for both reading and writing attributes to be quicker. You would then use the the enum method like so.

enum current_status: [:off, :on]

The enum method creates a getter and setter using the attribute current_status with the value being the index of the value within the values array passed in.

There are too many instances already where I’ve read some code and was left smiling about the new technique I just learnt. Not only does viewing the application’s source code show me how good code is written, but making the introduction project has me writing better code.

I am fortunate that I have one of the engineers reviewing my code via code reviews. During these code reviews, Radil, would comment on the specific lines with what I needed to change. I would make the necessary changes until I can create a branch with the feature working, then I would create another pull request. There are about ten parts to the project, but I am still only on the third part. I can already tell there is much more for me to learn.

TinyMCE, ActiveAdmin, and Rails 4

I was installing TinyMCE so I could have a WYSIWYG editor on a textarea within ActiveAdmin when I got the following error.

No route matches [GET] "/assets/tinymce/themes/advanced/theme.js"

I found the similar issue on the tinymce-rails gem’s docs. Losing TINY mce in dev when switching from 3.5.8 to 4.0.2 in Dev

The issue was caused by a change in TinyMCE’s theme. Apparently TinyMCE 4 replaced the ‘advanced’ theme with the ‘modern’ theme. Sure enough when I edited my active_admin.js.coffee CoffeeScript file to:

#= require active_admin/base
#= require tinymce
$(document).ready ->
  tinyMCE.init
    mode: "textareas"
    theme: "modern"
    editor_selector: "tinymce_editor"
  return

That solved the issue I was having. I followed along with this answer on StackOverflow to install tinyMCE to rails.

Railscast 053 Handling Exceptions

GitHub Repo

Heroku App

Rack Middleware

I created this episode in order to understand how rack middleware works. There was really only one line that pertained rack middleware

config.exceptions_app = self.routes

This line is a little hack to define the Rails routes as the rack middleware app that should handle exceptions. From the routes we can then match the status error in a route and map to a controller action.

Route

match '(errors)/:status', to: 'errors#show', constraints: {status: /\d{3}/}, via: :get

This route line provided me with a few lessons. the () in a route is an optional route. A route like products/:id(/:type/:year) would match a route for the product from the id and optional add the type or year params if specified.

The constraints part about further specifies what is acceptable in a route and what is not acceptable. Here we are using regex to constrain the status param to only be 3 digits. This could be useful when getting params from the route. The constraints can be analogous to how validations works for models.

Controller

class ErrorsController < ApplicationController
  def show
    @exception = env["action_dispatch.exception"]
    respond_to do |format|
      format.html { render action: request.path[1..-1] }
      format.json { render json: {status: request.path[1..-1], error: @exception.message} }
    end
  end
end

The @exception instance variable is set to the type of exception raised. The exception is store in the environment’s action_dispatch.exception. The action responds to different formats like html or json. Therequest.pathhas[1..-1]to turn/404to404`

Railscast 052 Update through Checkboxes

The GitHub Repo

The Heroku App

This episode combines the technique shown in Episode 017 habtm checkboxes and Episode 35 Custom REST Actions to update a task’s complete attribute through checkboxes.]

Some of the differences in this episode were the methods used to update the complete attribute. In episode 035, the update_attribute() was used to update a single record. In this episode we used the update_all() method. There was a slight difference in how the update_all() method was used in the video and how it is currently used. In the video the update_all() method accepts two arguments, the attribute with updated value, plus the ids of tasks to be updated. The update_all() method has been changed to accept only one argument, the attribute with the updated value. This creates some problems in specifying which record to update. Luckily, the API for update_all showed the correct way to use the updated version of update_all().

Task.where(id: params[:task_ids]).update_all([“complete=?”, true])

We use the where() method to return tasks fitting the passed in conditional.

The params[:task_ids] were sent from the form within the view.

<%= form_tag complete_tasks_path, method: :put do  %>
  <ul>
    <% @incomplete_tasks.each do |task| %>
    <li>
      <%= check_box_tag "task_ids[]", task.id %>
      <%= task.name %>
    </li>
    <% end %>
  </ul>
  <%= submit_tag "Complete task" %>
<% end %>

Here we use the form_tag because the form is not directly editing attributes on a model. We then specify the path and method to put. I am just realizing this now, but this put should be a patch to match up with what the Rails core team has been doing in transitioning from put to patch to match with RFC’s specifications.

The next part to focus on is the <%= check_box_tag "task_ids[]", task.id %> line. We are creating checkboxes for each task with the value of the task’s id. The name for each checkbox can be specified to task_ids[] because we are using a general check_box_tag. task_ids[] allows the task_ids parameter sent from the form to be an array able to hold multiple records. This is where we get the params[:task_ids] array passed into the where() method.