/note/tech

安全安心にソフトウェア開発を行うためのDesign Doc導入ガイド

SPAセキュリティ超入門

Tag:

コツコツ動くのが得意な人は“プロセス思考な人”と相性がいい 自分の「強み」を知り、チームで活かすための4タイプ診断

年齢を重ねたプログラマ

Feature-Sliced Design - スケーラブルなフロントエンドアーキテクチャを目指して

後で読む

【コードレビュー】長い関数orファイルへのレビュー方法

レビューをよくするようになって何年か経つのですが、よく目にするのが1つの関数とかファイルの行数が長くて何をしてるのか把握が難しい状態です。

この場合は必要な処理が書かれているか初見では判断できないのでリファクタリングが必要だということで、次のようなステップでコメントをしています。

Akkaを使用したCQRSパターンの実装

k1LoW/runn: runn is a package/tool for running operations following a scenario.

よさそう

参考資料:

2000年代のオブジェクト指向はやはり洗脳だったのか

MEMO:

OpenAIがリリースした高精度な音声認識モデル”Whisper”を使って、オンライン会議の音声を書き起こししてみた

しゅごい

GPUを用いた仮想通貨マイニングは「誰も儲からない」とマイナーが続々撤退開始との報道、イーサリアムのマージによる弊害

朗報だ

トーバルズ氏、Rust導入やM2搭載「MacBook Air」について語る

オレオレ Web アプリテンプレートを作ってる

対話と指摘は違うんだよね。対話による合意形成を好む人は、win-winなゴールを望むので相手と自分の立場を...

対話と指摘は違うんだよね。対話による合意形成を好む人は、win-winなゴールを望むので相手と自分の立場をなるべくフラットに持っていこうとするけど、指摘による合意形成を好む人は、win-loseなゴールを望むので自分の立場に上下を作りたがる。表面的には一緒に見えるけど中身は全くの別物である。

@komitsubo

こと技術者肌の人は、対話による合意形成を時間の無駄と考える傾向がある。彼らにとっては正解は常に1つ存在していてそれでいけばいいと思っている。”何故答えはある(そしてそれは自分の持論である事が多い)のに無駄な事をするのか”と思っているので無駄という言葉がよく出る。

@komitsubo

この手のエンジニア系の人は、win-loseな関係の事をwin-winと誤認している事が多い。win-winとは参加している誰かの持論ではなく参加している人が対話をする事で想像もしなかったよりよい合意形成案を生むことであって自分の正解と思っている自論で周りを納得させることじゃないんだよね。

@komitsubo

アジャイル宣言に出てくる対話もwin-winなものを創る活動であって、自分や他人の持論で相手を納得させるwin-loseやlose-winな話ではないと思うのだけど、正解を含めゼロサムな意見を好むエンジニア系の人はこの辺の違いがなかなか理解できないもんだよなぁとしみじみ思う。

@komitsubo

MEMO:

マイクロサービスの再考: タダ飯なんてものはない

デイリースクラムいらなくなくなくなーい!?

小規模開発会社の採用失敗談について振り返ってみる。

会社としての体制が定まらない内は新人〜ジュニア層の採用と育成は難しいわな

よく中抜き構造に対する批判を聞くけれども、表裏である雇用規制をどうすべきかにまで考えが及ぶ人は少ない...

よく中抜き構造に対する批判を聞くけれども、表裏である雇用規制をどうすべきかにまで考えが及ぶ人は少ない。必要に応じて直接雇用してプロジェクトが終わったところで解雇できれば理論的には内製できる。実際そうではないから要員を充足できるところまで階層構造が生まれる訳で

COCOAがダメだったのは「技術に対して投資して結果が得られなかったのがダメ」とかではなく企業の中抜き構造がダメだったというのが浮き彫りになったのが正しいんだよなぁ

@jdgtmpdawj

@masanork

実際は組織能力とか賃金体系、比較優位といった諸々もあってエンティティを分けることが経済合理的なケースもある。とはいえ役割による分業の方が、雇用構造による分業よりもずっと階層が浅く、取引費用やコミュニケーションコストも小さいのではないかな

@masanork

MEMO:

なぜ近年、Zig,Rust,Go,CarbonなどのC/C++ Likeの言語が乱立しているのですか?に対するJunji Ueharaさんの回答

Cが危険であり、Cを使い続けることができない状況だからです。

プログラミング言語のセキュリティについて調べてみる

から孫引きすると

2019年と古めの統計ではあるがIs One Programming Language More Secure Than The Rest?によると、脆弱性情報の多いランキングとして以下のようになっているそうです。

C言語 (47%)

PHP (17%)

Java(12%)

JavaScript (11%)

Python (6%)

C++ (6%)

Ruby (5%)

と実に脆弱性の半分がCで作られています。このことは、Shellshock脆弱性[1] やHeartbleed脆弱性[2] などで代表されるような、バッファオーバーフローを簡単に引き起こしてしまう、現代のレベルから劣っているとしか言いようがない、かつ直しようがない言語設計(50年も前の言語なのでしょうがないのですが)、また置き換えられることなくあまりにも長く使われてきたシステムプログラミング領域の言語であったということから来ています。

一方、システムプログラミングの領域では、やはり性能が求められます。CPUが倍に速くなったからソフトウェアの性能は半分で良いと考える人はいません。特にクラウドやサーバサイドでは、ハードウエアで倍量の処理ができるように速度が向上したなら、倍のユーザの同時処理を行うことが求められます。高価なインスタンスを利用するからと言って、じゃあその分遅い言語で書いていいんだね、とかが許される余地はありません。アプリケーションはともかく、「その上で全てが動作する、その動作速度にあらゆるユーザのあらゆる処理が依存する」ようなシステムプログラミングでは特にそうなのです。

