この記事はPHPStan開発者のOndřej Mirtesによって2024年5月13日にPHPStan Blogに書かれた記事を翻訳したものです。 phpstan.org エラー識別子を備えたPHPStan 1.11、PHPStan Proの再始動など このリリースは一年にわたって取り組んできました。それは一年何もリリースしてこなかったということではありません。PHPStan 1.11の開発に着手してからも私は並行して1.10.x系の作業を継続し、2023年4月から2024年の間に54ものリリースを世に送り出しましたが、私は今年始めのある時期に「もう十分だ！(enough!)」と叫びました。そして、1.11の素晴らしい改善がゴールテープを切って世界に出ることを止められませんでした。 エラー識別子 (Error Identifiers) エラー識別子を追加しようと決めたとき、それが大変な作業

オルト @oooooooorrt 友人から教えて貰った名大消化器外科作成の名古屋飯ガイドのクオリティが高過ぎて笑った。外科学会に合わせて1回限りになるのもなんなので、勝手ながら有効活用しよう jp.jssoc.or.jp/jss124/kodelin… 2024-04-10 16:48:48

# 参考資料 - https://speakerdeck.com/pokotyamu/furikaeri-2024-95ceb97e-d587-4c4b-a4ec-5e52672644f6 - https://www.1101.com/umeda_iwata/ - https://speakerdeck.com/soudai/release-small

Unleash feature management is built with large enterprises in mind so you don't have to build it yourself. We are open source, private, secure, and ready for the most complex setups out of the box.

IT業界で10年以上過ごしている中で、凄いと思う人達にたくさん出会ってきました。最初はとくに新卒で入社した会社の先輩方が中心でした。ここでいう凄さとは何かというと「仕事を片づけるのが早い」とか「成果物の完成度が高い」などです。当時、こんなふうに自分もなってみたいという思いが強くて必至で真似しようと試行錯誤したのですが、全然うまくいきませんでした。ありていにいえば、表面上の凄さだけを見ていたことが失敗の原因だったかと思っています。早く仕事を片づけようと焦り、結果完成度も下がり…と、さんざんでした。 その後はアプローチを変えて、彼らの日常の何気ない振る舞いなどを観察することにしました。すると、彼らのうちの多くの凄さの源泉は驚異的に頭の回転が速いとか、ほかの誰もが持っていない異能力を持っていたりするわけではなく、世間で当たり前と言われていることを息をするようにやっていることだとわかりました。たと

こんにちは、はじめまして。さくらインターネット株式会社の長野雅広（@kazeburo）です。Webの業界に入ったのは学生だった2000年頃で、キャリアは20年以上になります。おそらくこの業界でも長い方ではないでしょうか。20年の間にmixiやlivedoor、メルカリといった企業で働く機会を得て、どの職場でもサービスの裏側にあるインフラや、Webアプリケーションの運用を支える仕事、今ではSREと呼ばれるような業務に携わってきました。 そして今年の1月から、さくらインターネットにてクラウドを中心にサービスの開発を行っています。つまり、インフラやクラウドを利用して一般のお客様向けにサービスを作るという仕事から、クラウドを作ることを仕事にする、という選択をしました。 この記事では、どのような経験からSREとして働くようになったのか、また現職に至る選択をした経緯について語りたいと思います。加えて、

Amazon Web Services ブログ AWS Black Belt コンテナシリーズのあるきかた 2021年10月版 みなさん、こんにちは。ソリューションアーキテクト、コンテナスペシャリストの荒木です。 AWS Black Belt オンラインセミナーのオンデマンドビデオ化に伴って、コンテナサービスシリーズは6月からリニューアルしました。ひとつのビデオあたりのトピックを小さく絞ってお届けしています。 その結果、今日までの3ヶ月で18の コンテナに関するAWS Black Belt オンラインセミナーをお届けしました。他にも本 Blog を通じて AWS でのコンテナに関する数多くのアップデートをお届けしています。 アプリケーションエンジニアの方や、すでに AWS でのコンテナを活用されている技術者の方はもちろん、コンテナに興味のある多くの方に活用いただきました。そんな方々から、も

お疲れ様です、2週間前に思いついた自作キーボードがさっき完成したSREの西田(k.bigwheel)です。 初めて自分で設計したキーボードが完成！名前はuni48にしました🌚 #自作キーボード pic.twitter.com/wFxz6DoVvn— k.bigwheel⌨️🦀🖊️ SREエンジニア@Speee株式会社 (@k_bigwheel) 2020年12月29日 僕がSRE(Site Reliability Engineer)という職種を知ったのは一年前のSpeeeの採用面接の中でした。SREになったのも入社のときからなのでやっと1年経ったばかりですね〜。 この1年のSREとしての自分を振り返ると、元バックエンド屋・インフラ屋としての経験もあって技術選定やアーキテクチャ的な面での大きな失敗は幸いにしてありませんでした。 発生した失敗もすべて想定の範囲内でその面ではよく価値を発揮

Talked at CloudNative Days Spring 2021 Online #CNDO2021. https://event.cloudnativedays.jp/cndo2021/talks/801

ssmjp ssmonline #8 "第三回はたのさん祭 オンライン"( https://ssmjp.connpass.com/event/206074/ )での発表資料です。 (運用設計ラボ合同会社 波田野裕一)

