読者です 読者をやめる 読者になる 読者になる

駄文型

プログラミングとか英語とかの話題を中心にした至極ちゃらんぽらんな日記です。

現代人のための統計リテラシーその1 構成概念を直接測定しようとしてはいけない

統計 仕事

観察しようとする構成概念を直接測定しようとしてはいけない。これは心理学系の研究において常識であり鉄則である。構成概念は文字通り概念であり、そもそも直接測定できない。

構成概念

construct

理研究などにおいて、人の行動のメカニズムを説明するために、研究者によって人為的に構成された概念のこと。

構成概念の例として「思いやり」、「リーダーシップ」、「社交性」などが挙げられるが、これらは直に見たり、測定したりすることはできない。そのため、ある構成概念の存在を仮定した場合、その構成概念の影響を受けるであろう複数の行動や態度を測定し、構成概念の存在を検証する。因子分析は構成概念の探索や検証に用いることの多い手法であり、抽出された因子を構成概念と見なしている。

構成概念 | 統計用語集 | 統計WEB

素人がアンケートを作成すると、しばしば「構成概念を直接測定しようとした」アンケートが生まれる。例えば、従業員満足度を調査しようとして以下のような質問を設けるのはあまり有効な方法ではない。

Q. あなたは現在の業務に満足していますか。
5. 満足 - 4. やや満足 - 3. 普通 - 2. やや不満 - 1. 不満

これは構成概念を直接測定しようとした質問の典型だ。この質問でわかるのは「従業員が【あなたは現在の業務に満足していますか。】という質問に対して何と答えたか」であって、「従業員の業務への満足度」ではない。「従業員の業務への満足度」を測定したいなら、「従業員の業務への満足度」とは何かを定義し、分解し、客観的・定量的に測定可能な変数まで分解する必要がある。たとえば「従業員の業務への満足度」という構成概念の場合、以下のように分解できる。

従業員の業務への満足度
├── 希望する業務内容と現状の業務との距離
│   ├── 現在の業務内容
│   ├── 希望する業務内容
└── 業務量
    ├── 現在の業務量
    └── 残業時間 など
※この分解が妥当かどうかはひとまず置いておいてください。

ある程度分解していけば、直接測定可能な変数まで落とし込める。構成概念はこれらの変数の総体であり、直接測定することはできない。

直接測定すべきでないのは、なにもこういった概念に限らない。自然科学の分野においても、多くの場合観測したいものを直接測定できないので、しない。中学校の理科の実験を思い出してほしい。目に見えない二酸化炭素を観測するには石灰水を使う。石灰水に二酸化炭素を吹き込むと、炭酸カルシウムが生成し、白濁する。実験では二酸化炭素を直接観測しようとせず、石灰水の白濁を観測する。

物理量には適正な測定方法があり、構成概念もまた同じである。適正に分解して構成概念を観測できず、さらにその先にある目標を達成できない。

その1としたけど続かないかもしれない。

統計学が最強の学問である

統計学が最強の学問である

統計学が最強の学問である[実践編]---データ分析のための思想と方法

統計学が最強の学問である[実践編]---データ分析のための思想と方法

広告を非表示にする

今日こそ始めるソースコード・リーディング Node.js のコードを読んでみよう

Node.js JavaScript 技術っぽいもの

細かくカスタマイズできるメソッドを実装しようとして、引数が多くなってしまうことがある。オプションを引数で渡すことになる。デフォルト引数を利用して省略可な引数を用意したいが、一番後ろは必須のこれがいいみたいなケースがないだろうか。僕は4年に1回くらいある気がする。最後尾の引数はコールバック関数に、というのは Node.js だとよくある気がする。そういえば fs.readFile() なんかは真ん中にオプションを詰め込むタイプになっている。どう実装するのが一番普通なんだろうか。気になったので Node.js のソースを読むことにする。

フォークしてローカルにダウンロード

