Diego Plentz plentz

## podcasts.md

      
              1 file
            
          
              1 fork
            
          
              5 comments
            
          
              2 stars
            
          
                plentz
                / podcasts.md
            
            
              Last active Jun 8, 2019
            
              
                podcasts
              
          
      View podcasts.md
  
    
hipsters.tech
like a boss
gimlet startup podcasts (recomendação do pcalcado)
masters of scale (recomendação do pcalcado)
revisionist history (recomendação do bzanchet)
dtr (podcast do tinder)
we are netflix

parei de ouvir:

99% invisible


## ladder.md

      
              1 file
            
          
              0 forks
            
          
              0 comments
            
          
              2 stars
            
          
                plentz
                / ladder.md
            
            
              Created Oct 28, 2015
                — forked from jamtur01/ladder.md
            
              
                Kickstarter Engineering Ladder
              
          
      View ladder.md
  
    
    These are the Kickstarter Engineering and Data role definitions for both teams.


Technical
Data
People


Junior Software Engineer


Software Engineer
Data Analyst


Senior Software Engineer
Data Scientist
Engineering Manager


Staff Engineer
VP of Data
Engineering Director


Principal Engineer

CTO


## recover_opsworks_sg.sh
#!/bin/sh
# creating security groups
ec2-create-group 'AWS-OpsWorks-Web-Server' -d 'AWS OpsWorks Web server - do not change or delete'
ec2-create-group 'AWS-OpsWorks-Default-Server' -d 'AWS OpsWorks Default server - do not change or delete'
ec2-create-group 'AWS-OpsWorks-Blank-Server' -d 'AWS OpsWorks blank server - do not change or delete'
ec2-create-group 'AWS-OpsWorks-LB-Server' -d 'AWS OpsWorks load balancer - do not change or delete'
ec2-create-group 'AWS-OpsWorks-PHP-App-Server' -d 'AWS OpsWorks PHP-App server - do not change or delete'
ec2-create-group 'AWS-OpsWorks-DB-Master-Server' -d 'AWS OpsWorks database master server - do not change or delete'
ec2-create-group 'AWS-OpsWorks-Memcached-Server' -d 'AWS OpsWorks Memcached server - do not change or delete'
ec2-create-group 'AWS-OpsWorks-Monitoring-Master-Server' -d 'AWS OpsWorks Monitoring Ganglia server - do not change or delete'

## default.rb
include_recipe "logrotate"

logrotate_app "tomcat" do
  cookbook  "logrotate"
  path      "/var/log/tomcat/catalina.out"
  options   ["copytruncate", "missingok", "notifempty"]
  frequency "daily"
  rotate    3
  create    "644 tomcat tomcat"
  size      "50M"

## elastic_beanstalk_external_sessions.md

      
              1 file
            
          
              0 forks
            
          
              1 comment
            
          
              1 star
            
          
                plentz
                / elastic_beanstalk_external_sessions.md
            
            
              Last active Nov 4, 2016
                — forked from mlconnor/elastic_beanstalk_external_sessions.md
            
          
      View elastic_beanstalk_external_sessions.md
  
    
    Session Management in an Autoscaling Environment
Problem Statement
User sessions in J2EE and LAMP stacks have traditionally been handled in memory by the application server handling the user request.  Because of that, load balancers have been configured to use sticky sessions.  By sticky sessions we mean that once the user has visited the site, they will be assigned an app server and will return to that server for subsequent requests.  The load balancers typically handle that by referencing the users session cookie.
Elastic cloud environments differ from traditional server configurations in that they have a variable number of servers based on traffic loads whereas traditional configurations had a fixed number of servers.  When traffic volumes decline it is necessary to vaporize servers.  In doing so, we would lose user sessions (essentially forcing a logout) unless we come up with a new strategy for session management.
A new approach
After much research, it is clear that the best

  
## nginx.conf
# to generate your dhparam.pem file, run in the terminal
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048

## gist:5630854
...
[Thread 0x2aaad4201940 (LWP 11770) exited]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x2aaac6464940 (LWP 11237)]
vm_exec_core (th=0x83ba000, initial=0) at vm_exec.c:35
35  {
(gdb) t a a bt


## 135.log
+ jruby -S -Xdebug.loadService.timing=true rake db:migrate db:test:prepare
2012-12-13T14:07:09.652-02:00: LoadService:   -> jruby
2012-12-13T14:07:09.727-02:00: LoadService:     -> java
2012-12-13T14:07:09.812-02:00: LoadService:       -> jruby/java
2012-12-13T14:07:09.935-02:00: LoadService:         -> jruby/java/java_module
2012-12-13T14:07:09.957-02:00: LoadService:         <- jruby/java/java_module - 21ms
2012-12-13T14:07:09.957-02:00: LoadService:         -> jruby/java/java_package_module_template
2012-12-13T14:07:09.970-02:00: LoadService:         <- jruby/java/java_package_module_template - 13ms
2012-12-13T14:07:09.970-02:00: LoadService:         -> jruby/java/java_utilities
2012-12-13T14:07:09.983-02:00: LoadService:         <- jruby/java/java_utilities - 13ms

## Gemfile.rb
# this don't work (bundler don't support nested platform/grouping https://github.com/carlhuda/bundler/issues/1298)
group :development, :test do
    gem 'pg', :platforms => :ruby
    gem 'activerecord-jdbcpostgresql-adapter', :platforms => :jruby
end

# you should do something like this
group :development, :test do
    gem 'pg' if RUBY_PLATFORM != 'java'
    gem 'activerecord-jdbcpostgresql-adapter' if RUBY_PLATFORM == 'java'

## deploy.rb
require "capistrano_colors"
require "railsless-deploy"

set :default_stage, "dev"
require "capistrano/ext/multistage"

set :use_sudo, false
set :application, "bar"
set :user, "www-data"
set :group, "www-data"