複数のコンピューター間で直接データを送受信するP2Pは、従来のクライアント・サーバー構造が抱える「サーバーへのアクセス集中」や「中央集権」などの問題を解決する技術として注目を集めてきました。P2Pはデータを分散して保存できる点が特徴であり、ビットコインなどの暗号通貨やBitTorrentなどで活用されています。オープンソースソフトウェアの「Hypercore Protocol」を使うと、そんなP2Pによる分散型ストレージやKVSを無料で簡単に利用できるとのことなので、実際に使ってみました。
ふーむ
日本のIT業界だけやけど、実際に手を動かしてコードを書くプログラマが一番安くて、エクセル方眼紙でポエム書いてるSE、パワポ紙芝居のコンサル、彼らを呼びつけるだけの伝書鳩PM、それに発注する顧客の方が単価高くないといけないと盲信されてるカルト宗教。需要と供給が逆転。
SI屋さんは総合商社という考え方もあるらしい。
最近はpydanticが人気なのか
2020年4月：とある企業（以下ではM社と呼びます。Mに特に意味はありません。）のインターンに応募し、書類選考落ち
↓
2020年8月：話だけでも聞きたかったので、カジュアル面談に応募するが、「以前の応募から半年経ってからにしてね」と言われる（引用1参考）
↓
2020年11月：2020年4月から半年以上経ったので改めてカジュアル面談に応募し、VPoE（以下ではV氏と呼びます。）と実際に面談する → 今回の話
正直一言で言うと「就活ですごく相性の悪い人と出会った」だけだと思うのですが、少なくとも僕はこの方がVPoEというポジションにいる企業に入社したいとは思わないです。
※ちなみに、M社とは、WEB系の中でも強いプログラマ達が集うあの企業です。
最初から相手にする気が無いにしてももう少し態度ってものがあるだろ感
京都市は総額117億円を投じた基幹系システムの刷新を一部を除き中断した。国が自治体システムの標準化を決め、再度の改変が必要になるとみたからだ。最悪の場合は投資額のうち100億円近くが無駄に終わる可能性がある。2016年の延期後にベンダーを切り替えたが、2019年に再度の延期を決定。開発遅延の背景には進捗管理の甘さや協力体制の不備、想定不足があった。
損切りするのも勇気やぞ
高校から～専門高校時代にかれこれ５年ぐらいプログラムの勉強したけど結局挫折して今は経理畑で毎日エクセル方眼紙の整理してる。
仕事では全くと言っていいほどプログラムは使わない。
エクセルでマクロは組むけど、プログラムの勉強で得た知識は殆ど使わず、淡々とネットや本から拾ったコードをコピペして継ぎ接ぎしてるだけ。
それでも「柳沼さんすご～～い。何でもすぐやっちゃいますね」と感謝されてる。
プログラムの勉強してた頃はこんなこと全く無くて、ギブハブでも学校でも就活でも「お前みたいなゴミレベルがプログラマー自称してんじゃねえよ。使い物にならねーんだよカス（意訳」としか言われたことがないし、そうやって罵倒されながらも身につけたプログラミング能力は今現在自分の人生においてクソの役にもたってない。
せいぜいソシャゲのリセマラ・周回マクロ組む時に使うぐらいか？
でもEXCELの知識はめっちゃ使ってる。
なるたけマクロじゃなくて関数で解決するスタイルなおかげで、プログラムを本能的に拒絶するタイプの相手でも「まあ……これぐらいなら何とか使って見回すわ」と仕事を振ってもちゃんと引き継いでもらえている。
給料の査定もいいし、仕事に余裕があるから有給も消化できてる。
同級生でプログラムバリバリだぜ～～と調子こいてた奴の多くは自分なんぞよりも低い給料で有給も消化できてないらしく「いや……IT業界の良さって華々しさぐらいっすね……ヌマさんの仕事マジダセーけどそれ以外は羨ましいとしか言えんわ」「わかる。ダセー以外は俺の理想」ってよく言われてる。
俺がエクセルの勉強に使ってる時間って、全部足してもプログラムの勉強に使った時間より少ないと思うんだけど、人生においてずっと役に立ってる。
雑に計算して１０倍じゃ効かないと思ってる。
世の中には「プログラムの勉強こそ正義！エクセル方眼紙は雑魚！」みたいな空気に酔ってる人が多いけど、格好良さじゃなくて実用性を求めるならエクセルの勉強のほうがずっと役に立つと思う。
つうかMSオフィス大体どれも時間投資した分だけちゃんと返ってくる。
プログラミングはお山の大将になってイキろうとお猿さんが群がりすぎた山が多すぎるから、投資効率がめっちゃ悪い。
まあ楽しいとは思うよ。
エクセルなんぞより。
でも少ない投資で仕事を楽にしたり給料をもらうって意味じゃ圧倒的にエクセルが上だわ。
スキルとは相対評価なので全体から見れば多少アレでも需要があって供給が少ないところに潜り込めれば無双できたりもする。
これは成功事例と言えるだろう。
「StarFive JH7100」と名付けられたBeagleVのSoCには、1.5GHzのクロック周波数で2MBのL2キャッシュを備えたデュアルコアRISC-Vプロセッサ「SiFive U74」が搭載されています。StarFive JH7100は他にも、東芝の次世代車載SoCにも採用されている画像認識エンジン「Tensilica Vision P6 DSP」やNVIDIAのディープラーニング用エンジン「NVDLA」、ニューラルネットワークエンジンを搭載しており、機械学習に適したSoCとなっています。
BeagleVは周辺機器も充実しており、USB 3.0ポートやギガビット対応イーサネットポート、IEEE 802.11b/g/n対応Wi-Fiアンテナ、Bluetooth 4.2、HDMIポート、microSDカードスロットなどを搭載。USB Type-Cポートは給電に使用します。また、RAM容量は4GBモデルと8GBモデルが存在し、4GBモデルは119ドル(約1万2400円)、8GBモデルは149ドル(約1万5500円)と価格が分かれています。
おもしろそう
GCP（GCE）でそこそこ長めのバッチ処理（処理時間がCloud Functionsの制限を超えそうな処理）を実行したい場合どうすればいいか調べていた。
王道としてはCloud ComposerやCloud Data Fusionを使うということなのだろうか。
とはいえ、システムをもう少しコンパクトに抑えたいという思いもあって、適当なトリガーからプリエンプティブルインスタンスを起動して、その中でコンテナを動かし、バッチ処理を行う的なことがしたい。
以下のドキュメントを見る限り、実現できそうではある。
GKEだとこの辺はもっと簡単に実現できるのだが、はてさて。
申し込みDONE。2021/01/22開催。
興味があるセッションは↓ぐらいかな？
アーカイブ公開してもらえると助かるのだが。
理由が気になったのでチャットで色んな人に聞いたらどうやらlet/constはES6策定前からFirefoxに存在するということが判明し、当時を知るのは恐らくJason Orendorffという話になったので本人に聞いたら挙動こそ違うものの確かに存在したとのこと
letが再代入不可だったらわりとすぐに受け入れて進んで使っていたと思うんですが、まさかのreassignableでOCamlと真逆なので記憶から抹消していたフシがある。そして、ただの変数宣言にconstと5文字打つのわりと苦痛…スコープの問題も分かるので、本当に若者に煽られたくて5文字書いてるだけ
でlet/constの命名を決めたのはJason OrendorffではなくBrendan Eichだったと思うという話になり、理由を聞いたところどうやらSMLインスパイアだったらしい
追加情報
JS engines already added
constin the late '90s (SpiderMonkey did; I believe at some point Opera's Futhark engine added it as a synonym forvar, lol).letindeed came from ML familiy (not from BASIC).
コンピュータ考古学だ
「データサイエンティストになるにはなにを勉強したらよいですか？」って丸投げな質問がたまにくるけど、その職業がなにをやってるのか調べて学ぶべき事項へ分解するのは難しいのかな？
私が「竹馬の練習しておくといいですよ！」と返したら竹馬の練習するのだろうか？
脳が仕事していない人は頭脳労働には向かないのだ
webの話です
PythonやRubyの話になると処理速度の話持ち出す人いるけど今どきマシンスペックだってどんどん上がってるから言語選びで処理速度とか気にしなくてよくない？って思う
むしろそういうこと言うお前はさぞかし効率の良いコード書いてるんだろうな、って詰めたくなる
例えばPythonではfor文ループでappendするのとビルトインのlist関数を使うのとでは処理にかかる時間が倍以上違うしそのばその場にあった適切なライブラリを使うだけでもかなり速くなる
っていうじゃん？
Rust で書かれた Discord と PHP で書かれた Slack の処理速度差感じることは割とあると思う
Twitter も Rails 時代は落ちまくってたけど Java に移行してから安定してるやろ？そういうことよ
今どき Rails とかでいいって言ってるのは
・スケールしたらリプレイスする前提で初期の開発速度に極振りすることを分かっている人
・スケール後のトレードオフまで目がいかずに軽い気持ちで起業とか考えてる人
のどっちか
煽りよる
Go言語で開発されたAPI Gateway。競合はKong。Kongより高速に動作することを謳っている。
ＳＥＳの人売り社長は、頭のねじが飛んでる狂った別次元の人間という認識がネットでされてるが
まぁ間違いではないんだが、そんな人格破綻者なんてごく一部で、実際は彼らなりに悩みがあるということを、俺は新卒の時に知ったので語りたい
前置きをしていくと、俺はそういうブラック企業やるような社長なんて、死ねばいいと思ってるし、社会のガンだと思うし、言っては悪いが反社の一員と分類してもいいくらいじゃないかとさえ思う
今は亡き社長も、そんな人間だったが、それに至るまでにはいろんな人生の挫折とかがあったということを知った
供養がてらに「仮面ライダーになれなかった男の人生」を知って、何か考えてもらえればと思う
今でこそ、ちゃんとした会社に入ってエンジニアとしてたくさんの経験を積ませてもらって
それなりな人生を歩ませてもらってるが、ＩＴエンジニアのお定まりの通り、俺も新卒の頃は今思えばヤバいと言っていいような底辺人売りＳＥＳにいた
まぁ絵に描いたようなＳＥＳのブラック企業の社長って感じで、面接のときだけ人当りはよく、すっとぼけてレガシーな現場に送り込んでピンハネ三昧、営業活動と称してキャバクラ風俗ハシゴして
気に入らなければキ〇ガイの様に発狂してあたり構わず喚き散らし、物に八つ当たりをして威嚇する、反社との付き合いをほのめかして自分を大きく見せようとする、そんなオッサンだった
俺も最初は理解不能のキ〇ガイかと思っていたが、やめるまでの半年間付き合ううちに、早く死にたいからそんな無茶な暴飲暴食や、奇行を恐怖からやっていたということがだんだんとわかってきたんだ
都内の貸しビルの一角みたいな、ＳＥＳお定まりの金のかからない殺風景な社長のオフィスには、パターゴルフセット、開けて中身見れば風俗やキャバ嬢ばっかの名刺入れとかそんな中に似つかないように、仮面ライダーBLACKRXのフィギュアが置かれていた
社長はその仮面ライダーが好きだという、子供のころからのファンで、仮面ライダーみたいな正義のヒーローになりたかったんだという
おりしも社長が若いころには就職氷河期、Ａラン大学でバリバリの計算機科学を学んだ社長は、今は見る影もないが、当時は凄かった国内大手の某ＩＴ系企業に入ることができたそうで、順調にエリートエンジニアコースを歩んでいた、南光太郎の様な格好いいヒーローを目指して、エンジニアとして頑張っていたそうだ
ところが、おりしもリストラブームから00年代初頭の、地獄のようなブラックＩＴ業界旋風、その中で社長は理解のある上司から、パワハラ上司の下へと転籍となってしまったところから、歯車が狂ったのだという
いじめ、暴言、いやがらせ、今やれば刑事事件で捕まりそうなレベルのいびりを受けて、とうとう社長は身心が壊れてしまった。体の震えや動悸が止まらなくなり、躁鬱で泣き出したり激高したり、今の性格の基礎がこの時の後遺症でできているようだった。
社長は会社を辞めた、というより辞めさせられたというのが近いのかもしれない
辞めていくエンジニアたちが集まって、自分たちが派遣するという形で特定派遣の企業を立てたそうだ(今でこそこんな有様だが、当時は社長や経営層がみんなエンジニアで、自ら客先常駐して稼ぐ特定派遣だって結構多かったのだ)
めげずに何度も諦めないで立ち上がろうとした社長の心を支えていたのは、子供のころからのヒーロー、仮面ライダーBLACKRXだった。
だが、大手企業の看板もなく、おりしも法整備が追い付かずリアルヤクザまでもがエロゲー作って売ってたくらい無法地帯だったIT業界、野比YRPの軍曹日記のようなことは日常茶飯事で、社長も足元を見られ、無茶振りをさせられ、下請けいじめによってどんどん身心を疲弊させていった
一人、また一人と一緒に会社をやめて合流したかつての同僚や仲間たちが、IT業界に見切りをつけてやめていく、当時はまだみんな30代とか、定年間際、第二の人生を歩める余裕があったのだ
だが、社長はそれでも最後まで諦めようとしなかった、逃げるのは悪いことだ、と最後まで責任を持ち続けた
結果、倒産、多額の借金を背負わされ自己破産、とうとう社長は壊れた。
それからは坂を転がるようにヤクザ者と付き合い、ブラックSESでﾄﾞﾅﾄﾞﾅ人売りで稼ぎ
営業と称して昼間から飲み歩く、かつて仮面ライダーになりたかった男とは思えない、人間のクズにまで落ちぶれていったそうな
社長は既に重度の内臓疾患だか癌だかを患っていたようで、治療もまともにせず、そんな破滅的な生活を続けていた、不起訴になっているが、警察沙汰にだって何度もなっていると聞いた。
俺が入って辞めるころには、社長だって死ぬ間際だと悟っていたのか、マトモな人間は(俺もすぐ辞める予定だったけど)離れていき、もう人売りするだけの人間さえ寄り付かず、完全にご破算状態の中で、気弱になった酒の席で、俺だけにその生い立ちを打ち明けていた。
思えば恐怖と寂しさがあったんだと、今に思う。その時俺は、ムカっ腹が立っていたので「どうでもいい話すんなよ、いい年こいたオッサンが未だに仮面ライダー仮面ライダーって頭おかしいんじゃねえのか？俺をこんな目に遭わせやがってとっとと肝臓がんで死ぬほど苦しんでからくたばれよ」と思っていたが
今振り返れば、誰かに話を聞いて欲しかったんだろうな。
社長は俺の態度で察しているのか、この世のものとは思えない、俺も二度とあんな顔を拝むことはないだろうというほど、絶望に突き抜けた表情をしていたのを、ハッキリと覚えている、社長は、息ながらに地獄に堕ちたんだろう。
そして会社辞めて紆余曲折あって数年、いい人たちといい会社に恵まれていたころ、社長が肝臓のガンだか疾患だかで死んだという報せを聞いた。
口から血を吐いてもがき苦しんで、今までの早く死にたいがためにやっていた滅茶苦茶な行動のツケを払って最後まで苦しんで死んでいったという。
正義のヒーロー仮面ライダーにもなれず、開き直ってショッカー怪人や暴力団やヤクザにもなれず、ＩＴエンジニアとしても中途半端で、どこにも居場所がなくなった社長は、何物にもなれず、死んでいった。
嘘松とか主語がﾃﾞｶいとか、何を言ってくれてもいい、ウンチだとかでもきもくて金のないオッサンは…とか言い出し始めてくれてもいい
ＩＴ業界の影で「仮面ライダーになれなかった男」の話を、頭の片隅に忘れないで欲しい
そして、社会でそんな風に無軌道な生き方をしている半グレだとかＤＱＮだとか、ブラック企業の社長や滅茶苦茶なことを言う学者や政治家や芸能人、ユーチューバーだってそうだ、それらは完全に頭が狂った人間でなく、ただの小心者な普通の人間で、自分の悩み多き人生を少しでも早く終わらせたくて、自分を傷つけるようなあんなムーブをしているのだと、俺は思う
彼らもまた「仮面ライダーになれなかった男たち」なんだろう
誰からも嫌われて行き場をなくした社長の形見の仮面ライダーＢＬＡＣＫＲＸは、俺の部屋でリボルケインを掲げて、社長の変わりのように悪に対して今日も正義のために戦っている
設定を書いたはいいけど、即お蔵入りになってしまったので供養としてここに記録しておく。
実際にはcheckoutの後に色々手順があったけどそういうのは省略。
version: 2.1
orbs:
gcp-gcr: circleci/gcp-gcr@0.11.0
jobs:
build-and-push:
executor: gcp-gcr/default
steps:
- checkout
- gcp-gcr/gcr-auth
- gcp-gcr/build-image:
image: $IMAGE_NAME
tag: $CIRCLE_SHA1
- gcp-gcr/push-image:
image: $IMAGE_NAME
tag: $CIRCLE_SHA1
workflows:
main:
jobs:
- build-and-push
データの性質を抽象化して、値の種類を分類し、値の種類ごとに有効な関数の集合を定義するために、Javaではclassを宣言し、Haskellではmoduleを宣言する。
同じアプローチなんだけど、Javaだとオブジェクト指向プログラミングと呼び、Haskellだと関数的なプログラミングと呼ぶ？
Javaのクラスをイミュータブルに設計することで関数的なアプローチに近づいた。
Haskellの関数群とデータの構築操作を、値の種類ごとにmoduleにまとめることでオブジェクト指向プログラミングのカプセルと同じアプローチになる。
GoやPythonの関数とメソッドの違いにも通じている
特定のデータ構造と明示的に関連づけた関数がメソッド。
オブジェクト指向プログラミングのカプセル化の実現。
SES会社からアサインされているエンジニア、傍からみていても改善すべきポイントが山のようにあり、まさに伸びシロしかないという状態だが
彼を育成・指導することが自身の評価に繋がる人間が周囲にひとりもいない為、第二新卒のような彼が自分自身で気付くしかないという状態。ベリーハード
システム開発会社の通常の請負契約だと容易に案件赤字になるために必然的に育成・指導などの生産性向上の努力が生じる
SES会社の準委任契約においてはSES会社は案件赤字になりようがないため、このポイントではビジネスモデル構造的に生産性向上努力が発生しない
SESは滅ぼされなければならない。
さておき、こういう状況でちょっとした指導をしてくれる奇特な人もいたりするのだけど、SESでやってきている若手としては「善意で教えてくれている」のか「客からの業務上の指摘（ダメ出し）」なのかよく分からずパニックになってしまう悲劇が発生しがち。
そもそもSESの業務としては仕様通りのものを実装して納品することが第一目標になるので、そこに注意を向けることになるわけだが、ここで気紛れに「こうした方がいいよ」みたいなアドバイスや指導が入ると「他の部分もやり直すべきなのか？ 実装もテストも？」ということになるのでかなり暗澹たる気分になってしまう。
最悪の場合、「言うことをコロコロ変えるんじゃねぇ！」とキレられてしまうこともある。
したがって、SESを使う場合は「学習や指導によるキャッチアップ」より「ルールでがんじがらめに縛る」方が結果的にはお互い楽という状況が発生しがち。
あと「なにもないかもしれないのに、なんでそんなに繰り返しテストするの？」という指摘がたまにあります。
これはソフトウェアテストとハードウェアテストの根本的な考え方の違いに起因するのかなと思っています。
ソフトウェアテストでは主に網羅的な機能チェックつまりカバレッジが重視される傾向にあると思います。わかりやすく言えば、デプロイ前に網羅的に1回テストパスすれば良い、というのがソフトウェアテスト的な考え方です。
一方で、ハードウェアはわずかな環境によって結果が違ってきたりするので、例えば「USBメモリが10回に1回くらい認識されないんだよね」みたいなことが出てきます。USBメモリならユーザが目の前いるので抜き差ししてもらえば良いですが、これがどこかに組み込まれてしかも1000台出荷して毎日100台が不具合を起こすシステムと聞くとだいぶまずいですよね。
この故障率が10回に１回なのか、100回に１回なのか、10,000回に１回なのかがわからないというのがハードウェアテストの考え方のベースにあります。つまり、ハードウェアテストとは故障率を明らかにすることだといえます。
この辺の考え方の違いは興味深い。
ソフトウェア開発の歴史はハードウェアを抽象化する試みの歴史とも言え、現在ではハードウェアはスペック以外はほぼ意識されない存在になっている。
ソフトウェアエンジニアの立場では、ハードウェアの個体差に起因する問題は無視できるレベルの誤差、あるいは問題が生じたらパーツ交換で回復するものという感覚になっている（それ自体は進歩の方向性として正しい）。
しかし、ハードウェア込みでプロダクトを提供する組込み開発ではこのような思考をするのだなと。
最低限のタスクランナー機能があればよいので大体以下のようになる。
#!/bin/bash
set -eux
CMD=$1 && shift
OPTION=$@
function main() {
case ${CMD} in
# -- APサーバを起動
start)
poetry run gunicorn -w4 --bind 0.0.0.0:8080 src.xxx.app:app --reload
;;
# -- ビルド（何かビルドが必要なものがある場合）
build)
poetry run xxx build
;;
# -- テスト実行
test)
poetry run pytest ${OPTION}
;;
# -- デプロイ
deploy)
echo "デプロイ処理"
;;
# -- 対応する処理が存在しない
*)
echo "does not match parameter."
;;
esac
}
# -- Run Script.
main
複雑なサブコマンドや引数が必要になることは少ないのでチェック処理などは必要性に迫られない限り省略している。
このスクリプトを task.sh みたいな名前でプロジェクトルートに配置する。利用時は↓のように呼び出す。
$ ./task.sh start
最近はほぼ100%dockerを使うので↓みたいになる。
$ docker-compose exec <コンテナ> bash task.sh start
このようにしている理由は Poetry の scripts はタスクランナー機能ではないということらしいので。詳しくは以下のリンク先を参照。
Pipenvから見ると退化したように見える反面、パッケージ管理ツールに依存しなくなったとも言え、いいんだか悪いんだかといった感じである。
ヘルプドキュメントが無いとかシェル補完効かないみたいな問題やプロジェクトメンバー全員にシェルスクリプト力（ちから）を求めるのはどうなんだみたいな話もあるものの、とりあえず必要十分なので良しとしている。
いやまじ、一番謎なのは休日勉強勢よりも
圧倒的に「エンジニアに向いてない人間などいない」勢だろ。
普通に有害だし。
人間、絶対的に向き不向きはあるっての。
問題はその向き不向きが永久に成立するのか、ただの現在値なのかは別として。
何れにせよ現在のスナップショットとして「向いてない」ので、何かしらパラダイムシフトするか辞めるかした方が本人のため、っていう奴は間違いなく存在するやろ。
「エンジニアに向いてない人間などいない」って「頑張ればみんなプロスポーツ選手になれる」ぐらいの暴論だと思うのだ
・そもそも、「現状のフローはまともに動かないシステム用の間に合わせのもの」という認識が現場の誰にもなく、「誤りを防ぐための丁寧で価値のあるチェック体制」だと認識されていた
・今のフローを考案した人がリスペクトされていて、そのフローが神聖視されていた
・現状のシステムで複雑な仕事を丁寧に回せる人が評価されてリーダーになっていて、その人が今のフローを変えることを望まなかった
・経営層は「システムがまともに動かない」という問題は把握していたものの、具体的にどんなフローが走っているかは理解していなかった
・現状のフローに「これおかしいだろ」と思ってそう指摘する人もいたが、そういう人たちは「面倒なタスクを嫌う怠惰な人たち」とみなされて冷遇されるか、あるいは既に退職していた
で、我々がヒアリングしたのがまさにその、「今のフローを丁寧に回すことで評価されたリーダー」だったので、フローを変えられること自体を拒絶されてしまった、という話なんですよ。
そのリーダーさんにしてみれば、今のタスクをきちんと回すだけで自分は十分評価されるし、フローが変わったらその後どう成果を出せばいいか分からない、ということで、一種の抵抗勢力になっていたみたいなんです。
こういう闇が深い話、まれによくある
ダメなマネージャは進捗を尋ねる。
よいマネージャは必要なときに報告を受ける。
ダメなマネージャはマイクロマネージメントをする。
よいマネージャは責任を委譲する。
ダメなマネージャは皆の前で恥をさらさせてモチベーションを下げさせる。
よいマネージャは目標でモチベーションを上げさせる。
ところで、XDSDもそうっぽいけど、アジャイルな開発手法は基本的に、意欲に満ちた優秀なメンバで構成されたチームを前提に組み立てられたものだ。 私の会社を含む、日本の大企業がやっているような、経験(ほぼ)不問、サークルやバイトでの体験談を聞いて新卒一括人柄採用なんてボランティアみたいな選考方法を刷新しない限り、上手く回るようになることはない。 こんないい加減なやり方で集められた烏合の衆で、何千万も何億も稼ぐソフトウェアを作ろうってんだから、上の人たちはさぞかし大変なんだろう。意欲に欠けた部下の尻を叩くためにデイリースタンドアップをやらざるを得ないマネージャを批判するのは、ちょっと気の毒に思える。
よって、PJ管理ツールを全社に導入して、各PJのQCDを可視化し、常時監視できる状態にしたい。
すると、PJメンバーは毎日、PJ管理ツール上で、詳細化されたWBSに進捗率と実績工数を入力するように躾けられる。
一般に、高価な有償パッケージ製品のPJ管理ツールを導入して、社員だけでなく、内製開発にいる準委任契約の協力会社メンバー（BP）にもその運用を強制させる。
それにより、毎週・毎日のPJ報告では、進捗や原価は自動計算できるから、理論上は、毎日、PJ報告を提出させることで、PJのEVM、原価と粗利、営業利益を出力させることはできる。
でも、実際にそんな運用をしたら、メンバーの進捗・工数入力の作業負荷が大きくなり、肝心のPJ作業時間が削られるので、そこまではやらないのが普通。
大多数のPJメンバーは、PJ管理ツールにデータを入力するだけの役割であって、PJ管理ツールやその運用を改善しようというインセンティブは働かない。
一般に、PJ管理ツールではユーザの権限制御が厳しく、一般のPJメンバーには、PJの採算情報はもちろん、メンバーの月額単価のようなマスタ情報にアクセスできないようにしているので、彼らが触るメニュー画面は、制限された機能が少しだけ載せられているだけであり、非常に貧弱な機能に過ぎない。
つまり、PJメンバーから見れば、PJ管理ツールは単なるデータ入力基盤に過ぎず、面倒なシステム以上のものではない。
ゆえに、PJメンバーにとって、PJ管理ツールを使いこなす動機やインセンティブがない。
これは本当にある話だ。
「俺に利益が無いなら余計な仕事を増やすな」の精神を忘れてはならない。
導入はこちらの方が簡単そうな感じか。
興味深いけど、gitから移行してまで使いたいかという別にそんなこともなく。
やりたい事は次の通り。
みたいな感じ。
ぱっと考えると各ノードにファイルをプッシュしてやればよさそうな気もするが、次の理由からそれはよい考えではない。
したがって、各ノードからファイルをプルしてもらう方式がベストであろう。
具体的な流れとしては以下の通り。
このような方式ならノードが幾つ増えても確実に最新のファイルを展開することが可能になる。
定期的に実行したい処理が複数あるのだが、アプリがコンテナで動くことを前提にするとホストシステムのcronを使うのはちょっとなー...という感があり、かといってRundeckはちょっと大袈裟な感じがあるかなといったところで、軽量でコンテナで動きそうなジョブスケジューラを探していたので助かった。
Jobberなんかは求めてたものに近そうな気がする。
適当にドキュメントを読みながら考えてみたが、幾つか問題点がありそうな気がしてきた。
そう考えるとジョブスケジューラのようなミドルウェアを使い定期的な処理を集約するのではなく、プログラム単体でスケジューリングを行う自己完結したプログラムを個別にコンテナ化しておく方が運用は楽な気がしてきた。
大抵の言語には定期実行をスケジューリングするライブラリが存在するのでそれらを利用すればよい。
ただ、こちらの方法にも問題があり、それは定期実行を行う処理が個別のコンテナとして散らばるのでcronで管理していた時より利用状況が見えにくくなること。
cronで管理している場合は、最悪crontabを片っ端から見ていけば実行される処理を特定することができたものが、それぞれの処理が個別のコンテナとして分散すると管理不能になる恐れがある。
とはいえ、まさにそのためにコンテナオーケストレーションツール（Kubernetes）が存在するのだという話でもあるので、コンテナの数が増えるのが目に見えてるなら素直にKubernetes使いましょうということになるのではないだろうか。
今回の想定はローカルマシン or LAN内サーバで定期的に特定の処理を行いたいだけだったので、docker-compose + スケジューリングライブラリの組み合わせが妥当かなという結論に至った。
これの問題点は、ただログインを行うためだけに 6 つのクラスの API を確認しなければならないということです。開発していたのはライブラリのため、開発に関わっていない一般ユーザに上のソースコードを書かせる必要があります。（たとえ、このライブラリの入門者であったとしても。）
なお、実際には上記のような調子で何十個もクラスを書いたため、実装した私本人でも実装を確認しながらでなければ使えないという酷い状態になりました。
過ぎたるは猶及ばざるが如しかな
GNAP の設計の中で、以下3つのポイントが重要だと考えています。
- フロントチャンネルのセンシティブ情報交換の最小化
- JSON により表現された、しっかりと定義されたデータモデル
- トランザクションモデルと多様なインタラクション方式
実際のところ、大半の開発者が同程度に、結局なにか目の前で不味いことが起きていても気付かないだろう。似たような要件で仕様が上がってきたら、多くの開発者が同じようなことをやるだろう。 上から目線で評論家気取りでこれは酷いなどとのたまうばかり、火事場を外から眺めて他人事で自分のことは棚に上げ、 人のふり見て我が振り直しもしない、お前もお前もお前も、漫然とインターネットをしている醜い卑しい下賤の生き物ばかり。なんとかしてくれ。
こういう風に満足してしまった状態は直感的によくないと感じていて、知らないうちに増長して同僚たちに迷惑をかけてないかどうかが不安になってしまう。例えば何か新しい要素技術Xが登場してきて、それはやってみる価値があるかどうかという話になる。私は昔の技術Yに似ているという第一印象を持つが、概要だけだと何が違うのかよく分からない。そのときにすぐ「昔のYと何がちがうの？」みたいなことを悪しざまに言ってしまうと、これはいわゆる老害というやつで、Xに挑戦しようとする若者の足を引っ張ってしまうことになるわけだ。妙な偏見のない状態で実際にやってみれば成功するんじゃないか？わたしが変なことを言って偏見を植え付けてはいないか？となるのである。こういうとき、どういう風にリアクションするのがよいだろうか？
その価値を見極めるために、過去の歴史を知っておくことは副次的に必要だけど、もっと重要なのは現在の技術やソフトウェアで何ができないかを知っておくことだ。現代の人たちがどういう問題を抱えているかを何かのきっかけで知ったときに、それが技術的に解決できるかどうか、解決できるとしてどれくらいの手間がかかるのかを即座に偏見なしに判定できるようになっていると、勢いはなくてもオッサンとしての価値は下がらないんじゃないか。いやいや偏見なしって、そんなことが簡単にできるならそもそも悩んでない・・・と思って今日もゲームに励んでいる。
私の感覚ですが2-3年の開発経験も、10年以上の開発経験もスキル的には似たり寄ったりの場合が多いです
つまり
「経験年数が長いからという理由だけで給与に差をつける意味がない＝一定以上の経験なら同じ給与レンジ」
ということです
ではどういう場合に給与を多く払ってもいいかというと
後輩の指導・育成、マネジメントやマーケティングの知見、チームビルディング、その人固有のハイレベルなスキルなどがある場合です
ハイレベルなスキルとは、アドネットワーク業界が長くその業務に精通しているとか、ゲーム業界に長くいたのでリリースから運用まで一気通貫で面倒が見れるなどです
基本的に成長曲線は初期の頃ほど上昇率が良いです、知らないことばかりなので知識習得の効率が良いからです
だんだんと新しく覚えることが減ってくると成長曲線は緩やかになります
これは、既存の知識で大体の業務をこなせるようになったことを意味します
エンジニアとして一人前の状態です
これは確かにそう思う
多様性は結構なことだが、リソースが分散するとそれだけプロジェクトの持続性が危うくなる。RedHatとしてはCentOS Streamにリソースを集中して欲しいところではなかろうか。
ADOP (Application Domain Others Pettern) は中長期的に運用可能なコードへ誘導するアプリケーションアーキテクチャパターンです。
ADOP は次の特徴があります。
- 最小限のルールである
- 指針が明確である
- 特定の技術スタックに縛られない
- テスタビリティが確保される
これらの特徴は、コードを自然と中長期的に運用可能なコードへ導きます。
最小規模の(クリーン|オニオン|ヘキサゴナル)アーキテクチャという感じか
・フォントサイズベース
・Vertical Rhythm
・Modular Scale
・8の倍数
米Googleの「Workspace」を含む同社の多くのサービスが12月14日の午後9時ごろから約45分間使えなくなっていた障害の原因は、各種サービスにログインするための認証ツールのストレージクォータの問題だったと、Googleが同日、英Guardianなどのメディアに声明文を送った。
Googleの広報担当者によると、このダウンの原因は、Googleとサードパーティのサービスへのログイン方法を管理する認証ツールの障害だったという。認証を処理するサービスのためのストレージが不足すると自動的に割当を増やす（ストレージクォータ）ツールが正常に動作しなかった。
この問題により、GmailやGoogleカレンダーなど、利用するためにログインが必要なサービスが利用できなくなった。また、Googleの認証プラットフォームを利用するサードパーティのサービスでも、ユーザーがログインできなくなっていた。Googleは、日本時間の14日午後9時32分に問題は解決したとしている。
ふーむ
DDLからER図を生成してくれるツール。
とのこと
とりあえずコンテナに入れてしまえばなんでも公開できるのね。
nginx + 静的コンテンツなコンテナを作れば静的サイトの配信も簡単にできそう（GCSを使わないのはnginxでIP制限をしたいから）。
上記のように、デフォルトだと https://petstore.swagger.io/v2/swagger.json がロードされているが、GETパラメータでurlを指定してやると任意のAPI定義を読み込むことが可能。
↓ではYAML版をロードしてみた。
良さそう。
YAML（or JSON）が巨大化するのを避ける為にAPI毎にYAMLを分割しているが、これならAPI毎に個別にSwaggerコンテナを立てる必要は無さそう。
やったね。
利用者からすればそりゃ不満ではあるだろう