ISUCON13 イベントレポート : ISUCON公式Blog
こんにちは、ISUCONの運営を担当している櫛井です。 ISUCONとはLINEヤフー株式会社が運営窓口となって開催している、お題となるWebサービスを決められたレギュレーションの中で限界まで高速化を図るチューニングバトルです。過去の実績も所属している会社も全く関係ない、結果が全てのガチンコバトルです。 2023年11月25日(土)にガーデンテラス紀尾井町にあるOpen Collaboration Hub「LODGE」にて、運営と一部の選手が集まりISUCON13を開催しました。会場の様子を含め、レポートをお届けしたいと思います。 関連エントリ ISUCON13開催決定！今年は本選のみ開催！＆参加チームとメンバーリスト #isucon : ISUCON公式BlogISUCON13 関連エントリまとめ : ISUCON公式Blog ISUCON13まとめ - Togetter 会場では運営用
Remix の SPA モード
Remix の SPA モード 2024.01.14 Remix は React のフルスタックフレームワークで、Web 標準に基づいた API で構築されていることが特徴です。Node.js のようなサーバーサイドの JavaScript 環境で動作することを前提としています。しかし、現実の世界ではサーバーを用意せずに、静的なファイルをホスティングするだけの環境で Web アプリケーションを構築することが有効な場合も多くあります。このような需要を満たすために、Remix v2.5.0 から実験的に SPA モードが導入されました。 Remix は React のフルスタックフレームワークで、Web 標準に基づいて構築されていることが特徴です。例えばデータのミューテーションはクライアントからサーバーの API をコールするのではなく、HTML のフォームを使って行うといます。また Resp
2023年も開発合宿を開催しました - freee Developers Hub
こんにちは、関西拠点にて freee販売の開発を行っております、bucyou (ぶちょー) です。2023年も freee Developers Hub をご覧いただきありがとうございました。2024年も引き続き freee での技術的な知見や、カンファレンスレポートをお送りしてまいりますので何ぞとよろしくお願いいたします。 さて、昨年は Advent Calendar の真っ只中でお知らせ出来ていなかった、2023年の開発合宿についてのご報告です。 過去の開発合宿の記事一覧です。 2022年も開発合宿を開催しました！ - freee Developers Hub 2021年も開発合宿を開催しました - freee Developers Hub 2020年も開発合宿を開催しました - freee Developers Hub 2019 年も開発合宿を行いました - freee Develo
TerraformフォークとなるOpenTofu 1.6.0を、Provider側の気持ちになりながら試してみた - kmuto’s blog
3行 現時点ではOpenTofu 1.6.0はユーザー体験としてはほぼTerraform 1.6なので、コマンドがterraform→tofuになった以外はユーザー側で感じる変化はなさそう（設定ファイルやstateファイルなどもTerraformそのまま）。Mackerel Providerも動く。 Provider側としては、すでに登録されているProviderであれば、当面は何もしなくてもGitHubリリースしたものがOpenTofuレジストリに最新反映される模様（GPG署名している場合は公開鍵をレジストリにサブミットする必要あり）。 今の時点では問題ないと言っても、OpenTofu/Terraformの乖離が進んで互換性が失われると、Providerは別リポジトリを用意する必要がありそう or Terraform/OpenTofuどちらかを諦めることになりそう。 3行 背景 ユーザー
設計とはどういう行為か、AIで設計を自動化できるか？ | タイム・コンサルタントの日誌から
2月の中旬、まだ大勢の人の集まる会合が可能だった頃（なんだか遠い昔のようだが）、「日本学術振興会 プロセスシステム工学第143委員会」（通称「PSE143委員会」）という場に招かれ、講演をさせていただいた。会合全体のテーマは「新しい設計手法・視点」で、わたしは『システム設計は果たして工学たりうるか？』と題するお話をした。 設計とは何か、という問題について、最近あれこれの角度から考えてみている。わたし自身はエンジニアリング会社でずっと働いており、とくに駆け出しの頃は、設計部門でキャリアを積んだ。今は設計の現場から離れてしまったが、今でも設計の良し悪しこそ、その後の仕事の質や利益を、大きく左右すると信じている。そして、プロジェクト・マネジメントの分野に設計論が欠けていることが問題だ、とは以前も書いたとおりだ。 では、ひるがえって、設計とはどういう行為なのか、設計の質とは何が決めるのか、そして昨
「頭がいい人」で終わらせない思考様式の種類の話 - 満足せる豚。眠たげなポチ。
さて、ここは自分のブログなので自分語りであれなんであれ、好きなことを書いていいのだ。なんという自由。自由は素晴らしい。その自由の前にはこれが株式会社エス・エム・エス Advent Calendar の一部 (12⁄18 の回) であることなど些細なことである。 2024年を迎えて2月になると、今の会社へ入社をして10年目に突入する。これまで転職が多く、長く同じところにいるイメージが少ないからだろうか、「なぜ今の会社にいるのか・続けられるのか」という質問を度々受ける。プライベートで会った知人にも聞かれるし、カジュアル面談のような場でも聞かれる。 決まって答えているのは「上司に不満がない状態でいられるから。そして、その行き着く先である経営に不満がない状態でいられるから」である (本題ではないので説明はしない。気になる人は直接聞いてください) のだが、もう少しその内訳を考えてみた。で、その中で思
AWS リージョンの短いエイリアスとしての空港コード - Qiita
※ (?) は AWS による資料に記載がなく、筆者予想のもの 急いでない人向け AWS を日々使い倒している諸姉諸兄におかれましては、全リージョン名を暗記していることは当然かと思います。 リージョンとアベイラビリティーゾーン - Amazon Elastic Compute Cloud しかし、 ap-northeast-1 や us-west-2 というのは何かの名前（例えば、マルチリージョン構成におけるインスタンスや ELB の名称）の一部にリージョン識別子として入れるにはどうにも長いと思いませんか？私は思います。 そこで空港コードです。正確には IATA 空港コード（3レターコード）です。 唐突に何言ってんだという感じですが、実は AWS 内部で符牒として使われているようなのです。 公式のドキュメントに記載はありませんが、 aws iad pdx などで検索してみると AWS 発の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
第5回：エンジニアド・デザイン──一点突破から考える工学的プローチ