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

雀巽の日記帳

雀巽が綴る日常の記録

日帰りで痔瘻の手術をしてきました

日常生活

本日、日帰りで痔瘻の手術をしてきました(´;ω;`)

全体的に消化器官が弱く下痢しやすいんですが、半年前の新サービスリリース直前に下痢下痢してたころ、痔瘻になっちゃってたっぽいです。

この頃は夜中まで働いてたりと、睡眠不足も重なっており免疫力が低下してたと思うので、それで……という感じだと思います。

痔瘻(じろう)」とは、名前の通り痔の一種ではありますが、よく知られてる「いぼ痔」や「切れ痔」とは別物です。「あな痔」と呼ばれることもあるそうです。 治療方法が手術オンリーというクレイジーなやつです。勘弁してくれよまじで……。

welq.jp

入院して半身麻酔での手術が多いようですが、近所の先生は基本的に日帰りで局所麻酔で手術を行うスタイルのようでした。

おそらく術式は下記のリンクにある「痔瘻結紮法」か何じゃないかなと思います。

www.amigo2.ne.jp

有名な治療法は思い切ってバサッといく「痔瘻切開開放術式」と、数ヶ月かけて徐々に取り除く「シートン法」だそうですが、 「ウチではシートン法みたいなまどろっこしいことはしない」とおっしゃっていました。強い。

じゃあ何なんだろうと思って説明を元に調べてみたところ、「痔瘻結紮法」が一番近そうな感じでした。

術式に使っていたゴムもネットで調べて出てくるものに比べて細い気もしますし、外に出てる結び目も小さい感じがしますし、 確かに一般的なシートン法ではないんだろうなぁという感じです。ただ、原理はシートン法と同じだと思います。

Wikipedia での医療関連情報は間違っているものも多いと良く聞きますし、まだまだインターネットは発展途上だなとも思いました。

完治するまではなんとも言えませんが、普通は「入院・半身麻酔・数ヶ月」で処置するものを「日帰り・局所麻酔・数週間」で終わらせるという、 圧倒的名医感漂う先生*1でした。説明も丁寧でわかりやすく、こちらのどんな質問にも答えてくれる信頼できる先生でした。

とりあえず、今日からしばらくの間、痛み止めとの共同生活が始まります……!

全ては身体が資本!健康第一でいきましょう!

*1:超名医かヤブ医者のどっちかだろうなって感じがしますね。笑

ERD(論理設計・物理設計)の管理について

ITライフ

ERD(論理設計・物理設計)の管理についてのメモです。

Web サービス企業では設計書の作成や管理がされない傾向にありますが、 以前も書いたように ERD は作成し管理すべきだと考えています。

necojackarc.hatenablog.com

ただ、最近 ERD の管理で煩わしいなと感じる部分がありました。 それは、Railsマイグレーションファイルと物理設計の内容が重複していることです。

論理設計はもう一段抽象度の高い内容となっているので重複していると感じないのですが、 物理設計に関しては「物理設計 = データベースの実装」となるので、内容が重複してしまっていました。

これに対する2パターンの解決案を書きます。

パターン1: 論理設計のみ保持する

論理設計の ERD のみドキュメント管理をし、物理設計を作らないパターンです。 マイグレーションファイルなので実装自体が管理されている場合、これで良い気がします。

パターン2: 物理設計を保持し DDL を利用する

DDL を利用し、物理設計の変更自体をデータベース自体の変更とするパターンです。 SIer 時代に大規模プロジェクトではこちらのパターンを採用していました。

まとめ

  • 論理設計は実装の経緯や意図が現れているため常に保持すべき
  • 物理設計は実装そのものであるので二重管理となる場合は不要

単純に「同じ抽象度のモノを同時に管理するのは DRY じゃない」という話でした。

「達人プログラマー」が全部入りエンジニア教本だった

ITライフ

「達人プログラマーシステム開発の職人から名匠への道」を読みました。

達人プログラマー―システム開発の職人から名匠への道

達人プログラマー―システム開発の職人から名匠への道

  • 作者: アンドリューハント,デビッドトーマス,Andrew Hunt,David Thomas,村上雅章
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2000/11
  • メディア: 単行本
  • 購入: 42人 クリック: 1,099回
  • この商品を含むブログ (350件) を見る

こちらは UNIXという考え方―その設計思想と哲学と共に t_wada さんが「若者向け課題図書」として挙げられていた本です。

necojackarc.hatenablog.com

読んだ感想ですが、流石若者向け課題図書と言うだけあって「全部入り教本」という感じでした。

開発者としての哲学に始まり、ツール、設計技法、そしてプロジェクト運営など、 システムを作る上で必要になることに対して一通り言及しています。

そして、それぞれで述べられている「心がけ」は色々なプラクティスや手法にも通ずる的を射たものでした。

確かにこの辺りの内容は早い段階で抑えておくべきだなと思います。 知っておいて欲しい心がけの宝庫でした。

ただ、そういった特性上、タイミングによって響く言葉は違うということも痛感しました。

リーダブルコードの時もそうだったのですが、 知っていることや当然だと思っていることも多く載っており、 一瞬「せやな」という感情に支配されていたりもしました。笑

necojackarc.hatenablog.com

もちろん幅広いトピックを扱っているので、響いた部分も多々あります。

以下、響いた言葉を一部抜粋していきます。

早めにクラッシュさせること

障害対応やデバッグをしている際に、本当の原因がどこかわからないで困ることがあるなというのを思い出しました。 例外が起きた位置でクラッシュさせておけば、原因究明に大いに役立ちます。死んだプログラムは嘘をつかない。

全ての例外ハンドラーを除去しても、そのプログラムは動作することができるだろうか?

例外を通常の制御フローに組み込むのは間違いなく悪手です。 そしてこのセリフは例外ハンドラーの使われ方が正しいか正しくないかを考える際に役立つなと思いました。

ソフトウェアは建築と言うよりもガーデニング(つまりコンクリートではなく、より有機的なもの)に近い

「建築のようには絶対行きません!そうだそうだ!もしそうならウォーターフローでうまくいくはずだ!」みたいな気持ちになりました。 今度からソフトウェア開発はガーデニングに例えようと思います。もしそんな機会があれば……。

まず、初期の計画と条件に従って、庭にさまざまな植物を植えます。すると、あるものは力強く育ち、あるものは枯れてコンポストの材料になってしまいます。また、日当たりや雨風の関係で植物をお互いに動かすようなことも行います。育ちすぎた植物は、株分けしたり剪定し、配色の合わないものは美的感覚を満足できるところに移動させます。雑草を抜き、必要に応じて肥料もやります。常に庭の健康状態を監視して、必要な調整(土壌、植物、レイアウト)を行うのです。

リファクタリングの必要なコードを「腫瘍」と考える

小さい内に摘出しないと肥大化して転移するという点で、まさに腫瘍だなと思いました。 腫瘍を見つけたらしっかり無視せず、チケットを切るなど何らかの対応はしておきたい。

プロジェクトの用語集を作ること

これ大事!共通言語大事!

枠にとらわれずに考えるのではなく、枠を見つけだすこと

見かけ上の制約に囚われず、自分が思っているよりも大きな「真の制約」を見つけるべきという話です。 枠を見誤っているケースというのは確かによくあると思います。本物の枠を見極めていきたい。

解説しない方が良い場合もある

「靴ひもの結び方を言葉で説明してみる」とこれの意味がすぐにわかると思います。 自然言語だけでは伝わらない情報がある、というのは肝に銘じておきたいです。

ストレート・ジャケット*1効果

解釈の余地を与えない設計というのは、スキルや技芸といったプログラミング努力を奪い去る意味らしいです。 解釈の余地がないとなると、単なる作業になってしまい、全く面白くないですものね。

自然言語の限界」と「ストレート・ジャケット効果」から、詳細過ぎる仕様書がいかに害であるかがわかりますね。

まとめ

エンジニアとして心がけを幅広く教えてくれる良書でした!

*1:straitjacket: 拘束服

「Head Firstデザインパターン」が設計力を底上げしてくれる良書だった

ITライフ

「Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本」を読みました。

Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本

Head Firstデザインパターン ―頭とからだで覚えるデザインパターンの基本

新人研修中に凄腕エンジニアに薦められて早三年半、やっっっと読みました。 流石凄い先輩が推薦してるだけあって、期待通りかなりの良書でした。

以下、良かったところをザックリ書いていきます。

パターンが活躍する実例から導入が始まる

特に良いなと感じた点は、各パターンが活躍する実例から導入が始まる点です。

大まかな流れとしては、「こんなものが作りたいんだよねー」という小話(要件)が最初にあり、まずはそれに沿った設計が提示されます。 すると要件の変更やら何やらが発生し、現状の設計のままだと問題があることに気づき、リファクタリングを余儀なくされます。 そこで「むむ、確かに。どうしたら良いんだろう」と考えさせられてからの、パターンの登場!

このような流れなので、そのパターンが適用できる状況や、解決可能な問題がスッと頭に入ってきます。

パターンへの深い理解がしやすく、記憶にも残りやすい作りになってるなと感じます。

デザインパターンへ懐疑的な人へのメッセージ

デザインパターンへ懐疑的な人へのメッセージが載っていたのも良かったです。

というのも、実は「優れたオブジェクト指向設計をしてればデザインパターンは不要では?」と若干思ってました*1。 しかし、そうじゃないんだよと、デザインパターンを学ぶことに意義はあるよと、そういう話があり良かったです。

重要度が高いパターンの重点的解説

使用頻度が高く重要度が高いと思われるパターンを重点的に解説してある点も、メリハリがあり良かったです。 正直「こんなにいっぱいあんのかよ」と思ってたので、重要なものを示してくれるのは本当にありがたかったです。

パターンは単なる道具

デザインパターンに縛られるな。パターンは単なる道具。基本は設計原則に従いシンプルに保て」と言った、当然だけど初学者がハマりがちな罠への言及もしかっかりあり良かったです。

目指すところは優れたオブジェクト指向設計であるというのを強く感じました。

まとめ

とっても良い本でした!

*1:ホントは本を読むのがめんどくさくてそう言い訳してただけです。笑

「道を歩けば前置詞がわかる」が面白かった

英語生活

「道を歩けば前置詞がわかる」を読みました。

道を歩けば前置詞がわかる

道を歩けば前置詞がわかる

前置詞関連本はこれで2冊目です。

necojackarc.hatenablog.com

今回読んだ本は、基本的に「道を歩く」という日常の動作と前置詞のイメージを関連付けて説明しています。 前回読んだ本が独自理論感の強い本だったので、「王道」な感じがするこの本を2冊目として選んでみました。

前置詞の説明に使われている「道を歩く」ことに関連したイメージが非常にわかりやすく、とても良かったです。

「なるほど!」と思う説明が多く、今回もまた前置詞のイメージが一段厚くなった感じがします。

また、日本人が前置詞や句動詞を使いこなすためのコツが3章に書いてあり、そちらも良かったです。

知れば知るほど、前置詞は深いなぁという感じがします。

前置詞の持つ底知れぬ表現力を使いこなしたい……!

『医師のつくった「頭のよさ」テスト』を読んだ

日常生活

『医師のつくった「頭のよさ」テスト~認知特性から見た6つのパターン~』を読みました。

医師のつくった「頭のよさ」テスト 認知特性から見た6つのパターン (光文社新書)

医師のつくった「頭のよさ」テスト 認知特性から見た6つのパターン (光文社新書)

思考や認知の好みを6種類の「認知特性」に分類し、それぞれの特徴などについて書いてある本です。

認知特性とは、外界からの情報を頭の中で理解したり、整理したり、記憶したり、表現したりする方法のことらしいです。

大きく分けると3つで、視覚優位者、言語優位者、聴覚優位者に分類できるそうです。

以下のサイトに目を通すと、本の概要がスッキリわかると思います。

ddnavi.com

個人的には「あーなるほどね」と思うことが書かれていました。 同じ科目でも人によってアプローチが違うことや、得意不得意などもこの辺の特性に基づくと確かにそうかもなーと思うことが多かったです。

自分の認知特性とその特徴を把握しておくと、何かと役立つ気がするので、読んでみると楽しいと思います。 特に、子育て中の人や教師など、子供と関わる人は読んでみると得るものが大きい気がします。

認知特性は以下のサイトでも診断できるので、一度やってみると面白いと思います。

micri.jp

ちなみにやってみたらこんな結果になりました。

f:id:necojackarc:20160821162503p:plain

26以上で強い認知特性*1、14以下で弱い認知特性とのことです。

つまり、私は言語抽象 + 聴覚言語の2タイプの特性が強いようです。

■言語抽象タイプ…文字や文章を図式化してから思考する。初対面の人を名刺の文字で覚え、ノートをわかりやすくまとめるのが上手い。内科系医師、作家、教師、金融関係者、心理学者など。

■聴覚言語タイプ…文字や文章を耳から入れる音として情報処理する。難しい話題でも、一度聞くと理解でき、ダジャレや人の言葉尻を捉えるのが上手い。弁護士、教師、落語家、アナウンサー、音を意識できる作詞家など。

あなたに最適な記憶法も分かる!? 自分の「認知特性」を調べてみよう

言語抽象タイプは「言葉に文字や数字、図を系統立てて結びつけるのが得意」で、聴覚言語タイプは「イメージよりも言語そのもので思考を働かせることができる」らしいです。

また、言語抽象タイプは「書いてある言葉」に強く、聴覚言語タイプは「音声としての言葉」に強いというのが大きな違いですが、どちらも言語優位ということで被る点も多いようです。要するに完全なる左脳優位者。

まとめると、書き言葉も話し言葉も「言語という抽象的なイメージ」として処理するタイプ、と言えると思います。

裏を返すと情報処理に映像を使わない傾向にあるとも言えそうです。

これに関しては「予想通り & 仰るとおり」感があって、なかなか納得できます。

で、これをどう活用するかというと、例えば自分にあった勉強法や暗記法を行う、認知特性を意識したコミュニケーションを行う(認知特性が違えば同じことを聞いても同じように理解するわけじゃない)など、色々あります。

詳しくは本を読んでください!笑

ただ、この本には「解答」は載っていないので、認知特性を知った後は自分次第……と、いう感じです。

雑にまとめると「人それぞれ違う」ということを認知特性という視点から理解できる、そんな本でした。

*1:このサイトの方では46以上で強い認知特性となっていましたが、本では26以上が強い認知特性となっていました。 サイトと本では設問数が違うので46が正しい可能性もありますが、46はちょっと極端すぎる気がするので、26の間違いじゃないかなと思っています。

「イシューからはじめよ」が噂通り良書だった

日常生活

『イシューからはじめよ―知的生産の「シンプルな本質」』を読みました。

イシューからはじめよ―知的生産の「シンプルな本質」

イシューからはじめよ―知的生産の「シンプルな本質」

「知的生産の本質」について書かれた本で、序章の「この本の考え方」に非常に共感でき、読んでいて面白かったです。 「犬の道」という表現が出てくるのですが、まさに生産性の違いの本質を簡潔に表している気がしました。

印象に残ってる部分を復習がてら簡潔にまとめてみます。

「悩む」と「考える」は違う

  • 悩む - 「答えが出ない」という前提
  • 考える - 「答えが出る」という前提

根性に逃げるな

  • 労働時間なんてどうでもいい
  • うさぎ跳びを繰り返してもイチローになれない

良いイシューとは

  1. 本質的な選択肢である
  2. 深い仮説がある
  3. 答えを出せる

1次情報に触れる

  • 1次情報とは誰のフィルター通ってない情報。
  • 2次情報だと「情報を切り出した断面」になってしまう。

「集め過ぎ」と「知り過ぎ」のデメリット

  • 集め過ぎる新しい取り込みのスピードが鈍る
    • いわゆる100%までの労力とそれ以下までの労力の相関の話
  • 知識が増えすぎると、その知識の枠で答えが出せてしまうので知恵が減る
    • 「知り過ぎたバカ」にならないように注意

脳は「異質な差分」を協調して情報処理をする

  • 脳は「異質な差分」を協調して情報処理するように進化している

うどんの匂いが食べているうちに数パーセント弱くなってもすぐには察知できない。 同じ形のグラフやチャートが続くと、2枚目以降に関しては認知する能力が格段に落ちる。

「理解する」とは「情報をつなぐこと」

  • 脳神経系では「2つ以上の意味が重なりつながったとき」と「理解したとき」は本質的に区別できない
    • 「情報のつなぎ」が起こらないと記憶は消える
    • 「情報のつなぎ」を繰り返すことで理解が進み記憶が定着する

いくつも手法をもつ(固執しない)

  • 「もっている手札の数」「自分の技となっている手法の豊かさ」がバリューを生み出す人としての資質に直接的に関わる
    • 最初の5年や10年はなるべく広い経験とスキルの育成に励むべき

完成度よりも回転数(エレガントよりもスピード)

  • 何度も取り組む(回転をあげる)ことでレベルを上げる
    • こちらもいわゆる100%までの労力とそれ以下までの労力の相関の話

「デルブリュックの教え」

ひとつ、聞き手は完全に無知だと思え
ひとつ、聞き手は高度の知性をもつと想定せよ

「賢いが無知」というのが基本とする受け手の想定となる。

実験の2つの結果

  • もし結果が仮設を確認したなら、何かを計測したことになる
  • もし結果が仮設に反していたら、何かを発見したことになる

仮説が崩れたら「発見だ!」と思うぐらいの気持ちでよい。

本当にイシューかどうか振り返る

「この作業ってほんとうに意味があるのか?」と思ったら立ち止まって、「それは本当にイシューなのか?」と問いかけることからはじめる。

感想

一言でまとめてしまうと正しい問題*1設定と仮説検証が重要、という話だと思います。 この本では、これをいかにうまくやれるかが生産性に大きく寄与するということの説明と、それを実践するための手法や考え方について書かれています。

序章の「考え方」についてが本当に「知的生産における生産性の本質」をついてると感じるので、是非そこだけでも読んでみて欲しいです。

「犬の道」に踏み込まないように気をつけていきたいですね。

知的生産の本質を教えてくれる良い本でした。

*1:日本語の「問題」だと、"problem", "issue", "question" と意味が広いので、この本では意味を明確にするために「イシュー」と呼んでいるんだと思います。