a t e v a n s . c o m

(╯°□°)╯︵ <ǝlqɐʇ/>

Very helpful. Difficulty not addressed: load testing in production.

Javascript is an interesting language. While Ruby has a style guide, and Python has a few (including Google's, they are not critical to how your code functions. They just help avoid those "strip whitespace" commits that touch every line in your repo and permanently ruin git blame.

With Javascript, the style is the substance. Take these two for example:

var object = {
    method: function(data){ ... },
    _variable: 3

object2 = {
    method: function(datae){ ... },
    _variable: 2

var Klass = function(){
    this.method = function(data){ ... };
    this.variable = 4;
    return this;

These seemingly small differences might not affect how a short script works, but they are critical to how your app works as a whole. The first declares a single object. The second declares a global variable. The third declares effectively a factory function.

Newlines can result in syntax errors for strings. Missing semicolons can ruin your JS after compression. Using reserved words as object keys can break your code in some browsers. Failing to use === can result in unexpected behavior.

It is essential to use a Javascript style guide. Frameworks like Express and Angular can help standardize things like object and module declarations, and CoffeeScript can provide syntax sugar to cover simple issues.

Otherwise, AirBnB's style guide is comprehensive and helps show best practices. Pick something, and stick with it, especially if you are working on a team.

This is funny XD

=>    hashrocket
<=>   spaceship
~>    twiddlewaka
->    stabby lambda

Some random things I built to help deal with timezones in Ruby / JS

Update: Extracted this into a gem (in beta): HappyTime

Finally! A way to get a truly, really random number in Ruby. Forget rand(), messings with seeds, etc. This gem uses the real thing - true randomness. Amazing.

String#remove_formatting , from the StringEx library. Gets rid of unicode griefer chars, html entities, basically any BS you can think of.


Fred Wilson:

What you might miss, and I missed until recently, is that Tweetstorming has some unique characteristics, which I outlined in my storm, that make it different and possibly better in some respects.

What you also might have missed: tweet storms are annoying as hell, in that they clog up the receiver's timeline with a bunch of stuff they may or may not care about, and as a bonus are difficult to read in sequence / context.

Get a tumblr. Post an essay. Post a link to essay on Twitter. I hate that "let's monopolize all my follower's timelines" is gaining legitimacy by giving it a name.

Creating a Bucket Policy:

You use the AWS Policy Generator to generate a Bucket Policy. There are several examples online and Amazon has a ton of examples.

Allow viewing & downloading of S3 objects directly via a browser. If, for example, you send attachments via email and also want to link to them on S3.

AWS is so full of its own jargon at this point - set an S3 bucket policy and ACL, but make sure you have the right IAM key, and also CORS doesn't conflict. And that's just for S3. Don't even look at Route 51.

Everything you know about Unix server administration has been reinvented on AWS with slightly different names and parameters, so none of the knowledge is transferrable outside of Amazon's infrastructure. Heavy lock-in. I don't like it.

Time comparison with ActiveSupport failed

now = Time.zone.now => Wed, 19 Feb 2014 21:30:56 UTC +00:00 Time.zone.at(now.to_i) => Wed, 19 Feb 2014 21:30:56 UTC +00:00 now == Time.zone.at(now.to_i) => false

How is it possible?


Time.zone.at(now.to_i).to_i == now.to_i => true

Selected Answer (from jvperrin)

Ruby tracks time down to the nanosecond:

now = Time.zone.now => Wed, 19 Feb 2014 21:30:56 UTC +00:00 Time.zone.at(now.to_f) => Wed, 19 Feb 2014 21:30:56 UTC +00:00 now == Time.zone.at(now.to_f) => false

But if you compare the nanoseconds, you will see they are not the same, even when creating the time object using the float value, because the float value used to create the new time object is not as accurate as the nanosecond value of the time:

now.nsec => 956134961 Time.zone.at(now.to_f).nsec => 956134796

Got hit with this while testing.

From the docs:

params = ActionController::Parameters.new({
  person: {
    name: 'Francesco',
    age:  22,
    role: 'admin'

permitted = params.require(:person).permit(:name, :age)
permitted            # => {"name"=>"Francesco", "age"=>22}
permitted.class      # => ActionController::Parameters
permitted.permitted? # => true

Chainable method calls are wrong here. It's okay for doing the most basic possible forms, using all the Rails defaults, but for anything else it's crap. See bullshit like this - and that's for sanctioned nested_attributes type calls.

Let's take a simple example:

params = ActionController::Parameters.new(first: true, second: {first_hash: 1, second_hash: 2, third_hash: 3})

How do we get the values of both :first and :second ? If you know in advance what all the possible keys for :second are, you can do this:

params.permit(:first, :second => [:first_hash, :second_hash, :third_hash])

If you don't know exactly which keys are there, or want to use logic based on what keys are present... well, no. Definitely not.

If you're doing doing something like tags, lists, or other things that don't nicely map to one parameter => single-level hash, you're in for a rough ride. If you only want to allow certain attributes to be edited by certain users, you need a hacky workaround like building up a giant array or hash before calling .permit . If you want to call params.permit in a before_filter, get lost. If you want to save Javascript logs or something else with a totally arbitrary structure, go die in a fire.

A better model would be to pass a schema to StrongParameters. Imagine if we could call something like this:

def user_params
    user: {
      email: String,
      tags: [Array, String],
      happiness_level: Numeric,
      preferences: {
        remember_me: Boolean,
        email_me: Boolean
      js_analytics: JSON,
      js_events: Array,
      js_logs: Hash

This would be way nicer - you could specify conversions so you don't get strings where you expect numbers or booleans. You could specify what sub-attributes to allow on a hash or array, or just use the raw class if you want to sort it out yourself. And, this theoretical schema method would just return a new Parameters instance with the schema applied - if you wanted to get different attributes earlier or later in the request, just call params.schema again.

I've been developing with Rails for ten years now. If I find this crap difficult, I can't imagine what people in coding boot camps must think of it.

Update: the rails_param looks like a good alternative.