ソフトウェア設計を学びたい人々にまず教えるべきことはテスト技法ではないか - 余白
根本の問題意識 ソフトウェアの設計スキルはどのように獲得する（させる）ことが効果的であるのか ソフトウェアアーキテクチャの目的 そもそもソフトウェアアーキテクチャはどのような欲望を満たすための方法か ソフトウェアアーキテクチャの目的は、求められるシステムを構築・保守するための必要な人材を最小限に抑えること である。 (CLEAN ARCHITECTURE) 「求められるシステムを構築・保守するための必要な人材を最小限に抑えたい」 => 構築容易性 と 保守容易性 を確保したい 構築容易性 「構築しやすさ」とは？ ソフトウェアを構築するとはどういうことか ソフトウェアの2つの価値: 「振る舞い」と「構造」 振る舞い: 要件を満たすこと => いわゆる機能 構造: 振る舞いを簡単に変更できること => いわゆるアーキテクチャ 構築しやすさ=価値の生み出しやすさ 要件を満たしながら振る舞いを変更
情報ではなく経験をアウトプットすること - 余白
調べれば大抵の情報は誰でも手に入る今日このごろ。特に技術的な情報はオープンソースで一次情報へのアクセスは容易になった。 それと同時に繰り返し言われるアウトプットの重要性。 しかし、ブログやLTなどでアウトプットしても、「もっと質のいい情報があるのに自分がアウトプットする必要があるのか」「逆にノイズになるだけじゃないか」というような考えになってしまう人もいるのではないか。 そんな架空の声にお応えして、それでもなおあえて、一次情報ではない「あなたのアウトプット」の重要性を伝えてみようと思う。 実際にやる人は多くない 定量的なデータがあるわけではないが、直感的に共感してもらえるだろう。 ある技術や手法が話題になったとして、それを情報として知っている人はこの時代いくらでもいる。 だが、それを実際にその手でやったことがあるというだけでかなり群衆からは抜きん出た経験を持つことになる。 ましてやそれをや
謙遜しないと決めている話 - 余白
僕は誰かに褒められたとき、謙遜しないようにしている。 褒められたら「ありがとうございます」「嬉しいです」「照れます」と、はっきり言葉で喜びを示す。 これを心がけはじめた最初のころは意識的だったけど、最近では意識しなくても自然にそう振る舞えるようになった。 これまで何人かに、「それいいですね」と言われることがあって、そういえばこの自分ルールについてちゃんと言葉にしたことがなかったなと思ってこの記事を書いている。 褒めたいと思ったあなたを否定しない 「謙遜しない」というルールの根幹は、「褒めたいと思ったあなたを否定しない」ということ。 褒めてもらったことが、自分が本当に認められたいことではないときもある。あるいは、何気なくやったことで自分ではそれほど価値を感じていないことのときもある。 それでも、相手が自分を褒めたいと思ったそのことはその人にとって疑いようのない事実である。「そう思った」という
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