ということで、システムプログラミング分野では、旺盛なソフトウェア開発需要のもとで、Cと同等の実行速度は必要であり、ハイリスクなC以外の選択肢は強く求められているのです。

本来なら、C++はその役を担っても良いものでした。しかしパラダイムシフトに匹敵する方針転換を一つの言語上で後方互換を保ったまま何度も行ったことで、その仕様は難解なものとなりました。後方互換を必要としない開発分野では、まさに重荷というべき、採用コストがペイしないうえに保守コスト上も受け入れがたい言語とみなされ始めました。

以上がCの代替言語が出てきた背景となります。残る疑問は、なぜ、この時期にそしてなぜ多数なのか、です。

多数であることについてですが、質問に挙げられた言語をそれぞれ見ていくと、コンセプト、解決したい領域がそれぞれ異なっていることがわかります。

例えばgoはネットワーク・並列処理であるし、CarbonはC++のプログラミングモデルそのままに重荷である後方互換を除去し、良いところだけを取り出したものです。Rustはリッチな型システムに裏打ちされた静的解析によるメモリエラーの撲滅を目指しています。Zigはより直球でCを代替するもので、一周戻ってRust疲れを癒やす存在です。

だから多数なのには理由があり、Cがあまりにも多くを負うていたことの反動だとも言えるでしょう。

最後に「なぜ今なのか」です。といってもGoやRustが出たのもそんなに新しい話ではないですが、D言語やVなんかもあるし印象としては確かに増えてはいます。

その理由を説明するなら、C以外の言語、例えばHaskell,Ruby,JS,Erlang,Typescript言語による成長期・実験期が終わり、言語機能ごとの評価が定まり、良い機能は何か、あんまり良くない機能は何かのコンセンサスが取れてきたということがあります。収穫期が来たということです。

多角的、総合的な意味で「良いシステムプログラミング言語」をどうすれば作れるかがわかってきて、言語設計業界が成熟し、メリットが大きい言語を作れるようになり、ついに偉大すぎるCの遺産を捨ててでも移行する苦痛を凌ぐようになってきました。Cを捨てるメリットが、損益分岐点を超えつつあるのが今だから、いまそのような言語が我々の目に良く付き始めるようになっているのです。その動向は大きな潮流であり、業界全体に普遍的だから、C代替の多数の言語が今、現れています。

脚注

[1] 2014年シェルショック脆弱性 - Wikipedia

[2] ハートブリード - Wikipedia

SOLIDを代替する設計原則、CUPIDについて

SOLID原則はプリンシパル(ルールやガイドライン)を定めたものであるのに対し、CUPIDはソフトウェアが持つべき性質・特徴を定めたものです。SOLID原則はOOPやプログラミング言語に依存するところがありますが、CUPIDは基本的にOOPやプログラミング言語に依存しません。

CUPIDは下記の頭文字です。ソフトウェアはこれらの性質・特徴を持つように作るべきだというのがCUPIDが伝えるものです。

  • Composable : 他のコンポーネントと組み合わせしやすいこと
  • Unix philosophy : ひとつのことをうまくやること
  • Predictable : なにをするのか予測できること
  • Idiomatic : 自然に感じられること
  • Domain-based : ドメイン言語とドメインの構造を使うこと

Pull Requestの質を向上させるために行った戦略/戦術の話

terraform-docsをGithub Actions上で実行して、プルリクエスト時にモジュールのドキュメントを自動生成してみる

便利そう

k6の使い方 シンプル&軽快な負荷試験ツールを試す

どうして統合テストは重要なんだろう?

Remix.runのKent C.Dodds氏や、VercelのGuillermo Rauch氏などの著名なソフトウェアエンジニアは、統合テストがE2Eテストよりも低コストで、単体テストよりもカバー範囲が広いことを理由に、もっと統合テストを重視するように提唱しています。

「静的テスト、単体テスト、統合テスト、E2Eテストのバランスはチームが何を重視するかによって変化します。このバランスは、厳密なルールとして捉えるべきものではないでしょう。

あくまで一般論です。使用できるツールでアプリをテストするのがどれだけ簡単か、難しいかによって、実際に異なるのです。 一般的な考え方は、静的テストと統合テストによって、かけたコストに対してユーザに“素晴らしい”価値を保証します。そして単体テストとE2Eテストによって、“良い”価値が得ることができのです。なので全て利用していきましょう」

統合テストの大きな価値の一つは、E2Eテストと同じようにユーザーのふるまいをテストできることにあります。 ユーザーがコンポーネントを単体で使用することはほとんどなく、ほとんどのWebアプリは、異なるコンポーネント間の相互作用として実行されます。

このため、統合テストは、特定のロジックの入力と出力をテストするだけの単体テストと比べて、テスト結果の信頼性が高くなると思います。

なので、最初に書くべきなのは統合テストだと捉えています。 この考え方は、ほとんどの人は直感に反したり、異なる意見を持っているかもしれません。

開発サイクルの中で不具合を発見するのが遅ければ遅いほど、その修正にかかる費用は高くなると教えられてきました。統合テストなどの「大きなタスク」に着手する前に、すべての細部を完璧にしようとします。

先に単体テストを書いていては必要なビジネスロジックを柔軟に変更しながら開発を進めることができません。

確かに関数/メソッドレベルのユニットテストより、それらを呼び出すエンドポイント的な部分のテストから書き始めることが多い。

