BoltHR - Jacksonville, FL - Fulltime - email: efleming@bolthr.com

We are willing to work with you on timeline for relocation and provide assistance. We pay well.

We are create HR tech software focused on small and medium sized businesses. We are well funded by our founders and pre-launch. Our software is looking to make an impact on small/medium sized businesses by providing easy to use and beautiful products. We have a design first mentality, we like to get things in front of customers fast and collect feedback, and we build our products to be fast in order to provide an optimal user experience.

Our development office is located in booming downtown Jacksonville. No state income tax, great weather, an NFL team that is improving (we hope), beaches, tons of great outdoor activities, and a tech scene that is growing fast.

Out tech stack includes Node.js, Angular, Mongo, MySQL, and various Amazon Web Services. We are looking for front end developers and back end developers excited about working with Javascript across the entire stack. We would prefer people with experience with out current stack but want to hear from people that are interested.

If even remotely interested, shoot me an email at efleming@bolthr.com. I am the CTO and I'll get back to you immediately. We are going to build a great team, a great product, and have fun doing it. I hope you'll be a part of it.

Not wrong, a lot of their performance gains were a result of caching their templates client side and having their servers only return data. That is a much smaller load on the server and easily could account for the reduction in servers. The title makes it sound as if they reduced their servers and increased their performance simply by migrating from ruby to node.

This. Many rails apps spend much of their time rendering views, and even a decent caching strategy on the server can increase performance tons.

They do seem to prioritize paying customer, particularly during outages.

https://status.heroku.com/incidents/151

"We prioritize getting top-paying customers back online over our larger base of free users, which is why customers (particularly those with dedicated databases) were back online much more quickly than free apps. While we think this prioritization makes sense, we do strive to provide a high level of service to everyone. Even though the outage was much shorter (less than 16 hours in most cases) for our top customers than for our free users (as much as 3 days in some cases), we measure our downtime as the time it took to get 100% of apps back online."

Thanks for the link. Makes me feel better :)

I implemented these examples in Ruby 1.9, would love to know if there are more efficient ways of doing some of these:

    def cook(p1, p2, f)
      puts "get the " + p1.to_s
      f.call(p1)
      f.call(p2)
    end

    cook( "lobster", "water", lambda {|x| puts "pot " + x })
    cook( "chicken", "coconut", lambda {|x| puts "boom " + x })

    @a = [1,2,3]
    @a.map {|x| puts x*2}
    @a.map {|x| puts x}

    def sum(a)
      @a.reduce(0) do |a, b|
        a + b
      end
    end

    def join(a)
      @a.reduce("") do |a, b|
        a.to_s + b.to_s
      end
    end

    puts "sum " + sum(@a).to_s
    puts "join " + join(@a)

Here's one more efficient way... use perl!

  #!/usr/bin/perl
  
  use Modern::Perl;
  use List::Util 'reduce';
  
  sub cook {
    my ($i1, $i2, $f) = @_;
    say "get the $i1";
    $f->($i1);
    $f->($i2);
  }
  
  cook "lobster", "water",   sub { say "pot "  . shift };
  cook "chicken", "coconut", sub { say "boom " . shift };
  
  my @a = (1, 2, 3);
  
  map { say $_ * 2 } @a;
  map { say $_     } @a;
  
  sub my_sum {
    reduce { $a + $b } 0, @_;
  }
  
  sub my_join {
    reduce { $a . $b } "", @_;
  }
  
  say "sum "  . my_sum(@a);
  say "join " . my_join(@a);