/note/tech

再考 - ドメインサービス

認証と認可と課金とコアドメインを分離したシステムは勝てるという話

これは確かに。

Scrapyとscikit-learn、Streamlitで作るかんたん機械学習アプリケーション

ソフトウェアアーキテクチャのためのC4モデル

ふーむ

エンジニアのリモートワーク in BASE

Netflix創業者の新著「No Rules」から学ぶ企業文化の3つの指針

これらの自由がある一方で、もう1つのキーワードである「責任」についても徹底しています。例えば、プロジェクトをローンチする週に休暇を取る、個人的な旅行に会社の経費を流用するなど、明らかにまずい行動をとったことが判明すれば、その社員は即解雇されます。しかも、ただの解雇ではありません。他の社員への教訓となるよう、社内で大々的に通知されるのです。具体的には、解雇理由の細かな説明が全体メールで送信され、その前例から学ぶよう促されます。

Netflixの軍事組織ぽさ、結構好きなんだが自分なら1年保たずに解雇されてそう

コロナ期のSES市場はこういう感じでした。(これ書いた時期は2020年7月中旬)

貴重な現場リポート

spacecloudのVPS4GBプランが2000円

4GBプランが2000円は安いな。

とはいえ、4GB(2GB)ってどういう意味なんだろうかっていうのと、名前を聞かない会社だから何となく不安という。

Twitterとインスタのアカウントがあるのに全く更新が無いのはちょっと怖い。

kind(Kubernetes in Docker)で学習を始めるまで

kindで動かす場合、コントロールプレーンのメモリ使用量は820MB前後、ワーカーノードが72MB程度になるのか(+アプリのリソース)。

試すにしてもメモリ2GBのVPSじゃちょっと苦しいかな(1GBはOSが消費し、残りの1GBをkindとアプリが取り合う)。

4GBならまぁなんとかって感じか。

ローカルマシンで試してみるのがよさそうではある。

勉強しなくなった上司に自分の人生を預けるほどエンジニアは馬鹿では無い。なので...

勉強しなくなった上司に自分の人生を預けるほどエンジニアは馬鹿では無い。なのでマネージャーになったらマネジメントやるから技術勉強しなくていいとか思ってたら本気でやばい。マネージャーだろうがなんだろうがIT業界に身を置いてるのに、技術にキャッチアップする気がないとか死しか無い。

@kyuns

ライフステージの変化で最新技術を追い切れないことがあることは理解できるので、マネージャが不勉強なのは別にそこまで重要ではなく、現役世代を信任して権限委譲してくれればそれでいい。

むしろ、マネージャに求めるのはチームビルディングや調整スキルなどエンジニアの後方支援能力である。マネージャ個人に管理スキル・技術スキル両方に長けた完璧超人であることを求めるのは負担が大き過ぎて不合理である。

では、何故人はマネージャに完璧を求めてしまうのか?

それは自立するスキルも覚悟もなく、マネージャにぶら下がっていたい・守られていたいという卑怯で小賢しい下卑た性根の持ち主であるからに他ならない。

goのenumは文字列でいいのではないかという話

確かに数値でなければいけない理由もない。

マスターデータ管理に対する 共通基盤システム開発というアプローチ

その後むしろみんなhttpsになってそっちで暗号化されたからBASIC認証でも別にいいかんじに...

BASIC認証といえば、20年以上前に、BASIC認証はほとんど平文と同等なのでヤバすぎるし、強める目的のDigest認証というものが出てきたからそれを頑張って実装したりしたが結局普及せず、その後むしろみんなhttpsになってそっちで暗号化されたからBASIC認証でも別にいいかんじになってしまったな

@koizuka

これな

プロダクトが進捗していないと感じた時の戦い方

歴史ある会社・組織で、VUCA時代に対応できるプロダクト作りをするための課題と対応方法とは

超Scrum入門〜未完成フラクタルと15minSprint〜

組織と個人が内発的動機により継続的に成長するための施策

営業日などの規則性と例外を扱うための設計

・具体的な schedule をベタで持って、アプリケーションはその schedule に基づいて動作する

・schedule をつくるための規則は scheduling policy として別に保持する

15分スプリントを2年間やったけど質問ある?

アーカイブを聞いてる

エンジニアに独学を期待するのはもう時代遅れだと思う。

そりゃ若者は手厚くフォローした方がいいと思うけど、中堅・ベテランは独学できないと即死すると思うんだが

エンジニアの評価グレード制の導入について

BASEのチーム開発における設計レビューの取り組み

Goでのサービスロケータパターン

サービスロケータはアンチパターンと言われていますがGoのStructual Subtypingと組み合わせれば実はきれいに実装できるんじゃないかと思っています。

なのでプログラム全体でサービス群を共有するための箱として使うには結構よい手法で見直してよいのではないかと思い本記事を書きました。

Pythonでは動的にモジュールを改変できるからDI要らないのではという事も思ったけど、サービスロケータで一元管理するのも悪くなさそう。

Pythonの場合はDuckTypingで属性名さえあっていればとりあえず実行できるので。

サービスロケータがアンチパターン化するのは静的な言語に特有な話なんだろうか? そこがわからない。

関連:

制御不能な時代のプロジェクトマネジメント

いい資料だ

ダメなプログラムは行き当たりばったり

エンジニアとして仕事をしているとダメなプログラムに遭遇することもしばしばである。

ダメなプログラムによく見られる特徴として「行き当たりばったり」ということが挙げられる。

例えば↓のようなプログラム。

function main($param) {

    // 引数を元にデータ取得
    $dataList = repos->find($param);
    // 何かの判定
    if (...) {
        // 何かの処理
    }
    // 何かの判定
    if (...) {
        // 何かの処理
    }
    // List全体から何かを検索
    foreach ($v as $dataList){
        if (...) {
            // 何かの処理
        }
    }
    // ここで再び何かのデータ取得!
    $dataList2 = repos->find(...);
    :
    :
    // こんな感じで何百行もダラダラ続く
}

処理の先頭でデータ取得をした後、雑多な処理を行った後、再びデータ取得を行っている。このようなコードは「行き当たりばったり」である。

処理に必要なデータは処理の先頭でまとめて取得しておくべきである。

無論、ある程度処理が進まないとデータ取得のキーになる値が決定できない場合はあるし、そのような場合は例外である。

