deepak

# provisioning a rails stack with
# - ngixn web server and reverse proxy
# - puma app server
# - redis
# - elasticsearch
# - Amazon RDS using  etc for the SQL database 
# installed on an AWS EC2 instance running Ubuntu 14.04 LTS

# fix locale.
# needed to remove login warning 

deepak

1. view paths ?
2. where are the layout and view file located ?
3. is the database.yml valid ? 
   sanity check: eyeball if it is running locally.
4. any "very" old libs and/or known security vulnerabilities ?

for (1) can delete a partial and see the stacktrace

something like 

zudov

I recently read this interesting post about eventual values. One thing that struck me and which I failed to understand is:

• Eventual Values can be interacted with like normal values.
• If an Eventual Value is part of a simple value operation, then that expression resolves to a new Eventual > Value which resolves when all its Eventual Values are resolved.

If I understood the author correctly, that is supposed to be solving several problems:

1. "I don’t know if this is a Promise or not" (I don't know if it's the resolved result of the action, or the action itself).
2. "I’d really like to write code that interacts with values, and not Promises, and leave the machinery to the computer to work out".

isaacs

Promises vs Eventual Values

A few times on Twitter, I've complained that Promises are a poor conceptual stand-in for Eventual Values.

A colleague of mine pointed out that I tweet this or something like it every few months. He's correct, I do.

The responses usually flow in saying something to the effect of "Well,

deepak

installing MIT Schema

The SICP page recommends MIT scheme,
so that is what we will use

to install it, on Apple OSX using Homebrew:

  brew tap x11
  brew cask install xquartz

acdlite

/**
 * Basic proof of concept.
 * - Hot reloadable
 * - Stateless stores
 * - Stores and action creators interoperable with Redux.
 */

import React, { Component } from 'react';

export default function dispatch(store, atom, action) {

markrendle

Update, September 2016

OK, you can pretty much ignore what I wrote below this update, because it doesn't really apply anymore.

I wrote this over a year ago, and at the time I had spent a couple of weeks trying to get Kafka 0.8 working with .NET and then Node.js with much frustration and very little success. I was rather angry. It keeps getting linked, though, and just popped up on Hacker News, so here's sort of an update, although I haven't used Kafka at all this year so I don't really have any new information.

In the end, we managed to get things working with a Node.js client, although we continued to have problems, both with our code and with managing a Kafka/Zookeeper cluster generally. What made it worse was that I did not then, and do not now, believe that Kafka was the correct solution for that particular problem at that particular company. What they were trying to achieve could have been done more simply with any number of other messaging systems, with a subscriber reading messages off and writing

ryanflorence

Folder Structure

Please note

While this gist has been shared and followed for years, I regret not giving more background. It was originally a gist for the engineering org I was in, not a "general suggestion" for any React app.

Typically I avoid folders altogether. Heck, I even avoid new files. If I can build an app with one 2000 line file I will. New files and folders are a pain.

ryanflorence

.
├── actions
├── stores
├── views
│   ├── Anonymous
│   │   ├── __tests__
│   │   ├── views
│   │   │   ├── Home
│   │   │   │   ├── __tests__
│   │   │   │   └── Handler.js

oakes

Contents

• Why care about Rust?
• The Toolchain
• Creating a New Project
• Modules
• Crates
• Types
• References
• Mutability