打ち合わせで実現したいこと

良い打ち合わせは自然とは生まれないものです。自戒の意味も込めて考え直してみました。

参加者と、いわゆるファシリテーターの役割がごっちゃになっているので注意が必要かもしれません。


  • 目的を明確にする
    • 何のために集まっているか?
    • 情報を知ってもらう / 案を出す / 決断する(どれか1つの場合もあるし、複数の場合もある)
  • 進行する
    • 上記の目的が複数に該当する場合、いまどの段階なのか意識する
      • 参加者に意識してもらう、も大事
    • 意見が少ない(が、何か言いたそうな)人にタイミングよく振る
    • ある観点で情報が充足してきたら観点を増やす
    • 意見が盛り上がらなかったとき用の話題を出す
      • 事前に用意しとく
  • 次の行動を決める
    • 誰が / いつまで / 何を
      • 何を、はとくに曖昧になりがち;参加者全員で具体的に認識をあわせることが理想
    • もし早く終わったらさっさと終わる
  • 上記を準備しとく
    • できれば事前に展開しとく

これらは文字にしたら誰にとっても当然なことに見えると思いますが、なかなか(部分的にですら)達成された打ち合わせには出会えません。

あと、教科書的にはこれらを「常に意識しましょう」とか言いたくなりますが、何かを常に意識するなんて(少なくとも自分には)不可能なので、チェックポイント的に時間を区切って確認する、とかの技術も別途必要ですね。

ドヴォルザークの序曲「オセロ」について

ドヴォルザークの序曲「オセロ」作品93は、ここ数年で出会ったクラシック曲の中で断トツに好きな曲だ。

youtu.be

この曲は序曲3部作の3曲目らしい。2曲目はドヴォルザークの作品の中でも有名な「謝肉祭」。アマチュアオケの演奏会情報を掲載されている i-Amabile さん をみてみると、これまでの演奏回数は2017年12月19日現在で「謝肉祭」が119回、「オセロ」が11回と、10倍以上の差がある。たしかに、謝肉祭と比べられたら派手さは少ない。というか地味。

そんな地味なこの曲のどこが好きなのかというと、上の音源でいうと序盤である4:00以降に現れる、映画音楽的な勇ましい旋律、この旋律が一瞬で終わってその後同じ形では二度と登場しないところ。 こんなに格好いいのに。チャイコフスキーだったらこれをもう2、3回は使ってるよ。8:30あたりでもう一度現れると思いきや肩透かし。9:50あたりから、すこし形を変えて登場。でもあの頃の姿じゃない。コーダでついに来るか!と思ったらやっぱり来ない。で、ドヴォルザーク特有のアクロバティックなコード進行で突然終わり!

で聴き終わって、あの旋律がまた聴きたくなるんだ... 序盤にいいところを持ってきて、期待感を膨らませたまま、そのカタルシスを解放させるでもなく終わる。もしこれが映画だったら不快だろう。でも音楽なんだから、そのまま繰り返しても誰も文句を言わないはずだ。しかしドヴォルザークはそうせず、敢えて手間をかけて変奏した。1回聴いただけでは満足できない音楽体験、それを彼は目指していたんだ(本当か?)。

それでいて、何回も聴いているうちに、前奏も内声が充実しててクソ良いことに気づいたり、各楽器のソロ、アンサンブルがめっちゃ良かったり、そういえばドヴォルザークのここまで洗練されて劇的な曲って知らないかも?と思いはじめたり、「ここ完全に新世界じゃん!」とツッコミをいれたり(オセロと新世界は作曲時期が重複している;新世界のほうが完成が3年ほど後)、いろいろな楽しみ方ができるようになっている。

いつか演奏したい。

Elasticsearch でつまづいた話 (5)

Bucket Selector Aggregation というのがある。Terms Aggregation を柔軟にしたようなもので、「あるフィールドで特定の条件を満たすレコードの単位で集計」というような記述ができる。

下の例では 2 つのフィールドをまたがって条件を指定している。  

