spicycode

# 0 is too far from ` ;)
set -g base-index 1

# Automatically set window title
set-window-option -g automatic-rename on
set-option -g set-titles on

#set -g default-terminal screen-256color
set -g status-keys vi
set -g history-limit 10000

matope

#NoSQLデータモデリング技法

原文：NoSQL Data Modeling Techniques « Highly Scalable Blog

I translated this article for study. contact matope[dot]ono[gmail] if any problem.

NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティックな理論に欠けている。本稿で、私はデータモデリングの視点からのNoSQLシステムファミリーの短い比較といくつかの共通するモデリングテクニックの要約を解説したい。

本稿をレビューして文法を清書してくれたDaniel Kirkdorfferに感謝したいと思う

MohamedAlaa

tmux shortcuts & cheatsheet

start new:

tmux

start new with session name:

tmux new -s myname

railwaycat

#!/usr/bin/perl

# Emacs starter for Emacs mac port

# Thanks to Aquamacs Project and David Reitter

my $args = "";
my $tmpfiles = "";

for my $f (@ARGV) {

disnet

defaults write -app Skim SKAutoReloadFileUpdate -boolean true

misho104

\usepackage{amsmath,arev,mathspec}
\setmainfont{Roboto}
\usepackage[italic,selfGreek]{mathastext}

tkf

kaityo256

研究者として生きていくコツ

これは卜部さんの優秀なプログラマーになるためのコツに影響されて書いたものです。

著者について

自分を構成する要素は、大きい順にシステムエンジニア、プログラマ、研究者だと思っています。でも、おそらく給料は「研究者」として払われているため、研究者として生きていくコツとしました。僕はさほど優秀とは言えませんが、とりあえずそれなりに長いことそれで食っています。大学の教授のウェブサイトに「研究者としてのコツ」みたいなことが書いてあることがありますが、これには「既に大学の教授になっている人が書いている」という強烈なバイアスがかかっています。もちろん参考になることも書いてありますが、「死ぬほど研究しろ、研究のことだけ考えろ」的な文章が多い印象です。これは普通の人にとって役に立たない助言です。これは平均的な研究者として生きていくための戯言、ポエムだと思ってください。

健康第一

voluntas

デスマーチが起きる理由 - ３つの指標

著者： 青い鴉（ぶるくろ）さん @bluecrow2

これは結城浩さんの運用されていた YukiWiki に当時 Coffee 様 (青い鴉（ぶるくろ）さん）がかかれていた文章です。 ただ 2018 年 3 月 7 日に YukiWiki が運用停止したため消えてしまいました。その記事のバックアップです。

今は 404 ですが、もともとの記事の URL は http://www.hyuki.com/yukiwiki/wiki.cgi?%A5%C7%A5%B9%A5%DE%A1%BC%A5%C1%A4%AC%B5%AF%A4%AD%A4%EB%CD%FD%CD%B3 になります。

昔、自分がとても感銘を受けた文章なので、このまま読めなくなるのはとてももったいないと思い、バックアップとして公開しています。

noto

これは私が支援先に提供した、1 on 1 に関するノウハウや、思いを述べたドキュメントを元にしています。企業の枠を超えて共有したいことが多いので、ここに貼ります。

概要

• 世の中には 1 on 1 の本があるようですが、とりあえずは『1 on 1 で 何を話すのか？ マネージャ/ソフトウェアエンジニアの立場から - サンフランシスコではたらくソフトウェアエンジニア』を読んでもらえればよいと思います (higepon さんに感謝!)。
• 1 on 1 は 1 対 1 で話すミーティングで、基本定期的にやります。上長とメンバーとの間で行うのが基本です。
• グループ/チームでのミーティングを補完するためのものです。
  • みんなの前では話しづらい、込み入った内容を話します。
  • チームとして行っているタスクの進捗確認に 1 on 1 を使うのは避けましょう。それは 1 on 1 の目的に沿っていません。
• 基本、「メンバーの時間」と捉えてください。メンバーが話したいこと、上長に質問したいこと、相談したいことを話す時間です。
• ですので、上長は相手の話をさえぎらず、聞くことに徹してください (話すのが得意な人、好きな人がマネージャになっている可能性が高いというバイアスに注意しましょうｗ)。