3. 副作用 冪等、安全、キャッシャブルのセクションに入る前に、まず「副作用」について解説します。 2014 年 6 月に廃止された RFC-2616 の「9.1 安全と冪等メソッド」のセクション では、「副作用（side effects）」という表現が使用されてきましたが、多くの方は、この「副作用」のことを、「リソースの状態の変化」と解釈されてきたことと思います。[ 1 ] 特に関数型プログラミングにおいては頻出する表現ですが、ソフトウェア工学的にも コンピューターの論理的な状態を変化させ、以降の結果に影響を与えること [ 2 ] とされています。 しかし、HTTP の「冪等と安全」の解釈の混乱を招いてきた要因 [ 3 ] の一つのは、この「副作用」の表現方法が適切ではなかった、ということではないでしょうか。 以下では、その理由について解説しますが、その必要のない方はこのセクションはスキ

はじめに この記事は、本番環境などでやらかしちゃった人 Advent Calendar 2023の11日目です。 どうも、@_tinojiと申します。実に4年ぶりにアドベントカレンダーに参加しました。 正規表現で1文字消し忘れて、なんぴとたりともサービスにログインできない状態にしてしまったという話をします。正規表現にはまじで気をつけましょうという教訓になれば・・・ 犠牲となったログイン画面 とあるtoBなWebサービスを開発していたときの話です。法人のユーザーが使う管理画面的なイメージです。 当然ログイン機能があって、至って普通なログインなのですが1つだけ特徴がありまして、ログイン画面のURLをアカウントごとに変えています。https://example.com/<uuid>/loginみたいな感じですね。 あまり見ない形式ではありつつも、個別のUUIDを特定されない限りログイン画面に対し

やりたいこと まずはHSP3の布教を一つまみ... 筆者は中学生の時にHSP3とともに育ちました。 HSP3は子供心を上手にくすぐったすごい言語です。 子供向け言語というと、「Scratch」のようなブロック型言語が思い浮かびますが、HSP3はゴリゴリのスクリプトベースのコンパイル式言語です。文法はBASICと類似しています。 （解答のみ提出の時代の）情報オリンピックもHSP3で解いていました。 さあ、これの何がすごいのでしょうか？ 何よりも、 自分のスクリプトがグラフィカルに命宿る ところであると考えています。 これが空文字列のスクリプトを「実行」した結果です。 「実行結果」となるウィンドウが現れます。 これがハロワです こうやっていじることができます。 HSP3はWindows APIの操作を十分に簡略化したことが特徴です。（そのため、MacOSは使えない） 中3の僕はC++でウィンド

はじめに find コマンドの使い方は、ざっくり調べただけではよくわからんとなりますが、見逃しがちなルールを知れば簡単に理解できます。find コマンドに限りませんが使い方を調べるのが面倒だからと曖昧な理解で使うと逆にもっと分からなくなって時間がかかります。急がば回れ、理解して正しく使ったほうがシンプルで楽で簡単です。この記事では find コマンドの使い方を理解するために必要なルールと使い方の実践的な知識をまとめました。 Q&A（？）: -type や -perm の説明はしないの？ ⇒ それらはドキュメントを読むか検索すればすぐにわかることで難しいポイントではありません。重要なのは基本のルールを理解することです。 関連記事 POSIX 準拠のシェルスクリプトでは find | xargs よりも find -exec {} + を使うべき！ 移植性の話はこちら ⇒ findコマンドのオ

