カープ敗戦前後の読書録
週末に読んだ本。
これはソフトバンクの孫正義氏の社長室長をしていた人が書いた本です。
読んでみた感想としては、「オススメしません」。
いくつかは評価できると思えますが、これが私の感じていることを解決できるかという点で、解決できないと感じた為です。
終盤、エクセルやパワポのテクニックの話になったところで飽きてきました。
うーん、営業職の人には良いのかもしれませんね。
実家からの帰りの新幹線でもう一冊読みました。
内容はさきほどの本と重複する部分があります。
すごく単純明快なことが書いています。
特に、この本で伝えたいことが青字で強調されて頭に入ってきます。
読むのに2時間かからないかも。
文字も大きくて、文章が少ない、そのうえ論旨が明快。
軽く読むならこちらの本が良いでしょう。
いずれの本においても共感できる部分がある。自分が資料を書くときにまずぶち当たるのは、「伝えたい」は何か、「効果的に伝える方法」は何かなんてことで、どちらもそういう話は取り上げてます。
自分の書く資料は、文章が少ない。
下手したら文章がない。
心のどころで「オレは俳人になる！」とか思っている。
575のように、コーヒーをドリップするように、無駄を削ぎ落としたいと考えている。
困ったことに、せっかく削ぎ落としたのに、これを入れろ、あれを入れろと言われる場面があることだ。メッセージがブレる。まじで困る。
入れないと次のステップに進ませてくれない。
proxy環境下のhyperlegder/fabricの勘所
とにかく面倒くさい。
日本人であるビハインドの次に、プロキシ通さないといけないビハインド。
1つ目
Windows上のvagrantプログラムが最新のboxを探すためのproxy設定。
これはコマンドプロンプトからvagrant upを呼ぶ前提として、Windowsが認識するhttp_proxyやhttps_proxyを環境変数としてsetする。
これ自体はファイルの修正は不要。
2つ目
vagrant upした時に、virtual box上の仮想マシン(ubuntu)がapt-getするので、そこにプロキシを通してあげるために、(自分のやり方では)vagrant-proxyが導入されている前提で、VagrantFileにそれ用の記述をしておく。まあ、ファイルを書き換えなくても、プラグインが認識する環境変数を渡す手もある。
あと、後々に変にdockerコンテナ間の通信でプロキシを挟まないようにNO_PROXYも書いておいたほうがいい。
3つ目
プロビジョニング中に呼ばれるsetup.shで/etc/default/dockerを上書き(>)しやがるせいでハマるため、setup.shを修正して、/etc/default/dockerに、プロキシ設定をexportする記述を追記(>>)する。
上書きしやがるというのは、vagrant-proxyにおけるdocker用設定は意味ねーって状態になる区間があるという話です。
4つ目
仮想マシン上でプロビジョニング中にdocker buildする際に、apt-getがまた動くのだけれど、それに対応するために、docker.shにONBUILD時の環境変数(ENV)としてプロキシ設定を書き加える。
docker.shからdocker build時に呼び出されるcommon.shに書き加える方法もあるが、docker.shで作ってるDockerFileに対して設定を与えるほうがスマートであろうと考えている。
うーむ、/etc/apt配下ファイルをコピー(COPY)する？というやり方もあるのかもしれんが、いまはONBUILD ENVで環境変数を切っている。
まとめ
インターネットに繋ぎたがる3つの主体。
仮想マシン上でのapt-get
仮想マシン上でdocker build時のapt-get
vagrant-proxyを導入しただけでは動かないから覚悟しときやー。
地方銀行・第二地方銀行の勘定系システム勢力図を紐解く
おもにウィキペディアから情報を得ています。
把握漏れはありえます。
都銀、信託銀行、ネット銀行などは含みません。
調査対象は以下のページに記載されていた地方銀行・第二地方銀行のみです。
勘定系システムの把握率、地方銀行98.46%、第二地方銀行82.93%です。
だいたい把握できてるから、ざっくり感覚で楽しもう。
参加行数ベスト5
| 地銀共同センター | 14 | NTTデータ |
| NEXTBASE | 12 | 日立製作所 |
| BankVision | 10 | 日本ユニシス |
| STELLA CUBE | 8 | NTTデータ |
| じゅうだん会共同版システム | 7 | 日本IBM |
| Chance地銀共同化システム | 7 | 日本IBM |
地方銀行に人気ベスト5
| 地銀共同センター | 13 | NTTデータ |
| BankVision | 10 | 日本ユニシス |
| じゅうだん会共同版システム | 7 | 日本IBM |
| Chance地銀共同化システム | 6 | 日本IBM |
| MEJAR | 4 | NTTデータ |
| TSUBASAプロジェクト | 4 | 日本IBM（仮） |
第二地方銀行に人気ベスト5
| NEXTBASE | 12 | 日立製作所 |
| システムバンキング九州共同センター | 6 | NTTデータ |
| STELLA CUBE | 5 | NTTデータ |
| BankingWeb21 | 2 | NEC |
5番目はたくさんあるので省略させてもらいます
一位と二位を日本IBMとNTTデータが争うのが昔からの構図。
三位に日本ユニシスなのかな？
日立製作所のNEXTBASEは本当に第二地方銀行に人気があるんだなぁー
z/OSのC言語でウカツにsleep関数使った話
やりたいことは単純だ。
USSの特定のフォルダに、
特定のファイルがあったら、
1秒スリープしてループする。
ファイルがなくなったらループ終了。
原案を作るのにUSSにsshログインして、
ぺぺぺっとviで書き上げた。
ほとんどマニュアルの例。
USS上で実際に動く。
使用した関数は、stat関数とsleep関数。
原案をもとに、修正対象ソースを変更。
JCL流してコンパイルからリンクエディットまでする。
ロードモジュールを動かす。
ファイルがない場合の埋め込んだログが、
JOBLOGにでている。
よし、成功したと思っていた。
数日後、いざファイルを置いてみると、
CEEDUMP吐くくらいの異常終了。
sleep関数はPOSIX(ON)にしないと動かないというではないか。
わかった、試してみよう。
JCLのPARMにPOSIX(ON)を追加。
ぐは、データセットアクセスしてるコードがfopen()できなくなった。
ふむ。stat関数は意図した通りに動くので、ファイル存在確認はできている。
書き方の変更が必要なのは、sleep関数のみだ。
ネットを調べてみる。
clock関数を使うやり方は却下、あんなCPUバカスカ使うコードは書きたくない、腐ってもシステムエンジニアだ。
selectやpollはどうだろうか。
あんまりピンとこない。
ソケットになにかが書き込まれるのを待ち受けるみたいのにはイメージがあうんだけど、ファイルが削除されたことを待ち受けるとかはイメージに合わない。
pthread_cond_timedwaitは？
これもPOSIXかぁ。
settimerとかどうだろう。
POSIX依存だとさ。ひどい。
sigtimedwait関数じゃね？
MVS依存はするけど、いけそうなイメージがわいた。
sigtimedwaitで実装した。
ただ、コーディングミスで痛い目を見た。
EINVALがでる理由は、timespecの値だった。
秒に値は入れていたが、ナノに値を入れなかったせいで、ある箇所では動き、ある箇所では動かないでEINVALが返却された。
マイナンバーの「通知カード」を受け取ってきた話
年に数回しか郵便受けを開けないナイスガイです。
年末に久しぶりに郵便受けを開けました。
当然ながら、巷で噂のマイナンバーの郵便は、郵便局に戻され、
保管期限も過ぎて、船橋市役所に送り戻されており、
船橋市役所から別の案内がきておりました。
というわけで、その案内書に従うのです。
１月２０日までに受け取らないといけないと書いてありました。
受け取り方法は、再度の郵送か、市役所の窓口へ行って受け取るかの２つです。
郵送されても郵便受けを開かない漢ですから、
１月４日お休みをいただいている身のため、
朝から船橋市役所へ足を運んだのです。
２年１０ヶ月も船橋市に住んでおきながら、初めて市役所に行きます。
船橋駅の周辺って、無駄にスクランブル交差点があるなー、へー。
大きな通りを歩いていたにもかかわらず、どこを曲がれば市役所か案内板もなかったため、通りすぎてしまった。
迷ってしまったが、市役所に到着。
どこで何すればいいだっけ？
そういうときは、案内所の人に聞く。
「マイナンバーは、市役所別館です。出て、左へ行き、突き当りの右です。」という趣旨の説明を受ける。
あー恥ずかしい、市役所から届いた紙をテキトーに読んでいた。
では、いざ船橋市役所別館へ。
すでに人は別館の玄関から溢れ始めている。
時刻は１０時２４分。
船橋市役所別館におけるマイナンバーの事務は１０時開始です。
さて、並び始めるとすぐに整理券を受け取る。
５７８番と書いてある。
むむむ、なんでこんなに数字が大きいんだろう。
「１時間くらいは待つことになるかもしれません」という趣旨の説明を受ける。
他に船橋でする用事もあったのだが、待つことにした。
１０時３１分、中から５３０番を呼ぶ声が聞こえた。
視認可能な人数は１２人である、３６人も中にいるのか。
そこから、見えない中の様子を想定して、
待ち行列理論で、何分くらいかかるもんなのか計算し始めた。
３人でてくるのに２～３分はかかっている。
職員は何人対応しているのだろうか。
中が見えるポジションまで進んだ。
机に座っている職員は５人のようだ。
一人処理するのに３～５分かかっていることになる。
そこから思いを馳せて、もしも船橋市６２万人のうち受け取れなかった人が５％程度ならば、
今の処理能力で窓口受け取りをすると、５０日は必要になると計算した。
すでに受け取った人もいるだろうし、再郵送の人もいるだろうから、これから５０日ってことはないけど。
たまに緑の番号札を呼び出す声が聞こえる。
受け取り用の番号札だ。
それにしても、なんで市役所で「緑」なんて使うんだろう。
「赤」かもしれんじゃん。
職員のいる机に呼ばれるまで５５分待った。
船橋市役所から送られてきた紙と、本人確認書類として運転免許証をだした。
運転免許証のコピーを取ってよいかと聞かれて同意した。
紙の案内①に名前と電話番号を書くように言われたので書いた。
なんで電話番号がいるんだ・・・。
それに案内①は「郵送」を希望する人のための紙だし。
机での手続きは２分で終わり、緑の番号札をもらった。
また、ぼーと待つターン。
大きな声が聞こえてきた。
見ると、机の流れが滞っている。
５０歳台の男性だろうか。
どうやら父親の分のマイナンバーを受け取りたいらしい。
職員は「確実に本人に」の一点張りなのだが、ひたすらに申し訳なさそうに耐えている。
よく見ると、他も静かに滞っている。
どうやら本人確認書類のコピーを取ることが不服なのか、
利用目的を明示して、利用目的以外に使わないと誓え的な話をしている。
ふー、言われてみればその通りと思わせる内容ではあるのだが、残念な話だ。
１０年前を思い出してみろ、個人情報保護法なんてなくて、
ほとんどの日本人はそんなことをゴネたりしなかった。
いろんな人達が混ざっているもんで、自分みたいに２分で処理されるわけもない。
ふと窓を見ると、長蛇の列は、別館の玄関どころか、別館の入り口の道路付近まで伸びていた。
彼らはこれから机に座るまでに１時間半は覚悟しなくてはならない。
緑の番号札を受け取ってから１７分で、ようやく受け取れた。
受け取るときに郵送物の住所と氏名が正しいかの確認を求めれ、そして緑の番号札を返した。
トータルで１時間１４分かかったことになる。
問題点を２つ感じる。
これは本人確認したことにしてよいものだろうか。
「本人確認」した人に渡した「緑の番号札」を持っている人に渡しているのであって、
厳密に言うと本人に渡したという確証が持てない。
最後に自分へ「通知カード」の入った郵送物を渡した人は、机で受け付けた人とは別の人だし、
再度本人確認書類の提示を求めてさきほどのコピーと突き合わせるくらいまでやればいいのにな。
もう一つは電話番号だ。
結局なんで必要だったのかわからない。
個人情報の開示請求でもしてやろうかしら。
ちなみにe-GOVで「個人番号」を含む「個人情報ファイル簿」を検索したら、全府省で４件ヒットした。
文部科学省の「国費外国人留学生ファイル」
法務省の「上陸審査における個人識別情報提供記録マスタファイル」
法務省の「自動化ゲート利用希望者登録記録マスタファイル」
厚生労働省の「東電福島第一原発作業員の長期的健康管理システム」
こんなところに、ふーくーしーまー。
地方自治体のはどうやれば調べられるのかわからない。
地方自治体次第だな。
尼崎市はすごく細かく公表できている。個人番号があるのかは調べてないけど。
最後に、船橋市役所別館の待ち時間を実況ツイッターで実況してたのを、
マイナンバー反対派のアカウントが２つほどリツイートしていたが、
私は反対しているわけではないので迷惑な話だ。
混雑が予想されるなかで１時間１４分なのだから、合格点ではないだろうか。
でもね、平日以外で受け取りに行くのは自殺行為だよ、きっと。
PRHWってなんでっしゃろ
とあるダンプの、とあるレジスタに、
ちらりと見えたのがPRHW。
いったい何の略なんだろう。
答えはココに書かれていた。
Program Request Handle Work Area control blockということだ。
つまるところは、MQの接続ハンドルとかを置いておくエリアのようだ。
control blockのレイアウトがわかったわけでもないので役には立たない。
GradleのtestLogging
testLoggingの初期値（LogLevel別）
調べたことを表にまとめるとこうだった。
| debug | info | lifecycle | warn | quiet | error | ||
|---|---|---|---|---|---|---|---|
| events | STARTED | ○ | × | × | × | × | × |
| PASSED | ○ | × | × | × | × | × | |
| SKIPPED | ○ | ○ | × | × | × | × | |
| FAILED | ○ | ○ | ○ | × | × | × | |
| STANDARD_OUT | ○ | ○ | × | × | × | × | |
| STANDARD_ERROR | ○ | ○ | × | × | × | × | |
| displayGranularity | 2 | 2 | 2 | 2 | 2 | 2 | |
| maxGranularity | -1 | -1 | -1 | -1 | -1 | -1 | |
| minGranularity | 0 | -1 | -1 | -1 | -1 | -1 | |
| showExceptions | true | true | true | true | true | true | |
| showCauses | true | true | true | true | true | true | |
| showStackTraces | true | true | true | true | true | true | |
| exceptionFormat | FULL | FULL | SHORT | FULL | FULL | FULL | |
| stackTraceFilters | ENTRY_POINT | × | × | × | × | × | × |
| TRUNCATE | × | ○ | ○ | ○ | ○ | ○ | |
| GROOVY | × | × | × | × | × | × | |
| showStandardStreams | true | true | false | false | false | false | |
テストの開始ログが欲しい
lifecycleだとテストが動いてるのか止まっているのか良くわからない。
仮に初期値のままやるのであれば、gradle --debugとか頭おかしいことをすることになる。
では、lifecycleのeventsにSTARTEDを加えるのか？
それだとテストメソッドごとにログがでてきて憤死する。
せめて、テストクラスごとにログがでてくれればいい。
そういうときって、TestタスクのbeforeSuiteを書けばできそうだ。
test {
beforeSuite { desc ->
logger.lifecycle("{} {}",desc.name, tasks.testing.logging.TestLogEvent.STARTED)
}
}
あと、gradle --infoのときはテストメソッドの開始ログ、終了ログを出してやろう。
でも、標準出力と標準エラーはごめんこうむりたい。
test {
testLogging {
info {
events "started","passed","skipped","failed"
}
}
}
lifecycleだけexceptionFormat=SHORTなのは嫌
test {
exceptionFormat "FULL"
}
もしくは
test {
testLogging {
lifecycle {
exceptionFormat "FULL"
}
}
}
テスト結果の統計を見たい
何もしなくてもTestタスク全体の統計はでるけど、テストクラス単位のも出してみるか。
そういう時はafterSuiteを使う。
ちょっと懲りすぎかもしれないがこういうコード。
test {
afterSuite { desc, result ->
def event = tasks.testing.logging.TestLogEvent.FAILED
def level = logging.LogLevel.ERROR
if( tasks.testing.TestResult.ResultType.SUCCESS == result.resultType ){
event = tasks.testing.logging.TestLogEvent.PASSED
level = logging.LogLevel.LIFECYCLE
} else if ( tasks.testing.TestResult.ResultType.SKIPPED == result.resultType ){
event = tasks.testing.logging.TestLogEvent.SKIPPED
level = logging.LogLevel.WARN
}
logger.log(level, "{} {} total={} passed={} skipped={} failed={} elapse={} sec", desc.className, event, result.testCount, result.successfulTestCount, result.skippedTestCount, result.failedTestCount, (result.endTime - result.startTime)/1000)
}
}