{
  "bucket_selector": {
    "buckets_path": {
      "my_var1": "the_sum", 
      "my_var2": "the_value_count"
    },
    "script": "params.my_var1 > params.my_var2"
  }
}

これを Nested Aggregation 等と組み合わせて使用したい場合、フィールド名の指定が素直にいかない。 Nested の外から Nested 以下のフィールドを指定しようとすると > を使ってたどる必要がある。

{
  "aggs" : {
    "nested_agg" : {
      "nested" : {
        "path" : "product"
      },
      "aggs" : {
        "sum_values" : {
          "sum" : {
            "field" : "price"
          }
        }
      }
    },
    "bucket_agg" : {
      "bucket_selector" : {
        "bucket_path" : {
          "var" : "nested_agg>price"
        },
        "script" : {
          "var > 100"
        }
      }
    }
  }
}

この > でフィールドをたどるのはおそらく bucket_selector に限った話ではないと思うが、調べてもなかなか情報に当たらなかったので結構なハマりポイントだと思う。

Node.js × TypeScript 勉強中

Node.js × TypeScript の勉強中。いずれも触るのはほぼ初めてです。各種チュートリアル記事を読んで試していますが、「このおまじないは何?どっからきたの?」状態なので、今回疑問に思ったことがそれぞれがどの文脈に帰属する問題なのか (Node.js / TypeScript あるいは他のなにか) をまとめました。

こういう、新しいものを学ぶときの手探り感を大事にしていきたい。

知っていたこと

  • Node.js はサーバーサイドで動く js だよ
  • TypeScript をコンパイルすると JavaScript になるよ; pure js と違って型があるよ
  • npm はパッケージをいい感じにインストール・管理してくれるやつだよ; 設定は package.json に記述するよ

export / import ってなんやねん

MyApp.js

export class MyApp {
  doSomething(){
    ...
  }
}

app.js

import {MyApp} from './MyApp'

let app = new MyApp();
app.doSomething();

export / import は ES6 (もともとは CommonJS で生まれたらしい) で既定される構文で、 js ファイルをまたがってモジュール (変数や関数) を利用したい場合に使用します。サーバーサイド js の繁栄に伴いモジュール管理の重要性が高まってきたことによって導入された構文のようです。従来のワークアラウンドとしては、グローバルに名前空間を切って擬似的にモジュール化を実現するという手段がありましたが、依存関係を解決できませんし、グローバル汚染はやはり発生してしまっていました。 export / import によって、これをスマートに実現できるようになったわけですね。

経緯については こちらの記事 で大変わかりやすく書かれています。

typings ってなんやねん

Node.js × TypeScript のチュートリアル記事でよく登場するのが以下のおまじないです。

npm install -g typescript
npm install -g typings

typescript はわかるとして typings はなんでしょうね。これは TypeScript の型定義を管理してくれるツールのようです。何もしないと TypeScript が Node.js の型を解釈できないわけですが、 typings install dt~node のようなコマンドによって、TypeScript のコンパイルが通るようにしてくれます。

型のインストール設定は typings.json に書きます。なので git 管理するときはこいつを突っ込んでおけば良いようです。

一方で、 typings を使わない記事では以下のようなおまじないが登場していました。

npm install @types/node --save

調べてみると、 @types も TypeScript の型定義を管理してくれるようです。こちらの方が新しいんですね。package.json に追加するだけでよく、 typings のインストールや typings ファイル群 / typings.json を管理する必要がないため、シンプルに済みそうです。ただし、 TypeScript の中の人の記事 によれば this is still a work in progress. だそうですから、このあたりのエコシステムはまだ変わる可能性がありそうです。

typings 以前には tsd というものもあったらしいですが、もはや非推奨らしいので触れません。

npm install -g ってなんやねん

↑でも登場していました。npm install のオプションであることはひと目でわかりますが、多くのインストールのインストラクションで指定されています。