しかし、このようなプログラムは多くの場合、特段の設計はされておらず場当たり的に(行き当たりばったり)で逐次的に書かれたものが多い。

その為、コードがスパゲッティ化し保守が非常に困難(あるいは不可能)という状態になりがちである。

Python データベース マスタ Enum

DBに何かしらのコードが管理されていて、プログラムからもそれを扱いたいというニーズはよくある。

例えば都道府県コード的なもの。

[{code:'01', name:'北海道'},{code:'02', name:'青森'},,,,]

このようなコードをDBで管理している理由は、(1)テーブル間で参照制約を持たせる為、(2)コードが追加/変化する可能性がある為である。

したがって、(1)の理由だけならともかく、(2)の理由もある場合、プログラムコードに静的にコードを定義することはDBとの乖離を生じるリスクがある。

そこで、DBのデータを元にEnumを作りたくなる。

Pythonでは↓みたいな感じでEnumを動的に生成できる。

prefecture = Enum('Prefecture', (('北海道', '01'), ('青森', '02'),,,,))
print(prefecture.北海道)  # '01'

もっともこれではコード上に静的にキーと値のペアを定義できるEnumの良さをスポイルしているのではないかという懸念はあり、それは実際一理あるので、採用する場合は深く検討する必要がある。

RubyとDependency Injectionについてまとめる

RubyはJavaのような言語と比べて動的であり一度生成したインスタンスであっても変更が容易であり依存の変更も容易である。よって静的な言語において必要性があったDIコンテナのような仕組みを導入しても複雑性が増してしまうだけなのではないか、ということらしい。

Pythonも同じだと思う

ふだんの開発でPRを出すときに考えていること

The Top 10 Things Executives Should Know About Software

日本語形態素解析器 MeCab を Python から利用する際の語彙データ(UniDic)が AWS 上で...

エンジニアはサービス/ユーザー目線で考えるのが仕事!な人の方が個人的には怖い

⏩エンジニアは技術のことだけ考えるのが仕事!

な人よりも、

⏩エンジニアはサービス/ユーザー目線で考えるのが仕事!

な人の方が個人的には怖い。

ビジネスコスト感覚がなく、お花畑的にUI/UXを追求するモンスターになって、事業側と摩擦が起きるケースは割と多いかと😭

@flsc_taro

「私の目の黒いうちはこんなUI,登録フロー,課金フローは許さないです!ユーザビリティを第一に!」

みたいな。「自分たちはITを知ってる」という自負や自信があるんでしょうけど、別にエンジニアはUI/UX領域でマウント取れるほどの専門家でもなく、ビジネスサイドの決定の方が大抵の場合、正しい。

@flsc_taro

自分の専門外のことに敬意を払えない者は何をやってもダメ

検査仕様書なしでシステム開発するとどうなるか?

検査仕様書なしでシステムを開発するとどうなるのか?

ある炎上プロジェクトの建て直しを通じて嫌と言うほど思い知らされた。

そのプロジェクトの顧客が一番怒っていたのは「一体どういうテストをしてリリースしてるんだ?」という点だった。

プロジェクトの建て直しはやり慣れているのでまずは検査仕様書をレビューして検査項目の強化だな、とか軽く考えていた。

でもプロマネに検査仕様書を見せてくれと言っても整理できてないから待ってくれ、の一点張り。

まずは社内の人間で見るだけだから整理なんていらないよ、と説得しても頑固に出さない。

なんとそいつは検査仕様書なしでテスト(うちの会社の定義ではそんなもんはテストと言わないけど)して顧客にリリースしてた。

■全く動かないシステムをリリース

顧客は「全く動かない」と怒っていたが僕はいくらそれはないだろ、顧客が話を盛っているんだろうと甘く考えていた。

しかし、プロジェクトの自称テスターに新規に動作環境を作って導入させてみようとしたら見事に出来なかった。。。

なんとその自称テスターはいつも試行錯誤しながらテスト環境を作り、試行錯誤しながら何とか動けばテストOKとしていたと言う。

これでは顧客が動かないと怒り狂うのは当然だった。

■派遣は検査仕様書を作らなくていい!?

もちろん検査仕様書があればさすがにここまでバカな事態にはならない。

検査仕様書は顧客へ納品する契約になっているし、社内規定でも検査仕様書なしなんて通らない。

プロマネを問い詰めると呆れたことに派遣が検査仕様書を作るのはおかしいなんて言い出した。

うちの会社では通常、検査仕様書は派遣テスターが作っていて派遣テスターの契約内容も「検査仕様書の作成」となっている。

念のために炎上プロジェクトの派遣契約書を確認してみたが内容は同じだった。

派遣テスターの派遣元会社にも膨大な費用が支払われていた。

一体、派遣テスターに契約通りの仕事をさせずに何をやらせていたのか?

なんと「ある一定時間適当に(検査仕様書なしで)システムを触る」ことをテストだと言い張った。

■マンガのような自称パフォーマンステスト

顧客は「そちらのパフォーマンステストの成績だけは満足しているがうちでは動作していない」とも言っていた。

とてつもなく悪い予感がして聞き取りを進めると時間はストップウォッチで計測したと言う。

普通ならテストコードを書く派遣テスターが計測ポイントを埋め込むのになぜストップウォッチ?

この段階でテストコードを書ける派遣テスターがプロジェクトに1人もいないことがわかった。

全社的にテストの自動化が進められているのになぜ!?

さらに実装したというプログラマーに確認すると、実装が難しいので後回しにしていると言う。

テスターに頼まれてストップウォッチで計測できるように処理を数万回か繰り返すコードだけ入れたと。

つまりほとんど空の処理を数万回ブン回すだけの意味のないコードの実行時間がパフォーマンステストの成績として顧客に提出されていた。

顧客のところで動かないのは当然だ、実装出来てないんだから。。。

このことを僕の上司に報告すると「そんなマンガのようなことがうちの会社で現実にあるのか、、、」と頭を抱えていた。

会社の信用に直結するのと他にも多くの仕事を出す大口顧客のため上司から役員へ報告することになった。

■検査仕様書なしに意を唱えるプログラマーに頑固者のレッテル貼り

パフォーマンスが要求される難しい処理の実装ができてないのに、スケジュール上では実装の進捗がほぼ100%になっている。

プロマネを問い詰めると他にも似たような箇所がいくつかあるらしい。