別にフォークしなくても git clone git@github.com:nodejs/node.git でダウンロードできる。フォークするのは「俺は〇〇っていうフレームワークを読んでいるぜ」というのをアピールするためでもあるし、フォークしておけばなんとなくテンションが上って自分のモチベーションが上がる気がするからだ。ストイックな方はフォークしなくてよい。

https://github.com/nodejs/node にアクセスして右上にある Fork ボタンを押してフォークしよう。簡単すぎる。GitHubってすごい。フォークしたらそこから git clone でクローンしよう。軽く読むだけならクローンしなくてもブラウザでいい。

読む

fs.readFile()

前置きが無駄に長くなったが、ソースを読んで見る。 fs.readFile()lib/fs.js にある。

arguments[arguments.length - 1] で最後尾の要素を取って maybeCallback に渡しているようだ。この時点で似たような機能がない言語だと同じように実装できないことがわかる。つらい。

ところでこのコードは gist-it で持ってきているのだが、非常に便利。下記のスクリプトでいける。

<script src="http://gist-it.appspot.com/github/kohei-kimura/node/blob/master/lib/fs.js?slice=271:298"></script>

参考にしたエントリ: はてなブログでGitHubのコードを貼り付け/引用する - メンチカツには醤油でしょ!!

maybeCallback

maybeCallback では型のチェックをしているだけのようだ。 retthow() は同じく lib/fs.js で定義されているがここでは省略する。単にエラーなら thow するだけの関数だ。 fs.readFile() にコールバック関数を渡さなければこれがコールバック関数になるようだ。

getOptions

まず fs.readFile() にオプションを渡さなければ、optionsは未定義かnullかコールバック関数が入っているはずなので、デフォルトを返す。

で、stringの場合はエンコーディング設定にして、objectならそのまま返す。ここで自分が勘違いしていたことに気づいた。fs.readFile()

fs.readFile("file.txt", "utf-8", "r", callback);

などとすれば、いい感じに引数を解釈してオプションをセットしてくれるのかと思っていたが、オプションが複数ある場合はちゃんとオブジェクトで渡さないとだめなようだ。ちゃんとドキュメントにもそう書いてある

感想

結構普通だった。自分の勘違いにも気づけてよかったのでソース読むの大事だね(泣)

具体的なモチベーション重要。ただ漠然と「勉強になるって言うし、フレームワークのソース読んでみよう」と思っても量が多すぎて理解できない。自分がいつも使っているフレームワーク・ライブラリで「そういえばこの辺の処理どうなってるんだろう」と疑問が湧いたらその部分だけ読むと、自分が読むべき範囲が限られるのでよい。というか、仕事のプロジェクトでいきなり既存のコード全体読んだりしないよね。機能追加やバグフィックスというゴールがあって、そのために必要な箇所を都度読んでいくことが多い。OSSも同じだ。なんか「レールズのコードは勉強になるってみんな言ってる!読まなきゃ!(焦)」みたいな漠然としたモチベーションで始めてもうまくいくはずなかった。それで年間12回くらい挫折してる。みんなって誰だよ。まずは自分の分かる範囲の浅いところからはじめて、少しずつ深めていけばよいのだ。仕事と同じだ。OSSだからって変な肩肘張ってた。

あとは、そのフレームワーク・ライブラリのユーザーとして使いこなせるようになるのが先。使いこなしてないってことは、まだ仕様を理解できてないってことだし、仕様がわからないコード読んでもわかるわけない。こんな当たり前すぎることに何故気づかなかったのか。

広告を非表示にする

開発者のための #OpenShift Tips

技術っぽいもの Docker

一応都度更新するかもしれないので、Gistで上げておいた。

OpenShift for Developers: A Guide for Impatient Beginners

OpenShift for Developers: A Guide for Impatient Beginners

広告を非表示にする

React.jsで1年アルバムを作成するWebサービスを子育ての合間に作った

