並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 197件

新着順 人気順

ログの検索結果1 - 40 件 / 197件

  • Mac やめて Linux PC を自作した - IT戦記

    みなさまお元気ですか 暑さも少し落ち着いてきて、ようやく外に出てもいいかなという気になってきました。季節の変わり目体調には気をつけていきたいですね。 実は、一ヶ月くらい前に Linux PC を自作して Mac から移行しました。そのときの考え、その後の感想を残しておきます。 また、学んだことや作業のログを細かく残しておきたいと思います。(どこかの誰かが不安に思ったときに同じ失敗や疑問を経験した人がいて安心してもらえたら嬉しい) Ubuntu のインストール画面 (ベストオープンソースと開発しよう!) 目次 Mac をやめるきっかけ、経緯 Ubuntu に移行して一ヶ月の感想 おまけ1: どのような PC になったか おまけ2: 事前に学んだこと おまけ3: PC の組み立て おまけ4: Ubuntu のセットアップ 加筆/修正 指摘のあった誤字を修正 NVEnc について誤った内容があっ

      Mac やめて Linux PC を自作した - IT戦記
    • 自分がヤバい思想にハマらないか俯瞰する仕組みが欲しい|深津 貴之 (fladdict)

      ネットで色々な記事を読んでると、自分の足元とか現在地がよくわからなくなるので、定期的に現在位置とかをチェックする仕組みが欲しいなぁ…というメモ。 1. チェックしたい思想を定義するまず自己診断したい思想やムーブメントを定義し、図のセンターにおく。 「リベラル」「新自由主義」「フェミニズム」とか抽象レベルでも、「地球温暖化」「中絶法」のような具体的な思索でもよい。 2. 上下左右の極端な思想を定義するその分野の思想の、一番極端なバージョンを定義し、図の上下左右に配置する。 超急進 vs 超保守 画面の左右を超急進(既存制度を根本からぶっ壊すレベルで進めたい)と、超保守(既存制度を1mmを変えたくない、可能なら巻き戻したい)。 規範遵守 vs 規範無視 画面の上下を、規範遵守(法律と倫理を完璧にコンプリートしたプロトコルで執行したい)と、規範無視(目的の達成のためなら、私刑、暴力、破壊行為など

        自分がヤバい思想にハマらないか俯瞰する仕組みが欲しい|深津 貴之 (fladdict)
      • 神奈川県立高校ネット出願システムのGmail到達性問題、改めて深堀りしてみた | DevelopersIO

        神奈川県ネット出願システムのGmailへのメール到達性問題は、不適切なサーバー設定、大量メール送信、DNSミス、バウンスメール処理不備、急激な送信量増加、準備不足、新ドメインの低信頼性が複合的に作用して発生したと推測されます。 2024年1月、神奈川県のネット出願システムでGmailにメールが届かないトラブルが発生しました。 身内が受験するため、出願システムのトラブルに巻き込まれた当事者として原因調査を試みていました。 先日『日経クロステック』より、本件について取材を受ける機会がありました。 取材協力した記事で取り上げられた問題について、さらに深堀り、詳細な分析を行った内容を以下に紹介いたします。 問題の概要 概要 志願者登録時、二次元コード読み取りと空メール送信が必要 "@gmail.com"アドレスへの返信メールが届かない不具合発生 原因 システムのメールサーバ設定が不十分 大量メール

          神奈川県立高校ネット出願システムのGmail到達性問題、改めて深堀りしてみた | DevelopersIO
        • 人生イチ旨かったレストランの話をさせてほしい

          追記 気づいたら伸びてた、ありがたい。 店の名前言った方がいい→これは何人か推測されてる通りKOZO、ありがとうKOZO。 金に糸目をつけない美食か→決してそこまで敷居は高くない。食べログに値段出てたけどソシャゲのガチャ20連と同じ程度なので庶民にも十分手が出る。何に価値を感じるかってあると思うけどこれは本気でいい体験だった。 目的 ステマとかではない。よっしゃ再訪のチャンス!とか思っていたらお店が閉店になっていてショックを受けた。 なんなら親の還暦祝いを絶対そこでしたかったぐらいの勢いだし親が死ぬまでには、いや自分が死ぬまでにもう一度あの店(シェフ)の料理を食べておきたいと思った。 辞めた理由ってのもあるだろうけど正直有名店の半額以下だしコスパ良すぎて儲からないなら倍払っていいまであるからもう一度店出してという、中毒患者の呻きみたいなものだと思ってほしい。 どんな店なの 京都にあるガスト

            人生イチ旨かったレストランの話をさせてほしい
          • Macがスリープ中にバッテリーが爆減りしだしたので解決するためにした事

            経緯 2023年10月ほどに以前から使用していたMacBook Pro(OS sonoma)がスリープ後に再度開くとバッテリーを消費しきってしまう現象が発生した。前日にMacBookを利用後翌日にはMacが電源なしでは操作できない状態となっていたため非常に面倒なため調査を開始 似たような症状は他の知人MacBook Pro(OS Ventura)でも再現していた 対象の人 Mac設定のログイン項目の見直しを行ったが解決できなかった人、あるいは原因と思われるアプリケーションの設定をオフにすることが出来ない人 MacのSMCのリセットなどを行ったが全然解決ができなかった人 他のサイトなどでMacバッテリードレインについて調べたが解決できずにっちもさっちも行かない人 実行環境 MacBook Pro 2020 13-inch プロセッサ 2.3 GHz クアッドコアIntel Core i7 O

              Macがスリープ中にバッテリーが爆減りしだしたので解決するためにした事
            • 「データエンジニアの市場価値」を上げたい。リクルートグループのニジボックスが“有料級のインプット教材”をつくるワケ - はてなニュース

              「全ての企業のサービスを成長させる」をミッションに掲げ、WebサイトやアプリのUI/UX改善をはじめ、技術力でサービスやプロダクトの成長を支援してきた、リクルートグループのニジボックス。 そんな同社が今注力するのは「データ人材」の育成です。具体的には、BIエンジニア、データエンジニアなど、データ領域でリクルートとともにプロダクトを「共創」できる専門家集団の立ち上げを進めています。その背景には、リクルートでプロダクトのデータ利活用が急速に進んだ結果、「共創」ニーズに対して人材が圧倒的に不足している、という課題がありました。 リクルートグループにおいて、データ実務が担えるエンジニアを、スピーディーに育てなければならない。そのために社内で活用されているのが、「インプットプログラム」と名付けられた新人エンジニアの研修プログラムです。プログラムを修了すれば、リクルートグループの実務で通用する知識やス

                「データエンジニアの市場価値」を上げたい。リクルートグループのニジボックスが“有料級のインプット教材”をつくるワケ - はてなニュース
              • PyCon JPはいますぐ生まれ変わるべき

                昨年からトラブルが続いているPyCon JPですが、9月27日のPyCon JP 2024を前にして、また新しい火種が生まれました。 2024年9月22日、PyCon JPの技術に対する不正の告発、並びに技術者と大衆に対しての警鐘(以下、怪文書2)というタイトルの記事が突如として公開されたためです。 この記事は、python_bokume2というアカウントで公開されていることから、およそ4ヶ月前の2024年5月31日にpython_bokumetsuというアカウントで投稿された採択されるプロポーザルを書こう!!(現在はアカウントごと削除されている。以下、怪文書1)を書いた人と同じ人物による投稿であることがうかがえます。 最初に記事に関しては、インターネットでいうところのいわゆる完全なる怪文書であったのに対して、今回の怪文書2では、具体的な登場人物の名前やSlackのログなど、実際におこなわ

                  PyCon JPはいますぐ生まれ変わるべき
                • デイリーポータルZ・林さんがリクルート流「データマネジメント」を深掘り。そもそもデータって大事なんですか……? - はてなニュース

                  「デイリーポータルZ」代表の林雄司です。これまではウェブマスターとか編集長と名乗って、一企業のなかでサラリーマンとしてサイトを運営していましたが、2024年1月にとうとう独立してしまいました。これからは、自分でコンテンツを作るだけじゃなく、営業とか経営をして、きちんとお金を稼がないといけません。 デイリーポータルZは、これまで大きな企業のもとで運営してきましたが、正直なところ20年余りずっと赤字でした。独立して赤字だとサイトを続けられないので、なんとか自分でも稼ごうといろいろやっていますが、けっこう難しいことだと身にしみています。 独立してみたら想像以上に多くの方や企業に応援していただき、驚くべきことに今は何とか黒字を保っています。でも、これからずっとこの状況が続くかどうかは分かりません。だから、もっとちゃんと稼がないとと思って、そのためにはどうすればいいんだろう、といろいろ考えたり、お金

                    デイリーポータルZ・林さんがリクルート流「データマネジメント」を深掘り。そもそもデータって大事なんですか……? - はてなニュース
                  • スロークエリログをどう使えばいいのかって疑問、全て解決

                    これはなに ども、レバテック開発部のもりたです。 今回はMySQLでのスロークエリログについて調査してまとめました。 スロークエリログといえば古くからパフォーマンスチューニングの力強い味方といったふうに語られることも多いですが、最近はクラウドで使える便利なツールも生まれています。この記事ではスロークエリログの一般的な使い方を紹介するとともに、他のツールとの比較や、どんな場面でスロークエリログが役に立つのか、また役に立たない場合はどんなツールを利用することができるのかについてまとめました。 足りないところなどあればおおいにマサカリ投げていただけると幸いです。 記事の流れ 記事の流れ この記事はそこそこ長いので、初めに記事の流れを解説します。適宜読み飛ばしてください。 なぜスロークエリログなのか ここではそもそもスロークエリログをなぜ確認したいのかみたいなところを説明します スロークエリログの

                      スロークエリログをどう使えばいいのかって疑問、全て解決
                    • 個人開発でもADR (アーキテクチャデシジョンレコード)を書くことの利点 - laiso

                      起業なのか請負開発か趣味のプロジェクト(ペットプロジェクト)かによって状況は異なりますが「私のチームの開発者は私1人だけです」という個人開発においても、ADRは有効なツールとなりえます。 ADRとは何か? ADR(アーキテクチャデシジョンレコード)は、ソフトウェアアーキテクチャにおける重要な設計判断とその根拠、影響、関係する検討事項などを記録した文書です。 一見、現代的な響きですが、その実態はシステム設計ドキュメントの一部です。 "ADR"で検索すると真っ先にヒットするアーキテクチャの入門書『Design It! ―プログラマーのためのアーキテクティング入門』では、ADRは「アーキテクチャ手法に対する開発者寄りのアプローチ」と説明されており、アーキテクトと開発者自身がアーキテクチャに関する意思決定を記録し、共有するための手法として位置づけられています。 アーキテクチャデシジョンレコード(A

                        個人開発でもADR (アーキテクチャデシジョンレコード)を書くことの利点 - laiso
                      • ルールは現場で死にました - The Rules of Programming の読書感想文 - じゃあ、おうちで学べる

                        本日は人生の数ある選択肢のなかから、こちらのブログを読むという行動を選んでくださいまして、まことにありがとうございます。 はじめに プログラミングの世界には多くの指針や原則が存在します。Chris Zimmerman氏の「The Rules of Programming」(邦題:ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール)は、不変の知恵を凝縮した一冊です。これらの原則は、多くの開発現場で活用できる有益な内容となっていると思いました。 The Rules of Programming: How to Write Better Code (English Edition) 作者:Zimmerman, ChrisO'Reilly MediaAmazon 本書は、大ヒットゲーム『Ghost of Tsushima』などで知られるゲーム制作スタジオ、Sucker Pun

                          ルールは現場で死にました - The Rules of Programming の読書感想文 - じゃあ、おうちで学べる
                        • プロダクト目線とエンジニア目線でストーリーを紡ぐ「全体マップ」の作り方 - KAKEHASHI Tech Blog

                          カケハシでエンジニアリングマネージャーを担当しているいくおです。 今回は、私たちのチームで中規模以上(複数スプリントにまたがるもの)の機能開発を行うときに作成している「全体マップ」について紹介します。 全体マップを考案したのはチームメンバーの椎葉さんなのですが、「いくおさん言語化うまいからブログにしてください!」とおだてられたので、それを真に受けて私がブログに書きます。 全体マップを作るようになってから、中規模の開発で自分たちの状況を把握しやすくなりました。また、全体マップを通して関係者全員がコミュニケーションすることで、なめらかな協働関係を築けるようになりました。こういった実体験からも、ぜひ多くの現場で全体マップを試してみたいと思っています。 では、全体マップとは一体なんなのか、どうやって活用するとよいのか、解説します。 この記事は秋の技術特集 2024の6記事目です。 ユーザーストーリ

                            プロダクト目線とエンジニア目線でストーリーを紡ぐ「全体マップ」の作り方 - KAKEHASHI Tech Blog
                          • KPIのモニタリング自動化と運用体制の整備 - ZOZO TECH BLOG

                            はじめに こんにちは。データシステム部/推薦基盤ブロックの佐藤 (@rayuron) です。私たちはZOZOTOWNのパーソナライズを実現する推薦システムを開発・運用しています。推薦システムごとにKPIを策定していますが、データの欠損やリリース時の不具合によってKPIが意図しない値を取ることがあるため定常的に確認する必要があり、これをKPIのモニタリングと呼んでいます。 先日、推薦システムの実績をLookerでモニタリングするというテックブログで推薦システムのKPIをモニタリングする方法を紹介しましたが、運用していく中でいくつかの課題が見えてきました。本記事では、より効率的かつ効果的なKPIのモニタリングを実現するための取り組みについて詳しくご紹介します。 はじめに 改善の背景と課題 背景 課題 トレンドを考慮した異常検知が不可能 モニタリングの設定が面倒 アラート対応フローが不明確 サマ

                              KPIのモニタリング自動化と運用体制の整備 - ZOZO TECH BLOG
                            • 資料生成AI「Napkin」でデカめの資料を作ってみたので知見を共有する

                              1.1.2 SREの目標と価値 SREの目標は、システムの信頼性を向上させることですが、それは単にシステムのダウンタイムを減らすことだけを意味するわけではありません。ユーザーがサービスを快適に利用できるよう、パフォーマンス、可用性、セキュリティ、スケーラビリティなど、様々な側面からシステムの信頼性を高めることを目指します。 SREの導入によって、以下のような価値がもたらされます。 システムの安定稼働と信頼性向上 運用コストの削減 開発スピードの向上 組織全体の信頼性向上 1.2 SREの原則 SREを実践する上で重要な原則をいくつか紹介します。これらの原則は、GoogleのSREチームが長年の経験から得た教訓に基づいており、SREを実践する上で指針となるものです。 1.2.1 モニタリングと可観測性 SREでは、システムの状態を常に把握し、問題が発生した場合には迅速に検知できるように、モニ

                                資料生成AI「Napkin」でデカめの資料を作ってみたので知見を共有する
                              • 北村紗衣という「ひと」 : 「男みたいな女」と言う場合の「女」とは、 フェミニズムが言うところの「女」なのか?|年間読書人

                                北村紗衣という「ひと」 : 「男みたいな女」と言う場合の「女」とは、 フェミニズムが言うところの「女」なのか? 『「ひと」の「首尾一貫性」とか「連続性」というのは、ひとであるための論理的、解剖学的な特性ではなく、むしろ、社会的に設定され維持されている理解可能性の規範なのである。セックスとかジェンダーとかセクシュアリティといった安定化概念によって「アイデンティティ」が保証されるなら、「ひと」という概念が疑問に付されるのは、「首尾一貫しない」「非連続的な」ジェンダーの存在が出現するときである。なぜならそのような存在は、ひとのように見えはしても、ひとが定義されるときの文化的に理解可能なジェンダー規範には合致しないものであるからだ。 「理解可能な」ジェンダーとは、セックスと、ジェンダーと、性的実践および性的欲望のあいだに、首尾一貫した連続した関係を設定し、維持していこうとするものである。換言すれば

                                  北村紗衣という「ひと」 : 「男みたいな女」と言う場合の「女」とは、 フェミニズムが言うところの「女」なのか?|年間読書人
                                • ファミ通VS.ファミマガの歴史。塩崎剛三氏と山本直人氏,レジェンド編集者がマイコン誌時代からファミコンブームまでを語る

                                  ファミ通VS.ファミマガの歴史。塩崎剛三氏と山本直人氏,レジェンド編集者がマイコン誌時代からファミコンブームまでを語る ライター:箭本進一 カメラマン:愛甲武司 12→ 元「ログイン」「ファミコン通信」編集長である塩崎剛三氏の書籍「198Xのファミコン狂騒曲」が2024年8月31日に出版される。この本では,「ログイン」のいちコーナーから始まったファミコン通信(以下,ファミ通)が,週刊誌として刊行されることや,リメイク版が発売された「オホーツクに消ゆ」など,さまざまなムーブメントが作られていく様子が語られている。 4Gamerではこの書籍の発売を記念し,塩崎剛三氏と世界初のファミコン誌である「ファミリーコンピュータMagazine」(以下,ファミマガ)の元編集長である山本直人氏との対談を掲載する。マイコン(パソコン)雑誌から家庭用ゲーム機の雑誌へ移る……というよく似た経歴の両氏が,ファミコン

                                    ファミ通VS.ファミマガの歴史。塩崎剛三氏と山本直人氏,レジェンド編集者がマイコン誌時代からファミコンブームまでを語る
                                  • 監視ツールを迷ったら CloudWatch から始めてみるのもありなのでは - カミナシ エンジニアブログ

                                    こんにちは、新規プロダクトの開発をしています、a2 (@A2hiro_tim )です。 昨日、開発してきたプロダクトについて、正式リリースを発表させていただきました 🎉 prtimes.jp employee.kaminashi.jp さて、新規プロダクトの立ち上げは、技術選定や運用ツールの自由度が高く、どの監視ツールを使うか、選択に迷うこともあると思います。 我々のチームでは複数ツールの使用経験はあるものの、特定のツールの導入経験や深い知見があるメンバーはいなかったので、フラットに比較検討し、 Amazon CloudWatch の利用から始めてみよう、と意思決定しました。 主な選定理由は、 AWS エコシステムの中で完結できるため、Terraform Cloud などの既存の設定を流用できて新しく覚えることが少ない、AWS 上でコストを一元管理できる、等のメリットがある。 サービス開

                                      監視ツールを迷ったら CloudWatch から始めてみるのもありなのでは - カミナシ エンジニアブログ
                                    • データにまつわる“お悩み”を根こそぎ解決。リクルートのビジネスを支える影の仕事人「アナリティクスエンジニア」の素顔 - はてなニュース

                                      データを利活用してカスタマー・クライアント双方の「不」の解消を目指してきたリクルートが、今注力する領域は「データを用いた意思決定の質向上」とそのための「データの整備」です。 そこにフルコミットするため、新たに生まれた職種がアナリティクスエンジニアです。例えば、図書館を作るのがデータエンジニアで、図書館に収納された本を使って価値を生み出すのがデータサイエンティストだとすれば、本の整理や目録の作成などを通じてさながら司書のような役割を果たすのがアナリティクスエンジニアです。言うなれば「データの整備人」。 リクルートにおいては、データを用いた意思決定を加速させるうえで、必要不可欠の存在です。 とはいえ、まだまだ一般的には知られていないアナリティクスエンジニアの仕事。彼らは組織のなかでどのような役割を果たし、どのように事業へ貢献しているのでしょうか。そしてどんなバックグラウンドを持っているのでしょ

                                        データにまつわる“お悩み”を根こそぎ解決。リクルートのビジネスを支える影の仕事人「アナリティクスエンジニア」の素顔 - はてなニュース
                                      • DEEN池森秀一が語る、そばへの深い愛情と十割そばが絶品のお店【通いたくなるお店】 - おなじみ丨近くの店から、なじみの店へ。

                                        ロックバンド「DEEN」のボーカリスト・池森秀一さんはそば好きとして知られ、またご自身でもそば店もプロデュースしています。そばの魅力について改めて語っていただくとともに、「通いたくなるお店」とは何かを伺いました。 一度ならず、何度も足を運んでくれる“おなじみさん”は、飲食店にとって心強い存在です。そうした常連客の心をつかむお店は、どのような工夫をしているのでしょうか。また、お客さんから見てどういうお店が「通いたくなるお店」なのでしょうか。 今回お話を伺ったのは、人気ロックバンド「DEEN」のフロントマンであり、そば好きとしても知られる池森秀一さんです。約16年前からそばを食べ続け、全国ツアーの際には地方の名店を巡るのがライフワークになったそう。これまで200軒以上のそば店を訪れ、さらにご自身でもそば店もプロデュースしています。そばの魅力について改めて語っていただくとともに、お客さんとして、

                                          DEEN池森秀一が語る、そばへの深い愛情と十割そばが絶品のお店【通いたくなるお店】 - おなじみ丨近くの店から、なじみの店へ。
                                        • データアーキテクチャ特集 データ利活用を推進する8社の技術選定 - Findy Tools

                                          公開日 2024/09/12更新日 2024/09/13データアーキテクチャ特集 データ利活用を推進する8社の技術選定 毎回ご好評頂いているアーキテクチャ特集の今回のテーマは、データ分析基盤です。 データ活用に特に力を入れている日本のIT企業8社にご協力頂き、それぞれの技術選定の裏側と今後の展望についてご寄稿頂きました。 ※ご紹介は企業名のアルファベット順となっております 株式会社朝日新聞社 アーキテクチャ選択の背景や意図 これまでは、朝日新聞デジタル(朝デジ)のサービス開発・運用において、データを収集する基盤が存在せず業務ごとに Adobe Analytics や AWS QuickSight、 内製のツールなど様々なBIツールが乱立している状態でした。そこで、複数のシステムのデータソースを統合的に可視化・分析を可能にするために、分析基盤の構築に着手しました。 まず、データを集積・加工す

                                            データアーキテクチャ特集 データ利活用を推進する8社の技術選定 - Findy Tools
                                          • 21社の監視・オブザーバビリティ アーキテクチャ特集 - Findy Tools

                                            デジタル時代の企業にとって、システムの安定稼働と迅速な問題解決は、競争力を維持するための重要な要素です。21社にご寄稿頂いた「Amazon CloudWatch」「Datadog」「Grafana」「New Relic」「Prometheus」「Sentry」「Splunk」の各ツールレビュー記事を参照・抜粋し、それぞれの企業がどのようにシステムの健全性を確保し、未来の課題に備えているのかをアーキテクチャを通してご紹介します。 ※ツール名・ご寄稿企業名共にアルファベット順で掲載しております Amazon CloudWatchAWS CloudWatchは、AWSのクラウドリソースとアプリケーションの監視と管理を行うためのサービスです。メトリックス、ログ、イベントなどを収集、追跡し、可視化することで、システム全体の状態を把握し、問題の早期発見と解決をサポートします。 ▼Amazon Clou

                                              21社の監視・オブザーバビリティ アーキテクチャ特集 - Findy Tools
                                            • データベースエンジニアのスキルアップ 専門書輪読会とMySQLモブプロの取り組み

                                              こんにちは。LINEヤフー株式会社でデータベースエンジニアをしている、松浦、中園、大塚、曽根、笠井です。 データベースはLINEヤフーのさまざまなサービスを支える重要なソフトウエアですが、その安定的な運用やトラブルシューティングには、データベースに関する専門的な知識が必要です。 一方で、データベース部門に配属される新卒のエンジニアは、全員が学生時代にデータベースを専門的に勉強しているわけではありません。このような新卒エンジニアは、データベース部門へ配属後、OJTや実際のデータベースの運用業務に携わりながら、データベースに関する専門知識を深めていきます。 今回のブログ記事では、データベースエンジニアとしての専門性を高めるために、部門内で実施している専門書の輪読会、そして、MySQLを題材としたデータベースカーネルのモブプログラミング(以下、モブプロ)の取り組みについてご紹介します。 1. 輪

                                                データベースエンジニアのスキルアップ 専門書輪読会とMySQLモブプロの取り組み
                                              • なぜエンジニアのあなたの質問は伝わらないのか? - Qiita

                                                はじめに 包み隠さずオープンに伝えると、投稿主は質問が全然上手ではありません。 多分、この記事を読んでいる皆さんの方が何倍も上手です。 ということで本記事は以上です(冗談です) こちらでは誰よりも質問下手だった投稿主が試行錯誤した結果、導き出した良い質問・悪い質問それぞれの共通点や法則性を提唱します(単なる一般論でしたらすみません) あなたの質問はなぜ伝わらないのか 結論? それは、あなたの質問に愛がないからです。 というのは半分冗談として(笑)、よくありそうな悩みを以下に記載します。 拙い文章ですが、皆さんのお役に立てれば幸いです。 テクニックに走ることによる弊害 「本をたくさん読んだり、質問フォーマットで文章を丁寧に書いてみたけど、全然伝わらない!」 生成AIに聞いてみたりしたら、たとえばこんな答えが返ってくると思います。 Q. 私はエンジニアなのですが、質問はなぜ伝わらないのでしょう

                                                  なぜエンジニアのあなたの質問は伝わらないのか? - Qiita
                                                • GitHub ActionsのJobが落ちたときに何をするべきかを記述するPlaybookの仕組みを作って運用している話 - newmo 技術ブログ

                                                  newmoではGitHub Actionsを自動テスト、Lint、デプロイなどに利用しています。 また、newmoではmonorepoで開発しているため、1つのリポジトリに複数のチーム/複数のアプリケーションが存在しています。 GitHub Actionsではpathsを使うことで、特定のファイルが変更された場合のみ特定のWorkflowが実行できます。 newmoのmonorepoのworkflowでは基本的にpathsが指定されていますが、それでも普段は触らないファイルを変更して意図せずにCIが落ちることがあります。 GitHub ActionsのCIが落ちたときに、そのCIの仕組みを作った人やチーム以外だと何をすべきかわからないことがあります。 この問題の解決するを手助けするシンプルな仕組みとして、GitHub ActionsにCIが落ちたときに何をするべきかを表示するPlayboo

                                                    GitHub ActionsのJobが落ちたときに何をするべきかを記述するPlaybookの仕組みを作って運用している話 - newmo 技術ブログ
                                                  • Remix on CloudflarePages + Prisma + Supabase で銀の弾丸を目指す 20240828

                                                    自分が思う最強の(かつ貧者の)構成を目指したログ。流行りの技術選定ってやつしたかった。 結論だけ言うと、まだ綺麗ではないが現実的に動く。動かし方を理解してないと事故る、かも。 この記事は自分がたどり着いた結論を順を追って記述するが、自分にとって自明な場所の差分を記録してないので、コードをなぞるより変更意図を追って各々自分で組み立てる、ということを推奨する。 動いてるリポジトリはここ。ただこの記事の説明を読まないと、その意図が伝わらない。 追記 20240829: DATABASE_URL で Connection Pool を有効にするのに ?pgbouncer=true を追加 https://supabase.com/partners/integrations/prisma このスタックの意図 Remix on cloudflare-pages コストとパフォーマンスを両立できる、20

                                                      Remix on CloudflarePages + Prisma + Supabase で銀の弾丸を目指す 20240828
                                                    • webでの発言と「居酒屋」のたとえ - 誰がログ

                                                      webで批判や非難、誹謗中傷などネガティブな言及が話題になったときの「居酒屋じゃないんだから」「居酒屋でやれ」といった表現が以前から気になっています。さいきんもいくつかの話題で見かけました。表現としては特に新しいというわけではなく、かなり前から使われていると思います。 この表現を使っている人がみな同じ意図で使っているわけではなさそうですが、「居酒屋での発言なら問題が発生しない(可能性が高い)」ということは共通しているのではないでしょうか。 そのなぜ問題が発生しなさそうなのかという理由のところが気になっていて、これも推測でしかありませんが、「パブリックな場ではないので問題のある発言であっても届いてはまずい人に届きにくい」とか「酒席なのでなかったことにしてよい/してもらえる」などが思いつきます。 私の感覚では、前者は分からなくもないけど後者には賛同できないといった辺りです。 つまり、届かないだ

                                                        webでの発言と「居酒屋」のたとえ - 誰がログ
                                                      • プロダクト開発のモニタリングにおいて大事な4つの段階とベストプラクティス - KAKEHASHI Tech Blog

                                                        カケハシで Musubi Insight のバックエンドエンジニアをしている末松です。今回はプロダクトのモニタリングをどう進めていくべきかについて、4つの大事な段階とそのベストプラクティスを紹介したいと思います。 この記事は秋の技術特集 2024の 10 記事目です。 想定読者 モニタリングの悩みあるある モニタリングを始めるためには モニタリングにおいて大事な4つの段階 1. 【可視化】プロダクトの状況がさまざまな断面で可視化されている 【可視化】 のベストプラクティス 2. 【共有】プロダクトの状況が定期的にチームに共有・認識されている 【共有】 のベストプラクティス 3. 【検知】プロダクトが異常な状態であることにチームが気付くことができる 【検知】 のベストプラクティス 4. 【集中】チームが優先すべき指標が定まっている 【集中】 のベストプラクティス まとめ 想定読者 プロダクト

                                                          プロダクト開発のモニタリングにおいて大事な4つの段階とベストプラクティス - KAKEHASHI Tech Blog
                                                        • PHP アプリケーションのトレース計装ではじめる OpenTelemetry 入門 - Shin x Blog

                                                          OpenTelemetry を利用して PHP アプリケーションのテレメトリデータを計装する方法をまとめました。 本エントリのコードは下記で公開しています。 github.com OpenTelemetry とは 用語 PHP アプリケーションのマニュアル計装(手動計装) 構成 OTel Collector Jaeger 動作環境 必要なパッケージ PHP コード 設定 実行 PHP アプリケーションのゼロコード計装(自動計装) 必要な拡張とパッケージ 設定 PHP コード 実行 さいごに 参照 OpenTelemetry とは opentelemetry.io OpenTelemetry は、サービスやアプリケーションのテレメトリーデータ(トレース、メトリクス、ログなど)を計装、生成、収集、送信するためのオブザーバビリティフレームワークです。ベンダーニュートラルな OSS であり、CNC

                                                            PHP アプリケーションのトレース計装ではじめる OpenTelemetry 入門 - Shin x Blog
                                                          • スクラムガイド(LeSS版)

                                                            スクラムガイドの目的 スクラムは複雑なプロダクトを開発、提供、保守する為のフレームワークである。このガイドではスクラムを定義している。定義には役割、イベント、作成物とそれらをまとめるルールが含まれている。フレームワークの各要素は特定の目的を有し、スクラムによって実現される価値と成果にとって不可欠な要素となる。スクラムの考え方や構造を変えたり、要素を省いたり、ルールを無視する事は問題を隠し、スクラムから得られる価値を限定したり、無意味な物にしてしまうのである。 Ken Schwaber と Jeff Sutherlandはスクラムのフレームワークを作る事に重要な役割を担った。 LeSS(大規模スクラム)は複数のチームでプロダクト開発をする際にスクラムを適応し、組織のシステムが変化した結果として形作られ、LeSSはLeSSルールにて定義をされている。LeSSルールは、各チームのレベルではスクラ

                                                              スクラムガイド(LeSS版)
                                                            • SREチーム発足と今期の取り組みについて - Findy Tech Blog

                                                              はじめに 皆様、はじめまして。Findyでプロダクト開発部/SREとしてジョインしました安達(@adachin0817)と申します。今年の6月に入社し、ちょうど3ヶ月が経ちました。本日は、SREチームの立ち上げに関する0から1のプロセスと、今期の取り組みについてご紹介させていただきたいと思います。 SREチーム発足 2023年までは、バックエンドチームがインフラを担当していました。しかし、サービスの拡大に伴い、バックエンドチームのリソースが不足し、SRE的な改善が十分に行えない状況が続いていました。そこで、昨年からSREの大矢とチームリーダーの下司(@gessy0129)がジョインし、現在は3名体制で活動しております。 SREチームの位置づけとミッション SREチームは横断的なSRE活動をしており、これを「横断SRE」と指しています。一方で、各プロダクトにおいてSRE的な役割を担っていたメ

                                                                SREチーム発足と今期の取り組みについて - Findy Tech Blog
                                                              • 正しさ @verygoodreality 18年6月11日 まだあるか分からないけど、昔2chの引きこも..

                                                                正しさ @verygoodreality 18年6月11日 まだあるか分からないけど、昔2chの引きこもり板で電車の乗り方とか荷物の送り方とか「引きこもっているから分からないor忘れてしまった社会の常識」を質問するスレとその過去ログをまとめたページがあって、俺は引きこもりではなかったけどその情報が普通に役に立ったんだよな。 https://twitter.com/verygoodreality/status/1006164848940548098 posted at 22:22:48 正しさ @verygoodreality 18年6月11日 で、当時はこんなこと考えなかったけど、田舎に育つということは引きこもりと同程度に情報が遮断された・分からない状態であるということだったんだなと今になって分かるんだよな。 https://twitter.com/verygoodreality/stat

                                                                  正しさ @verygoodreality 18年6月11日 まだあるか分からないけど、昔2chの引きこも..
                                                                • 私の記事「北村紗衣という人」(2024年8月30日付)が、通報削除されました。|年間読書人

                                                                  たぶん昨日(2024年9月13日)のことです。無論、私自身が「削除」したのではありません。 「管理者」からの事前通告もなく、いきなりの削除でした。 昨日のお昼すぎ頃、私自身の別の記事を見たら、当該記事「北村紗衣という人」へのリンク部分が、 『note この記事は閲覧できません』 となっていたのです。 (これが、削除された「傷跡」)「閲覧」できないのではなく、要は、この記事で扱われた、「武蔵大学の教授」で「表象文化論学会」所属の学者でもある北村紗衣が、この記事に関し、「note」の管理者へ、「削除要請」の「通報」をしたから、記事が削除されてしまったのです。当人が「通報」しないことには、なかなか記事削除なんてされません。 (武蔵大学教授・北村紗衣先生の御著書)北村紗衣が、私の記事「北村紗衣という人」の削除を望んでいたというのは、この記事が、2週間ほどで「138」もの「好き」をいただいた人気記事

                                                                    私の記事「北村紗衣という人」(2024年8月30日付)が、通報削除されました。|年間読書人
                                                                  • 「AWSを始めた頃に陥りがちなポイントをまとめてみた」というタイトルで登壇しました #classmethod_forgevision_fusic | DevelopersIO

                                                                    「AWSを始めた頃に陥りがちなポイントをまとめてみた」というタイトルで登壇しました #classmethod_forgevision_fusic この度、「Fusic x フォージビジョン x クラスメソッド Vol.2【AWS勉強会】」というイベントで、「AWSを始めた頃に陥りがちなポイントをまとめてみた」というタイトルで登壇しました。今回はその内容をダイジェストで紹介します。 はじめに おのやんです。 この度、2024/09/05に開催された Fusic x フォージビジョン x クラスメソッド Vol.2【AWS勉強会】というイベントで、「AWSを始めた頃に陥りがちなポイントをまとめてみた」というタイトルで登壇しました。 ということで、こちらの登壇内容をダイジェストで紹介したいと思います。 イベント概要 Fusic x フォージビジョン x クラスメソッド 3社合同 AWS 勉強会開

                                                                      「AWSを始めた頃に陥りがちなポイントをまとめてみた」というタイトルで登壇しました #classmethod_forgevision_fusic | DevelopersIO
                                                                    • Twitterのカルチャーが「残っている」という自負――ロプロス × yositosi 開発者対談

                                                                      TwilogとTogetterの15周年を記念し、それぞれのオリジナル開発者同士による対談をお届けする Twitter関連サービスとしてどちらも2009年にスタートし、2024年で15周年を迎えたTogetterとTwliog。その記念として、それぞれのオリジナル開発者であるyositosi(吉田俊明)とロプロス氏に、初めてTwitterに触れた頃の話からサービスの開発〜発展、Xへの変化を含むイーロン・マスク体制以降の動乱まで、この15年を振り返ってもらった。 Twitterはゆるくて気軽な雰囲気、APIも多機能で自由度が高かった ロプロスさんはいつ頃Twitterを始めたんですか?私が始めたのは2007年で、当時勤めていた会社の同僚たちの間で話題になっていたのがきっかけです。日本国内での最初の盛り上がりみたいなものが、このタイミングであったと記憶しています。「百式」の田口元さんあたりから

                                                                        Twitterのカルチャーが「残っている」という自負――ロプロス × yositosi 開発者対談
                                                                      • 形態論(言語学)の教科書・概説書を書きましたので少しだけ補足と宣伝 - 誰がログ

                                                                        はじめに どういう特徴があるか どのような教科書か レベル 練習問題 言語(データ) 文献 訳語 おわりに おまけ はじめに 乙黒亮さんと共著で『形態論の諸相 6つの現象と2つの理論』という本を書きました。刊行は10月10日でもう少し先ですが、Amazonほかで予約もできるような段階ですので先に少し宣伝しておきます。 以下のくろしお出版のページに詳細な情報が載っていて、書影の下にある「サンプルページを見る」から「まえがき」「目次」と各章の冒頭部分を読むことができます。 形態論の諸相 6つの現象と2つの理論|くろしお出版WEB Amazonのページはこちら この記事では本書には直接は書かれていない私個人の見解などについて少し補足のようなものを書いてみます。重要なところはあとで個人サイトの方にまとめなおすかもしれません。 どういう特徴があるか 言語学の形態論という研究領域の教科書です。教科書と

                                                                          形態論(言語学)の教科書・概説書を書きましたので少しだけ補足と宣伝 - 誰がログ
                                                                        • 2ヶ月でリリースしたFindy Toolsの技術選定の裏側 - Findy Tools

                                                                          これまで、Findy Toolsのアーキテクチャ特集記事では、テーマや分野ごとに複数の企業からアーキテクチャや技術選定の背景を伺い、まとめた記事をお届けしてきました。今回から始まる新シリーズでは、1社の技術選定についてさらに深く掘り下げ、個々の選択がどのように全体の成功に寄与しているのかをより詳細に探っていきたいと思います。初回の本記事では、まず私たち自身であるFindy Toolsが、2ヶ月という短期間でリリースに至った技術選定の裏側をご紹介します。 Findy Toolsについて Findy Toolsは開発ツールに特化したレビューサイトです。 ツールのレビューや他社のアーキテクチャを見て技術選定の参考にすることが出来ます。2024年1月にベータ版としてサービスをリリースしました。 ベータ版までは ほとんど1人で開発され、現在は3名で開発を行っています。 立ち上げのスピードを重視して、

                                                                            2ヶ月でリリースしたFindy Toolsの技術選定の裏側 - Findy Tools
                                                                          • OSS開発に参加する方法 - 2024-09-18 - ククログ

                                                                            こんにちは。7月にクリアコードに入社した藤田です。 クリアコードでは「フリーソフトウェアで稼ぐ」という理念をもとに、さまざまな活動がオープンになっており、 OSS開発もその一環です。 私が所属するチームは、Fluentdという拡張性の高いOSSのログ収集ソフトウェアを扱っています。 クリアコードに入社するとともに、新たなOSSに挑戦しております。 そこで、この記事では私なりのOSSに参加する方法についてご紹介したいと思います。 この内容に沿って作業されると、すぐにPull Requestを作成することができるかと思います。 それを足がかりにより大きな課題へ挑戦してみてください。 クリアコードでOSS開発 私が所属しているFluentdチームは、Fluentdの導入支援や運営サポートなどの エンタープライズサポートをベースに、Fluentdをオープンに開発しています。 我々の活動は http

                                                                              OSS開発に参加する方法 - 2024-09-18 - ククログ
                                                                            • エンジニア主導で爆速開発を実現する - Tabelog Tech Blog

                                                                              はじめに こんにちは。食べログ開発本部 ウェブ開発1部の羽澤です。 マネージャーという立場で働いておりまして、案件をリードしたり、一歩引いてメンバーや案件をサポートしたり、その時々で役割を変えながら日々過ごしております。 その中でいつも頭を悩ませているのが、いかに早く開発を進めるかということです。これは食べログだけでなくどんな組織でも常に考えている、永遠の課題だと思います。 今回は食べログの開発体制を紹介しながら、自分として爆速で進められたと感じている案件を紹介します。「なぜうまく行ったのか」を掘り下げることで見えてきた重要な視点を、「爆速で進める1つのポイント」としてまとめてみました。 プロジェクト体制の紹介 開発の話の前に、前提となる組織の形を紹介します。 私の所属するウェブ開発1部では、マトリクス型の組織を採用しております。 ウェブ開発1部の事例ではありませんが、以下の記事が参考にな

                                                                                エンジニア主導で爆速開発を実現する - Tabelog Tech Blog
                                                                              • macOS版cURLはcURLと証明書検証の仕様が異なる | さくらのナレッジ

                                                                                はじめに 2023年12月に「cURLの"--cacert"オプション利用時の挙動がmacOSとLinuxで異なる」という内容のissueが立ち、2024年3月にcURLの開発者であるDaniel Stenberg氏が「THE APPLE CURL SECURITY INCIDENT 12604」というタイトルで記事を公開しました。 この記事では本件に関する詳細の説明と検証、また独自の掘り下げを行い、macOS版cURLとオリジナルのcURLの違いについて解説します。ただし、本件は明らかになっていない部分が多くあるため、本記事には推測や仮説が含まれます。ご了承ください。 --cacertオプションにおけるmacOSのcURLとオリジナルのcURLの違い まずはDaniel Stenberg氏の記事で述べられた内容を元に、"--cacert"オプションにおけるmacOS版cURLとオリジナル

                                                                                  macOS版cURLはcURLと証明書検証の仕様が異なる | さくらのナレッジ
                                                                                • より快適なエラーログ監視を目指して

                                                                                  2024/09/11 New Relic User Group Vol.11 ただのLT大会『より快適なエラーログ監視を目指して』 レバテックでの Datadog から NewRelic への移行に際し、エラーログの Slack 通知を改善し、より快適なエラーログ監視を実現したお話です。

                                                                                    より快適なエラーログ監視を目指して