じゃあ、その難しい部分も含めて一体いつ実装が終わるのかわかるようにスケジュールを引き直してくれ、と言ったが彼には出来なかった。

実装できるプログラマがいないからだという。

たしかに開発現場はプログラム言語の入門書を読みながら仕事しているプログラマーが多かった。

不審に思って開発体制の資料や過去のプログラマーの契約書を確認するとプロジェクト初期には僕も一緒に仕事をしたことがある超優秀なプログラマーが2人いた。

しかし、2人ともプロジェクト途中で契約解除となっている。

契約解除の経緯についてプロマネを問い詰めると「仕事の段取りが悪いから契約更新しなかった」と言う。

僕は2人をよく知っていたのですぐに嘘だとわかった。

プロジェクトメンバーに話を聞くと、2人は「今のテストはまずいですよ」とプロマネに提言したらしい。

でもプロマネは頑固に検査仕様書なしでのテストを強行し、再度2人が提言すると「彼らは頑固者だから仕事ができない」などレッテル貼りするようになったという。

そして2人とも契約解除し、入門書を読みながら仕事するレベルのプログラマーだけが残って実装完了のスケジュールすらひけなくなったというわけだ。

■プロマネは涙を流しながら机を叩き部屋を出ていった

社内での対策会議でプロマネはなぜ検査仕様書を作らないのか当然追求された。

僕に言ったのと同様に「派遣が検査仕様書を作るのはおかしい・・・」と言おうものなら、役員が

「だったら誰が作るんだよ!? 派遣が作らないなら社員が作るのか!? 社員に作る時間がないから派遣が作るんだろうが!!」

「検査仕様書を作れないテスターなんてうちにはまったく要らない人材だよ、そんな要らない人材にいくら支払ったかわかってんのか!?」

と大声で反論する。

プロマネが

「派遣が検査仕様書を作らない会社もありますが・・・」

と言い訳しても

「他所の会社なんて知らねーよ!!うちの会社はうちのルールでやるのが当然だろうが!!」

と火に油を注いだだけだった。

「検査仕様書なしに異論を唱えたプログラマーを契約解除した理由をここで説明してみろ!!」

そんな追求をされているうちにプロマネをまったく明後日の方向の話を始めた。

「これはパワハラですよ。声が大きいからパワハラです。」

眼鏡の後ろから涙をボロボロ流しながら机を叩いた。

「これはパ!、(机を叩く)、ワ!、(机を叩く)、ハ!、(机を叩く)、ラ!、(机を叩く)」

そして猛ダッシュで会議室を出ていったが、引き止める者は誰もいなかった。

僕は呆れるのを通り越してこんな人間がうちの会社のプロマネやって会社の信用を失墜させたのか、と思うと情けなくなった。

後日、プロマネは本社に役員からパワハラを受けたと訴えたが相手にされず、懲戒免職となった。

プロマネとしての力量不足でプロジェクトを失敗させたなら懲戒免職なんてありえないが、彼の場合は社内規定にも顧客との契約にも故意に背き頑固に検査仕様書を否定した結果、失敗させたのだから仕方がない。

普通ならプロジェクトの建て直しでは(体調不良などで)プロマネがいないのは困るもんだが彼の場合は特に困ることはなかった。

■検査仕様書を作らなくていいと主張されるなら裁判所を通してください

プロジェクトメンバーは大幅に入れ替えるしかなった。

特に役員の言う通り、検査仕様書を作れないテスターなんてうちの会社では全く必要ない。

テスターを派遣していた会社への説明はあっという間に終わった。

同席した役員が「検査仕様書を作れないなら支払いはできません。契約書の作業内容に検査仕様書作成とあるのにやらなくていいと主張されるなら裁判所を通してください。」と言ったからだ。

派遣会社も彼のように「検査仕様書を作らせない派遣先もあるのですが・・・」と切り出したが「だったらそういう会社とだけ取引すればいいでしょう。うちは検査仕様書すら作れない会社とおつきあいする気はまったくありません。」と返されて終わった。

■なぜ彼は頑固に検査仕様書を否定したのか?

なぜ彼はプロジェクトをこれだけ大炎上させながら頑固に検査仕様書を否定し続けたのか?

いくら彼と話をしてもまったく埒があかずわからなかった。

ただ、プロジェクトメンバーから彼がある女性派遣テスターと男女の関係にあったと聞いた。

彼女はテスターといっても検査仕様書が作れないのでプロジェクト内での彼女の存在を正当化するために彼がおかしなことを言い始めたんじゃないかと噂されていた。

それが本当なら呆れるを通り越して同じ会社の人間して情けないし、おぞましいとしか言いようがない。

もう彼と話すことは永遠にないだろうから真相はわからないが。

スキルやリソースがあっても、それを司る人間がバグるとどうしようもなくなってしまうのがシステム開発(無常観)

命題論理や述語論理ももちろん有用なのだが、徹底的に命題分解・述語分解するアプローチが実用的かどうか?

計算ルールを、長大なtrue/falseのマトリクスで表現した資料を見ている。デシジョンテーブル(決定表)の応用か。

計算構造のモデル化のアプローチとして、すべて決定表に展開するのは違和感があるなあ。不必要な複雑さを持ち込んでいる気がする。

計算式とか判断式を部品化するアプローチでいきたい

@masuda220

実際、その決定表の資料の意図を、計算・判断をカプセル化した値オブジェクトを使って表現していくと、決定表からは見えてこなかった構造がわかりやすく見えてきているように思う。

命題論理や述語論理ももちろん有用なのだが、徹底的に命題分解・述語分解するアプローチが実用的かどうか?

@masuda220

僕も「こんな使えねー奴が来るとは思わなかった」って言われた現場もあれば、「いろいろやってくれて...

僕も「こんな使えねー奴が来るとは思わなかった」って言われた現場もあれば、「いろいろやってくれて助かってる」って言われた現場もある。合わない職場はさっさと辞めて次を探そう。合う現場はきっとある

@joeokubo

なんでみんなリモートを「生産性」だけで評価するの

なんでみんなリモートを「生産性」だけで評価するの。「文化醸成」とか「関係構築」とか「成長」とか中長期で影響出るものいっぱいあるだろうに。

@dkatsura

基本軸は成果で、「文化」や「人間関係」「成長」なんていうのはその副産物でしかないから。

独り立ちしていない内はそういうのが重要な気はしてたけど、結局それは守られていたいという願望を言い換えたものでしかなかった。

