STEP 1: First Install HomeBrew, download it from http://brew.sh
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
STEP 2: Install Hadoop
$ brew search hadoop
$ brew install hadoop
<!DOCTYPE html> | |
<html lang="en"> | |
<head> | |
<meta charset="UTF-8"> | |
<title>Keycloak JS Demo</title> | |
<style> | |
body { |
STEP 1: First Install HomeBrew, download it from http://brew.sh
$ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
STEP 2: Install Hadoop
$ brew search hadoop
$ brew install hadoop
[DEFAULT] | |
product_ranking_start = 10 | |
product_ranking_steps_down = 0.2 | |
cat_ranking_start = 10 | |
cat_ranking_steps_down = 0.2 | |
product_recommendations_campaignArn=arn:aws:personalize:us-east-2:11123456:campaign/es-test03-hrnn | |
product_rankings_campaignArn=arn:aws:personalize:us-east-2:222789:campaign/es-test03-rank | |
property1_recommendations_campaignArn=arn:aws:personalize:us-east-2:3333456:campaign/es-test03-cat-hrnn | |
property1_rankings_campaignArn=arn:aws:personalize:us-east-2:444789:campaign/es-test03-cat-rank |
Create a buffer DB inbetween the client and the database server that kept common objects in memory (like the whole page and comments section) allowing fast edits (and appends) and only syncing it all to the DB every X seconds or after the object has fallen off the front page and things have slowed down for it.
A incrementing counter would be needed as we would need to sync stuff before it has a DB id? Or we could get a database ID on first save, but still use the buffer DB until things died back down.
Redis could be the sync store since multiple servers could read-write to it in an ATOMIC / ACID way without problems. You cannot ever prevent race conditions (two people making changes to a comment); only race conditions that clober previous updates (two people saving a comment at the same time resulting in a lost comment).
Each element of the object which needs CRUD support would need to be a new HASH
with the ID stored in a SET
(except for the root objec
application { | |
config { | |
baseName gateway, | |
packageName com.okta.developer.gateway, | |
applicationType gateway, | |
authenticationType oauth2, | |
prodDatabaseType postgresql, | |
searchEngine elasticsearch, | |
serviceDiscoveryType eureka, | |
testFrameworks [protractor] |
#!/bin/sh | |
# Command-line world clock | |
# Taken from http://stackoverflow.com/questions/370075/command-line-world-clock | |
# .worldclock.zones file looks like: | |
# US/Pacific | |
# Europe/Berlin | |
# Chile/Continental | |
: ${WORLDCLOCK_ZONES:=$HOME/.worldclock.zones} |
# Author: Pieter Noordhuis | |
# Description: Simple demo to showcase Redis PubSub with EventMachine | |
# | |
# Update 7 Oct 2010: | |
# - This example does *not* appear to work with Chrome >=6.0. Apparently, | |
# the WebSocket protocol implementation in the cramp gem does not work | |
# well with Chrome's (newer) WebSocket implementation. | |
# | |
# Requirements: | |
# - rubygems: eventmachine, thin, cramp, sinatra, yajl-ruby |
digraph cloud_platform { | |
rankdir=LR | |
splines=ortho | |
subgraph cluster_1 { | |
11 -> 12 -> 13 -> 14 | |
} | |
subgraph cluster_2 { | |
21 -> 22 -> 23 -> 24 |