g は global を意味するようで、どこで実行してもパスが通るようにするためのものです。 windows であれば /appdata/Roaming/npm に配置されるようですね。

世間では高い頻度で使用されるオプションですが、できるだけ使いたくない派 の方もいらっしゃるようです。たしかに、ローカルで動いてたけど別の環境で動かなくなった、ということでハマることは容易に想像できますねー。

use strict ってなんやねん

TypeScript をコンパイルすると、生成された js ファイルの先頭行に "use strict"; が登場します。これは ES5 以降の規格で、指定すると js の構文チェックがより厳格に行われるようになるらしいです。

pure js でも、将来の ECMAScript への移行をスムーズにするため等の目的で、積極的に利用していきたいですね。

tsc はどこで実行するんじゃい

tsc は TypeScript のコンパイルを行うコマンドです。プロジェクトのルートで npm とか叩いてて、ソースは src ディレクトリの中にいる、みたいなときにルートでひたすら tsc 実行してて、「ヘルプしか出てこないやんけ!」と騒いでいましたが、ソースと同じディレクトリで実行する必要がありました。まあ当然なんですけど。

ターミナルでわざわざルートとソースのディレクトリを行き来するのはクソ面倒ですしオペミスのもとなので、 npm のスクリプトに追加しとくのが良いんでしょうね。

{
  "scripts": {
    "build": "tsc -p src"
  }
}

(-p オプションで実行ディレクトリを指定できる)

セミコロンは要らんのかい

各種チュートリアル記事で Node.js / TypeScript の行末セミコロンが無いコードが沢山ありました。 JavaScript には自動セミコロン挿入という機能があるが害悪である、というのが一般的な認識だと思っていたので、こっちの世界では書かないのか正しいのか??と困惑しました。

これは結果的にはたまたまだったようです。セミコロンが無いほうが読みやすい、というのもわからなくはないですが、Node.js のコアコントリビューターであるFelix Geisendörfer 氏はセミコロンつけろと言っています。つけなくても大丈夫であるという確証は得られてませんが、好みの問題なのでしょうかね。


というわけで Node.js の実際の部分とかには全然踏み込めてないわけですが、そのへんは回を改めましょうかね。

仕事中のBGM

昨日の仕事中の BGM - tom-manabe’s kiroku に触発されて、仕事中にきく BGM について。

私は仕事中はほぼエレクトロニカアンビエントか、できるだけ感情が動かないような曲を聴きます。だいたい垂れ流しなのですが、たまに凄い刺さるアーティストに当たるので紹介。

Fugenn & The White Elephants

いやー、もう単純にめちゃくちゃかっこいいですね。低音パートが押し付けがましくなく鮮明なところも良い。

youtu.be

 

Olafur Arnalds

ピアノとストリングス中心の穏やかな曲が多いですね。アルバム "...And They Have Escaped the Weight of Darkness" なんかは、夜寝る前に読書でもしながら流すのにもちょうどいいです。

youtu.be

 

Goldmund

こちらもピアノ中心 (このアルバム "Two Point Discrimination" はピアノソロ)ですが、この不安定さはなんですかね。でも不思議と安心するのです。ただし切羽詰まっているときに聴くとマジで追い詰められるので止めたほうがいいですね。

youtu.be

 

Akisai

アコギ中心。メロもシンプルでポップな曲が多いですね。

youtu.be

 

[.que]

彼はもう定番化していますね。ラジオなんかでもよくかかっています。ポップで親しみやすく爽やかで、かつ嫌味じゃない(個人的に、 No. 9 はちょっと嫌味くさい)。

youtu.be

 

Hammock

美しい!!!

youtu.be

 

(番外) Television

残業して行き詰ったときは Television を聴きますね。

Marqueen Moon は疑う余地のない名盤ですが、どこがどう名盤なのか全く説明できないところが凄い。

youtu.be

 

Elasticsearch でつまづいた話 (5)