におうコードの問題集 〜ソフトウェア設計に立ち向かう編〜

面白そうだけど、リファクタリング(書籍)以上の情報は無さそうかな?

トランプ政権、就労ビザの発給要件を厳格化

Donald Trump米政権は、高い技能を有する外国人労働者用のH-1Bビザに新たな要件を課す。労働省と国土安全保障省が米国時間10月6日に発表した規則は、米国の雇用主が米国人労働者を「低賃金の外国人労働者」に置き換えることを制限するものだ。

労働省の新しい規則では、外国人労働者の賃金を「米国で同じように雇用されている労働者に支払われている賃金と同等にすること」が雇用主に求められる。国土安全保障省の規則では、申請した「専門職」の学位を取得していることが外国人労働者に求められる。労働省の規則は8日に発効し、国土安全保障省の規則は2カ月以内に発効する予定だと、CBS Newsは報じている。

アメリカ以外の国に高技能移民が流れるか、あるいは自国で活躍するようになったりするのかしらね

ScalaとGolangでDDDを実装比較してみた

CTOに一年間パワハラをし続けてきたベテランエンジニアが会社から退職勧告を受けたらしい

CTOに一年間パワハラをし続けてきたベテランエンジニアが会社から退職勧告を受けたらしい。

ベテランさんは会社から引継ぎ資料作成を命じられたけど、鬱になったCTOとの会話や連絡が一切禁じられているので、何を引き継げば良いのか分からない問題が発生。

弊社、今が最高にエキサイティングで面白い

@nepinepimate3

傍から見てる分には面白い

『The DevOps 逆転だ!』著者に聞く、「DevOps」や自動化よりも大切なこと

「Python 3.9.0」がリリース、Windows 7へのインストールは禁止に

「Python 3.9.0」は、Windows版においてはじめてデフォルトで64ビット版のインストーラを用意しており、Windows 7へのインストールを積極的に禁止し、サポート外のWindowsとは互換性がない。

禁止しちゃうんだ

典型的な値オブジェクトは、一つか二つのプリミティブ型のフィールド変数を持ち、値の種類を...

典型的な値オブジェクトは、一つか二つのプリミティブ型のフィールド変数を持ち、値の種類を表すわかりやすいクラス名を持ち、getter/setterを持たず、メソッドは短く、メソッド内のネストは一段まで、メソッド内にelseはなく、1行にドットはあってもひとつで、クラスは小さい。

@masuda220

オブジェクト指向エクササイズなんだけどね。

値オブジェクト設計の練習帳だと思えばよい。

カプセル化の練習帳でもある。

値オブジェクトのメソッドの集合は

足し算・引き算

掛け算

割り算

同値判定

大小判定

最小値・最大値

標準の文字列表現の定義

のサブセットになる。

@masuda220

Java生みの親、ゴスリン氏が語るJavaとAndroid

「その中でも大きかったことの1つは、(家電企業が)顧客との関係を神聖なものだと考えていたということだ。彼らは決して安全を犠牲にすることはなかった。私がコンピューター業界で気になっていたことの1つは、パフォーマンスを得るためには信頼性を犠牲してもよいという風潮だった」とGosling氏は述べた。

「トースターでトーストを焼こうとしたときに、顧客が死ぬようなことは起こってはならないし、炎上して火事になるようなこともあってはならない」

「1990年代の初めには、セキュリティ上の脆弱性が生まれる一番の原因はポインターであることが分かっていた。例えば50%、60%、70%がバグで、それらの大部分がバッファオーバーフローなどの問題だった。それが起きないようにする必要があった。『こんな状況を続けるわけにはいかない』というのが私が最初に思っていたことだった」

「Chromeは要するに巨大なC++のコードだが、そのセキュリティ上の脆弱性の60~70%が、ばかげたポインターの問題だった。30年経っても何も変わっていないのかと思わざるを得なかった」とGosling氏は述べた。

同氏は、「(GoogleがAndroidにJavaを使用したことについては)満足している」と話す一方で、「Javaは長年にわたって携帯電話で使われており、非常にうまくいっていた。彼らのやり方について言えば、いろんな意味で、彼らはあらゆる約束事を破った」とも語った。

「その責任者だったAndy Rubinという人物は、多くの面で一線を越えた。それらのことが膨れ上がって、巨大な訴訟に発展してしまった。(グーグルは)そんなことをする必要はなかったし、実際、一線を越えなければずっと安上がりだったはずだ」

さらにGosling氏は「私はそのうちに、あの問題がなくても、いずれ何かが爆発しただろうと思うようになった。(Rubin氏は)爆弾メーカーのようなものだと考えるようになった」とも述べている。

名指しで批判は珍しいな

Essential Phoneの人か。

つらい時にアゲる机

今さら聞けない人のためのK8s超入門

TheAlgorithms/Python

様々なアルゴリズムのPython実装

値オブジェクトは型とデータ抽象というオブジェクト指向プログラミングの基本のわかりやすい具体例

値オブジェクトは、値の種類をクラスで表現したもの。

例えば、金額、数量、期限、期間、...。

値の種類の分類を型と呼ぶ。

つまり値オブジェクトは型の具体例。

型は、操作の集合で定義する。操作の集合で型を定義することをデータ抽象と呼ぶ。

値オブジェクトはデータ抽象の具体例。

@masuda220

値オブジェクトは型とデータ抽象というオブジェクト指向プログラミングの基本のわかりやすい具体例。

アプリケーションで関心のある値の種類を分類して、クラスを使ってアプリケーション固有の型を定義するのがオブジェクト指向プログラミングによるアプリケーション開発の中核の活動。

@masuda220

開発者の扱うコードの量や複雑さはここ10年で100倍以上に増えている

ユニバーサルコード検索を専門とするSourcegraphが、アメリカ・カナダで活躍する500人以上のソフトウェア開発者を対象に、コードの複雑さと管理の問題についての調査を行いました。その結果、開発者の扱うコードの量は10年前と比較して膨大なものとなっており、半数以上が100倍以上に増えていることが判明しています。

Sourcegraphは報告書の中で、「現代の大規模で複雑なコードベースでは、コードの量と複雑さが大幅に増加しているため、開発者がコードを発見し、理解し、修正することが常に問題となっています」と指摘し、量と複雑さが膨大なレベルになったものを「ビッグコード」と定義。また、ソフトウェア開発者の92%が「自分の所属する組織がビッグコードの悪影響を受けている」と答えたことを報告しています。

