jmervine

require 'net/http'
class Item 
  #replaced with dynamic initialization below 
  #attr_reader :id, :user, :state
  #
  #
  # Sample JSON
  #
  # [{ "id":1, "user":"john", "state":"active" },
  #  { "id":2, "user":"jane", "state":"inactive" },

steveklabnik

require 'minitest/autorun'

class CaptureIoTest < MiniTest::Unit::TestCase
  def test_puts
    out, err = capture_io do
      puts "hey"
    end

    assert_equal "hey\n", out
  end

benaryorg

#![feature(core_intrinsics)]

struct Something
{
	data:u32,
}

impl Something
{
	pub fn name(&self)->String

dolfelt

import React, { Component, PropTypes } from 'react';
import createBrowserHistory from 'history/createBrowserHistory';
import History from 'react-router/History';
import StaticRouter from 'react-router/StaticRouter';

import { LOCATION_CHANGE } from './routerReducer';

class DispatchingRouter extends Component {
  static propTypes = {
    store: PropTypes.object,

carols10cents

Ruby to Rust Cheat Sheet

The goal of this is to have an easily-scannable reference for the most common syntax idioms in Ruby and Rust so that programmers most comfortable with Ruby can quickly get through the syntax differences and feel like they could read and write basic Rust programs.

What do you think? Does this meet its goal? If not, why not?

Variables

Ruby:

slikts

React context vs Redux in 2020

The [React docs][condoc] give some example use cases for context:

Context is designed to share data that can be considered “global” for a tree of React components, such as the current authenticated user, theme, or preferred language.

The common property of these use cases is that data like the current theme doesn't change often and needs to be shared deep down the component tree, which would be cumbersome with "[prop drilling][drill]". Something else that needs to be shared everywhere is the application state when using a "single source of truth" pattern, so it would follow that the context API would help with that as well, but there's a catch: components that use context will rerender every time that the provided value changes, so sharing the whole application state through context would cause excessive render lifecycles.

myitcv

/*
Copyright (c) 2015 Paul Jolly <paul@myitcv.org.uk)

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

vjpr

ChromeRPC

I will eventually turn this into a bower module when I have time with tests and the whole shebang.

Usage

background.html

darky

virtual_class = (classes...)->
  classes.reduceRight (Parent, Child)->
    class Child_Projection extends Parent
      constructor: ->
        # Temporary replace Child.__super__ and call original `constructor`
        child_super = Child.__super__
        Child.__super__ = Child_Projection.__super__
        Child.apply @, arguments
        Child.__super__ = child_super

mathisonian

The final result: require() any module on npm in your browser console with browserify

This article is written to explain how the above gif works in the chrome (and other) browser consoles. A quick disclaimer: this whole thing is a huge hack, it shouldn't be used for anything seriously, and there are probably much better ways of accomplishing the same.

Update: There are much better ways of accomplishing the same, and the script has been updated to use a much simpler method pulling directly from browserify-cdn. See this thread for details: mathisonian/requirify#5

inspiration