Hiroki Uchida nikuyoshi

コードレビューの基本

一番大事な事

ソースコードはプロジェクトの共同所有物である

誰かだけが触れるコードを無くす

ラムダノート執筆の手引き

ラムダノートでの執筆を検討いただき、ありがとうございます。執筆に際して当社からのお願いをまとめます。

執筆を始める前に

まずは企画の方向性を編集者と共有しましょう。 内容案と書名案のほかに、以下の4点の言語化をお願いしています。

Set parameters

$ export ECS_CLUSTER_NAME={YOUR_ECS_CLUSTER_NAME}
$ export ECS_SERVICE_NAME={YOUR_ECS_SERVICE_NAME}

RegisterScalableTarget

THIS WAS ORIGINALLY POSTED ON MY TUMBLR ON FEB 25, 2011. I forgot I had a Tumblr account. I recently logged in (in light of the acquisition by Automattic), found some old posts, and I'm republishing them exactly as they were with zero modifications.

CloudFormation: The Big Picture

Amazon announced CloudFormation to the public yesterday, and while the general opinion I could glean from various sources shows that people are excited about this new technology, many are still unsure what it is and how it fits into their current cloud workflow. I feel as though I have a firm grasp on CloudFormation and will attempt to answer some questions here.

Note: I'm definitely not a representative of Amazon in any way, and anything here is simply my educated opinion on the matter.

blacklist/whitelist master/slave に関する情報集め

blacklist/whitelist、master/slave という単語は相応しくないという意見に OSS がどの様に対応すべきかを自身で考える為の情報集めです。見つけ次第、逐次更新していきます。

僕(mattn) 自身は black lives matter に同意をしています。blacklist/whitelist、master/slave という単語を廃止する事が、歴史的背景を持たない文化圏では特定の意味を持たなかった為、個人的には若干思う所はありますが、廃止自身に反対するつもりはありません。

昔から、主副を表す物には master/slave という単語が使われてきました。ハードディスクの IDE、仮想端末(pty)、色々あります。またネットワークの IP フィルタリングに関しては blacklist/whitelist と表記した物が今でも沢山あります。

我々日本人が意識せずに使っていた blacklist/whitelist、master/slave という単語が、人々にどの様に影響しうるのか、今後 OSS としてどの様に関わっていけば良いかを理解する上で、自分なりの情報集めをしたいと思っています。

この記事はpyspa advent calendar 2020の18日目の記事です。前日は、flagboyの配られたカードで勝負するでした。主旨は異なりますが、徒然草百十段の「双六の名人」が思い出されました。明日はYutaka Matsubara a.k.a. mopemopeさんの記事となります。お楽しみに。

1ヶ月で10,000行くらいのコードを書いた話

行数を書くと「いやいや、私はもっと高い生産性を持っている」、という方は少なくないだろう。登大遊氏に至っては、ネットワークプログラミングという複雑な領域での実装でありながら「1日に少なくとも3,000行程度、多く書くときで10,000行」と述べており、凡才さを思い知らされる。

さて、この記事は、私のような動物でも高効率にコードを書くために何をしたのかを備忘として残しておく主旨である。

開発環境編

name

cognitive-rhythm-writing

description

説明的な文章に緩急を設計するための規範。緩急を装飾ではなく認知モードの切替（観察→逡巡→断定→再観察）と未回収の緊張の管理として扱い、文の拍、段落の密度波形、節の入り方、緩みと駄文の判別、執筆後の機械的な点検手順を定める。読み物として読ませたい章・記事・解説文を生成するとき、または「密度はあるが平坦でおもしろくない」文章を診断・修正するときに使用する。

認知リズムを生むための日本語ライティング規範

密度の高い文章が退屈になるのは、情報が多いからではなく、全文が同じ認知モードで書かれているからである。この規範は、読者の認知モード（観察する、迷う、確信する、確かめ直す）を意図的に切り替え、常に「続きを読む理由」を維持することで、読み進める推進力を作る。

	#!/bin/sh

	#######################################################
	#
	# Precondition: Complete executing the following command
	# ssh-keygen -t rsa
	#
	# How to use:
	# sh ssh-auto-auth.sh {user name}@{IP address}
	#

	AWSTemplateFormatVersion: 2010-09-09
	Description: It's time to redemption
	Resources:
	# これが罪深くも過去に手で作られた IAM ユーザー (Import の対象)
	MyHandCraftedIAMUser:
	Type: AWS::IAM::User
	DeletionPolicy: Retain

	# こちらは CFn でちゃんと作る IAM グループ
	MyCFnCreatedIAMGroup: