Skip to content

Instantly share code, notes, and snippets.

@mackuba

mackuba/rupy_2012_notes.md

Last active December 17, 2015 22:09
Show Gist options
  • Save mackuba/5680221 to your computer and use it in GitHub Desktop.
Save mackuba/5680221 to your computer and use it in GitHub Desktop.
Download ZIP
Notes from RuPy 2012 (http://12.rupy.eu)
Raw
rupy_2012_notes.md

Javascript as language for native apps (Stepan Bechynsky)

  • Windows RT - new system library for Windows apps, unified for Intel and ARM computers and tablets
    • can be used from C++, C# (with XAML) or HTML/Javascript apps
    • HTML/Javascript apps can access the whole RT API and standard browser API
    • WinJS - Javascript bindings for WinRT and application framework
  • Visual Studio 2012 is needed to build the app, but most of the work can be done on any OS, as it’s mostly just JS
  • controls: <div data-win-control="WinJS.UI.ToggleSwitch" data-win-options="{title: '...'}">
  • access from JS to any system APIs, like camera capture, updating live tiles
  • package.appmanifest - application config, e.g. permissions that the app requests from the user
  • live tiles work only for apps that have been started by the user before since system boot, so they had a chance to create some communication channels etc.

Python performance landscape (Maciej Fijalkowski)

  • Guido says: built-in data types are your friends - use tuples, dicts, lists -> this sounds like the opposite of Ruby best practices (see "primitive obsession")...

Event oriented architecture and big client side applications (Mihael Konjevic)

  • authors of JavascriptMVC, CanJS, StealJS, jQuery++
  • modules should be:
    • dumb (do one thing)
    • lonely (should know as little as possible about context and other modules)
    • replaceable
  • custom events in jQuery: $([Models.Search]).trigger('search', searchData)
  • instead of objects telling other objects what to do, objects observe other objects for events that they’re interested in; e.g.:
    • search widget sends a 'search' event
    • history module saves an entry when search is performed
    • disabler module enables/disables tabs when that happens
    • results module loads data
    • search widget doesn’t know about any of them
  • "The secret to building large apps is to never build large apps" - don’t even try to make large apps, make small components that cooperate
  • folder structure:
    • tabs/* - tabs module
    • tabs.js - module code
    • tabs.html - demo page (can be run with just that module, independently of other modules)
    • funcunit.html - test page
    • tabs_test.js - test code
    • tabs.css - CSS for the module

Breaking the Big Ball of Mud (James Coglan)

  • developer at Songkick, slides.jcoglan.com
  • initial state:
    • standard Rails app structure, several "subprojects" in vendor - kind of separated but using models and other things from the main app
    • even if it looks modular, it usually has hidden dependencies everywhere
    • monolythic deployment - change in one module means whole app needs to be redeployed
    • build took 2 hours, deploys took days
    • reasons: unawareness of tech debt, focus on new features
  • step 1: extract shared code (business logic, models from app/models), test and support stuff (lib) etc.)
    • songkick-core and songkick-domain
  • step 2: encourage small libraries
    • small modules are easier to develop, test and deploy
    • made a dependency manager - modules declare their dependencies and only use what is declared
    • no circular dependencies
    • simplifies testing and deployment
    • you can see the dependency tree
  • step 3: break the dependencies, make smaller processes
    • extracted shared logic into web services, split along domain boundaries
    • encapsulate data stores and business logic
    • the API doesn’t have to reflect the ActiveRecord object graph, it should be designed around use cases
    • "Remember that the job of your model layer is not to represent objects but to answer questions. Provide an API that answers the questions your application has, as simply and efficiently as possible." (http://seldo.com/weblog/2011/08/11/orm_is_an_antipattern)
    • you'll need to write some support code to handle HTTP-based communication, build pseudo-models that wrap received JSON data - write this code once
    • even if it means duplicating some code in multiple services, so be it; sometimes you should repeat yourself
    • don’t do this too early, do it when you learn a lot about your business domain
  • http://songkick.com/devblog
  • thrift - for building web services that talk to each other

JS - from good to great (an ode to assert) (Olov Lassus)

Rust from Python and Ruby (Armin Ronacher)

  • new language by Mozilla, still under construction
  • strongly typed, but types are inferred
  • immutable by default
  • concurrency via message passing

Fly, You Tools! (Piotr Szotkowski)

Slides: http://talks.chastell.net/rupy-2012/

  • git:
    • git commit --allow-empty - lets you create an empty commit
    • sponge - let you pipe contents of a file back into that file
    • git rebase --autosquash - automatically joins commits named e.g. "fixup! title of some other commit"
    • git diff --ignore-all-space / git diff -w
    • git checkout - - switch to previously used branch
  • postgres:
  • tr -d s - removes s’s
  • tr ' ' + - replaces spaces with pluses
  • bc - calculates whatever is passed to it
  • xargs without args - concatenates all lines into one line
  • pv - progress bar
  • diff <(...) <(...) - diffs result of two commands
  • pgrep, pkill - kill processes by name
  • timeout - kills a program after given time
  • ncdu - what takes space on the disk
  • proxylocal - expose local port outside
  • man $(ls /bin /usr/bin | shuf -n 1)

When not to use OO (Mike Burns)

Why should I care about Rails 4? (Steve Klabnik)

Video: http://www.youtube.com/watch?v=yV_EYXr7aWs

  • Ruby 1.9.3 required
  • some features extracted to gems (e.g. observers, ActiveResource, page and action caching, mass assignment)
  • many of the new features are gems that you can use right now
  • Rails.queue.push(job) - common interface for background processing (in development it will use an in-memory queue and will process jobs in threads inside the same process)
  • mailers automatically use queues now
  • ActionController::Live - streaming data
  • Sprockets is much faster
  • PATCH added, use it instead of PUT for #update (PUT can still be used)
  • 4.0 only adds new features and deprecations, 4.1 will remove old features
  • routing concerns
  • turbolinks - kind of unstable now
  • ActiveRecord's all returns a relation, use to_a to return an array
  • don’t use match in routes without specifying allowed methods
  • see gems: rails-api, active_model_serializers (useful for interacting with frontend frameworks like EmberJS)

Challenges in A/B Testing Mobile Native Apps (Eric Florenzano)

  • you can download a manifest with all A/B testing options at startup, and make choices offline on the phone
    • what about first launch, tests on the first screen?
  • you can bundle the manifest in the app itself
    • it adds a step to the build process and prevents you from updating the data easily
  • goal tracking (user passed a point in the app)
    • you have to keep a database locally and upload it periodically because the user might not have a connection all the time
    • upload everything when app quits
    • you need to check if you’re not receiving the same data twice or receiving very old data from a month ago
  • user should have a consistent experience, once they’re placed in a test bucket they should stay there for the duration of a session, so that the UI doesn’t suddenly change
    • for mobile users, session might be until next time they update the app, because users don't usually log out of their apps (but they're used to changes when they update the app)
  • problem: updates on native mobile apps may take a lot of time to get to the users (because of app store approval etc.)
    • parametrized tests - have parameters in tests that you can change on the server (label text, colors etc.)
    • you need to think ahead what options you will need
    • data must be kept compact, don’t put e.g. binary data there
    • client must be able to download the manifest and pick the options really fast so that the UI doesn’t wait
  • some questions to ask yourself:
    • which variation is winning, how confident are we about it?
    • how many people have seen this element and how many of them have reached the goal (e.g. completed the registration)?
  • ABBA (http://www.thumbtack.com/labs/abba) - calculator for AB tests
  • don’t change too much, do small targeted changes because it might be confusing for the users if they have a very different UI than their friend has
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment