Instantly share code, notes, and snippets.

View gist:0721407cc12ca9adf04d6f19de66a1e6
08-31 09:56:57.609 19045 19055 E StrictMode: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
08-31 09:56:57.609 19045 19055 E StrictMode: java.lang.Throwable: Explicit termination method 'close' not called
08-31 09:56:57.609 19045 19055 E StrictMode: at dalvik.system.CloseGuard.open(CloseGuard.java:180)
08-31 09:56:57.609 19045 19055 E StrictMode: at java.net.AbstractPlainSocketImpl.create(AbstractPlainSocketImpl.java:103)
08-31 09:56:57.609 19045 19055 E StrictMode: at java.net.Socket.createImpl(Socket.java:464)
08-31 09:56:57.609 19045 19055 E StrictMode: at java.net.Socket.getImpl(Socket.java:530)
08-31 09:56:57.609 19045 19055 E StrictMode: at java.net.Socket.setSoSndTimeout(Socket.java:1194)
08-31 09:56:57.609 19045 19055 E StrictMode: at com.android.okhttp.Connection.setTimeouts(Connection.java:508)
08-31 09:56:57.609 19045 19055 E StrictMode: at com.android.okhttp.Connection.connectAndSetOwner(Connection.java:4
View podcasts.md
  • hipsters.tech
  • like a boss
  • nerdcast
  • tim ferris show
  • gimlet startup podcasts (recomendação do pcalcado)
  • masters of scale (recomendação do pcalcado)
  • revisionist history (recomendação do bzanchet)
  • dtr (podcast do tinder)

parei de ouvir:

View gist:4034431196232f750291def7c85ff7cd
From: FALHA XP <falhas@xpi.com.br>
Date: dom, 15 de jan de 2017 22:02
Subject: FALHA DE SEGURANÇA XP INVESTIMENTOS
To: Recipients <falhas@xpi.com.br>

Prezados,

View 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'
View 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"
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

View nginx.conf
# to generate your dhparam.pem file, run in the terminal
openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048
View gist:5630854
This file has been truncated, but you can view the full file.
...
[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
View 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