例えば、コントローラやユースケースの実装&テストから始めて実際にテストを動かしながら実装を進める方がやりやすい。

Twitter強まる風圧 内部告発者が証言、イーロン・マスク氏に加勢

米ツイッターの経営が視界不良だ。13日に開いた臨時株主総会で、米起業家のイーロン・マスク氏と4月に合意した総額440億ドル(約6兆3000億円)の買収取引を承認した。同日には米議会上院が、同社のセキュリティー問題を内部告発した元幹部を証人に招き、外国勢力によるスパイ行為などのリスクを問いただした。買収撤回を表明しているマスク氏との法廷闘争に影響する可能性がある。

「非常に大きな影響力を持つ会社でありながら、業界のセキュリティー基準から10年以上遅れている」。ツイッター元幹部のピーター・ザトコ氏は13日、米上院司法委員会が首都ワシントンで開いた公聴会に出席し、同社のIT(情報技術)システムの脆弱性が経営陣によって意図的に見過ごされ、事実が隠蔽されてきたと証言した。

多くの企業はITシステムを稼働中の本番環境と、開発のためのテスト環境に分けている。ところがツイッターではザトコ氏が在籍していた2022年1月まで社内にテスト環境は存在しなかったという。攻撃者の視点でシステムを診断する「ホワイトハッカー」でもある同氏の目には「奇妙で異例」と映った。

ザトコ氏によると従業員の半数を占める4000人近いエンジニアが本番環境にアクセスすれば、電話番号や位置情報を含む多くの個人情報を閲覧できる状態だった。社内ではエンジニアの作業履歴などを追跡する仕組みも整っていなかった。

ツイッターを解雇される直前には中国の情報機関の工作員が同社に在籍していた事実を知らされたという。ザトコ氏は13日の公聴会では「ツイッターの従業員ならばこの部屋にいる議員全員のアカウントを乗っ取ることができると言っても過言ではない」と訴え、米規制当局の対応を促した。

Twitterぐらいの規模になってしまうと本番相当のテスト環境を作るのに多大なコストが掛かるだろうから、フィーチャーフラグを仕込んだ上で本番に直接適用するという方針でも別に不思議ではないが(テストとレビューは厳格にやる前提)。

Facebookもそんな感じの開発フローだと聞いたことがある。

ユーザーデータに対するパーミッションや作業内容の監査ログ機能が無いのは流石にダメだと思うけども。

エ〜クエクエクエク(エクセル怪人の笑い声)今日もセルを結合して中央揃えして、検索に引っかからないように...

エ〜クエクエクエク(エクセル怪人の笑い声)今日もセルを結合して中央揃えして、検索に引っかからないようにテキストボックスに大事なことを書いて、印刷する予定も無いのに印刷範囲を設定していくエクねえ……

@_Rayshiki

ある種の人々において、Excelを独創的な使い方をしたがるのは何故なのか

Docker Desktop 4.12登場。ターミナル機能の統合、containerdによるイメージ管理、Dockerボリュームの...

WindowsやMacなどのローカル環境に簡単にDockerコンテナを用いた開発環境を導入できるソフトウェア「Docker Desktop」の最新版「Docker Desktop 4.12」がリリースされました。

2つ目はDockerイメージの管理にcontainerdが使われるようになることです。まだ実験的実装の段階ですが、Dockerイメージの保存やプッシュ、プルといった管理にはDocker独自の実装であるグラフドライバーが用いられていました。

今回のDocker Desktop 4.12からは、このグラフドライバの代わりにcontainerdの機能であるSnapshotterが用いられ、containerdの機能を呼び出してイメージ管理が行われるようになります。

これによって他のcontainerdを用いた環境との整合性や互換性がより高くなると説明されています。

へぇー

業務委託テックリードと技術的負債

基本方針が決まったので、先程作ったリストの項目それぞれに、おおまかに優先順位を付けていくことにしました。 ただ数字を書き込んだだけだと分かりにくいかと思い、各項目に「出血中」「痛みを伴っている」「健康診断判定E」「体脂肪率40% -> 20%」など、健康状態に例えてラベル付けをしていきました。

例えば、極めて改修頻度が低くメンテが後手に回った結果、CIが古く不安定になっているリポジトリには、改修頻度が低いほど自動でのサポートが必須だと考えたため、「出血中」というラベルを付けました。

他にも、フレームワークや言語のバージョンが古いものには「健康診断判定G」、オンプレからクラウドに移行するだけで開発が機敏になるものには「体脂肪率40% -> 20%」などとラベル付けをしました。

その頃社内でのイベントで、「基盤領域の業務の説明をして欲しい」という依頼が来ました。 基盤領域の業務は、非エンジニア職の方々には見えにくく、「こっちはこんなに忙しいのに何をしているのだろう」などという不信にも繋がりかねません。今後の技術的負債の解消に向け、そういった不信感は致命的です。 それを少しでも解消するための良いチャンスと受け止め、プレゼンでは基盤領域の仕事を、アルバイトで求人が多い飲食店チェーンに置き換えて話をしてみました。 要約すると、以下のような感じになります。

  • 揚げ物ブームが来たのででかいフライヤーを導入したが、ブームが終わったら稼働率が落ちた。これを撤去したり、新しい機材を入れたりしなければならない
  • 包丁もコンロも、各調理器具は手入れをしなければ、継続的に使えない
  • こういったものを常に、現在の仕事が滞り無くできたり、新しいブームにすぐ乗れたりするように保つ必要がある
  • Webシステムにおいて、そういった手入れや準備、研究、調査をするのが、基盤領域の仕事