Stageを複数定義している状態で、エラー発生後のStageも実行する方法のメモ。 検証バージョン Jenkins 2.222.1 エラーが発生したStageでJobが終了する書き方 pipeline { agent any stages { stage('Test AP1') { steps { echo "test ap 1" } } stage('Test AP2') { steps { echo "test ap 2" } } stage('Test AP3') { steps { echo "test ap 3" } } } } pipeline { agent any stages { stage('Test AP1') { steps { catchError { echo "test ap 1" } } } stage('Test AP2') { steps { catch

3大クラウド(AWS,Azure,GCP)をそれぞれプロダクションで実運用した感想(その1 シェア、将来性)AWSAzureGoogleCloud 3大クラウド(AWS,Azure,GCP)をプロダクションで実運用した感想(その1 シェア、将来性) はじめに 今まで私がエンジニアとして10年以上仕事をしてきた過程で、利用されているクラウドインフラ基盤を転職要件に含めていなかったことも相まって、AWS(Amazon Web Services),Azure(Microsoft Azure),GCP(Google Cloud Platform)という3大クラウドのクラウド基盤で、サービスの立ち上げから運用まで関与することができました。 各々のクラウド基盤に関して掘り下げられていることはあっても、エンジニア/SREの視点から俯瞰して述べられていることはあんまり無いので私が実務レベルで各々のサービス

TLDR AWSで2022年の1月から9月までのアップデートが多数ありました。私（と、何人かのサポーター）が考えた、この期間内の打破されたアンチパターンを紹介します。32項目ありました！ アンチパターンって何よ？ 「AWSでこうしたい」という思いからAWSを使っていく方は多いはずです。 そのなかで、数多くのAWS使いこなしの工夫が生まれ、成功例が生まれていきました。AWSのサービスとして提供されていないことを工夫でなんとかした、そんな成功例たち。それが「秘伝のタレ」となり、「さわってはいけないもの」、あるいは「ロストテクノロジー」として、封をしたパターンとなっていないでしょうか？ 動作やプロセス、構造について、当初は妥当であったのに、最終的に悪い結果が繰り返されるパターンであり、リファクタリングするための方法が存在するパターンこそがアンチパターンです。サービスアップデートされれば、いままで

はじめに そりゃまあ 30 年も経てば古くなりますよ。「入門UNIXシェルプログラミング」は今もシェルスクリプトに関するオススメの本として名前が挙がる名著です。しかしこの本は古い本です。POSIX でシェルが標準化される以前の本で、内容から判断するとおそらく 1990 年ぐらいの常識に基づいて書かれています。 古いから参考にならないと言うつもりはありません。しかしどれだけ優れた本でも時間の流れには勝てません。良書であると思っているからこそ、古くなってしまった内容は訂正する必要があると考えています。なおシェルスクリプトに関する古い本はこれだけではありません。オライリーから出版されている本も古い本ばかりです。いつ頃に（原書が）書かれた本なのかを確認した方が良いでしょう。 ということでレビューというていで、古くなってしまった内容の訂正を行いたいと思います。新しく「入門UNIXシェルプログラミング

はじめに SQLite は世界で一番使われている　だから世界で一番凄いものに決まってるだろ SQLite は世界で最も使われている RDBMS です。名前に反して（？）おもちゃの RDBMS ではありません。元ネタと同じで 一番普及しているからと言って必ずしも一番凄いものであるとは限りませんが、普及しているのであればそこには何かしらの理由があるはずです。その理由を調べないことには、凄いか凄くないかの結論は出せないので SQLite のなにがそんなに凄いのかを調査しました。 2022/04/01 続編記事↓を書きました。 注意 この記事は「なぜシェルスクリプトで高度なデータ管理にSQLiteを使うべきなのか？ ～ UNIX/POSIXコマンドの欠点をSQLで解決する」の補足記事して書いたものです。ところどころ不自然にシェルスクリプトや Unix コマンドの話が登場するのはそのためです。基本的

TL;DR 最近の設計志向はイベント駆動がかなり中心になっている とくにDDD界隈がここまでイベント駆動一本槍だとは思わなかった ストーリーを出発点にイベント駆動で設計を組み立てる「イベントストーミング」がかなり多くの場所で事例として取り上げられている はじめに 最近、洋書や動画の講演資料などいくつか海外の情報源に当たることがおおくなり、その中で「結構日本でやられている取り組みとちがうなー」と考えることが多く、一旦そのあたりの差分をまとめておこうかと思いました。 ただの出羽守（あるいは鹿鳴館精神）ではなく、一つの潮流としてこんなのがあるってのを記述できればなと思います イベントが設計の基本線となりつつある、、、のか？ まず1つ目に驚いたのが、イベントが設計の中心になっている、そう感じる機会が多かったこと。 ここで言うイベントは、実践ドメイン駆動設計の中でも「ドメインイベント」として実装パタ

はじめに 書籍化 本記事を元に ゲームで学ぶ探索アルゴリズム実践入門～木探索とメタヒューリスティクス という書籍を出版することになりました！ 本記事を読んで気になっていただけたらご購入をご検討いただけるとうれしいです！ この記事で得られる技術 ゲームルールに適した探索アルゴリズムを選択する ゲーム木探索をするのに適したクラス設計 主要なゲーム木探索アルゴリズムの実装 この記事の特徴 汎用アルゴリズムの実装例による他ゲームへの応用力と、実際に動作可能なサンプルコードによる具体的実装イメージの両視点でわかりやすくした（片方しか記載のない記事が多い） サンプルコード付き日本語記事がほぼないDUCTを解説している サンプルコードは印のついたメソッドを実装したクラスさえ書けば、アルゴリズム部分を変更せずそのまま他のゲームで動作可能になっている この記事で扱わない関連技術 探索の高速化 多様性の確保

はじめに どんなソフトウェアエンジニアも拡張しやすくメンテナンスしやすいソフトウェアを作りたいと思っているはずです。また、どんなプロダクトマネージャも同様に拡張しやすいシンプルな要求を作りたいと考えているはずです。 しかし、将来の不確実性や発展性に対して見通しを立てるのは難しいものです。そのため、開発チームの思いとは裏腹にソフトウェアの複雑性はどんどんと増大していきます。気がついたら技術的負債と呼ばれるような手もつけられない泥団子になってしまうということもしばしばです。誰もが生産性を下げるために機能を追加したいわけではなく、ビジネス価値を提供するために機能を追加したいだけなのにです。 このような状況を避けるためにはどうしたらよいのでしょうか。今回はその一つの手段として、要求には隠れた「意図」があり、それを発見していくことの重要性についてまずはお話しします。さらにわかりやすい要求が持つ仕様の

Webアプリケーション開発についての知見を、自分の経験と知識をベースに整理してみようという試みです。 いわゆるサーバサイドにスコープを絞り、フロントエンドは対象外です。筆者は普段、オブジェクト指向言語で書いているので、本記事でもその前提（Ruby、PHP、Python、Java、Scalaあたりを想定）になっています。 では、本編をどうぞ。 ソフトウェア開発は複雑さとの戦い 『人月の神話』では、ソフトウェアの本質的な困難性について4つの性質をあげている。その中で最初に出てくるのが「複雑性」である。『新人プログラマに知っておいてもらいたい人類がオブジェクト指向を手に入れるまでの軌跡』なんか読んでもらえると、ソフトウェアの複雑性と戦うために、人類が生み出してきた発明の数々が説明されている。 では、複雑さとは何か？もう少し掘り下げて考えてみよう。 複雑さの正体 Webアプリケーションが複雑になる

よく見かけるRepositoryパターンのアンチパターンの紹介と対策です。 Repositoryパターンとは Repositoryパターンとは永続化を隠蔽するためのデザインパターンで、DAO(DataAccessObject)パターンに似ていますが、より高い抽象度でエンティティの操作から永続化ストレージを完全に隠蔽します。 例えばDBコネクションやストレージのパス等はReposiotoryのインターフェースからは隠蔽され、Repositoryのユーザは永続化ストレージが何であるか(例えばMySQLやRedis等)を意識することなく保存や検索の操作を行うことができるようになります。 これによりRepositoryを利用するロジックは業務的な操作に集中できるようになる他、データベースの移行等の永続化層の変更が発生した際にロジックへの影響を切り離すことができるようになります。 // 例) ユーザ

kubernetesでもぷよぷよがしたいので同じ色のPodが4個くっついたらdeleteされるcustom controller「くべくべ」を作ったGokubernetes Kubernetes使ってると、Nodeにえらい数のPodが溜まってくじゃないですか。消したくなりますよね。連鎖してほしいですよね。なりません？なので、4つ同じ色のPodが4個くっついたらdeleteされる、爽快感のあるカオスエンジニアリング用のcustom contollerを作りました。 deleteされるだけでは寂しいので、deleteされていく様子を見るためのkubectl pluginも作りました。合わせて使うとこんな感じになります。 左側の●のひとつひとつがPodです。Nodeが列に対応してます。6Node構成です。各色8個ずつpodを立てていて、右側にreplicasetの増減を置いてみました。 レポジト

この記事は@yugui氏の書いた至高のDockerイメージ生成を求めてに感謝しつつ、記事が投稿された当時には無かったさまざまな事情を組み込んで再度まとめたものである。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメージを互いに配慮することなく柔軟に配備し実行できる 必要のないサービスがコンテナ内で走っていないので、セキュリティの向上に資する イメージの転送が効率的である ベースイメージ部分は一度送ればいちいち再転送する必要がないので、ベースイメージを共有する複数のイメージを効率的に転送できる 標準のレジストリAP

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 委譲チョットデキル人向けの要約 「委譲」や「デリゲート」が指すものはプログラマーによって違うことがある。 少なくとも下記３パターンあって、あまりにも初見殺しすぎるというお話です。 Forwarding（転送）のこと。GoFがDelegationであると誤用して広まった。元は誤用なのにこれが多数派。 JavaScriptなどのプロトタイプベースオブジェクト指向言語などでよく出てくる真のDelegationのこと。Henry Liebermanが定義した。（※JSの場合は暗黙の委譲をよく使っているはず） .NET Frameworkの仕様で

どんな言語なの 独自の系統の文法を持つシステムプログラミング言語のようです。コンパイラのツールスタックはflex, bison, LLVMと定番のツールを使い熟して書かれています。 Blawnの特徴は 型名の記述が一切不要 構文の可読性が高い すべての関数/クラスがC++でいうところのテンプレート関数/クラス コンパイル速度と実行速度が速い メモリが安全 とのこと。 型の記述が不要なのは型推論に因るものですが、型推論を知らない人には何をやってるのか分からないようで、混乱を生んでいますね。 下記の記事なども参考にして下さい。 人でもわかる型推論 型推論に関する最近の話題への雑感 可読性については各自で判断して下さい。 関数/クラスがテンプレートになっているのは少し使ってみたら分かるかと思います。後で触れます。 コンパイル速度と実行速度が速いというのは、コンパイルに関してはあんまり遅くなるよう

※当然ながら、障害発生時はどのグレードでも0bpsになります 「なら専用線選んでおけばいいじゃん」と思うかもしれませんが、費用が圧倒的に違い、同じ帯域なら１段あがるごとに2～10倍ほどになります。たとえば5倍として、ベストエフォート100Mbpsで月額10万円なら、帯域確保は50万円、帯域保証は250万円、専用線は1000万円という差になってしまうでしょう。予算は有限ですから、むやみに高い品質を選んでしまうと帯域がとれないということになります。同じ予算であれば、1Gbpsベストエフォートがよいのか、200Mbps帯域確保がよいのかは場合によって異なるので、適切な選択をするべきです。 そして、ベストエフォートはベストエフォートでも、1Gbpsで100Mbpsしか出ないキャリアもあれば、1Gbpsで900Mbpsくらいを保証しているキャリアもあります。これは概ね値段に比例しますが、つまりベスト

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 経緯と背景 @oukayuka はフリーランスな React 専門のフロントエンドエンジニアです。 いま現在、グロービスでお仕事をしていてふだんは麹町のオフィスに通っているのですが、あるとき社員のみなさんが研修で2日間いなくなり、チームのフロントエンド要員の業務委託2人が取り残される形になりました。 ちょうど暑くなってきて出勤しんどいしいい機会なので、1日だけフルリモートで前々から気になってた Visual Studio Live Share（以降、Live Share）を使ってお仕事してみたいと提案したところ、許可されたのでやってみま