技術っぽいもの React.js JavaScript インターネット 作ってみた

動機

娘が10ヶ月になり、写真を見返すことで成長を実感できるようになってきた。ベビーアルバム(↓のようなもの)もかなり充実してきた。そこで同じように月ごとの写真を選んで並べるようなWebサービスがあると嬉しいんじゃないかと思って作ってみた。React.jsもチュートリアルだけやって特に使う機会もなかったので、個人プロジェクトを始めてみようというモチベーションをぶつけてみた。

成果物

kohei-kimura.github.io

f:id:koheikimura:20161228225840p:plain

ソースコード

github.com

現在の仕様

  • 月ごとに好きな写真を選んで1ページのアルバムを作ることができる。
  • 画像をクリックして写真を変更する。
    • 画像はローカルから選択できる。
  • アルバムタイトル、アルバムの説明、写真の説明は自由に変更可能。
  • リロードするとすべて消える。

今後の対応

  • README書く
  • 保存・SNSシェア機能
    • 現在の仕様だと作ってもファイルとして保存したり印刷したりする以外に保存する方法がない
    • 簡単にシェアできるようにしたい
  • リファクタ
    • ソースきたないので
  • SNSから画像を検索して自動で写真を決定する機能
    • Like数などから月間で最も人気のある画像を取得してそれをアルバムにできるといい
  • レスポンシブ
    • 対応したつもりだったが、できてなかった

自問自答

  • これReactで作る意味あるのか
    • 今のところReactでなければ行けない理由はない
    • 今後機能追加していく段階で優位性がでるかもしれない
    • リアクト チョット ツカエル 状態になりたかった

感想

CSSつらい。めっちゃつらい。小さい子供がいると、まとまった時間を取ることが難しいので、細切れの時間を有効に使う事が重要。臨機応変に家事・子育てモードとプログラミングモードを切り替えることも重要で、家事育児の時間はフルコミットして、余裕がある時間帯に作業に戻る感じ。パートナーとの連携が必須。

WebデベロッパーのためのReact開発入門 JavaScript UIライブラリの基本と活用

WebデベロッパーのためのReact開発入門 JavaScript UIライブラリの基本と活用

広告を非表示にする

fluentdコンテナをDockerで立ててRailsのログをTreasureData by IDCFに保存する

技術っぽいもの Docker Ruby

参考

fluent.configの作成

<source>
  type forward
  bind 0.0.0.0
</source>

<match td.*.*>
  @type tdlog
  endpoint api.ybi.idcfcloud.net
  apikey $API_KEY
  auto_create_table
  use_ssl true
  buffer_type memory
  flush_interval 60s
</match>

例によってendpoint api.ybi.idcfcloud.netのところが重要で、これがないとログインエラーになる。

ローカルで動作確認

まずfluent-plugin-tdをインストール

$ gem install fluent-plugin-td

fluentd を起動。

$ fluentd -c fluent.config

JSONを投げる。TreasureDataにテーブルができていればOK。DBは事前につくっておく。td.<db_name>.<table_name>

$ echo '{"app":"command", "id":1, "message":"Hi!"}' | fluent-cat td.fluent.test

Docker

FROM fluent/fluentd
COPY fluent.conf /fluentd/etc/
RUN gem install fluent-plugin-td

copyはfluent/fluentdでやっているので必要ないはずだが、なぜか僕のビルド先(OpenShift)で動かなかったので明示的に入れた。docker runで起動すれば動く

$ docker build . -t $CONTAINER
$ docker run -p 24224:24224 $CONTAINER

Rails

fluent-loggerをインストール。

$ gem install fluent-logger

application_conraller.rb に下記を追加。requestの内容をログに含めることもできる。あとはRailsを起動してアクセスすればログが溜まっていく。はず。