ソースレビュー時の心掛け

COCOAの総括(オープンソースコミュニティとして) · Issue #1144 · cocoa-mhlw/cocoa

これはオープンソースプロジェクトあるあるだと思いますが、コントリビューターの方からもらう大きめのIssueに、最初から過不足無く情報が整っていることなんてほとんどありません。それ自体は当たり前のことです。ここで言いたいのは、Issueをもらった後、対話によって「なにがしたいのか」「どう変えるのか」を突き詰めていく課程が当然に必要になるということです。

しかし、取り込むかどうかわからないものの話を進めて、コントリビューターの時間を使ってもらって議論を深めて、やっぱり行政内で検討した結果駄目でした。というのは、ぼくとしては進められませんでした。

結果として大きめのIssueがほとんど処理できず、小さなIssueやPull Requestのみを取り込むという、言ってみればスケールの小さな活動に終始してしまったのが、ぼくの大きな反省です。

しかし、行政内での人の入れ替わりが激しい。最長でも2年ほどで異動するのが普通だそうです。意思決定者と聞いているポジションで着任したと聞いてから、一度も挨拶しないまま離任した人も居ます。そのような状況ですから、引き継ぎがあるとは言え、オープンソースコミュニティへの信頼は定期的にリセットされた状態になっていると個人的には感じています。

接触確認アプリ「COCOA」は、もともと10年続かない(続いて欲しくない)プロジェクトとぼくは認識しています。 その上で、ソフトウェアには10年以上使うものはそれなりにあります。ソフトウェアのオープンソースコミュニティと、人の入れ替わりが定期的にある行政とは相性が悪い気もします。

あと、もう少し物事を進める権限が欲しい。意思決定者と直接、話をさせてもらえる機会がちゃんと欲しい。意思決定者でなくてもいいから、どういう話し合いがあってそういう結論になったのか、経緯をきちんと教えて欲しい。

決済チームがテストコードを書く際に気を付けていること

TL;DR

  • 100%のテストカバレッジを目指す
  • テストはブラックボックスを優先して記述、どうしても到達できない場合はホワイトボックス
  • 最初のテストケースは、テスト対象が動作する最も一般的なケースであるべき

ソフトウェアを完成させる

ソフトウェアは何もしないと壊れる

というのは事実ではあるんだけど、それが良いことかというと、どうなのかなあと思う。ほかにも、我々プログラマはつい「ソフトウェアは完成しない」とかいってしまうし、それは雇用のためには良いことなんだろうけど、でも本当に完成しないんだろうか。

ここ最近ずっと G-SHOCK のオリジナルに近い四角いモデルをつけていて、こういう、完成した定番品というのが、コンピュータとかソフトウェアの世界にも、もう少しあってもいいんじゃないかと思う。

実行基盤(OS)自体が変化していく界隈だしなぁ

確かにWindows2000をWindows2000のままブラッシュアップしていってほしかった気持ちはある。

「不安に怯える普通の人」を統率するための「大本営」と「大本営発表」

OPA/Regoによる汎用的なGo言語の静的解析

なんかすごそう

プロジェクトを炎上させないためのひと手間「兆候管理」

Docker、いつでも簡単に再現性のあるLinuxランタイムを作って壊せて便利だと思って数年置いてたら...

Docker、いつでも簡単に再現性のあるLinuxランタイムを作って壊せて便利だと思って数年置いてたらDebianのバージョンが賞味期限切れでコンテナを再構築できず、ほんとにすごいのはAPTだったんだなとわかる回

@tadsan

CentOSイメージも古いバージョンはリポジトリのURLが変わったりしてすぐ動かなくなる。

やはり放置はダメなのだな。

『ELDEN RING』開発は自動化と効率化を追求―過去作と比較して語る開発の変化【CEDEC 2022】

とあるカンファレンスにでてきた「ソフトウェアはなにもしないと壊れる」という言葉に深くうなずく皆様...

とはいえ、オープン化してからソフトウェアの寿命はどんどん短くなっているのは事実で、それが全て好ましいとは思えないってのもある。

特に機械の制御機器に汎用PC(とソフトウェア)を使うのはライフサイクルが短すぎて厳しいというのはずっと言われていることだし(例えば、デジタルサイネージの管理システムが未だにWindows2000+VBアプリである、とか)。

Domain Modeling Made Functional を読んだ

ドメインの分析はイベントストーミングで行うべし、というところから始まっていて、DDD の実践書としてコンパクトながらよくまとまっている。DDD の入門という観点でもよさそう。

結局この本で言っている Functional とは

  • 静的な代数的データ型を駆使してモデリングすることと、
  • 不変なデータと副作用のない関数に基づいてワークフローを実装すること

ということのようである。

分析を経て得られたドメインモデルを、型を通じてモデリングしていく。ここではとくに直和型が重要な働きを持っていて、これを使うことで違うものを違うものとして表現できる。「ありえない状態はそもそも表現できないようにする(Making Illigal States Unrepresentable In Our Domain)」というのが大方針だ。

wolfeidau/hotwire-golang-website

This project provides some working examples using Go the hotwire/turbo library published by basecamp. This is based on a great post about Hotwire: HTML Over The Wire by @delitescere.

このプロジェクトは、basecamp によって公開されている Go hotwire/turbo ライブラリを使用して、いくつかの実例を提供します。 これは、@delitecere による Hotwire: HTML Over The Wire に関するすばらしい投稿に基づいています。

抽象化を嫌う理性的な理由を少し考えてみた

