タグ

thaimのブックマーク (1,767)

  • WEBサーバーのレスポンス圧縮でコスト削減 | 外道父の匠

    リクエストヘッダに『Accept-Encoding: gzip』を含む場合、クライアントが「gzip圧縮して返しても大丈夫よ」って言ってるので、サーバー側はレスポンスを返す際に条件を満たしていれば、レスポンス・ボディ部分を圧縮した上で、レスポンス・ヘッダに『Content-Encoding: gzip』を付与して「gzipで圧縮しておいたよ」と返します。 WEBサーバーに限らず、CloudFront といった CDN も同等の機能を持っていて、圧縮メリットがあると判断した場合は有効にしておくとよいでしょう。 圧縮ファイルの供給 – Amazon CloudFront 圧縮の目的 ここはエンジニアとしての話というても、自宅パソコンでも何かしら圧縮機能は使っているでしょうから、説明は不要でしょうが…… メインは容量の縮小、次いで複数データを1ファイルにまとめる、ってところで今回は容量縮小を”手

    WEBサーバーのレスポンス圧縮でコスト削減 | 外道父の匠
    thaim
    thaim 2024/05/03
  • タイムスタンプの精度を落とすときは切り捨てろ - methaneのブログ

    とあるプロジェクトでナノ秒からミリ秒への変換で四捨五入してきた人がいて、時刻を扱うときは保存精度未満は切り捨てるべきというのが常識になっていないなーと思ったので。 2023-10-01 を、何年か表示する時に、2024年に丸める人はいないだろう。 13:45 が何時か表示する時も、13時と表示するだろう。(口頭で何時?と聞かれたら14時と答えるかもしれないけれど) つまり、ある精度で表した時刻は、実際には次のような半開区間を示しているのである。 2023-01-01 00:00:00 <= 2023年 < 2024-01-01 00:00:00 13:45:00.000 <= 13:45 < 13:46:00.000 そして、そう決めたからには一貫して同じように、指定精度未満は切り捨てというルールを維持しなければならない。秒以下は四捨五入で、とかやってはいけないのだ。 一貫しないと何が問題

    タイムスタンプの精度を落とすときは切り捨てろ - methaneのブログ
    thaim
    thaim 2024/04/20
  • 型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog

    SmartHRで届出書類という機能を担当しているプロダクトエンジニアのsato-sと申します。 今日は、以前私が調査にとても苦労したパフォーマンス上の問題の話を紹介したいと思います。 TL;DR PostgreSQLのアップグレードを実施した アップグレード後、今までは問題のなかった特定のクエリの実行に1時間超かかり、DBCPU使用率がピッタリ100%に張り付くようになった 色々調査した結果、PostgreSQL上の型キャストの場所のせいで、良くないクエリプランが選択されることが原因だった 型キャストの場所には気をつけよう PostgreSQLのアップグレードと挫折 SmartHRでは基的にWebアプリケーションのデータベースとしてGoogle CloudのCloudSQLによって提供されるPostgreSQLを利用しています。 私の担当している届出書類機能では、利用中のPostgre

    型キャストの場所のせいで、秒で終わっていたクエリに1時間超かかるようになってしまった話 - SmartHR Tech Blog
  • なぜ我々は GitHub Copilot Enterprise の導入を見送ったのか - 一休.com Developers Blog

    CTO 室の恩田です。 今回は GitHub Copilot Enterprise を評価してみて、現時点ではまだ採用しないことを決めた、というお話をご紹介したいと思います。 きっかけ とあるエンジニアSlack で自身の times チャネルに時雨堂さんの GitHub Copilot Enterprise のススメという記事を投稿したことが発端でした。特に感想はなく URL に 👀 だけが添えられていたので、後で見るぐらいのメモだったんだと思います。 それを見かけた別のエンジニア技術雑談チャネルにその投稿を共有して、これは凄そうと話題を向けたところ、CTO の「評価してみる?」の一言で、有志が集って評価プロジェクトが始まりました。 雑談チャネルできっかけとなる投稿が共有されてから、30分足らずの出来事でした(笑)。 この話題が出たのは金曜日でしたが、週明け早々に稟議を終え、火曜

    なぜ我々は GitHub Copilot Enterprise の導入を見送ったのか - 一休.com Developers Blog
    thaim
    thaim 2024/04/15
    気になっていたけど自分たちで検証するところまではできなかった。短時間で検証・判断できるのすばらしい。
  • 「UIの色を変えただけで大量のクレームを頂戴してしまった話」の何が問題か?|moutend

    結論話題の記事「UIの色を変えただけで大量のクレームを頂戴してしまった話」を読みました。ユーザーを軽視した内容に驚愕したのですが、それよりも記事が批判されている原因を理解できていない様子の方が存在することに衝撃を受けました。 現職のデザイナーあるいはデザイナーを目指している方々にお伝えしたいことは以下の3点です。 具体的な不都合を訴える問い合わせは無益なクレームではなく有益なフィードバックです。プロダクトの価値向上につながる貴重な意見ですから無視するべきではありません。 時間の経過でユーザーがUIに慣れることはありません。問い合わせをしても無駄だと学習して離脱したパターンを疑いましょう。受け入れられる場合も含めて画面の変更はユーザーに負担を強いているのだと自覚してください。 色覚特性や色とコントラストについて学びましょう。色だけで情報を伝えるデザインはアンチパターンですから避けてください。

    「UIの色を変えただけで大量のクレームを頂戴してしまった話」の何が問題か?|moutend
    thaim
    thaim 2024/03/08
  • ガチでnoshを2年間食い続けた俺の夕食戦争|ジスロマック

    「nosh」というサービスがある。 いわゆる「宅配弁当」のサービスであり、冷凍された弁当が定期的に届く今流行りのシステムである。 ネット上の広告ではこれでもかと「定期的にご飯が届くなんて素晴らしい!」「チンするだけで美味しいお弁当がべられて最高!」などというプロモーションが打たれているので、誰でも一度は見たことがあるのではないだろうか。だが、個人的にあのPR漫画はほぼ嘘じゃないかと思っている。 私はnoshを2年使い続ける中で、もはや「戦争」とも言えるほどのを洗う戦いを繰り広げてきた。チンするだけで美味しい弁当がべられる。まぁ、嘘ではない。健康にいい事が定期的に届く。あながち嘘ではない。ただしこれは、「noshを使いこなすことができれば」の話である。 人は、noshで失敗すると心が死ぬ。 これは、私がnoshと繰り広げた「戦い」の歴史。PRでもなんでもなく、2年間に渡ってひたす

    ガチでnoshを2年間食い続けた俺の夕食戦争|ジスロマック
    thaim
    thaim 2024/03/04
    全部わかる。自分は昼食に採用しているからか、心を殺さずによい付き合いができている。それでもデッキ構築・維持が難しいよ。
  • 新規プロダクトの開発に Nuxt 3 を採用して良かったこと - ANDPAD Tech Blog

    ANDPADフロントエンドエンジニアの小泉です。 昨年の夏頃、担当したプロダクトで新規リポジトリでの開発を立ち上げる機会があり、Nuxt 3 を用いて構築を行いました。 アップデートではなく新規で Nuxt 3 サイトを構築するのは業務としては初めての経験だったのですが、Vue 3・Nuxt 3 の様々な機能によって、型安全な状態を保ったまま快適な開発を進められ、かつ3ページの全体実装を約7営業日で形にすることができました。 この記事では、「いま新規サービスのゼロからの立ち上げにNuxt 3を選択するとどんな嬉しいポイントがあるのか」という実例をご紹介できればと思います。 担当したプロダクトについて ANDPAD資料承認 | 製品のご紹介 2023年10月にリリースされた「ANDPAD資料承認」という、資料の申請・承認を一元管理する機能のフロントエンド開発を担当しました。 ただし、紹介サイ

    新規プロダクトの開発に Nuxt 3 を採用して良かったこと - ANDPAD Tech Blog
    thaim
    thaim 2024/03/03
  • KeyTrap (CVE-2023-50387)を検証してみた - knqyf263's blog

    DNS趣味でやっているだけですし有識者のレビューを経ているわけでもないので誤りを含むかもしれませんが、DNS界隈には優しい人しかいないのできっと丁寧に指摘してくれるはずです。 追記:めちゃくちゃ丁寧にレビューしていただいたので修正いたしました。森下さんほどの方に細かく見ていただいて恐れ多いです...(学生時代に某幅広合宿で森下さんの発表を見てDNSセキュリティに興味を持った) 4万文字を超える大作、おつかれさまです。わかりやすく書けていると思いました。 ざっと読んで、コメントしてみました。ご参考まで。https://t.co/bVj5WeFHQr https://t.co/ku5NOx6ua8— Yasuhiro Morishita (@OrangeMorishita) 2024年2月19日 要約 背景 詳細 DNSSECとは? DNSSECの可用性 鍵タグの衝突 攻撃内容 SigJam

    KeyTrap (CVE-2023-50387)を検証してみた - knqyf263's blog
  • パスキー利用状況レポート @ マネーフォワード ID (vol.4, Feb 2024) - Money Forward Developers Blog

    English version of this article is available here. はじめに こんにちは、マネーフォワード ID 開発チームの @nov です。 さて、みなさま、バレンタインデーいかがお過ごしでしょうか? おおよそ四半期毎のペースで公開している、パスキー利用状況レポートの時期がやってきました。 この3ヶ月、マネーフォワード ID ではパスキー周りで以下のような変化がありました。 パスキーでのログイン数が Google Sign-in を超えて、パスワードに次ぐ第二位のポジションへ ログイン直後以外のコンテキストでのパスキープロモーションを開始 パスキープロモーションページ内での文言変更 メールアドレスを持たないユーザーへのパスキーサポート それぞれの詳細については追々見ていくとして、まずは毎回恒例のこのコーナーから行きましょう。 パスキー登録状況 @ 20

    パスキー利用状況レポート @ マネーフォワード ID (vol.4, Feb 2024) - Money Forward Developers Blog
    thaim
    thaim 2024/02/18
  • 新型Snowballは凄くタフだった! | CyberAgent Developers Blog

    写真と比較表*3の通り、新型Snowballと旧型Snowballのサイズは同じです。インターフェース部分に変更がありますが、正直そこまで見た目の違いは分からないと思います。 大きさも変わらないため、今まで旧型Snowballを利用されていた方は設置に困らないはずです。設置担当者からは、電源を入れたときのファンの音が大きくなり、よりスムーズに排気が出来るようになったのでは、とのコメントを頂いています。 旧型Snowballでもファンの主張が大きかったですが、新型Snowballはもっとヤバい感じです。 性能はCPUは2.5倍以上、メモリは5倍以上、ストレージは2.5倍以上かつSSDに変更になっており、スペックが大幅に向上している事がわかりますね。 改善された点 旧型Snowballの3倍近くのデータ保存領域 Snowballは、発注後ベストエフォートでデータセンターに到着するため、当日急に

    新型Snowballは凄くタフだった! | CyberAgent Developers Blog
    thaim
    thaim 2024/02/18
  • デプロイ対象環境ごとに別々のSlackチャンネルに通知するGitHub Actionsの実装例 - KAYAC engineers' blog

    SREチームの長田です。 SRE関連の記事としては今年最初の記事になります。 今年も定期的にSREチームメンバーによる記事を投稿していく予定です。 よろしくお願いします。 さて、今回はGitHub Actionsのはなしです。 TL;DR デプロイを実行するGitHub Actionsの実行状況を デプロイ対象環境ごとに別々のSlackチャンネルに通知する場合の実装例として、 「slackapi/slack-github-actionで通知をつくりこむ」 「Actions Workflowを分ける」 「Actions Workflow実行の入り口を分ける」 の3つを紹介します。 背景 カヤックでは「まちのコイン」という地域通貨サービスを開発・運用しています。 coin.machino.co まちのコインの開発・運用チームの、特にサーバーサイドに関しては、 アプリケーションやインフラ構成の変

    デプロイ対象環境ごとに別々のSlackチャンネルに通知するGitHub Actionsの実装例 - KAYAC engineers' blog
  • dbus-sendを利用して既存のFirefoxプロセスでサイトを開く方法 - 2024-02-07 - ククログ

    Firefoxのプロセスが既に起動している場合、新たにFirefoxを起動しようとすると、既に起動している方のプロセスにてコンテンツが表示されます。 その一方で、同一のプロファイルを指定してFirefoxを追加で起動しようと試みた場合など、そのままでは既に起動しているプロセスにてコンテンツを開かせることができない場合もあります。 すでにFirefoxが起動中だが、応答しない旨のエラーメッセージが表示され、Firefoxを終了し別プロファイルを利用するようにうながされます。 このような挙動になるのは、プロファイルを保護するためにロックがかけられている状態になっているためです。 今回は、GNU/Linux環境下においてそのような場合でも既存のプロセスでタブを開けるように、dbus-sendをどのように利用するとよいかを説明します。 FirefoxのDBusインターフェースについて Firefo

    dbus-sendを利用して既存のFirefoxプロセスでサイトを開く方法 - 2024-02-07 - ククログ
  • What it was like working for GitLab

    I joined GitLab in October 2015, and left in December 2021 after working there for a little more than six years. While I previously wrote about leaving GitLab to work on Inko, I never discussed what it was like working for GitLab between 2015 and 2021. There are two reasons for this: I was suffering from burnout, and didn't have the energy to revisit the last six years of my life (at that time)I w

    thaim
    thaim 2024/02/11
  • リソース配分の前に、リソース獲得。ポートフォリオマネジメントの前に、PMF。制度作りの前に、カルチャー作り|福島良典 | LayerX

    リソース配分の前に、リソース獲得。ポートフォリオマネジメントの前に、PMF。制度作りの前に、カルチャー作り (※社内報の公開です。メモ的に書いてあるので、読みにくい部分があるかもしれません。箇条書き的に書いてあります) リソース配分を決める、ポートフォリオマネジメントをする、社内制度をつくる。 これらは非常に重要な仕事であるし、やったあと非常に達成感が得られる。しかし急成長企業ではこれの前に(あるいは同時に)もっとやらねばいけないことがあることに留意しないといけない。 リソース配分の前に、リソース獲得 ポートフォリオマネジメントの前に、PMF 制度作りの前に、カルチャー作り の3つを取り上げる。 リソース配分の前に、リソース獲得急成長企業における意思決定では常に何かを諦める必要がある。事業機会にたいしてリソースが常に足らない。なのでリソース配分はとても重要な意思決定である。 一方その裏で、

    リソース配分の前に、リソース獲得。ポートフォリオマネジメントの前に、PMF。制度作りの前に、カルチャー作り|福島良典 | LayerX
    thaim
    thaim 2024/02/09
    “制度の前に、カルチャーを作ろう”
  • ビジネスとオープンソースの狭間で 〜 Embulk の場合 (前編)

    2023 年はビジネスとオープンソースの関係が難しくなった年であったように思います。 6 月には、フルタイムの Ruby コミッターとして研究開発を行っていたお二人がクックパッド社の人員削減の影響を受けたことに端を発して、オープンソースに深く関わってきた一部のソフトウェア・エンジニアを中心に、ビジネスとオープンソースの関係について議論がありました。 8 月には HashiCorp 社が自社のオープンソース製品群のライセンスを Business Source License 1.1 (BSL) に変更したことも話題になりました。 また 2023 年は、一年を通して大規模言語モデル (Large Language Models; LLM) が話題になった年でもあり、ビジネスにも大きな影響がありました。 大規模言語モデルとオープンソースの関係に焦点を絞っても、「非オープンソースのライセンスで公開

    ビジネスとオープンソースの狭間で 〜 Embulk の場合 (前編)
  • AWS側の目線から理解する、Google Cloud ロードバランサの世界 - How elegant the tech world is...!

    はじめに お久しぶりです、iselegantです。 今回はAWSアーキテクトの目線から、多様なGoogle Cloud Load Balancingの世界を紹介してみたいと思います。 昨今、担当業務やプロジェクトによってはAWSのみならずGoogle Cloudを活用したり、マルチクラウドとして両方扱うエンジニアの方も多くなってきたのではないでしょうか? 特に、SI企業に所属する人においては、担当プロジェクトや業務、お客様が変われば利用するクラウドサービスも変わる、なんてこともよくあると思います。 私もその道を辿ってきた一人です。 現在ではクラウドサービス間においてもある程度のコモディティ化が進んでおり、ある一つのクラウドサービスに精通すると、他のクラウドサービス利用時におけるメンタルモデルが出来上がり、システムを構築する際に前提の知識や経験が大いに役立つはずです。特にAWSはサービスの幅

    AWS側の目線から理解する、Google Cloud ロードバランサの世界 - How elegant the tech world is...!
    thaim
    thaim 2024/01/15
  • AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠

    これまでもコンテナ関連の記事はそれなりに書いてきましたが、改めて最新事情に合わせて練り直したり見渡してみると、大きなところから小さなところまで選択肢が多すぎると感じました。 コンテナ系アーキテクチャを丸っと他所の構成で真似することって、おそらくほとんどなくて、参考にしつつ自分流に築き上げていくでしょうから、今回は築くにあたってどういう選択肢があるのかにフォーカスした変化系で攻めてみようと思った次第です:-) 目次 今年一発目の長いやつです。半分は学習教材用、半分は道楽なテイストです。 はじめに 基盤 インスタンス or コンテナ ECS or EKS on EC2 or FARGATE X86 or ARM64 ロードバランサー メンテナンス:ALB or ECS Service 共有 or 1環境毎 アクセスログ:ALB or WEBサーバー ECS / EKS デプロイ:Blue/Gr

    AWSコンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠
  • 数年間継続している「作業メモ」の話

    メモを残す習慣 以前、@gorou_178さんが「1日1ファイル、「調べたこと」「やったこと」を日報として残す」という記事を公開していた。 この記事の中に以下のようなくだりがある。 そこでふと思い出したのが元同僚のメモの取り方。 毎日1ファイル作成して、そのファイルにその日にやったこと(事細かくやった作業、実行したコマンドなども)をメモしていた。メモは年単位で残っておりとても驚いたことを覚えている。 この、「元同僚」というのはきっと私のことである。 私はメモを取ることが結構と好きな方で、メモを残すことがわりと習慣化している。 例を挙げると、普段からこういったことをやっている。 Google Keepに「Podcastに出演してほしいゲスト候補」、「勉強会・カンファレンスの登壇履歴」、「来月購入予定の日用品・雑貨」、「自宅周辺の行ったことないラーメン屋」、「読みたい・気になったマンガ」とい

    数年間継続している「作業メモ」の話
    thaim
    thaim 2024/01/10
    emacs+howm+dropboxを利用している。昔は1日1ファイルだったけど、今は1ヶ月1ファイルに落ち着いている。
  • WorkTime < Output < Outcome < Impact - yohhatu's note

    thaim
    thaim 2024/01/02
    確かにインパクトを意識することはあまりなかったな
  • こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba

    最近、毎日のようにEMのいくおさん( @dora_e_m )とTwitterXでわちゃわちゃしてる。彼のポストを見ていると、ガンプラをつくるかビールを飲むかしかしていないように見えるが、それで合っている。 という冗談はおいといて真面目な話をすると、エンジニアとしての僕は彼と仕事ができている今の時間のことを当に貴重な時間だと思っている。とにかく仕事がしやすいし、いろいろな気づきを与えてくれるおかげで、自分自身の成長も感じている。 エンジニアリングマネージャとしての知識が豊富でスキルが高いというのはもちろん、人との接し方や日常的なふるまいもとても尊敬できるものなのだ。 そこで今日は、僕が彼とこの3ヶ月間仕事をしていて、やりやすい・尊敬していると感じていることの中から10個だけ簡単に紹介しようと思う。僕からいくおさんへの日頃の感謝の気持ちをあらためて書いておこうと思っただけとも言う(ふだんから

    こんなエンジニアリングマネージャだから仕事がしやすいんだなぁと思う10個のこと - Mitsuyuki.Shiiba