eliperelman

#include <AFMotor.h>

const float rpm = 6.999999;
const int stepsPerRevolution = 200;
const int shieldPort = 1;
AF_Stepper motor(stepsPerRevolution, shieldPort);

void setup() {
  // set up Serial library at 9600 bps
  Serial.begin(9600);

eliperelman

                                         JSWEEKLY BINGO
+-------------------------------+-------------------------------+-------------------------------+
|  An article from someone who  |                               |                               |
|        just figured out       |    Baby's first functional    |    How to do this one very    |
| prototype-based OO and thinks |          programming          |   specific thing in Node.js   |
|  everyone else needs telling  |                               |                               |
+-------------------------------+-------------------------------+-------------------------------+
|                               |                               |                               |
|     A new jQuery release      |    A job in San Francisco     |   An introduction to an MVC   |
|                               |                               |           framework           |

eliperelman

Command to run:
ssh -L 2222:localhost:8501 user@remoteserver.com

where 2222 is the local port mapping it can be any number above 1000

where localhost must be set to localhost and refers to your current connection

where 8501 is the port you will be opening up on the remote machine

where user@remoteserver.com is the first hop in your quest for internal access

eliperelman

lib-cov
*.seed
*.log
*.csv
*.dat
*.out
*.pid
*.gz

pids

eliperelman

package com.eliperelman.plugins.headsup;

import org.bukkit.event.Listener;
import org.bukkit.plugin.java.JavaPlugin;

public class main extends JavaPlugin implements Listener {
    @Override
    public void onEnable() {
        getServer().getPluginManager().registerEvents(this, this);
    }

eliperelman

/^(?:(?!TOKEN).)*$[\r\n]/igm

eliperelman

var siteRoutes = {
    'login': 'layouts/login',
    'index': 'layouts/site'
};

App.ApplicationView = Ember.View.extend({
    layoutName: function () {
        var currentPath = this.get('controller.currentPath');

        if (siteRoutes[currentPath]) {

eliperelman

# Usage:
# wallpaper path/to/image.png

function wallpaper() {
  image=`echo $(cd $(dirname $1); pwd)/$(basename $1)`

  cd /System/Library/CoreServices

  sudo rm -f DefaultDesktop.jpg
  sudo ln -sf $image DefaultDesktop.jpg

eliperelman

I/Gonk    ( 1902): Setting nice for pid 1990 to 1
I/Gonk    ( 1902): Changed nice for pid 1990 from 18 to 1.
I/GeckoDump( 1902): XXX FIXME : Got a mozContentEvent: activity-choice
I/Gonk    ( 1902): Setting nice for pid 2479 to 18
I/Gonk    ( 1902): Changed nice for pid 2479 from 18 to 18.
I/Gecko   ( 1902): [Parent 1902] WARNING: waitpid failed pid:2479 errno:10: file /home/eli/B2G/gecko/ipc/chromium/src/base/process_util_posix.cc, line 254
I/Gonk    ( 1902): Setting nice for pid 2479 to 1
I/Gonk    ( 1902): Changed nice for pid 2479 from 18 to 1.
E/[Gralloc-ERROR]( 1902): int gralloc_register_buffer(const gralloc_module_t*, const native_handle_t*):79 Unable to register handle 0x48486290 coming from different process: 1902
E/[Gralloc-ERROR]( 1902): int gralloc_register_buffer(const gralloc_module_t*, const native_handle_t*):79 Unable to register handle 0x48486330 coming from different process: 1902

eliperelman

Problem

The current process of timing the launching of Firefox OS applications is tricky. At the time of writing, most tests rely on the firing of the window onload event in order to determine when it is ready to use. Unfortunately with the state of dynamic script and view loading, it's impossible to tell when an application is truly ready to be interacted with. The loading of these assets can be deferred, sometimes even to the point where it occurs after window onload. If we want to hold an application accountable to recommended launch times, engineers need only defer more loading until the test measurement completes in order to make metrics look attractive. Couple this with the fact that the event isn't truly indicative of user interactivity and you can see that the current state is unsustainable.

Interim Solution

I suggested that if we were to get an accurate pulse on when launch times occur, it was going to take being told by the application itself. There are techniques we can use to try