エンジニアの人たちね、まあ頭が良いということなんだろうけどもね、例えばなんだけど「Aを使ったBがしたい」...

エンジニアの人たちね、まあ頭が良いということなんだろうけどもね、例えばなんだけど「Aを使ったBがしたい」と言うと、そのAとBになった背景を聞くのね。

これは全然良いんだけど、最終的に「それならCがいいよ」って結論を出してくるの。相手はAを使ったBがしたいって言ってるのに。

@tmkwsn

これ逆に頭悪いんじゃない?って思うことはある

@tmkwsn

例えば1000を上限としてるのに、50くらい変わらないでしょって前提で、1050くらいの話を勧めてきたりとか。なんかいちいち話をズラしたり外堀だけ埋めてこようとするの。たぶん自分がしたい話を選んでるってことなんだろうけど、すげー会話しづらいよ。

@tmkwsn

制約条件を明示しない方が悪いのだ。

制約条件が明示されていないなら、結果に対して最善と思われる提案を出すに決まっているだろう。

dbtを導入して小規模チームでも運用可能なデータマネジメント体制を構築した話

レガシーなプロダクトからドメイン層を再設計する

ソフトウェアエンジニアとしての姿勢と心構え

タレントに貸したMacBook Proが「データ全削除」状態で返却され関係者が苦言

削除されて困るデータはそもそもバックアップしておくべきだし、初期化されて困るというのもよくわからない。

株式会社メルペイを退職します

Go Secure Coding Practice の日本語翻訳を公開します

アソビュー!ギフトを支える技術の現状と今後

デスクトップ環境をdisposableに保つ

もう5年以上続けている取り組みのひとつにデスクトップ環境をdisposableに保つというのがある。いつでも何があっても即座に環境を捨てて作り直せるようにするということ。EC2やVPSのインスタンスに対してAnsibleでプロビジョニングできる状態にしておけば即座に新しいホストを立てて古いホストを捨てられる、そんな状態を目指すということ。具体的には以下のようなことを心がけている。

設定を一発で復元するシェルスクリプト作っとこうと思いつつ、ずっと後回しにしてたけど少しずつやっていこうかな

ソフトウェアテスト入門

途中のコンテナ云々のところがよくわからなかった。

発表を聞かないと詳細がわからないタイプぽいが、発表のアーカイブは上がっているのだろうか。

Golangでモックサーバーのライブラリを実装してみた話

便利そう

HTTP GETで起動するバッチ処理、Confluenceに作ったAPIドキュメントにURIを貼ったらプレビュー機能が働いて...

HTTP GETで起動するバッチ処理、Confluenceに作ったAPIドキュメントにURIを貼ったらプレビュー機能が働いてバッチ処理が叩かれてしまい、障害が起こったのでConfluenceが禁止になった回。

@igz0

Goでのスクレイピングに使っていたgoqueryをcollyに置き換えてみた

よさそう

Go の interface は構造体の利用側が定義すると言う話

NOTE:

Hatena Engineer Seminar #21 GraphQL 活用編 #hatenatech

見ている

GolangはテストのためにInterfaceで公開しない

NOTE:

最近のお客様でもこれは強く言われる。なぜかと言うと変更にかかるコストの問題で、相手がSIerであれ情シス部門...

最近のお客様でもこれは強く言われる。なぜかと言うと変更にかかるコストの問題で、相手がSIerであれ情シス部門であれ、キャッシュアウトや交渉の手間を嫌うから。私も経理部員だったのでわかる。

これはあまり健全だとは言えない。コードで表現すべきことはそうすべきだと思います。(続く)

昔、お客様の基幹系システムをスクラッチ開発していた頃、システム運用担当の皆様ともよく打ち合わせしたが、ビジネスルールを如何にわかりやすくコードに書くかではなく、業務上変わり得るルールならそもそもコードに書かず、ユーザー部門がテーブル登録する仕様にしてくれという話の方が普通だった。

@sugimoto_kei

@tonymorrisjp

テーブルでビジネスロジックを表現するのが難しい場合があり、担当者が3代変われば、もはやブラックボックスになります。コードで表現してある方がまだしも親切で、リーダビリティが高いと尚よい。DevOpsが実現されていて内製化されていればもっとよい。

@tonymorrisjp

ビジネスロジックをテーブルで実装できるとなったら、ユーザーは仕様の決定を先送りする。過度な柔軟性を持たせることを要求する。 あんまり良いことではないが、変えようもない。情シス部門は事業部門より立場が弱い。昔に比べその傾向は強い。だったらコードの部分で何とかするしかないと思います。

@tonymorrisjp

昔、お客様の基幹系システムをスクラッチ開発していた頃、システム運用担当の皆様ともよく打ち合わせしたが...

昔、お客様の基幹系システムをスクラッチ開発していた頃、システム運用担当の皆様ともよく打ち合わせしたが、ビジネスルールを如何にわかりやすくコードに書くかではなく、業務上変わり得るルールならそもそもコードに書かず、ユーザー部門がテーブル登録する仕様にしてくれという話の方が普通だった。

@sugimoto_kei

この辺、この三十年ぐらいで、もしかしたらものすごく後退してきてるんじゃないかと感じることがある。

@sugimoto_kei

COBOL が Java になろうが、何かの関数型言語になろうが、変わり易いと分かっている業務ルールをハードコードして、リーダビリティ云々と言っているんじゃ、ソフトウェア設計としては、レベルが落ちているとしか言いようがない。

太陽電池でモーターを回し、木をこすって火を起こしている印象だ。

@sugimoto_kei

