IT技術全般において概念モデルは比喩ではなく本質だという考察 - t-hom’s diary
最近ネットワークの学習をしていて思うのが、10年前の私はよく概念モデルで躓いていたなということ。たとえばOSI参照モデル等。 学習が遅々として進まなかった原因として、概念モデルが登場したときにいつも腑に落ちず苦痛を伴っていたことを思い出した。 当時の私は実装こそが真実であり、概念モデルはそれを分かりやすく説明するための単なる比喩表現に過ぎないと勘違いしていた。 しかしそんなものを見せられても一向に実装がイメージできない。実際にどうなっているのか、どのように実装されているのかを理解できなければ分かったことにならないと思い込んでいたのだ。 たとえばTCP/IPモデルでいえば、層という概念が実際にどう実装されているのか、まさか図の通り積みあがっている何かがあるわけではあるまいし、だとすればどうなってるんだ。層ってなんなんだ！分からん、何も分からん！といった具合。 この考え方が変わったのは、ブログ
VBA 他人の書いた冗長なソースコードを読みこなすための7つのテクニック - t-hom’s diary
VBAの初心者が書いたコードは、どうしても冗長になってしまう。 知識は無くてもなんとか目の前の業務を楽にしたいという思いで、ネットからコピーしたりマクロの記録コードをつかったりしながらやっとの思いで仕上げたマクロ。私もVBAを始めた当初は、いわゆるコピペプログラマーだったのでよくわかる。 プロシージャを分割したり、関数を作るという発想はなく、同じ処理が出てきたら同じコードをコピーして使いまわす。そうしているうちにコードはどんどん膨らみ、使われなくなった変数やコードの断片が放置され、インデントはバラバラ。冗長で汚い、一度メンテナンスをやめると書いた本人にすら手の付けられないマクロになってしまう。 そこで今回は、他人の書いたVBAのソースコードを読むとき、私がどのようにして作業を進めるかを紹介する。 もちろん、自分が過去に書いた謎のコードを解読するときにも役に立つテクニックである。 具体的な方
Wordでメンテナンス性の高いドキュメントを作る鍵はスタイルと描画キャンバス - t-hom’s diary
前回、業務マニュアルを作る際に重要な3つのポイント（指示の明確さ、メンテナンス性、読みやすさ）について書いた。 thom.hateblo.jp 今回はこのうち、メンテナンス性について、具体的にWordをどう使えばメンテナンス性の良いドキュメントができるのかを紹介する。 文書構造を考える Wordは直観的に操作できるのでその機能を知らなくてもある程度使えてしまう。 これが最大の落とし穴である。 よくある過ち 過ちというのは言い過ぎかもしれないけれど、メンテナンスが面倒くさくなる例として、以下にサンプルの文書を用意した。 一見問題無いように見えるかもしれないが、これは見出しや表題に対して個別に書式を設定しており、ルーラーでインデントを整えたものだ。スタイルを使わないので全体が標準スタイルとなっている。 構造としては、以下のようなイメージ。 まず、手動で書式を設定しているため、同じ見出しのはずが
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