はじめに one visa というスタートアップで働いています。 この3月で働き始めて1年が経過したので、これまで学んだ考え方やスタンスを書いてみることにしました。 ※ かなりエモいエントリーになっており、技術的な話はほぼ出てきません。 ※ かなり長く、まとまりもないです。先に謝っておきます。すみません。 2017年12月に、いまの会社の代表に声をかけてもらい、当時働いていた会社に辞めると伝え、 2018年3月にエンジニアが自分だけという状況の one visa に入社しました。 辞める際に、当時お世話になっていた先輩から 「理想と粘りを持って、挑戦し続けたやつだけが成功する」 という言葉をいただきました。いまだによく思い出して、やってやろう！と勇気をもらっています。 スタートアップでの初めての仕事 前置きとして、入社当時の組織環境は、 主に、業務委託の方がメインとなり、プロダクトがリリー

元ネタ: モッククラス、下から見るか？横から見るか？ モッククラスを使うべきか否か、というネタを拾ったので書いてみます。これまでにモックについて殆ど書いてないことに気づいて驚きつつ。 Short Answer 「モックに何をさせたいの？」 質問に質問で返すなという感じですが、モックに何をさせたいか答えてみれば、モックを使うべきか否かはだいたい決まるよなーと思うのです。 モックは道具で、使うことで何かを改善するものです。 「このことをテストしたいから、モックをこう使う。」という文脈なく使用すると、無用な複雑性を作り込むことになります。 モックの使用は負債なので、十二分に利益を見込める場合にのみ使用するものだと思っています。 これはモックに限った話ではなく、何かを便利にするために道具を追加する際は必ず付いて回るトレードオフです。 Short Answer 露払い 使うべきか否か どちらでも差が

既存のユーザーが望んでいる事も、やっている事も根本的に間違っている場合、いくらユーザー調査しても正解は見つからない

PHPカンファレンス沖縄2019でLTをしてきました。 togetter.com speakerdeck.com LTの内容はミューテーションテストの基礎的な概要を紹介するといったものだったのですが、5分という時間の制約上伝えられなかったことがたくさんあるので、この記事で補足を兼ねて解説しなおしたいと思います。 ※この記事はあくまで僕の解釈です。一般的な解釈と異なる記述がある可能性があります。 ミューテーションテストとは ミューテーションテストとは、我々が実装したアプリケーションコードの一部を書き換え、書き換えたコードに対してテストを再度実行することでテストの品質を測ろうというものです。 簡単に表現すると「アプリケーションコードに変更が加わったのに、既存のテストがパスするのはおかしいんじゃないか？」という視点で品質を評価するということだと思います。要するにテストコードに対するテストですね。

こんにちは、サーバーサイドやっております 金城 (@o0h_)です。 なんとな〜〜〜くKindleのライブラリを見ていたら、スキエンティアがあって「とても美しくて良い話だなぁ。。。」と思った次第です。 スキエンティア (ビッグコミックススペシャル) 作者: 戸田誠二出版社/メーカー: 小学館発売日: 2014/06/16メディア: Kindle版この商品を含むブログを見る たまに読み返したいな。 さて、掲題のとおりですが、以前にママリのマスプロモーションを実施した際の負荷対策として作成した機構をプラグインとして公開しました。 ・・・という書き出しで以前に書いたのが、CakePHP2.x用のMaster/Replica接続管理プラグインです。 tech.connehito.com それから暫く経ちましたが、この度CakePHP3用の同様のプラグインを公開しました。 packagist.org

入った会社はWebサービスをやっていた。アクセスカウンターとかレンタル掲示板みたいな、そういうプリミティブな感じのウェッブ。今でも化石みたいに残っているとこがあるよね。teacupとか。もうないか。 当時はそういうことをしている会社をASP（Application Service Provider)と呼んでいて、「うちはASP事業やってるんです」と言うと通りが良かった。 名刺代わりっていうのかな、何が出来るのか、うちはこんなに技術力あります、ってのをさ、運営しているWebサービスで表現するわけ。同業者が集まったらさ、世間話している風で、自分とこのサービス自慢しまくるんだよね。なんかこう、いやあ負荷高くて、この前もサーバー落ちてぇとか、うちのユーザーは中学生が多いんでぇとか、今で言うマウントの取り合いだよね。どこも流行ってないからさ、意味のわからないとこで競ってるんだよ。 プログラマ的にはA

4月に(2019.04.16) RDS のメトリックスについて拡張がアナウンスされましたが、私がメトリックスをどのような観点で見ているかについて思いつくままに書き出してみました。参考になれば幸いです。 なお、ここに書き出している見解は個人のものであり所属している組織とは異なります。 主に MySQL データベースを念頭に書き出していきますが、ディスク IO 等は他のデータベースにもおおむね妥当すると思います。 項目は RDS のマニュアル を参考にしています。 それではメトリックスのグループ毎に見ていきたいと思います。 General ここで性能の観点から注目したいメトリックスは、numVCPUs です。cpuUtilization や loadAverageMinute などのグループを検討するときに参考にする。 cpuUtilization 各メトリックスは一定間隔、公表はされていませ