フルスタックフレームワークの進化が凄まじいものがあるから致し方ない面もある。

シリコンバレーの「何が」凄いのか

IT業界三大勘違い

IT業界三大勘違い

・要件定義はちゃんとやればブレ・漏れなく実施できる

・工数見積は精緻にやればズレなく見積もれる

・ちゃんと試験すればバグは0に出来る

@HAL1986____

人間の努力や認知能力に過大な期待をしてしまってる人は多いな。

ではどうするか? というとスクラム開発をやっていきましょうという話になる。

仕様書作成のポイント

すばらしい

GoogleCalendarAPIを利用して、PHPでGoogleカレンダーの情報を取得してみよう!(予定編)

ふむふむ

ビジネスロジックは入出力から独立してテスト。ここが保証された状態で、記録と参照をテストする。

テストの考え方として、

・ビジネスロジックテスト

・記録テスト

・参照テスト

・通知テスト

・検知テスト

のように対象を分けるのがよいと思う。

ビジネスロジックは入出力から独立してテスト。ここが保証された状態で、記録と参照をテストする。

そのうえで、通知・検知のテストを行う。

@masuda220

Sidekiq to Kafka ストリームベースのmicro services

オフィス縮退に関する一考察

正直、二度と出勤なんかしたくねぇわ感の方が強い。

コロナが収束して出勤がMUSTになったらフリーランスになろうと半分以上本気で考えるレベル。

理屈で考える、データベースのチューニング

Oracle限定という話ではない

レガシー撲滅だけをスローガンにした開発が当時の流行に乗っただけの、愚直な旧システムよりたちの悪い

差別を撲滅しようとしたリベラルがより知恵の浅い新たな差別者になる様子、レガシー撲滅だけをスローガンにした開発が当時の流行に乗っただけの、愚直な旧システムよりたちの悪いレガシーになるのと似てる

@tanakahisateru

それ以上いけない

開発チームの責務を「エンジニアリング観点でのサービス継続リスクをコントロールしながら...

31年勤めた富士通グループから退職した

富士通の人だったんだ

基礎も教われず、気づかず、IT系が特段好きでもなさそうで素養がなさそうな子を特訓すればいいんだろうか

基礎も教われず、気づかず、IT系が特段好きでもなさそうで素養がなさそうな子を特訓すればいいんだろうか。。。

悩ましい。

@gogotea3

職業とのミスマッチ起こしてる人は出来るだけ速やかに別の道を選んでもらった方がいいと思う。

本人は人生を無駄に消費し、企業は採用費用と人件費が無駄になり、上司やチームはサポートコストが無駄になるので誰も得していない。

Pythonで始める自然言語処理の基礎の基礎

「ソフトウェア病理学」SIG資料

↑のスライドで紹介されている「ソフトウェア病理学」、既に絶版の上にそもそものお値段が一万円超えというハードコアな逸品。

なお、Amazonではプレミアが付いてるのか29,800円。

こういう高額書籍は大きめの図書館にはありそうだから、図書館で読んだ方がいいかもしれない。

エリック・レイモンド: Microsoftは、WindowsをエミュレートするLinuxカーネルに切り替えているのか?

組織にテストを書く文化を根付かせる戦略と戦術(2020秋版)

定期的にアップデートされてるな

Java 15の新機能 Recordsを中心に

Java 15、中々興味深いことになっている

Python Nikola theme assets

Python製のスタティックサイトジェネレータであるところの Nikola について。

独自テーマを作る時にparentをbaseかbase-jinjaにすることを勧めているのだが。

If your theme uses Jinja as a template engine, inherit base-jinja or bootstrap3-jinja

.themeの設定ファイルはこんな感じ。

# mytheme.theme
[Theme]
engine = jinja
parent = base-jinja
license = GPL

このように設定するとbase由来のCSSやJSが一緒にビルドされてしまうのがちょっと気になる(実用上は別に問題ない)。

parentをNoneに設定してもassetsにbase由来のCSSやJSが生成されてしまう。

完全にまっさらな状態のthemeは作れないということだろうか?

アジャイル開発が世に広まって以降、設計スキルの無い(または弱い)エンジニアが設計から実装まで...

アジャイル開発が世に広まって以降、設計スキルの無い(または弱い)エンジニアが設計から実装まで行なうことが増え、かえって機敏性の低いソフトウェアが出来上がってしまってる状況があるというような話を先日聴いて、なるほどなーと思った。

設計スキルを身につけずにアジャイルとはなにごとか

@masuda220

@HayatoKamono

新しい言語やフレームワークの勉強はしても、そのベースとなる設計スキルについては勉強していない人は多い。

そもそもどうやって勉強すればいいんだとなってる人も多いのだろうか。

増田師の本を読み、そこに書かれている参考文献を片っ端から読めばいいだけなのであるが。

k3sのハードウェア性能要件

Hardware

Hardware requirements scale based on the size of your deployments. Minimum recommendations are outlined here.

RAM: 512MB Minimum (we recommend at least 1GB)

CPU: 1 Minimum

あれ、RAM1GBでいいのか。これは安めのVPSでも全然動かせそう。

Rancher2.4は100万のKubernetesクラスタをサポートする

InfoQ:「エッジ」とは何ですか?

Sheng Liang氏: エッジについて話すとき、人々は通常セットトップボックス、ATMマシン、IoTゲートウェイなどの小規模でスタンドアロンのコンピューティングリソースを意味します。ただし、最も広い意味では、エッジはクラウドにないコンピューティングリソースと考えることができます。したがって、ブランチオフィスはエッジロケーションの一部を構成するだけでなく、開発者のラップトップもデバイスエッジの一部であり、レガシーオンプレミスシステムはデータセンタエッジと見なすことができます

InfoQ: K3sとK8sの違いは何ですか?

Liang氏: K3sはK8sに特殊な構成とコンポーネントを追加して、エッジデバイスに簡単にデプロイおよび管理できるようにします。たとえば、K3sは、標準のetcd Key-Valueストア以外にも多くの構成データベースオプションを導入して、リソースに制約のある環境でKubernetesを操作しやすくしています。K8sは多くの場合専任のDevOpsエンジニアまたはSREによって運用されますが、K3sは単一のバイナリとしてパッケージ化されており、アプリケーションとともにデプロイしたり、サーバに組み込んだりできます。

