雀巽の日記帳

雀巽が綴る日常の記録

痔瘻手術から9日目で無事ゴムが取れました

先週の月曜日に痔瘻の手術をしてきたんですが、手術後9日目の本日、無事にゴムが取れました!

necojackarc.hatenablog.com

お医者さんが「1週間〜10日で取れる」とおっしゃていたんですが、まさにドンピシャリでした。

ちなみに、外れたゴムの記念写真も撮りました。

f:id:necojackarc:20161005133824j:plain

このサイズのゴムが1週間ちょっとで身体を貫通して外れるなんて、人間の身体って凄いですね……。

そして輪っかちっちゃ!こんなんがお尻についてたら痛いはずやわ!

明日また通院予定です。変な外れ方してないかだけが心配です。

経過良好だといいなー。

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

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

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

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

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

www.rakuc.com

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

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

www.amigo2.ne.jp

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

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

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

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

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

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

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

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

ERD(概念/論理/物理設計)の管理について

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

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

necojackarc.hatenablog.com

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

概念設計*1はもう一段抽象度の高い内容となっているので重複していると感じないのですが、 論理/物理設計に関しては「論理/物理設計 = テーブル構成そのまま」となるので、内容が重複してしまっていました。

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

パターン1: 概念設計のみ保持する

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

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

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

まとめ

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

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

補足: 概念/論理/物理設計について

それぞれが何をするべきフェーズなのか、以下にわかりやすくまとまっていました。

www.atmarkit.co.jp

概念設計

業務の観点から必要な情報を漏れなく管理できるように設計します。 抽出した情報は、正規化し、あるべき姿で情報を整理し、概念ER図に表します。

論理設計

データ構造の変更を最小限に抑えながら性能向上を図ります。

物理設計

ユーザー要件として性能要件や可用性を考慮したデータベースを設計します。そのために必要なハードウェア資源、ミドルウェアの選定、パラメータの設定を行います。

正規化が論理設計に含まれているケースもみますが、データベーススペシャリスト試験などの本を見てみると、 上記の分け方で書かれていたので、この分け方が一般的なんじゃないかと思います。

また、「概念設計では属性を書き出さない」という誤解もありますが、書き出すケースも書き出さないケースもあると思います

*1:属性を持っていないものこそが概念 ERD だという誤解を耳にしたことがありますが、属性は持っていても良いです。目的とフェーズ次第だと思います。例えば正規化をする際には属性が無いと難しいかと思いますし、概念上のデータをできるだけ正確に表すのであれば、属性も重要な要素になると思います。

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

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

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

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

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

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

necojackarc.hatenablog.com

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

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

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

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

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

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

necojackarc.hatenablog.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

*1:straitjacket: 拘束服

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

「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の間違いじゃないかなと思っています。