Elasticsearch でつまづいた話 (3) - take a keen edge のページング取得では、1回 scroll して、戻り値から次の scroll id を取得して、もう一度クエリを投げて... だったが、せっかくスナップショットをとっているのであれば並列で取得しにいきたいのが当然の心理。

そんなときに使うのが Sliced Scroll だ。 max で最大ページ数を決め、id で取得するページの index を指定する。

max を適当に決め打ちして、取得件数が都度変わる、でもいいのだが、リクエストする側のスループットを考えても、レスポンスのサイズはある程度固定されているほうが望ましい。なので作法としては

  1. _count を叩いて全件数 (N とする) を取得 (当然、フィルターするのであれば同じ条件で叩く)。
  2. 1回の取得件数 (M とする) を、リクエストする側の都合で適当に決め、N / M を切り上げて max とする。
  3. max まで各ページを並列 (各言語でお好きに) で取得するクエリを投げる 。
  4. レスポンスをマージ。

がよいだろう。もちろんスレッド数の制限とかネットワーク環境とか色々変数があるのでこれがベストではない。

今年読んだ本を総括

28冊。夏~秋にあまり読んでいなかったようだ。

ベストは終盤に滑り込んだ「失敗の科学」かな。「脳はなぜ都合よく記憶するのか」も面白かった。

来年は小説に力を入れていきたい。

技術書だとモデリング関係の書をもう数冊読みたい(実践しなきゃ意味ないというのは承知の上で)。Rも入門書で終わってしまったのでもうちょい攻めたい。

哲学書も最近手出せてない。「プラグマティズム入門」で、やっぱりこの領域が好きだなと思った。久々に中島にいくか。

 

Effective Debugging ―ソフトウェアとシステムをデバッグする66項目 Diomidis Spinellis
失敗の科学 失敗から学習する組織、学習できない組織 マシュー・サイド
戦略フレームワークの思考法 手塚 貞治
入門 考える技術・書く技術 山崎 康司  
UMLモデリングレッスン 平澤 章
プラグマティズム入門 (ちくま新書) 伊藤 邦武
会話の達人の話し方を真似したら人見知りの僕でも楽しく雑談できました 松橋 良紀
UMLモデリングのエッセンス―標準オブジェクトモデリング言語入門 (Object oriented selection) マーチン ファウラー; ケンドール スコット
フリー 〈無料〉からお金を生みだす新戦略 クリス・アンダーソン
HARD THINGS ベン・ホロウィッツ
脳はなぜ都合よく記憶するのか 記憶科学が教える脳と人間の不思議 ジュリア・ショウ
人の心を一瞬でつかむ方法―人を惹きつけて離さない「強さ」と「温かさ」の心理学 ジョン ネフィンジャー;マシュー コフート
変革の軌跡【世界で戦える会社に変わる"アジャイル・DevOps"導入の原則】 Gary Gruver;Tommy Mouser
世界一やさしい問題解決の授業―自分で考え、行動する力が身につく 渡辺 健介
ユーザーストーリーマッピング ジェフ・パターソン
人はなぜ物語を求めるのか (ちくまプリマー新書) 千野 帽子
あの会社はこうして潰れた (日経プレミアシリーズ) 帝国データバンク情報部藤森徹
悪童日記 (ハヤカワepi文庫) アゴタ クリストフ
Rによるやさしいテキストマイニング 林雄一郎
働く君に伝えたい「お金」の教養 出口 治明
教養バカ わかりやすく説明できる人だけが生き残る (SB新書) 竹内 薫
チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ エイミー・C・エドモンドソン
アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~ マイク コーン
エンジニアを説明上手にする本 相手に応じた技術情報や知識の伝え方 開米 瑞浩
カラマーゾフの兄弟4 (光文社古典新訳文庫) ドストエフスキー
カラマーゾフの兄弟3 (光文社古典新訳文庫) ドストエフスキー
カラマーゾフの兄弟2 (光文社古典新訳文庫) ドストエフスキー
カラマーゾフの兄弟1 (光文社古典新訳文庫) ドストエフスキー

 

bookmeter.com