メモリ4GB程度のVPSでサクッとk3sが動くようになれば色々面白そうなんだが

質問したはいいが回答が全く得られない。それよりも質問の仕方が悪いと非難される。

本当に辛い。

辛い。

エンジニアになれたはいいがわからないことが多すぎる。

「技術の調べ方について」自分のできうる限りの人に質問したはいいが回答が全く得られない。

それよりも質問の仕方が悪いと非難される。

どうすればいいのかわからない。

@yuuki_wifi

質問の仕方と言えばまずはこれ↓よな。

とはいえ、この短い文章からさえ滲み出る他責性の高さを見ると、関わり合いになるのはちょっと厳しいと判断されてるんじゃないだろうか。

Clean Architectureにおいてバリデーションはどこでやるべきか

結論から言うと

バリデーションはどのレイヤの責務なのか?という問い自体が間違いであり、レイヤごとにそのレイヤの責務となるバリデーションを行うべき、というのが今のところの結論。

ビジネスルールに関するバリデーションはドメイン層で、アプリケーションやシステム的な制約に由来するバリデーションはアプリケーション層で、というお話。

SciPy Japan 2020 - Apache Arrow 1.0 - A cross-language development platform for in-memory data

SciPy Japan 2020は2020年10月30日で約1ヶ月後なのですが、事前録画した動画を使ったオンラインイベントで、私の話は録画済みなのでここで先に公開します。SciPy Japan 2020に参加する人とこのブログを読む人は違う層だろうからです。Apache Arrowをよく知らない人がどうやってApache Arrowを使えばよいかがわかることを狙った内容にしました。

型と型検査で済むことをテストコードで書くのはムダ

型と型検査で済むことをテストコードで書くのはムダ

型で表現していることをコメントやドキュメントに書くのはノイズ

型の定義内容を確認するためにいちいち検索するのは面倒

@masuda220

型で表現している

型で表現できている

@masuda220

型が適切に定義されていればビジネスロジックのテストに集中できるという話

Apigee Edge プラットフォームにおけるアンチパターン一覧

・ポリシーに関するアンチパターン

・パフォーマンスに関するアンチパターン

・一般的なアンチパターン

・バックエンドに関するアンチパターン

・Edge for Private Cloud に関するアンチパターン

バリデーションには3種類のバリデーションがある 〜 セキュアなアプリケーションの構造 〜

全角英数字を半角英数字に置換するシェルスクリプト

最近何度か使う機会があったのでメモ。英数字だけでなく四則演算記号と全角空白、行末尾の空白も除去するようにした。

cat $SRC | \
sed -e 'y/abcdefghijklmnopqrstuvwxyz/abcdefghijklmnopqrstuvwxyz/' | \
sed -e 'y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/ABCDEFGHIJKLMNOPQRSTUVWXYZ/' | \
sed -e 'y/0123456789/0123456789/' | \
sed -e 's/+/+/g' | \
sed -e 's/ー/-/g' | \
sed -e 's/*/*/g' | \
sed -e 's///\//g' | \
sed -e 's/:/:/g' | \
sed -e 's/ / /g' | \
sed -e 's/ \+$//g' | \
cat >$DIST

何故人は全角英数字を使ってしまうのか。

止められないサービスのクラウド移行

誠実 × データ × 整備人 誠実なデータを扱う誠実な企業・整備人であるための話

tag:

最近使ったETL、ELTサービス(ツール)でデータ収集タスクについて考える

tag:

広告・マーケROIを可視化するためにETL/データ整備した話

tag:

第6回 データアーキテクト(データ整備人)を”前向きに”考える会

聞いてた。今回はあまり関心を引かれる話は無かったかな。

不安とストレスから解放される見積りとスケジュール方法

スケジュールバッファは、本当は10ヶ月後にリリースしたいが、完成予定を9ヶ月後に設定し、残り一ヶ月をバッファとして用意するようなものです。

フィーチャバッファは、各機能が優先順位でソートされているとして、本来はほしい機能と必要最低限の機能を分け、必要最低限の機能があれば、リリースできるとするものです。

フィーチャバッファは、「市場が最大の不確実性」という前提に立ったときに効力を発揮します。リリースするまで反応がわからないのだから、最小限の機能をリリースして不確実性を減らしていこうという考え方に基づいています。

スケジュールバッファは、「いつリリースできるのかが最大の不確実性」という前提に立ったときに効力を発揮します。リリース日が遅れた場合の機会損失や実契約上の損失などが重要で、スケジュールの不確実性を減らしていこうという考え方に基づいています。

メソッドの名前・引数の型・戻す値の型の情報をひとまとめてにして、なんて呼ぶのがいいのかな?

メソッドの名前・引数の型・戻す値の型の情報をひとまとめてにして、なんて呼ぶのがいいのかな?

シグネチャだと、戻す値の型を含まないし。

Javaの言語仕様としては、Method Header か。「メソッドの見出し」。

あまりしっくりこないが...

@masuda220

(メソッドの)見出し一覧がクラスの要約(Abstract)、というのはよい感じがする。

@masuda220

Interfaceでよいのでは??

メソッドに焦点を当てるとするなら、method interface definition(メソッドインターフェイス定義)みたいな感じでもよさそう。

マイクロサービス設計原則: SOLIDではなくIDEALS

SOLIDの原則の一部はマイクロサービスに適用されますが、オブジェクト指向は、一般に分散システムの要素、特にマイクロサービスとは根本的に異なる要素 (クラス、インターフェイス、階層など) を扱う設計パラダイムです。

したがって、マイクロサービス設計のために、次の一連の核となる原則を提案します:

  • Interface segregation: インターフェイス分離
  • Deployability (is on you): デプロイ容易性
  • Event-driven: イベント駆動
  • Availability over consistency: 整合性よりも可用性
  • Loose coupling: 疎結合
  • Single responsibility: 単一責任

原則は、マイクロサービスベースのソリューションの設計決定のすべての範囲を網羅しているわけではありませんが、最新のサービスベースのシステムを作成するための主要な懸念事項と成功要因に触れています。マイクロサービスに適用されるこれらの原則 (待望のマイクロサービスのIDEALS) の説明について読んでください。

GKEにIstioをインストールした時は15017ポートを解放しておくこと

An automatically created firewall rule does not open port 15017. This is needed by the Pilot discovery validation webhook.

