blockdiag シリーズで色々な作図をしてみる
作図をするときに使うソフトというと PowerPoint とか Visio とか色々あるけど、大抵は GUI で素材をチマチマとドラッグアンドドロップしていく系が多いと思う。 ただ、保存形式がバイナリだとバージョン管理なんかと相性悪いし、なにかをひとつ追加するだけで周りを全部移動させたりーとか考えると結構めんどいこともある。 それに対して blockdiag シリーズはテキストベースの設定ファイルを図に変換することができるツールだ。 blockdiag シリーズは作成する図に応じて blockdiag、seqdiag、nwdiag、actdiag と分かれていて、それぞれブロック図、シーケンス図、ネットワーク図、アクティビティ図を作成することができる。 まずはブロック図を作成できる blockdiag から使ってみよう。 OS X だと、まずは Homebrew で依存パッケージを入れてお
分かりにくいYAMAHAのルーター - 赤カブのケンのブログ
赤カブのケンのブログ 赤カブのケンが日頃やってること、考えていることを書くブログ。また、ボリュームのある内容は下のURLにまとめて、「赤カブのケンのブログ」には要約や速報だけを書くこともあります。 https://akakabu-bbs.appspot.com/?forum=自分でやってみよう
あなたの仕様書は大丈夫？ 日本語文のあいまい度診断ツール『ClearDoc』でドキュメントをチェック
ウォーターフォール型の開発では、要件定義、設計、プログラミング、テスト、運用といった作業工程が時系列に進んでいく。開発当初に作成される要件定義や基本設計のドキュメントは、そのプロジェクトに関わる人たち全員が目にするため、そのドキュメントにあいまいな点や複雑な点などがあれば、後々の行程で問題が発生し、品質と生産性に影響する。この課題を解消するのが、株式会社シーイーシー PROVEQサービス事業部の開発した日本語文のあいまい度診断ツール『ClearDoc』だ。 ウォーターフォール型の開発では、要件定義、設計、プログラミング、テスト、運用といった作業工程が時系列に進んでいく。開発当初に作成される要件定義や基本設計のドキュメントは、そのプロジェクトに関わる人たち全員が目にするため、そのドキュメントにあいまいな点や複雑な点などがあれば、後々の工程で問題が発生し、品質と生産性に影響する。この課題を解消
仕様書の書き方はどうやっておぼえるのか - Some Days You Get the Bear
（仕様書というよりは）資料を書くときにごく普通に意識していること。 ■言葉を統一する 同じものを指すのなら、常に同じ言葉で書き表す。 ■初出のものには説明を 重要なもの・ことについては、章を割いて説明する。 読み手の前提知識がどの程度で、どこまで説明を必要としているかを考える。 ■説明の流れを意識する 「どう説明したらわかったもらえるだろうか？」を意識し、 絵や語句の登場順などの、各章の関連・構成を考える。 ■図解 必要に応じて、文章や言葉を説明するための絵を示す （文章を使って絵を説明する、とも言える）。 このとき、説明したい文章・言葉と絵が対応づけされていることが 読み手にわかるようにする。 おおざっぱにイメージで言えば 読み手を迷わせない、混乱させない、ムダに想像させない ということだ。 こういう視点で見れるようになったのは たぶんレビューでいろんな人の資料を見るようになったからなの
まずは「箇条書き」でしょ！ ～仕様書の書き方（２）～ - Some Days You Get the Bear
仕様書の書き方、第２弾です。 漏れ抜けのないようにと、あれもこれもと盛り込みたくて、 ついつい長文になってしまうこと、けっこう多いように感じています。 しかし、仕様書は、 まずは「箇条書き」です！ 要素をきちんと分解し、１つのことを１つの項目として書き表すこと、 これがすごく大事な観点だと思っています。 なぜならば！ 我々は仕様書を書いているのだから。 なんだそりゃ！？ とお思いでしょうが、仕様書ならではの以下の役割があるからです。 ■よい設計の観点から 機能ブロックや入力情報等がきちんと整理・分解されることは、そのままわかりやすい設計につながります どんな機能、どんな情報があるかをきちんと把握できることは、システムの登場人物を正しく把握でき、概要の理解を助けます ■トレーサビリティの観点から 次工程のインプットとして、仕様書どうし・仕様どうしの各項目の対応付けが明確になります 特に仕様が
もう保守されない画面遷移図は嫌なので、UI Flow図を簡単にマークダウンぽく書くエディタ作った - Qiita
はじめに Webサービスやアプリを企画したり、立ち上げたりする際にプロトタイピングツールや、ExcelやPowerpoint、Illustraterなどを駆使した謎のファイルで画面遷移図を描くことがある。 こういう図を元に仕様を決めて行って、サービスを作っていくのは以下の点で困る。 画面遷移図が保守されない。 書くのが非常に面倒くさい ユーザーのモチベーションの流れが追いづらく、見た目ばかりに注目してしまうものになりがち マシンリーダブル(ソフトウェアで構造を取り出せない)でない。 このような欠点があってどうにも扱いづらい。 そんなわけで、markdown風のテキストから簡単に画面遷移図を描けないかなとコンパイラを作成し、次にそれをインタラクティブに編集できるエディタを作成した。 UI Flows図について 画面遷移図的なものを書く際に、僕が個人的につかっていた表現方法として、UI Flo
エラーハンドリング・クロニクル #nds41 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く
はじめに プログラミング技術の歴史は、ありとあらゆる歴史がそうであるように、いろんな「史観」で眺めることができます。ならば、プログラミング技術の歴史を、「エラーハンドリングとの戦い」という視点から見ることもできるのではないでしょうか。本日は、エラーハンドリングとの戦いの歴史を俯瞰することで、エラーハンドリングの勘所について考えていこうと思います。 なお、このエントリはNDSという勉強会の第41回で発表した内容と同一です。 Cの時代 Cの時代のエラーハンドリングでは、関数の返り値と、グローバル変数errnoを見ることで処理が成功したか失敗したかを見るのが一般的でした。 例として、文字列をlongに変換するstrtol関数をmanで引いてみましょう。すると、だいたい以下のようなことが書かれています。 変換に失敗すると、0を返す 変換に失敗した場合、グローバルな変数であるerrnoに以下の定数を
プログラミング原則一覧 - Strategic Choice
見つけた時に逐次エントリしている「プログラミング原則」カテゴリの一覧です。不定期に追加しています。プログラミング一般デメテルの法則DRY原則YAGNIKISS原則OAOOUNIX哲学可逆性曳光弾直交性契約による設計 DbCプログラマの三大美徳PIEの原則SLAPパフォーマンスチューニングの格言驚き最小の原則オブジェクト指向プログラミングパルナスの規則抽象データ型サブタイプ求めるな、命じよコマンドとクエリ分離原則オブジェクト指向設計パターン言語生成・使用分離の原則パターンの定義IOP
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
