技術の恩返し

私と皆の、分からないことが、分かるようになりますように。

いろんなものの考え方

障害発生したとき
 ・業務などに影響はあるか
 ・事実は何か(独立事象か、具体的に何が起こっているか)
 ・原因は何か(事象から仮説を立てて検証する)
 ・対策はどうするか(原因に対しての打ち手を検討する)

対策方法を考えるとき
 ・どんな指標があるか
 ・決め手となる指標はあるか
 ・やった方がいい理由と、やってはいけない理由を考える

システムの異常系の動作を考えるとき
 ・トレースできるか
 ・失敗時にリカバリーが楽にするにはどうするか
 ・デッドロックなどは起きるか

エラー文言の例

・Aのため、Bは、Cに対して、Dできません。
例)サーバが異常終了したため、システム更新者は、マスタデータに対して、反映できません

これを一番省略すると「Dできません」だけになる。
例えば、「更新できません」とだけ文言が出る。

あるいは、「Aのため、Dできません」だと、
「サーバに異常が発生しているため、更新できません」


・Sするのに、Tがありません
 例)更新を行う権限がありません

・Xで重大な問題が発生したため、直ちに終了する必要があります。
・Xで重大な問題が発生したため、プログラムを終了しました。

・ユーザ名またはパスワードが正しくありません。
・デバイスY が見つかりません(オンになっていません)
・設定Zが利用できません(有効になっていません)

システムの守り人になって大変なこと

保守や運用を数か月やっているんですが、
なかなか性に合わないです。

友人で、保守運用が楽しいって言っている人たち曰く
 ・障害をいかに起こさないか、連続記録に挑戦するゲーム感
 ・バグついでにミドルウェアの仕組みを知れて楽しい
とのこと。

個人的には
 ・障害発生後の、すぐに、正しく対応しなきゃいけないプレッシャー
 ・休日や深夜でも関係なく働くこと
 ・技術的負債が積み重なった先人のコードを読まなきゃいけないこと
あたりで、HP削られています。

開発の方が適正あると思うんで、保守運用も見越した開発ができるようになるための修行として日々を過ごしています。
インフラ側を色々と詳しくなれるのは楽しいですね。

プログラマとして生きていくのか、上流に行くのか

プログラマとして生きていくのか、コンサル方面で生きていくのか。
それぞれのいいところ考えてみた。
デメリットはそれぞれ裏返しだ。


プログラマの生き方
 〇 プログラミング楽しい
 〇 スーツ着なくていい(大体)
 〇 書類整理とかエクセルとか事務作業が少ない
 〇 集中して仕事しやすい(環境にもよるけど)
 〇 自分のペースで仕事できる(どうでもいい割り込みが少ない)
 〇 フレックス制が多く満員電車乗らなくて済む。朝もゆっくり。
 〇 興味のない業務知識の勉強が少なくて済む
 〇 外部のボトルネックが少ないから効率化しやすい
 〇 威圧的な人や大変な人と会話する機会が少ない(論理的に話せる)
 

コンサル側の生き方
 〇 給与が高い
 〇 なんか、すげーって言われる
 〇 コミュニケーションスキル上がる
 〇 システムの全体像とか考えられるしビジネス起こしやすい
 〇 マネジメントしたり、スケール大きいことできる
 〇 経営層とかビジネスの一線の人と一緒に仕事できる
 〇 概念を言語化したりモデル化する能力が伸びる
 〇 顧客の為に働ける

エンジニア能力表(仮)

何を中心に勉強していこうかなーと考え中。

☆は今達していないレベル
★は、今自分が達したと思っているレベル

LVは
 ・1:初心者(入門書1冊読んだ程度)
 ・2:経験者(半年くらいの実績、言われたことができるレベル)
 ・3:中堅(3年前後の実績。自分の頭で考えてできる、精度はまあまあ)
 ・4:ベテラン(10年前後の実績。周囲を巻き込んで、あるべき理想を実現できる)
 ・5:専門家(20年くらいの実績。本を出すレベル)
の5段階。

開発の仕事
 要件定義 ★★☆☆☆
 基本設計  ★★★☆☆
 詳細設計  ★★★☆☆
 プログラミング  ★★★☆☆
 テスト  ★★★☆☆
 
開発以外の仕事
 運用  ★★☆☆☆
 インフラ  ★☆☆☆☆
 経営  ★☆☆☆☆
 マネジメント  ★★☆☆☆
 営業  ★☆☆☆☆

仕事の領域
 組み込み系  ★★★☆☆
 業務系  ★★★☆☆
 WEB系  ☆☆☆☆☆

知識の領域
 コンピュータサイエンス  ★★★★☆
 ネットワーク  ★★☆☆☆
 Linux系OS  ★★☆☆☆
 Windows系OS  ★★☆☆☆
 開発プロセス  ★★☆☆☆
 データベース  ★★★☆☆
 セキュリティ  ★☆☆☆☆

バーコードの奥深き世界 DataMatrixコード

マトリクス型の2次元コード
シンボルサイズは、1辺10セル~144セルまで色々とある。
現在はECC200というバージョンが主に使用されている。1辺のセルの長さが偶数であれば、このバージョンであると考えてよい。

1辺が長い場合には、1辺26セルの単位で1かたまり(ブロック)として、複数配置する。
そのため、
 ・1辺26セル以下なら、1ブロック
 ・1辺28セル以上、52セル以下なら 4ブロック(2^2)
 ・1辺64セル以上、104セル以下なら 16ブロック(2^4)
となる


QRコード同様に、
 ・アライメントパターン
 ・誤り訂正符号
が存在する。

アライメントパターンは、L字の黒く塗りつぶしたセルが一番外側にあるものである。
※逆側のL字は白く塗りつぶしてある。これはクロックパターンと呼ばれる。
これによって、角度、位置検証を行う。

誤り訂正符号は、リードソロモン法で計算し、データ部に連結する。
なお、データはX軸、Y軸方向に平行には動かず、斜めに配置されているので注意。

バーコードの奥深き世界 QRコード

マトリクス型2次元コードは、正方形の白色背景の上に、セル(黒い正方形)を載せていく。

QRコードで、まず目につくのは、3辺に配置された正方形が黒く塗りつぶした正方形を内包しているところだろう。これは、位置検出を容易にするためのマークで、ファインダパターンと呼ばれる。
そのように、複数のセルが並んであるパターンを作る。そのパターンをあつめたものがQRコードである。

QRコードは大きく4つの要素を持つ
 ・ファインダパターン(位置検出のための切り出しシンボル)
 ・タイミングパターン(
 ・フォーマット情報(誤り訂正レベル、マスク番号)
 ・データ誤り訂正符号(リードソロモン富豪)


ファインダパターンは、どの方向でも読み取るため、左上、右上、左下の3か所に配置されている。
※また、モデル2からは、アライメントパターンと呼ばれる、右下にある特徴的なマークが存在する。これはゆがみを調整する(細かな位置調整)ためのものだ。

タイミングパターンはファインダパターン同士を結ぶ、黒と白のセルが交互に配置された線である。シンボル内のモジュール座標を決定する。

フォーマット情報は、ファインダパターンの周りに存在する線である。

サイズは3種類あり、
 ・マイクロQRコード 1辺が11セル 数字は35文字まで
 ・QRコードモデル1 1辺が21セル 数字は1167文字まで
 ・QRコードモデル2 1辺が25セル 数字は7089文字まで
※モデルが上がるごとに1辺のセル数が4つ増える