現状の社会が立ち行かない問題に結びついた。
技術の進歩と共に千差万別のやり方が生まれ、
技術者同士のコミュニケーションは連携が取り辛く、
教育コスト自体は負荷の大幅増加に伴って
独学が推奨され、手とり足とりしなくなった。
結果として全体でテンプレートや纏まりが無く
問題発生時の情報共有コストも跳ね上がり
疑問点が解消されないまま責任問題だけが浮上。

技術向上の観点からすると、
好きでやってる、無償だから、というのは分かる。
問題はそれを利用した上で利を得ようとする人。
キチンとした理解とか、そういう事が出来てれば
何も言う事は無い。
だが、理解せずに使うのは
こういう全体のリスク考えてないよね。
知らんじゃすまされんよ。

社会全体が幸せになるには、教育は大事だよ。
行き過ぎた個人主義はやっぱりよくない。
自分勝手な人は何言っても分かってくれないけど。
人は機械じゃないの、要らないからって
命を捨てるのかい？それはエゴだよ。
ただ、頭のレベル格差によっては、
もうどうしようもない事もあるんだよね。
非常に悩ましい。

たった一人の個人で考えた場合は、
結局取捨選択しかできない。
グループでなら、拾いあげられるかもだが、
人が増える度に別の問題のリスクが高まる。
ある意味で二律背反じゃねーのかこれ。
まぁ、それもグループ内教育が徹底してたら
問題無いんだけどね。
いや、ブラックは別よ、社会全体的に見ても
正しい意味で教育が行き届いていないとダメ。
それは上手く回ってるんじゃないの。
強制的に回してるの。現実見ろ。正しく働け。
誰も幸せになれないような会社はとっとと潰れろ。
幸せになれる会社ならどんどんやっちゃって。

午前中の面接が長引いた。
どうでもいいが、何でも出来るからと言って
社長にでもなればいいと言うのは安直ナリ。
利益ってのは価値を与えないと上がらない。
小さな金額なら不特定多数、大きな金額なら
スポンサーになるようなお金持ちさんから
価値と交換でお金を頂く訳で、その価値の大きさを
人に説得できるかは営業次第、説いても
相手が価値を共感できないなら売ったら詐欺じゃ。
その一方、お客さんはお金は払いたくないと仰る。
本当に人から満足を得るってのは難しいよ。
エロとかは安直だけど、競争激しいし、
資本主義である以上付加価値にも限界があるし、
行き過ぎた競争の果ては総ブラック化なわけで、
まいった、金が回らない限り破綻しか見えないｗ
まぁ、出来る事精一杯やるだけだな。
小さな事の積み重ねが、大きな事に繋がる。

あ、因みに結構上手く話せたと思う。
ってかやっぱりブラックと見なされるか、
以前のグレー会社・・・。

同日　14:23
朗報来たれり。

同日　18:09
なにか、だいじなことを、おもいだした。


同日　22:18
破壊する事、分かってきた。

右脳だけで絵を描いてるのが分かる。
大枠にルールはあるが、感性だけが動くから
センスがモロに出るということ。
細かく描写するにはデッサン不可避だが、
実物ルールに捕らわれる左脳要素は
絵の自由度を下げてしまう。
表現したい事を最初に右脳で明確化して、
細かく修正する際に左脳が働くけど右脳の結果を
壊さない様に修正するのがコツっぽいな。
簡単に言えば

どんな風に描いたら面白いかね＝右脳
これってどんな形だっけ？＝左脳

じっくりと取り組む内に、色々理解が進む。
興味深い点として、IPv6について。
未だに影が薄いが、既存のIPv4と如何にして
通信を可能にするかが現状の問題点のよう。
デュアルスタックとトンネリングによる解法が
主流なのは納得できるが、ブロードキャストが
出来ない、マルチキャストを使えというのが
根柢の問題ではなかろうか。
特にノード、リンク、サイト、管理のそれぞれ
ローカルという考え方が面倒。
しかも管理に至っては現状用途不明。
とりあえずFF0/8で定義してあるというのが特殊。
あと、IPv4ではDHCPによってIP割り当てられるが、
v6の場合ステートレスオートコンフィグレーション
によって自動でIP割り振られるのも大きい違い。
特定パケ処理用にフローラベルが20bit存在するが
実験段階である等色々まだまだ不備がある模様。

同日　22:45
下絵がある状態だと気付かないんだけど、
体部分を白く塗りつぶすとすげー違和感があって、
30分位してから理由に気付く。
右足と左足が逆にあると感じるからだと。

バレエの影絵錯覚と同じ原理だな。

なんか4月9日まで時間が出来た。
ちょっと調整して自重してたのに、まあええ。
CCENTの方は実機シミュレーション問題やった。
片手間でSQL本読む。従業員の欠勤テーブル
とかで連続欠勤集計する場合の対処とか読んだ。
個人的にはその日の前の出勤日を保持しておけば
連続休日判定をSQLで行う事を避けられると思う。
その前の出勤日ってのはどうやって出すか？
それこそphpとかのプログラムで算出するべき
なんだよなぁ、休日判定はお手の物。
餅は餅屋ってな。

別テーブルでカレンダー保持する場合、
カレンダーテーブルが必要な上に、
欠勤テーブルにはレコードが増えるのに対して、
上記方法ならdateフィールド1個増えるだけ。
そのフィールドが改変されているかのチェックも
集計前にphpを介してチェックすれば問題無い。
こうして考えると、ちょっと面白いと思った。
さて、そろそろ夕飯。