Fluent::Logger::FluentLogger.open(nil, :host=>ENV['FLUENTD_SERVICE_HOST'], :port=>ENV['FLUENTD_SERVICE_PORT'])
before_action :fluentpost
def fluentpost
  Fluent::Logger.post("td.#{db_name}.#{table_name}",{
    path:   request.fullpath,
    method: request.request_method,
    user:   user_name,
    body:   request.body,
    time:   Time.current.to_s
  })
end

広告を非表示にする

日報を支える技術

技術っぽいもの インターネット 仕事

日報について

日報書いてますか。僕の所属するチームは拠点が東京と福岡に分かれている上、各自やっていることが独立していていてるので、お互いが現在やっていることを把握するために必ず日報を書くことをルールとしている。1日の業務の中で困っていることや躓いたところを共有することで解決策が見つかることもある。

日報のデメリット

とはいえ良くない面もあって、「コストがかかる」というのが日報の一番のデメリットだと言える。一日の作業を振り返って、どんなことをやったか、どんな問題が出たか、それにどう対応したか、明日以降はどうするのか、などを考えるのは結構大変だと思う。それをチームメンバー全員がやるとなると合計でかなりの工数になると思う。かと言ってあまりに簡潔に書きすぎると作業の進捗状況をマネージャーが把握できないので、ミーティングの時間が長くなり、結局工数が嵩む。非同期に情報をやりとりできる日報のメリットが小さくなってしまう。

Slack分報との比較

昨今では(1年くらい前から?)Slack分報というものが流行っている。ひとりひとりがチャンネルを持っているので気軽に書き込めるという特徴がある。作業中にハマったことを書き込むことで、ほぼリアルタイムにアドバイスをもらえることもある。困ったり悩んではいるけど直接聞くほどではない問題をスムーズに解決できる。これは日報にはないメリットで、日報で同じような効果を得るのは1日に1回になってしまう。

一方でデメリットとしては、Slackのチャンネルが増えすぎてしまうとか情報量が多すぎて追えなくなってしまうとか、などがあげられる。メンバーの生産性に影響してしまうので、大きすぎるチームにはあまり向いていないかもしれない。

本題

僕は「今日のノート」というのを毎日書いていて、それをほぼそのまま日報にしている。ノートには今やっている作業や問題点をどんどん書いていく。そうすることで1日を振り返ってやった作業を思い出す時間が必要なくなるので、日報を書くコストが少し減る(気がする)。時系列に書いていくので、どんな1日だったか読み手が想像しやすいないようになっていると思う。やった作業を逐一書き込んでいくので、あとから振り返りやすい。一度やった作業を忘れてしまった場合、ググるより先にまず過去のノートを検索することができ、効率がいい。ノートはMarkdownで書いてgitで管理している。楽に運用できるようにちょっとだけ工夫しているのでまとめておく。

tnコマンド

ただのシェルスクリプト。所定のフォルダに今日のMarkdownファイルを作成して開いてくれる。tnと打てばすぐにノートを書き始められるので便利。はじめるための障害を小さくすることで習慣が続くようにしている。フォルダは月ごとに分けているので、フォルダ作成も自動でやってくれるようにしている。

Atom

atom-editor

テキストエディタですね。使い慣れたものを使うのが一番だと思うけど、Atomスニペットが使えるのでありがたい。また、GoogleIMEの設定を変更して日本語入力中でも#*が半角になるようにしておくとMarkdownを快適に書ける。

スニペット 概要
table テーブル
l リンク
img 画像
b 強調
i イタリック
code コード
t チェックボックス
legal 著作権表示
lorem ダミーテキスト

【Atom】Markdownで使えるスニペット一覧 - Qiita

Markdown Here

markdown-here.com

ノートを日報としてメールで送ってチームに共有するのだが、僕は基本的に小見出しと箇条書きの他にコードやコマンドを貼り付けたりリンクを貼ったりする。その場合、生のMarkdownよりHTMLに変換された方が読みやすい。Markdown HereはChromeFirefoxSafariなどで使えるブラウザ拡張機能で、Markdownで書いた文書を一瞬で変換してくれる。ctrl + option + mで変換できる。

