xdite

Security is Hard

Massive Assignment

• watch for ActiveRecord Relation, like has_many, has_many :through
• watch for user_roles, `group_users
• UPDATE action

Admin

pmeenan

// Support routines for automatically reporting user timing for common analytics platforms
// Currently supports Google Analytics, Boomerang and SOASTA mPulse
// In the case of boomerang, you will need to map the event names you want reported
// to timer names (for mPulse these need to be custom0, custom1, etc) using a global variable:
// rumMapping = {'aft': 'custom0'};
(function() {
var wtt = function(n, t, b) {
  t = Math.round(t);
  if (t >= 0 && t < 3600000) {
    // Google Analytics

jmoz

from twitter import Twitter, OAuth, TwitterHTTPError


OAUTH_TOKEN = 'foo'
OAUTH_SECRET = 'bar'
CONSUMER_KEY = 'baz'
CONSUMER_SECRET = 'bat'

t = Twitter(auth=OAuth(OAUTH_TOKEN, OAUTH_SECRET, CONSUMER_KEY, CONSUMER_SECRET))

harlow

require 'sinatra'
require 'twitter'

class App < Sinatra::Base
  get '/' do
    erb :index
  end
  
  post '/hashtags' do
    @user_name = user_name

stevebowman

console.log('Loading event');

// Twilio Credentials 
var accountSid = '';
var authToken = '';
var fromNumber = '';

var https = require('https');
var queryString = require('querystring');

tmcw

Optimization

Correctly prioritizing and targeting performance problems and optimization opportunities is one of the hardest things to master in programming. There are a lot of ways to do it wrong: by prematurely optimizing non-bottlenecks, or preferring fast solutions to clear solutions, or measuring problems incorrectly.

I'll try to summarize what I've learned about doing this right.

First, don't optimize until there's an issue. And issues should be defined as application issues: performance problems that are either detectable by the users (lag) or endanger the platform – i.e. problems that cause downtime, like out-of-memory issues. Until there's an issue, don't think about peformance at all: just solve the problem at hand, which is "creating value for the end-user," or some less-corporate translation of the same.

Second, only optimize with instruments. By instruments, I mean technology that lets you decipher which sub-part of the stack is the bottleneck. Let's say you see slowness around fet

DmitryTsepelev

ActiveRecord::Migration.remove_foreign_key(:current_table, :foreign_table) # no lock

ActiveRecord::Migration.add_column(:current_table, :column_bigint, :bigint) # no lock

copy_data = lambda do
  CurrentTable.where(column_bigint: nil).where.not(column: nil).in_batches do |batch|
    batch.update_all("column_bigint = column")
  end
end

kany

Rails 6 + ActionCable + Stimulus example for pushing updates to the view.

This example will show how to push updates to the view for a Model instance that has changed without the user having to refresh the page.

This example focuses more on getting ActionCable working with Stimulus. If you don't already have stimulus setup in your app, here's a great write up on how to set it up: https://medium.com/better-programming/how-to-add-stimulus-js-to-a-rails-6-application-4201837785f9

Example scenario

• You have a Scan model with attributes.
• You have a ScanController#show action.
• A user is viewing a Scan through the show.html.slim|haml|erb view template.

vitobotta

// This code is to be used with https://turbo.hotwire.dev. By default Turbo keeps visited pages in its cache 
// so that when you visit one of those pages again, Turbo will fetch the copy from cache first and present that to the user, then 
// it will fetch the updated page from the server and replace the preview. This makes for a much more responsive navigation 
// between pages. We can improve this further with the code in this file. It enables automatic prefetching of a page when you
// hover with the mouse on a link or touch it on a mobile device. There is a delay between the mouseover event and the click
// event, so with this trick the page is already being fetched before the click happens, speeding up also the first 
// view of a page not yet in cache. When the page has been prefetched it is then added to Turbo's cache so it's available for
// the next visit during the same session. Turbo's default behavior plus this trick make for much more responsive UIs (non SPA).

schneems

class Add
  attr_reader :result, :is_negative
  def initialize(a, b)
    @result = a + b
    @is_negative = @result < 0
  end
end


def add(a,b)