「うんこ」は漢字で「吽子」と書きます。
続きを読む うんこの漢字表現: うんこは漢字でどう書くのか – 吽子「読書」カテゴリーアーカイブ
リモートワークについて考える 『強いチームはオフィスを捨てる』
リモートワークを導入することについて、 リモートワークを実現している 37シグナルズ の CEO Json Fried と David Heinemeier Hansson の書いた『強いチームはオフィスを捨てる』を読んで考えてみた。
続きを読む リモートワークについて考える 『強いチームはオフィスを捨てる』記憶力を高めるために今日からできること
この一冊で「読む力」と「書く力」が面白いほど身につく!
『この一冊で「読む力」と「書く力」が面白いほど身につく! (青春出版社)』を読みました。
読む力と書く力に分けて合計120を超えるテクニックが紹介されています。 情報整理、速読・多読、ビジネス、企画書、メールと分野が多岐にわたるのですが、 その中でも 今の私に使えそうだと思ったテクニックを3つ紹介します。
資料として使いやすいノートは「1枚目」が違う
106ページに記載されているこの方法、とてもいいと思います。 ノートの最初の3ページほどを、目次として整えていきます。 さらに記号も使って見やすくわかりやすくします。
過去、アイディアをノートに書き溜めるということをやっていたのですが、どこになにを書いたかわからなくなって、使えるノートになりませんでした。 もしあのとき 最初の数ページで目次を作っていたら、 もっと有意義なノートになっていたと思います。
私が使っている B5 ノートは 35行60ページ あるので、 平均で 1ページにつき2行で目次に書き足すなら 最初の2ページを使えば済みます。
107、108、120、121ページのテクニック と合わせて使えば、 考える力も さらに伸びそうです。
好感度の高いメールは「締めのひと言」が違う
タイトルから考えて 「書き手の人間性」が垣間見えるような一文を追伸としていれる
というのが、 筆者が最も言いたかったことだと思うのですが、 私が注目したポイントはそこではありません。
ビジネスメールでは、 わかりやすく的確な文章を書くことが求められます。 文章のわかりやすさは、 自分で自分の作った文章を読んで感覚的に推敲・改善していくものですが、 この本にはその基準となる文字数が記載されていました。
50文字を超える文は要チェックです。 改善の余地があります。
新聞でも、 要点は50文字以内でまとめられているそうです。
手帳に書くとモチベーションが上がる「10年計画表」
今後10年のプランを手帳に書くというテクニックです。 私は手帳を使わないので、ノートあるいはパソコンやスマートフォンの背景に応用します。
過去に、 企業研修等で 今後の人生プラン・キャリアプランを考えることがありました。 でも、 考えたのはそのときだけで、 しばらく見てもいませんでした。
でも 今後のプランは きっと役に立つと思います。 だから見えるところに 10年プランを置いておこうと思いました。 自分のゴールが念頭にあったほうが、 濃い時間が過ごせるに決まっています。
DIxAOP の Java Framework, Spring
DIxAOP ってなんだ? と思っていたら、 ある人が紹介してくれました。 DIxAOPについてはわかりやすく書かれているそうです。 パラパラっと見てみましたが、 EAA や DDD などのアーキテクチャを一通り知っている人が書いた本に見えます。 今回は第1章をじっくり読んでみました。 Spring フレームワーク の前書きみたいな内容で、 Spring を使ったことのない私にはちょうどいいです。
Spring の特徴
Spring の特徴として 際立っているのが DIxAOP だ。 第1章では紹介程度になっているのだが DIxAOP なくして Spring は成り立たないといっても過言ではなさそうだ。
Spring の DIxAOP 設計 は Webアプリケーション が抱える 3つの問題点 を解決する。 以下、簡単にまとめた。
- オブジェクトのライフサイクルの問題
- オブジェクトの生存期間をコントロールする作りこみが困難
- 部品化の問題
- 部品化をするためには実装非依存にする必要があるが、それなりにコストがかかる。 (注: 単にインターフェースを使えばいいという問題ではない。)
- 技術隠蔽や不適切な技術隠蔽
- 高レベルの技術を初級レベルの開発者に利用させて不具合を引き起こしてしまったり、不適切な技術隠蔽をしてその技術の利用が困難になってしまったりすることが開発現場でよく起こる。
Spring では、 上2つの問題を DIコンテナ が、 最後の問題を AOP が解決する。
Webフレームワーク というと Rails や FuelPHP, CakePHP などがあり、 「(アクティブレコードパターンの) 簡単にデータベースが使えるもの」という印象を受けてしまいがちですが、 Spring3 入門 では アーキテクチャ の考え方からしっかりと書かれていて EAAに見られるパターンの説明も(第1章では)随所で行われています。 第1章では特にレイヤの分離の説明が重点的に行われています(フレームワークを使う人には是非ともわかるようになっていてほしい内容です!)。 コードの例もあり、全体的にしっかりした印象を受けます。
以下、第1章の中で私が(個人的に)重要だと思った内容を簡単に書き留めました。
アプリケーションアーキテクチャ
プログラムを作る際には 最低でも 2つの方面からの要件・目標がある。
- ユーザの要件: ユースケースなどで表される機能要求やレスポンスタイムなどの非機能要求
- 開発者・運用者の目標: 開発期間の厳守、変更・機能追加のしやすさ、テストのやりやすさ
この本では 2つ目の 開発者・運用者の目標 からアーキテクチャの重要性が説かれている。
アーキテクチャに求められるもの
- 開発効率
- 意図を把握しやすく、理解しやすい構造
- テストが容易に行える構造
- 柔軟性
- 変更しやすく、機能追加しやすい構造
- 将来の環境の変動に耐えられる頑健な構造
ティアとレイヤ
Web アプリケーション の アーキテクチャ は ティア と レイヤ に分かれている。 ティア は 物理層 を表し、 レイヤ は 論理層 を表す。
ティア
クライアント層、中間層、 EIS(Enterprise Information System)層 の 3つに分かれるのが基本となっている。
クライアント層 | パソコン、スマートフォン |
---|---|
中間層 | アプリケーションサーバ |
EIS層 | DB、レガシシステム |
レイヤ
EAA の冒頭あたりにある分類と同じ分け方でレイヤが書かれている(プレゼンテーション層、ビジネスロジック層、データアクセス層 の3層)。 (もちろん異なる分け方もある。) 互いに隣接するレイヤ間では一方向のアクセスのみ許す。
トランザクション処理がどのレイヤに属するのかは迷うところだが、本書ではプレゼンテーション層とビジネスロジック層の境界と説明されている。