alficles

Nuclear Power

Nuclear Power is a major new feature introduced to Factorio in version 0.15. It requires higher level technology compared to either Solar Power or Steam Boiler Power, but it offers very high power output in exchange. It's a great solution for middle- to end-game power generation and it works well in combination with other power generation techniques.

This guide is written for people who want to know exactly how nuclear power works, but don't necessarily want all the solutions. It focuses on what you should do and what you should know to get Nuclear up and running, but doesn't tell you what to do or exactly how to solve the problems.

First Steps

Technology Required: Nuclear Power You can mine uranium ore sooner, but you'll need the Nuclear Power technology to do anything useful with it.

gilbertw1

Macbook Arch Guide

• Installation
• General Setup
• System Time
• Display
• Keyboard
• Touchpad
• Sound
• Bluetooth

Avaq

const I  = x => x
const K  = x => y => x
const A  = f => x => f (x)
const T  = x => f => f (x)
const W  = f => x => f (x) (x)
const C  = f => y => x => f (x) (y)
const B  = f => g => x => f (g (x))
const S  = f => g => x => f (x) (g (x))
const S_ = f => g => x => f (g (x)) (x)
const S2 = f => g => h => x => f (g (x)) (h (x))

chantastic

Hi Nicholas,

I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:

The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't

eladmeidar

require "socket"

class Client
  def initialize(host, port)
    @server =  TCPSocket.open( host, port )
    @request = nil
    @response = nil
    listen
    send
    @request.join

eliotsykes

SSH to the vagrant OS command line.

Terminal $> vagrant ssh

Login to postgres database as vagrant user with the psql client:

vagrant@rails-dev-box: psql -U vagrant postgres

bitemyapp

The Learning Haskell guide has been moved to a git repo to enable outside contribution

Find it here: https://github.com/bitemyapp/learnhaskell

linjunpop

Deploy Rails 4 app with Dokku on DigitalOcean

Install dokku

First create a Ubuntu 13.04 x64 droplet on DigitalOcean Control Panel

Then ssh with root account, run this in termianl:

$ wget -qO- https://raw.github.com/progrium/dokku/master/bootstrap.sh | sudo bash

jed

How to set up stress-free SSL on an OS X development machine

One of the best ways to reduce complexity (read: stress) in web development is to minimize the differences between your development and production environments. After being frustrated by attempts to unify the approach to SSL on my local machine and in production, I searched for a workflow that would make the protocol invisible to me between all environments.

Most workflows make the following compromises:

• Use HTTPS in production but HTTP locally. This is annoying because it makes the environments inconsistent, and the protocol choices leak up into the stack. For example, your web application needs to understand the underlying protocol when using the secure flag for cookies. If you don't get this right, your HTTP development server won't be able to read the cookies it writes, or worse, your HTTPS production server could pass sensitive cookies over an insecure connection.

• Use production SSL certificates locally. This is annoying