git

別にバージョン管理をする必要はないのだが、リモートリポジトリに置いておけば他の環境にコピーしやすい。GitHubでもいいんだけど、無料でプライベートリポジトリを使いたかったのでbitbucketにプッシュしている。

まとめ

どんな情報共有の手法を採用するかはチームの事情によると思うので、これが全てにおいて最適というやり方はないと思う。課題もたくさんある。もっと自動化して出来る限り日報を書くことにかかるコストを下げ、自分が取り組むべき問題にフォーカスできるようにしたいという思いがある。

Atom実践入門──進化し続けるハッカブルなエディタ (WEB+DB PRESS plus)

Atom実践入門──進化し続けるハッカブルなエディタ (WEB+DB PRESS plus)

広告を非表示にする

夫が17時に帰宅したらどうなるか #もしも定時で帰れたら

日記 家庭 インターネット

前にも書いたが、僕は今朝型勤務をしていて、16時半ごろには仕事を終えて17時前には帰宅する。平日のスケジュールをまとめてみる。

家族構成

  • 夫(僕)
    • プログラマ
    • いわゆるエスイーではない
    • 7:30-16:15勤務
    • 残業はしないさせない持ち込ませない生きて帰すな見たら殺せの精神
  • 妻(美人)
    • 今年娘を出産
    • 専業主婦
    • 美人
  • 娘(かわいい)
    • もうすぐ10ヶ月
    • はいはいしたり、つかまり立ちしたり目が離せない時期
    • かわいい

1日の流れ

  • 6:20 起床
    • 身支度、朝食
    • 妻がお弁当を作ってくれる(←ありがたい!!!)
  • 6:50 家を出る
  • 7:20 オフィスに着く、仕事開始

  • 16:30ごろ 仕事終わり

  • 17:00 帰宅
    • 帰ったときにはいつも夕飯の準備はほぼ終わっている(←ありがたい!!!)
  • 17:30 お風呂
    • 妻と手分けをして片方が入れて片方がお風呂に連れて行って迎えに行く
    • 娘が終わったら交代で自分たちも入る
  • 18:30 娘の夕飯
  • 19:00 夕飯
  • 19:30 片付け
    • 食洗機があるけど調理器具を手洗いしたりゴミをまとめたりで20分くらいかかる
    • 片付けてる間は妻に娘を見ていてもらう
  • 20:00 ゆっくり
    • テレビを見たりブログ書いたり
  • 21:00 寝かしつけ
    • そのまま自分たちも寝る
  • 21:30 就寝

娘のお風呂や夕飯の時間はその日の本人の気分次第で前後する。帰ったらお昼寝しているときもあるし、寝かしつけ中のときもある。

育児参加について

やっぱり娘が手がかかる時期なので、できるだけ家事育児に参加するように努力している。また、それ以上に仕事で疲れないための努力を最大限している。疲れたら何もしたくない。そのために長時間労働しないというのは本当に重要。妻にも育児で疲れてほしくないので、僕ができることはなるべくやっているし、効率化のための投資は惜しまないようしている。僕はがんばっているつもりでも、結局は家事育児の大部分は妻にやってもらっているので、僕の家事育児への参加が足りない部分があったら遠慮なく言ってもらうようにしている。

長時間労働は社会的な問題なので、行政や政治(つまり有権者全員)ががんばらないといけない面もあると思うが、オーバーワークにならないように会社側と交渉するとか、条件が良いところに移るとか、個人でできることもあると思う。全国のパパとママ、がんばってください。

DSC_0272

部下を定時に帰す仕事術 (ポケット・シリーズ)

部下を定時に帰す仕事術 (ポケット・シリーズ)

広告を非表示にする