GKE に Istio をインストールした際は15017ポートを解放する必要があるらしい。

こちらはどうなんだろうか。これらのポートは内部的な利用だから外部公開はしない方がよさそうな気はする。

個人サイトについて

なぜ個人でウェブサイトを運用しているのかについて、整理しておきたい。

要約すると、以下の理由でやっている。

  • ウェブの技術を学べて費用対効果が高いから
  • 表示されるコンテンツを制御したいから
  • フィードバックの場と適切な距離を置きたいから
  • かっこいいから

自分も概ねこんな感じ+特定のサービスの終了に振り回されたくないというのがある。

RSSリーダーみたいに何度もサービス終了を経験すると自分でセルフホスティングした方がマシでは? となったし、実際その通りだった。

JavaScript での時刻操作に Moment.js ではなく Day.js を利用し続けている理由

Moment.jsさん、開発終わったって言うし、こっちに乗り換えとくか。

DuckDB - SQLite競合の組込みRDBMS

SQLiteに似た組込み型のRDBMSプロダクト。オープンソースでオランダの公務員が開発しているとのこと。

SQLiteよりデータ型が豊富なところやそれらデータ型向けの関数が豊富なところは優位性があると思う。

多くのデータベース管理システム(DBMS)が存在します。しかし、すべてのデータベースシステムに当てはまるワンサイズのものはありません。すべてのシステムは、特定のユースケースにうまく適応するために、異なるトレードオフを取っています。DuckDBも例外ではありません。ここでは、DuckDBがどのような目標を持っているのか、その理由は何なのか、そして技術的な手段でどのように目標を達成しようとしているのかを説明しようとしています。そもそもDuckDBは、構造化クエリ言語(SQL)をサポートするリレーショナル(テーブル指向)DBMSです。

高速な分析クエリ

DuckDBは、オンライン分析処理(OLAP)としても知られる分析クエリのワークロードをサポートするように設計されています。これらのワークロードは、テーブル全体の集計や複数の大きなテーブル間の結合など、保存されたデータセットの大部分を処理する複雑で比較的長時間のクエリが特徴です。データへの変更もまた、数行の追加や、テーブルの大部分が同時に変更または追加されるなど、かなり大規模なものになることが予想されます。

このような作業負荷を効率的にサポートするためには、個々の値ごとに消費されるCPUサイクルの量を減らすことが重要です。これを実現するためのデータ管理の最新技術は、ベクトル化されたクエリ実行エンジンまたはジャストインタイムのクエリ実行エンジンです。DuckDBには列ベクトル化されたクエリ実行エンジンが搭載されており、クエリは解釈されますが、1つの値(「ベクトル」)からの大量の値が1回の操作で処理されます。これにより、PostgreSQL、MySQL、SQLiteのように各行を順次処理する従来のシステムに見られるオーバーヘッドが大幅に削減されます。ベクトル化されたクエリ実行は、OLAPクエリのパフォーマンスをはるかに向上させます。

簡単操作

SQLite は世界で最も広く導入されている DBMS です。インストールが簡単で、プロセス内に組み込まれた操作が成功の鍵を握っています。DuckDBは、これらのシンプルさと組み込み操作の考え方を採用しています。

DuckDBには、コンパイル時もランタイム時も外部からの依存関係がありません。リリースでは、DuckDBのソース・ツリー全体が、ヘッダと実装ファイルの2つのファイルにコンパイルされ、いわゆる「アマルガム」と呼ばれています。これにより、デプロイや他のビルドプロセスへの統合が大幅に簡素化されます。ビルドに必要なのは、DuckDBのビルドに必要なすべてのものは、動作するC++11コンパイラです。

DuckDBの場合、インストール、更新、保守のためのDBMSサーバ・ソフトウェアは必要ありません。DuckDBは独立したプロセスとして実行されるのではなく、完全にホスト・プロセスに組み込まれています。DuckDBがターゲットとする分析的なユースケースでは、データベースとの間のデータ転送が高速であるという利点があります。いくつかのケースでは、DuckDBはコピーせずに外部データを処理することができます。例えば、DuckDBのPythonパッケージは、データをインポートしたりコピーしたりすることなく、Pandasデータ上で直接クエリを実行することができます。

豊富な機能

DuckDBは本格的なデータ管理機能を提供します。大規模な関数ライブラリやウィンドウ関数など、SQLによる複雑なクエリを幅広くサポートしています。DuckDBは、バルク最適化されたカスタムのマルチバージョン同時実行制御(MVCC)により、トランザクション保証(ACIDプロパティ)を提供します。データは、永続的な単一ファイル・データベースに格納することができます。DuckDBはセカンダリ・インデックスをサポートしており、単一のテーブル・エントリを検索しようとするクエリを高速化します。

DuckDBはPythonとRに深く統合されており、効率的なインタラクティブなデータ分析を実現します。DuckDBはJava、C、C++などのAPIを提供しています。

徹底したテスト

DuckDBは研究グループによって作成されたものですが、研究用のプロトタイプであることを意図したものではありません。DuckDBは安定した成熟したデータベースシステムであることを意図しています。

この安定性を促進するために、DuckDBは継続的インテグレーションを使用して集中的にテストされています。DuckDBのテストスイートには現在数百万のクエリが含まれており、SQLite、PostgreSQL、MonetDBのテストスイートから適応されたクエリも含まれています。テストは、さまざまなプラットフォームやコンパイラで繰り返し行われます。すべてのプルリクエストは、完全なテスト設定と照らし合わせてチェックされ、合格した場合にのみマージされます。

このテスト・スイートに加えて、高負荷時にDuckDBにストレスを与える様々なテストを実行しています。TPC-HおよびTPC-DSベンチマークを実行し、DuckDBを多数のクライアントが並列に使用する様々なテストを実行しています。

フリー&オープンソースライセンス

DuckDBの主な開発者はオランダの公務員です。私たちの給料は税金から支払われています。私たちは、私たちの仕事の成果をオランダや他の国の誰でも自由に利用できるようにすることが、社会に対する私たちの責任であり義務であると考えています。そのため、DuckDBは非常に寛容なMITライセンスのもとでリリースされています。DuckDBはオープンソースであり、ソースコード全体はGitHubで自由に利用できます。私たちは、私たちの行動規範を守ることを条件に、誰でも貢献を募っています。