僕のいたのがコンサルティング会社でレベルが高かったー、みたいな話ではなくて、お客様の情報システム部門がまずそういうスタンスだったですね。

@sugimoto_kei

確かにやりすぎのリスクはある。普通のマスター項目以上、汎用言語未満、みたいなところで寸止めするのが結構大事。#やりすぎがちなアカウントの述懐

@sugimoto_kei

DBのカラムにJSのコード断片入れておいてごにょごにょさせる、みたいな。けっこう凶器じみているかも。

@sugimoto_kei

本件、メタプログラミングを志向してるんじゃないんです。変わると言われがちな要件の背後にある変わらぬものを見い出そうとする試みなんですね。まあ、メタプログラミングは本来そうだと言えば、そうかもしれない。

@sugimoto_kei

そりゃ昔(今も?)みたいにコードの変更は「まず稟議を上げて部門長の承認を得て、システム部門に申請してシステム部門の承認を得て、そこから開発企業に発注して、先方の対応を待って漸く実装されたら、受入試験を実施して...(略」みたいな状況だったら、そりゃ利用部門で柔軟に変更できるようなDSL的な何かが欲しくもなるだろうけど。

社内に開発チームを常駐させて緊急性・重要性の高い案件から処理していくアジャイル開発のスタイルを採用するなら過度な柔軟性はむしろ生産性を下げるのでドメインロジックはコードで表現するのがやはり最適解だろう。

とはいえ、DSL的な何かで処理やデータを自由に定義できるという方向性自体は間違いでも無いので、そういうのはダッシュボードツールやJupyter Notebook的なものを提供すればよいだろう。

プロダクト開発でドキュメントを書かないとどうなるか

リファクタリングは事前準備が9割

光ディスクは滅びぬ。1TBあたり5ドル未満の光ストレージ技術

米Folio Photonicsは8月30日(現地時間)、多層光ディスク技術において重要なブレイクスルーを達成し、抜本的に低コストと大容量を両立させ、動的にリード/ライト可能な光ストレージディスクを開発したと発表した。製品の投入は2024年を予定している。

2024年投入時で1ディスクあたり1TB、これを10枚集約したカートリッジで10TBを達成する。その一方でコストに関してはHDDが1TBあたり25ドルであるのに対し、1TBあたり5ドル未満を達成できるとしている。将来的なロードマップでは1TBあたり1ドル以下を目指す。

現在の低コストなデータアーカイブ技術としてはテープがあるが、Folio Photonicsの光ディスクはランダムアクセス性を実現できるほか、電磁パルス攻撃、サーバー攻撃から保護できるエアギャップ、100年のメディア寿命を提供する。

本当に実現できるのだろうか?

エンジニアリングマネージャーのしごと - Forkwell Library #5

見ている

14万件の個人情報を誤削除、復旧できず 「焼肉きんぐ」運営元がサーバ移行でミス

飲食チェーン「焼肉きんぐ」などを運営する物語コーポレーション(愛知県豊橋市)は9月5日、顧客の個人情報14万3876件を誤って削除し、復旧できない状態だと発表した。サーバ移行時の確認不足によりデータを移行し損ね、そのまま古いサーバの契約期間が終了したという。削除した情報の漏えいは確認していない。

誤って削除した情報は、焼肉きんぐに加え「お好み焼き本舗」「焼肉かるびとはらみ」など計6ブランドのチェーン店に来店したことがある顧客の氏名、住所、電話番号、生年月日、性別、メールアドレス。いずれも、誕生日の顧客にサービスやキャンペーンを告知する目的で保存していたという。

oh...

ソフトウェア開発で「正確な工数見積はできない」というのは、新規なんてやってみるまで何ひとつ...

ソフトウェア開発で「正確な工数見積はできない」というのは、新規なんてやってみるまで何ひとつわからないという怠慢の肯定ではなくて、過去の経験からだいたいカンでこれぐらいかなと予測した数字は出せるけど、そんなものの足し算で長期計画のケツを約束する愚行をやめようという意味なのよね

@tanakahisateru

わかってればわかってるほど、こうなんですよね。本当に全くわからないなんて言い出す人は、きみ開発経験ほんとにあるの? ってことになっちゃう。まだそれは誠実なほうで、わからないのに見栄を張って数字を言っちゃう不誠実が横行するのが問題。動機が見栄だから、実際の結果はだいたい期待を下回る

@tanakahisateru

で、ボロを出したくない心理で、見積の間違いを隠すんですけど、そのままだと最後にバレるのは容易に想像できるので、言ったことと帳尻を合わすためにムリをするんですよね。まあ当然、開発者がそうやって疲弊したらソフトウェアのメンテ品質はさらに下がって、ますます遅れちゃうっていうのがオチです

@tanakahisateru

まあそのなんだ。100%でなければ0%かよみたいな極端な話は不毛だからやめようってことと、その中間の確からしさと不確実さを受け入れて、嘘の進捗管理をやめようよということです

@tanakahisateru

Chrome開発チームがSQLiteチームとWebAssembly版SQLiteを開発中。Webブラウザ上からのファイル書き込みで...

Google Chromeの開発チームは、すでに非推奨となっているWeb標準のWeb SQL Database APIをChromeから削除、その代替機能としてSQLite開発チームと協力してWebAssembly版のSQLiteを開発し、提供する予定であることを明らかにしました。

クライアントで本格的なDBが動けば嬉しいなと思うことはないでもないんだけども。

ちまちまREST APIを叩くよりSQLiteのデータファイルを直接配信/アップロードする方が効率的ってなるのだろうか。

frameable/el: Minimal JavaScript application framework / WebComponents base class

サンプルを見た感じ、中々良さそうだが

AWS Step Functions をゼロからざっくり理解する

イベントストリーミング入門 〜Apache Kafkaを活用した大規模リアルタイムデータ処理〜

Reactにおける責務(UI/ロジック)の切り分け

私の考えでは以下の使い分けが望ましいです。

UIとUIロジックは密結合

UIと業務ロジックは疎結合

UIロジックと業務ロジックは疎結合

  • atoms
    • コンポーネントの最小単位。
    • ロジックは持たない。
    • ステートレスなコンポーネント。
    • システム全体で流用できる。
  • molecules
    • atoms、moleculesの複合コンポーネント。
    • UIロジックを持つことがある。
    • ステートレスなコンポーネント。
    • システム全体で流用できる。
  • organisms
    • atoms、moleculesの複合コンポーネント。
    • 業務のドメイン情報をDOMに持つことがある。
    • そのためシステム全体で流用できるとは限らない。
    • APIとの疎通や業務ロジックを持つことがある。
    • PresentationalComponentsとContainerComponentsを分ける。

Reactベースのチャートツール選定(2022年版)

技術文書の書き方

docker-compose の bind mount を1行で書くな

TL;DR

  • docker-compose では bind mount の構文が "short", "long" の2通りあるが, それぞれ挙動が異なる
  • docker-compose.yml の volumes に略記法 (short syntax) を用いると, コンテナ内で non-root user を用いる際にエラーの発見が遅れる可能性があるので避けよう

services:
app:
    image: nginx
    volumes:
    - "./config:/config"

services:
app:
    image: nginx
    volumes:
    - type: bind
        source: "./config"
        target: "/config"

そんな指定の仕方があったのか

カミナシでの技術的負債プロジェクトとその決断

主要RDBMS製品のアーキテクチャ比較

プロダクト開発みたいに不確実なことをやる場合、成果が約束できないからって、やることを約束しちゃいけない

プロダクト開発みたいに不確実なことをやる場合、成果が約束できないからって、やることを約束しちゃいけない。ムダなことをひたすらやり続けることになる。約束していいのは、目指す成果とプロセスの透明性まで。

@haradakiro

JSON Crack

JSONの構造を可視化してくれるツール

Dockerイメージも用意されているのでローカルで動かすことも簡単

1つでも該当すると、「会議の成功率」は5分の1以下 AIが導き出した、会議の成功を阻む5要素とは

MEMO:

アウトプットが出ない会議の特徴5要素:

ハードワークで人は成長するか

期間の扱い方とその名前

セキュリティ・バイ・デザイン導入指南書

AWSが主導するElasticsearchのフォーク「OpenSearch」にCanonicalが参加へ

Linuxの主要なディストリビューションの1つであるUbuntuを開発するCanonicalは、AWSが主導するオープンソースの検索エンジン「OpenSearch」のプロジェクトへの参加を表明しました。

すでにOpenSearchにはオラクルを始めとする多くのパートナーが参加していますが、オープンソースの主要なプレイヤーの1つであるCanonicalの参加はAWSやOpenSearchの継続性に懸念を持つ人々にとって心強いものとなりそうです。

結局、ElasticsearchとOpenSearchは別の道を行くのか

A pattern language for microservices

マイクロサービスのデザインパターン

Cognitive Complexityを400以上減らすまでに何をしたか 〜 コード品質改善の具体的なプラクティス

コード品質を定量的に測る指標の1つにCognitive Complexityがあります。Cognitive Complexityは人間視点での複雑性を評価する指標で、例えばネストが深くなるほど複雑と判断される特徴があります。複雑なコードは変更に多くの時間を要し、テストが難しくなるので要改善なシグナルといえるでしょう。私たちが今回実施した品質改善の取り組みでは、コードの状態を定量的に説明するための数値の1つとしてCognitive Complexityを採用していました。実際にコード品質を向上させるまでに取り組みを紹介しつつ、Cognitive Complexityの値が低下(改善)した背景を解説します。

倉庫の在庫管理、なんと4割がまだ「紙」「エクセル」を使っていた! 現場から「本人しかわからない」の声も

物流関係のシステム開発を手掛けるダイアログ(東京都品川区)は8月29日、在庫管理の実態調査を発表。約4割が「Excel」や「紙」を利用していることがわかった。調査対象は、倉庫の在庫管理業務の担当者・経営者・役員189人。

「倉庫の在庫管理で主に行っている方法は、約4割が「Excel」や「紙」と回答しており、Excelでの在庫管理では、「Excelを作った本人しかわからない」や「リアルタイムで更新できない」などの課題の声が挙がりました。更には、Excelあるあるとして「計算式が壊れた際、復旧に時間がかかる」という悩みの声も。なお、半数以上が、現状の在庫管理の方法を変えていく必要性を実感しており、今後WMSを中心とした倉庫管理システムを検討する企業も増えているようです。また、WMS中心の倉庫管理システムに対する期待は高く、「機能種類の充実」や「機能の選択の自由性」、「拠点増加など、あらゆる需要変動への対応」、「様々なデバイスで業務可能か」などの機能が求められていることが分かりました。さまざまな管理方法として「エクセル」が身近で導入費用がかからないと考え、多くの企業に「エクセル」が普及しました。また、DX化が進む近年ではシステム化が重要視され、「在庫管理」においても「エクセル」や「システム」が同時に検索されていることから、このことから「在庫管理をシステム化したい」というニーズが増加していることが伺えます。一方で、「エクセル」は属人化しやすい傾向があり、誰にでも使いやすい管理方法とは言えない実態もあります。人材不足を課題とする企業においては、在庫管理業務の脱属人化による作業効率化を叶え、作業を標準化させるためにシステム導入の需要が加速しそうです」

スマート倉庫を運用できる規模の企業ならともかく、間貸しレベルの小規模企業だといちいちシステム化していられないし、搬入される貨物も多種多様なのでシステムの対応を待ってられないという現実はありそう。

メルカリWebのマイクロサービス化、その4年

メルカリWebのマイクロサービス化に向けた開発が始まり、最終的にweb-2がシャットダウンされるまで、実に4年以上の期間がかかりました。この記事では、この4年間に開発チームの中でどのような議論があり、どういった選択を行いながらアーキテクチャを変更していったのかを記述し、変化に強い組織やアーキテクチャについて考える上で参考にしていただければと思います。

これまでとこれからのGo

2022年8月にGo1.19がリリースされ、次のリリースは2023年に予定しているGo1.20です。Go1.20ではGo1.18やGo1.19に入らなかったジェネリクス関係の変更のリリースが期待できます。ここではGo1.20でリリースされると決まった訳ではありませんが、将来リリースされることが期待できる3つの機能について解説します。なお、本稿の執筆後に仕様が変更されたり、機能自体がリリースされない場合もあります。

マイクロサービス分割点の見つけ方

単機能のサービス

パフォーマンス特性が大きく異なるサービス

認証・認可ゲートウェイとなるサービス

外部のAPIを抽象化するサービス

期待値をチューニングする

一塊のコードを複数人に共有させないこと。セールス野郎に会社を仕切らせないこと。ハイエンドの製品を...

一塊のコードを複数人に共有させないこと。セールス野郎に会社を仕切らせないこと。ハイエンドの製品を作らないこと。コードを大きくしすぎないこと。バグを見つけるのを品質保証の人間に任せておかないこと。リリースの間を開けすぎないこと。開発者をユーザから隔離しないこと。

@pg_quote

Go Secure Coding Practice の日本語翻訳を公開します

SQLiteを分散データベースに変えるmvSQLite

mvSQLiteの特徴は、SQLiteのストレージレイヤーをFoundationDBに分離しているところです。   これにより、DynamoDBのように際限のないスケーラビリティ、point-in-timeでの読み取り、そしてRDBの厳密な一貫性を提供します。

作成者曰く、mvSQLiteの目標は「SQLiteを分散データベースに変えること」とのことです。

メンバーから「できてません」「進んでません」と言ってもらうために、考えたこと

【カミナシ原トリ×AlphaDrive赤澤】フェアなエンジニアリング組織をつくるために「短期的な非合理を...

ルールが細かい職場は働きづらい、なんてない。

ソフトウェア開発者は徹夜してはいけない

そりゃまぁそうじゃろ

DDD導入にどう立ち向かう? 開発現場への適用方法あれこれ②

Heroku 無料プランを終了

  • Public roadmap: launch of our interactive product roadmap for Heroku on GitHub.
  • Focus on mission critical: discontinue free product plans and delete inactive accounts.
  • Student and nonprofit program: an upcoming program to support students and nonprofits in conjunction with our nonprofit team.
  • Open source support: we will continue to contribute to open source projects, notably Cloud Native Buildpacks. We will be offering Heroku credits to select open source projects through Salesforce’s Open Source Program Office.

Our product, engineering, and security teams are spending an extraordinary amount of effort to manage fraud and abuse of the Heroku free product plans. In order to focus our resources on delivering mission-critical capabilities for customers, we will be phasing out our free plan for Heroku Dynos, free plan for Heroku Postgres, and free plan for Heroku Data for Redis®, as well as deleting inactive accounts.

Google翻訳:

  • 公開ロードマップ: GitHub で Heroku のインタラクティブな製品ロードマップを開始します。
  • ミッション クリティカルに焦点を当てる: 無料の製品プランを中止し、非アクティブなアカウントを削除します。
  • 学生および非営利プログラム: 非営利チームと協力して学生と非営利団体をサポートする今後のプログラム。
  • オープン ソース サポート: オープン ソース プロジェクト、特に Cloud Native Buildpacks に引き続き貢献します。 Salesforce のオープンソース プログラム オフィスを通じて、選択したオープンソース プロジェクトに Heroku クレジットを提供します。

Heroku の製品、エンジニアリング、およびセキュリティ チームは、Heroku の無料製品プランの詐欺や悪用を管理するために多大な労力を費やしています。 お客様にミッション クリティカルな機能を提供することにリソースを集中させるために、Heroku Dynos の無料プラン、Heroku Postgres の無料プラン、Heroku Data for Redis® の無料プランを段階的に廃止し、非アクティブなアカウントを削除します。

まぁ、無料プランは悪意のあるユーザーを呼び込んでしまうってのはある。

WEBサービスはいつまでも使えるわけではないという教訓である。

オブジェクト指向は継承で多態するプログラミング

オブジェクト指向って継承による多態があるからこそなんだけど、継承が非推奨になって以降に雰囲気でオブジェクト指向を知った人には、継承はオプションでカプセル化だけでオブジェクト指向って言ってしまいがちに思います。 実際はカプセル化はオブジェクト指向固有じゃなくて、クラスでカプセル化を実現してるだけです。

昔は「継承・カプセル化・ポリモーフィズム」がオブジェクト指向の三原則みたいな言い方されてたな。

30分でわかるシステム運用アンチパターン / Operations Anti Patterns in 30 minutes

NEXT