いまさら聞けない、テスト対象機種の選定方法 (2020年版)

テスト活動の納得感を持ってテストケースを激減させた話 #D3QA

あれから 10 年。まさーるさん(石井勝さん)を偲ぶ。

今日は福知山線の脱線事故から 10 年目の 4 月 25 日。つまり、まさーるさんこと石井勝さんが亡くなられてからも 10 年になる。

ふと思い出した。

上記の記事は2015/04/25に書かれた。

人間とはいつ死ぬかわからないものである。

プロジェクト憲章のメモ

プロジェクトのキックオフMTGでこの辺を共通認識にしておく感じの。

■目的
・プロジェクトの目的、必要性
■目標
・プロジェクトの完了条件、成果物
■スケジュール
・納期、マイルストーン
■前提条件/制約条件
・ビジネス的な面からの要求、法的規制、社内事情など
■予算
・いくら使えるのか、誰に確認するのか
■予測されるリスク
・プロジェクトに影響を及ぼし得る外部要素
■体制
・PM、メンバー
・責任範囲

PHP を好む理由

PHP を好む理由:

- ステートレスで運用が楽

- ゆるさと堅さの選択肢が広い

- composer の秀逸さ

- コミュニティ内の価値観が多様

まちがい:

- 人材確保が簡単で単価も安い

(↑安易に安い人に任せるのまじどうなっても知らんで。多様性があるってことはピンキリの振れ幅がすごいあるってことやで)

@tanakahisateru

Python を好む理由

Python を好む理由:

- おぼえることが少ない

- 基礎をおさえるのに過不足がない

- 高度なことでも組み合わせでてきて楽しい

- 用途が広いので興味が広がる

- 泥沼化した案件で使ってた思い出から悪口を言い出す人が少ない

まちがい:

- これだけで機械学習できる

- 平均年収が高い

@tanakahisateru

エンジニアから経営者にならねばならない、みたいな論調が大嫌いだ。

エンジニアから経営者にならねばならない、みたいな論調が大嫌いだ。

@irof

結局PG/SE/PMルートと同じだしなぁ。

@irof

それがあるのは否定しないし、それを選んだ人の努力や経験は素晴らしいと思う。それを唯一絶対の正解かのように語るの、ほんと、なんていうか。

@irof

全ての労働者が経営者視点を持つべき、それが唯一絶対の正解だ、みたいな論調は確かに反吐が出る。

一方で、「見識を広げていった結果、そのようになった」というのは尊ばれることだ。

要するにエスカレータ式の学校とかサラリーマンの出世街道みたいなノリで雑にまとめられるのが気に喰わないわけで、そんな脳死した連中と同じ扱いを受けることにプライドやら何やらが反発しているわけだ。

そして、それがエンジニアのあるべき資質でもある。

リモート時代の雑談/相談、Peer 1on1の始め方

"プロダクトオーナ”は最悪の発想だ

"技術的な判断は、チームが協同的に下すように求められています。プロダクトの判断も同じでよいのではないでしょうか?"と問いかけている。

スクラムの創始者であるJeff Sutherland氏がツイートした記事のひとつには、従来型の組織構造にアジャイルを当てはめようとしてアジャイルを破壊している組織によって、役割が歪められている傾向が強調されている。

さまざまな見解を要約すると、アジャイルの規模が拡大し、その利用がごく普通のことになっている一方で、プロダクトオーナという役割には明確なニーズがない場合や、明らかに状況に適合しない場合がある、ということだ。

命題を一般化して、「全てのアジャイル開発チームはプロダクトオーナー無しでも機能するべきだ」と考えると、確かにその通りかもしれん...と思ってはしまう。

開発チームがそこまで自律的に機能するならそれはひとつの理想ではある。

とはいえ、常にそこを求めるべきかと言うと人材の問題や学習コストもあるし...ってことで、まず最初から選択肢に挙がらない。

エンジニアの視点から考えてもプロダクトの意思決定に必要な情報や組織内の調整諸々にまで手を出したくない(手に余る)ものがある。

プロダクトを極めるより先に転職したくなる可能性の方が高いのでプロダクトはプロダクトオーナーに任せたい感はある。

僕は極端な話、自分も含めて人に興味がなくシステムや仕組みにしか興味ない

"マサカリ来るとメンタルがやられます"と繊細さん。そういう人は無茶したらダメ。僕は極端な話、自分も含めて人に興味がなくシステムや仕組みにしか興味ない。そのシステムがより良くなるならマサカリは必要。良くなるなら朝令暮改すればいい。プライドないんすか?それでシステムがよくなりますか

@j5ik2o

自分もこういうタイプではあるが、その一方で自分一人でできることに限界もあるので意識して他者を「接待」しないといけないのがつらいところである。

それとは関係なく、ただ知識をひけらかしてマウント取りたいとか、気に喰わないから当て擦りをするみたいなムーブは害悪でしかないので絶対に許してはならない。

DDD本で一番きらいな言葉は「コアドメイン」

DDD本で一番きらいな言葉は「コアドメイン」だな。気持ちはわかるけどね。

知識領域に関して中核とか周辺とかは無い。その時々で優先順位が移り変わっていくだけだ。領域に軽重をつけていると、その変化を見逃す。

ビジネス機能が大事な時もあるがテクノロジーが重要な時もある。

@sugimoto_kei

本来は、その時々の優先順位の問題に過ぎないのに、それを、ある知識領域と別の知識領域の重要度の差と見てしまう(そしてたぶんそれぞれを担当する人々の発言権の差とも)。

これはいわゆる「認知的不協和」以外の何者でもない。

@sugimoto_kei

これはわかる。

「コアドメイン」なるものは、ある局面において注視すべき要素であって、常に核心的な価値を持つわけではない。まさに文脈(コンテキスト)依存。

とはいえ、そのシステムが直面する状況の7割以上の局面で中核的な価値を持つなら、便宜的にも実質的にも「コアドメイン」と呼ぶしかないのは確かだったりする。

今は若干給与が高過ぎるんじゃないかという気もする

自分もプログラマなのでIT技術者の給与が上がるのは望ましいことなのだが、一方で企業の経営事情や利益構造とマッチした報酬になってるのかというと、今は若干給与が高過ぎるんじゃないかという気もする。人を育てる再現性が無く、ベテランを奪い合う状況がそれに影響している感じがしなくもない。

@joker1007

これは思う時はある

NEXT