Content-Length: 376336 | pFad | http://b.hatena.ne.jp/q/.tech

.techの人気記事 46件 - はてなブックマーク

並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 46件

新着順 人気順

.techの検索結果1 - 40 件 / 46件

.techに関するエントリは46件あります。 開発プログラミングセキュリティ などが関連タグです。 人気エントリには 『何故お役所ってオワコンIEが大好きなの?|楠 正憲(デジタル庁統括官)』などがあります。
  • 何故お役所ってオワコンIEが大好きなの?|楠 正憲(デジタル庁統括官)

    普通は役所のシステムって構築してから5年とか7年は塩漬けにして使うもので、一度やらかしてしまうと名誉挽回の機会なんて向こう数年は与えられないんだけど、こと本件に関しては高市総務大臣から「今すぐ私がマニュアルなしでも使えるように直しなさい」と叱責いただいて、しっかりと予算的なサポートも得られたことで、たったの数ヶ月で立て直すことができた。 この数ヶ月は外部のセキュリティやPKIの専門家の方から様々なサポートをいただいて何とか実現したんだけれども、役所のシステム開発としては非常識というか、極めて難易度が高い案件だった。「え?単にChromeやSafariをサポートするだけでしょ、難しい訳ないじゃん」と思う諸兄は、もうしばらくこの話に付き合って欲しい。 もともとマイナポータルは日本を代表するITベンダーと通信キャリアの3社が開発したんだけど、大臣からの叱責を受け「ちゃんとお金を払うから直してよ」

      何故お役所ってオワコンIEが大好きなの?|楠 正憲(デジタル庁統括官)
    • ソフトウェアエンジニアなら3秒で理解できる NFT 入門 - Okapies' Archive

      はじめに NFT って何ですか? ブロックチェーン上に記録された一意なトークン識別子をその保有者のアドレスと紐付ける情報、およびそれを状態変数として保持するスマートコントラクトのこと。 以上。 え、それだけ? はい。 「デジタル資産に唯一無二性を付与するインターネット以来の革命」なんじゃないの? これを読んでください: speakerdeck.com なるほど。ところで、この記事は何? いま話題の NFT について、NFT の標準仕様である EIP-721 の仕様書と、それを実装しているスマートコントラクトのソースコードから読み解けることを解説する。一般向けの解説とは異なる視点から光を当てることで、ソフトウェアエンジニアに「あ、NFT って単にそういうことだったのか」と理解してもらえるようにすることを狙っている。 また、NFT がソフトウェアとして具体的にどう実装されているかを知ることは、

        ソフトウェアエンジニアなら3秒で理解できる NFT 入門 - Okapies' Archive
      • コードレビューの目的と考え方 - osa_k’s diary

        まえがき コードレビューの目的 大目的 小目的 チェックリスト 優先度高(大きな損失を生む問題・後からの修正が困難な問題) 優先度中 優先度低(システムに大きな影響を与えない問題・後からの修正が容易な問題) レビューを負担にしないために レビューサイズのコントロール 誰がレビューをするか 議論をどうまとめるか 批判と個人攻撃 レビュワー向けアドバイス Code author向けアドバイス 参考文献 まえがき コードレビューの有効性が説かれるようになって久しい。しかし、コードレビューをするべきという観念ばかりが先立ってしまい、何のためにコードレビューをするのか、どのような点をレビューするべきなのかといった、目的や進め方に対する意識が曖昧なケースも数多くあるように思われる[6]。コードレビューの目的を理解せずに惰性でレビューしているだけでは、いずれレビューそのものが形骸化し、単に承認のハンコを

          コードレビューの目的と考え方 - osa_k’s diary
        • 2024年版のDockerfileの考え方&書き方 | フューチャー技術ブログ

          最近はお客さんとの勉強会でDockerのドキュメントをつまみ食いして読むというのをやっていますが、改めて最新版を読んでみて、いろいろ思考が整理されました。2020年の20.10のマルチステージビルドの導入で大きく変わったのですが、それ以前の資料もweb上には多数あり「マルチステージビルドがよくわからない」という人も見かけるので過去の情報のアンラーニングに使っていただけるように改めて整理していきます。 仕事でPythonコンテナをデプロイする人向けのDockerfile (1): オールマイティ編で触れた内容もありますが改めてそちらに含む内容も含めて書き直しています。 本エントリーの執筆には@tk0miya氏から多大なフィードバックをいただきました。ありがとうございます。 基本的なメンタルモデル現代的な使い方を見ていくために「Dockerを使ってビルドする」というのはどのようなものか考えを整

            2024年版のDockerfileの考え方&書き方 | フューチャー技術ブログ
          • Webサーバーアーキテクチャ進化論2023

            はじめに 最近プログラマーとしてのキャリアに一区切りつけようと思っており、これまでのプログラミングの勉強の集大成となるブログを書きたくなったので書く。初めてプログラミングをして、フロントエンド開発をして、サーバーから値が返ってきたときは「どういう仕組みで値が返ってきたんだ?」と疑問に思っていた。ずっと理解したくて理解できていなかった。だからずっと勉強していた。そして最近になってようやく自分の言葉で説明できるようになった気がしたのでブログを書きたい。 2015 年版が自分の原点であり、この記事を書くモチベーションになった このような記事は実は過去に存在している。 FYI: https://blog.yuuk.io/entry/2015-webserver-architecture その記事はサーバーがどういう仕組みで動いていて、どのように進化し、2015 年に至るかを解説してくれた記事だ。自

              Webサーバーアーキテクチャ進化論2023
            • AWSによるクラウド入門

              真野 智之 (Tomoyuki Mano) <tomoyukimano@gmail.com> version 1.0, 2020-06-19

              • プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう

                Founder Customer Fitこのセクションについて解決したい課題を見つけよう顧客を決めようリーンキャンバスを書こうミッションを決めようCustomer Problem Fitこのセクションについてペルソナを立てよう共感マップをつくろうカスタマージャーニーマップをつくろう課題仮説を整理しようプロブレムインタビューをしようProblem Solution FitこのセクションについてPEST分析をしようフックモデルを定義しようプロトタイプをつくろう解決策仮説を整理しようソリューションインタビューをしようSolution Product Fitこのセクションについて名前をつけようユーザーストーリーマップをつくろうMVPを構築しようMVP仮説を整理しようMVPインタビューをしようProduct Market Fitこのセクションについてグロースサイクルを定義しよう利用規約をつくろうプロ

                  プロダクトマネジメント入門: 失敗しないプロダクトの作り方を学ぼう
                • Kubernetes 1.20からDockerが非推奨になる理由 - inductor's blog

                  追記: Kubernetes側での公式のアナウンスが2本出ているのでこちらも合わせてご覧ください。 kubernetes.io kubernetes.io Kubernetesコミュニティを眺めていたら、やたらめったら色んな人達が1.20 RCのリリースノート引っ張り出して「Dockerが非推奨になるからちゃんと対策を検討してね!!!」とアナウンスをしていて、挙げ句SIG Contributexではその対策に追われてバタバタしている自体を観測しました。 CNCF Ambassador Slackでもだいぶ燃え上がっていて、見かねて dev.to に記事を投稿したのでそれをかんたんに日本語にまとめてみようと思います。英語のほうはこちらをご覧ください。 dev.to 追記2. 影響範囲を知りたい場合はまずこちらをお読みください blog.inductor.me 追記2. 影響範囲を知りたい場合

                    Kubernetes 1.20からDockerが非推奨になる理由 - inductor's blog
                  • エンジニアに独学を期待するのはもう時代遅れだと思う。 - ヨーロッパで働くIT土方社長のブログ

                    www.ntt.com これを見てちょっと最近の流れと違うなぁとしみじみ思ったので全力で反論してみる。。 僕自身は81年代生まれ、小学校6年生のときにPC98シリーズのN88Basicで独学でBasicから入って、中高とDirectX使ってゲーム作ったりして、大学のときにバイトで実務のプログラムを初めて〜、と何故かまぁ小さいながらも経営者として傍らまだ炎上した案件とかに入って消火活動に勤しんでたりしてる。まぁ後半はどうでもいいけど、この世代では日本海外とわず独学で勉強するのは至って普通だと思う。クロアチアだと勿論PC98じゃなくてAmigaとかドイツ製のPCが主流のよう。 で、一方で最近の新入社員たちを見てると最初からスクールに通って、大学で授業を真面目にうけて、インターンでメンターに面倒を見てもらって、バイトも常にメンターがいつつ実務に関わってって流れが普通。プログラミングは常に勉強とし

                      エンジニアに独学を期待するのはもう時代遅れだと思う。 - ヨーロッパで働くIT土方社長のブログ
                    • パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary

                      最近、パーフェクトRuby on Railsの増補改訂版をリリースさせていただいた身なので、久しぶりにRailsについて書いてみようと思う。 まあ、書籍の宣伝みたいなものです。 数日前に、noteというサービスでWebフロント側に投稿者のIPアドレスが露出するという漏洩事故が起きました。これがどれぐらい問題かは一旦置いておいて、何故こういうことになるのか、そしてRailsでよく使われるdeviseという認証機構作成ライブラリのより良い使い方について話をしていきます。 (noteがRailsを使っているか、ここで話をするdeviseを採用しているかは定かではないので、ここから先の話はその事故とは直接関係ありません。Railsだったとしても恐らく使ってないか変な使い方してると思うんですが、理由は後述) 何故こんなことが起きるのか そもそも、フロント側に何故IPアドレスを送ってんだ、という話です

                        パーフェクトRails著者が解説するdeviseの現代的なユーザー認証のモデル構成について - joker1007’s diary
                      • (翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book

                        本稿は Gergely Orosz 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 blog.pragmaticengineer.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Gergely Orosz 氏ではなく、本稿のコメント欄にお願いします。 著者も機械翻訳を下地にしたやり方に関心をもたれたようです。 The article translated to Japanese: https://t.co/4uynyyhm4E The author was transparent and noted that the article is a modification of an ML-translated article. This person managed to transl

                          (翻訳) ビッグテックのプロジェクトマネジメントとスクラム不在の謎 - forest book
                        • Design Docs at Google

                          One of the key elements of Google's software engineering culture is the use of design docs for defining software designs. These are relatively informal documents that the primary author or authors of a software system or application create before they embark on the coding project. The design doc documents the high level implementation strategy and key design decisions with emphasis on the trade-of

                            Design Docs at Google
                          • Oh Shit, Git!?!

                            Gitって難しい。簡単にぐちゃぐちゃの状態になっちゃうし、失敗を直す方法を知ろうとしたところでまじくそ不可能。Gitのドキュメンテーションって卵とニワトリの問題みたいなところがあって、ハマりから抜け出すために知ってないといけない事柄の名前をあらかじめ知っていないと、どうやって問題を解決したらいいのか検索することすらできないんだよね。 だからここに、私が遭遇したことのあるよろしくない状況から、最終的にどうやって抜け出したかをフツーの日本語で書いていこうと思う。 くっそー、超絶やらかした。お願い、Gitには魔法のタイムマシンがあるって言って? git reflog # こうすると、Gitでやったことがすべてのブランチに渡って全部見えるよ! # どのブランチにも HEAD@{index} ってインデックスがあるはずだから # やらかす前のやつを見つけて git reset HEAD@{index

                            • GitHub上のsensitive dataを削除するための手順と道のり | メルカリエンジニアリング

                              Advent Calendar day 7 担当の vvakame です。 予告では Apollo Federation Gateway Node.js実装についてポイント解説 としていましたが、社内各所のご協力によりAdvent Calendarの私の担当日に間に合う形で公開できる運びとなりました。そのため告知とは異なりますが GitHub上のsensitive data削除の手順と道のり をお届けしていきたいと思います。 メルペイVPoE hidekによるday 1の記事で振り返りがあったように、今年、弊社ではCodecovのBash Uploaderに係る情報流出という事案が発生しました。当該インシデント対応において、プレスリリースにも記載のある通り、ソースコード上に混入してしまった認証情報や一部個人情報などの機密性の高い情報(sensitive data)について調査を実施し、対応

                                GitHub上のsensitive dataを削除するための手順と道のり | メルカリエンジニアリング
                              • 30分でOpenID Connect完全に理解したと言えるようになる勉強会

                                社内向け勉強会で発表した内容です。 30分でと書いてありますが、実際には50分かかりました。 また時間の関係で結構省いたりしている箇所があります。 2020/07/19追記 ご指摘をいただいた箇所を多々修正いたしました。 特にOIDCとSPAの章が初版とは大幅に変更されていますのでご注意く…

                                  30分でOpenID Connect完全に理解したと言えるようになる勉強会
                                • スクリプト言語を舐めてはいけない|shi3z|note

                                  おれはハッカーだ。 なので、ハッカーではない人種と呑むのが苦手である。 たとえば「ITエンジニア」と自称するような人たちだ。 当然だが、ITエンジニアと自称する人はハッカーではない。 ITエンジニアと言う言葉はスコープが広すぎていちいち細かい説明を聞かなければならない。 これが厄介なところである。 あるとき、友達の家で飲み会をすると言われ、誰が来るの?と聞いたら知らないIT関連会社のエンジニアたちだという。 エンジニアと呑むと喧嘩しちゃうので断ったのだが、いろいろあっていくことになってしまった。 するとやっぱりこんなはなしをしていた。 「やっぱ私もRubyみたいなスクリプト言語なんか卒業してコンパイル言語やんなきゃ。処理速度がね…」 「コンパイル言語って?」 「TypeScriptとかJavaとかC#とか」 「それ、中間コード言語じゃねえか。なんの意味があるんだ。YARV知らないのか」 ま

                                    スクリプト言語を舐めてはいけない|shi3z|note
                                  • Minimal safe Bash script template

                                    Published on December 14, 2020   ·   Updated on December 16, 2020 Bash scripts. Almost anyone needs to write one sooner or later. Almost no one says “yeah, I love writing them”. And that’s why almost everyone is putting low attention while writing them. I won’t try to make you a Bash expert (since I’m not a one either), but I will show you a minimal template that will make your scripts safer. You

                                      Minimal safe Bash script template
                                    • Dockerイメージ分析ツール「dive」を利用してDockerイメージを軽量化する - 🤖

                                      はじめに Docker イメージサイズは小さければ小さいほど、Push と Pull の高速化につながり嬉しいです。 docker historyによってイメージレイヤーごとのサイズは分かりますが、どのレイヤーのどのファイルのサイズが大きいかは分かりません。 $ docker history maven:3-amazoncorretto-11 IMAGE CREATED CREATED BY SIZE COMMENT eb8a5bbcd061 12 days ago /bin/sh -c #(nop) CMD ["mvn"] 0B <missing> 12 days ago /bin/sh -c #(nop) ENTRYPOINT ["/usr/local/b… 0B <missing> 12 days ago /bin/sh -c #(nop) COPY file:2bbb488dd73

                                        Dockerイメージ分析ツール「dive」を利用してDockerイメージを軽量化する - 🤖
                                      • Gormが本番テーブルの数億件のデータを消そうとした話 - keroxpのScrapbox

                                        MySQLの場合、--safe-updatesオプションを利用することでこういった不慮のUPDATE/DELETEを防げるようです

                                          Gormが本番テーブルの数億件のデータを消そうとした話 - keroxpのScrapbox
                                        • 社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング

                                          この記事は、Merpay Tech Openness Month 2023 の4日目の記事です。 こんにちは。メルコインのバックエンドエンジニアの@goroです。 はじめに このGitHub Actionsのセキュリティガイドラインは、社内でGithub Actionsの利用に先駆け、社内有志によって検討されました。「GitHub Actionsを使うにあたりどういった点に留意すれば最低限の安全性を確保できるか学習してもらいたい」「定期的に本ドキュメントを見返してもらい自分たちのリポジトリーが安全な状態になっているか点検する際に役立ててもらいたい」という思いに基づいて作成されています。 今回はそんなガイドラインの一部を、社外の方々にも役立つと思い公開することにしました。 ガイドラインにおける目標 このガイドラインは事前に2段階の目標を設定して作成されています。まず第1に「常に達成したいこと

                                            社内用GitHub Actionsのセキュリティガイドラインを公開します | メルカリエンジニアリング
                                          • プログラムの「アーキテクチャに関するドキュメント」は面倒でも書くべき、ではどのように書くべきか?

                                            開発プロジェクトに新しく加わった時は、まずプロジェクトの理解が第一。しかし、全体像を把握できるようなドキュメントがなく、コードから断片的な情報をかき集めるしかない場合もあります。新参の開発者がスムーズにプロジェクトを理解できるよう、大規模なプロジェクトでは「プロジェクト全体のアーキテクチャ」を示した「ARCHITECTURE.md」を添えた方がよいと、エンジニアのAleksey Kladov氏が指摘しています。 ARCHITECTURE.md https://matklad.github.io//2021/02/06/ARCHITECTURE.md.html Kladov氏はオープンソースプロジェクトの開発に携わる中で、「プロジェクトのアーキテクチャに対する知識量」によって開発スピードに大きな差が生じると気づいたとのこと。アーキテクチャに関する知識がない開発者にとって、大量のコードは「バラ

                                              プログラムの「アーキテクチャに関するドキュメント」は面倒でも書くべき、ではどのように書くべきか?
                                            • ドキュメント駆動開発v2

                                              前提 ここで言っているドキュメントは仕様書ではなく、顧客向け製品ドキュメント。 ミドルウェア製品を開発 小さなチーム パッケージ製品とパッケージ製品のクラウド版 そのため顧客に提供するドキュメントが必ず必要 GitHub を利用 自分で開発する場合のフロー 作りたい機能をぼんやりでいいので GitHub Issue に追加する feature ブランチを切る デザインドキュメントをリポジトリの doc/ 以下に書く デザインドキュメントに合わせてコーディングを進めてなんとなく動くところまで作る 動かなくてもいいのでイメージを膨らませるためにコードを書いてみる デザインドキュメントは書き捨て前提で、とにかくメモを書く 製品ドキュメントを書き始めて、一旦書き終える ブランチマージに向けてコーディングを進める 書ける範囲でテストを書く ドキュメントを平行して修正する プルリクエストをだしてレビュ

                                                ドキュメント駆動開発v2
                                              • VSCodeでDraw.ioをLive Shareしたら最高の体験だった - 弥生開発者ブログ

                                                こんにちは、弥生のMisoca開発チームの黒曜(@kokuyouwind)です。 Kaigi on Railsの登壇が決まったのでよろしくおねがいします。弥生社員としては初登壇になります。 「おめでとうございます。 選考の結果、あなたのプロポーザルは採択されました!」 とのことなので、Kaigi on Railsお話しにいきますー— 黒曜 (@kokuyouwind) August 25, 2020 前回の記事が濃厚だったため、今回はライトなTips記事です。よろしくおねがいします。 tech.misoca.jp 👯‍♀️ VSCode LiveShareを使ったリモートペアプログラミング 皆さん、ペア作業してますか? ペアプログラミングはドライバー・オペレータの交代など具体的なノウハウも多く、このブログでも以前に紹介記事を書きました。 tech.misoca.jp 上記の記事ではリモー

                                                  VSCodeでDraw.ioをLive Shareしたら最高の体験だった - 弥生開発者ブログ
                                                • [翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita

                                                  こんにちは、食べログシステム本部長の京和です。 本エントリでは Shopify の Engineering Blog から、Kirsten Westeinde による「Deconstructing the Monolith: Designing Software that Maximizes Developer Productivity」を翻訳して掲載します。 食べログではユーザーや飲食店に価値を届けるスピードを最大化するべく、マイクロサービス化などをはじめとしたこれまでの組織やアーキテクチャを刷新するための取り組みを始めています。しかし、マイクロサービスはアプリケーションアーキテクチャとインフラアーキテクチャが複雑に絡み合ったシステムで技術的難易度が非常に高く、適切に構築できなければ「分散されたモノリス」と呼ばれるアンチパターンに陥ります。1 Shopifyではマイクロサービスではなく、

                                                    [翻訳] Shopifyにおけるモジュラモノリスへの移行 - Qiita
                                                  • また make の話してる(2020年9月14日) - なにもわからない

                                                    私の大好きな Makefile の話が盛り上がっていたのでまとめました。 「やめてね。」って方はお声がけください。 同じ会社にいるけど、真逆の感想を持っている。Makefile読まないと副作用が分からないし、Rakefile/package.jsonだけで済むのに無駄に1つレイヤ増えていて、Makefileできたときからいる人は楽だけど、途中から入った人にとっては学習コストが高い。 https://t.co/EXtmI3xl72— 神速 (@sinsoku_listy) 2020年9月13日 golangでMakefileを使うのは分かる。 ただ、RubyやNode.jsのリポジトリなら $ git clone xxx $ cd xxx $ bundle install && rake もしくは npm install && npm test で環境構築ができることを期待する。— 神速 (

                                                      また make の話してる(2020年9月14日) - なにもわからない
                                                    • (翻訳) ストーリーポイント再考 - forest book

                                                      本稿は Ron Jeffries 氏によって書かれた次の記事の日本語翻訳です。著者に翻訳の許可を得て公開しています。 ronjeffries.com また本稿は DeepL Pro を使って下訳したものに手を加えています。日本語翻訳の不具合または誤訳については Ron Jeffries 氏ではなく、本稿のコメント欄にお願いします。 ここから本文です。 ストーリーポイント再考 私はストーリーポイントを発明したかもしれない。もしそうだったとしたら、いまは申し訳なかったと言いたい。ストーリーポイントに関する私の現在の考えを探ってみよう。少なくとも何人かは私の考えに興味をもっているでしょう。 もちろん、ストーリーは XP のアイディアであり、スクラムのアイディアではありません。どういうわけか、スクラムの実践者はこのアイディアを採用しています。公式のスクラムガイドではバックログアイテムに言及している

                                                        (翻訳) ストーリーポイント再考 - forest book
                                                      • Rubyの並列並行処理のこれまでとこれから - クックパッド開発者ブログ

                                                        技術部の笹田です。今日で退職するので、バタバタと返却などの準備をしています。 本記事では、Rubyの並行並列処理の改善についての私の取り組みについて、おもに RubyKaigi 2022 と 2023 で発表した内容をもとにご紹介します。 並行と並列はよく似た言葉ですが、本記事では次のような意味で使います。 並行処理(concurrent processing)は、「複数の独立した実行単位が、待っていればいつか終わる(もしくは、処理が進む)」という論理的な概念で、古典的にはタイムシェアリングシステムなどが挙げられます。 並列処理(parallel processing)は、「複数の独立した実行単位のうちのいくつかが、あるタイミングで同時に動いている」という物理的な概念で、古典的には複数のCPU上で同時に実行させる、というものです。最近では、1つのCPU上で複数コアが同時に動いている、という

                                                          Rubyの並列並行処理のこれまでとこれから - クックパッド開発者ブログ
                                                        • 令和にふりかえる C10K 問題

                                                          C10K 問題 (the C10K problem) は1999年に Dan Kegel が発表した文章、ならびにそこで提示された「問題」です。文章はその後も2000年代前半に何度か更新されているのですが、さすがに令和に読み返すと、当初の問題意識がわかりにくいところがあります。 2000年からの10年は、 ソフトウェア面では、select(2), poll(2) にかわる新しいシステムコールの実装と、それを使ったアプリケーションの普及 ハードウェア面では、x86 アーキテクチャの64ビット移行、仮想化命令の追加と、マルチコア化 さらにそこにクラウドも登場する、面白い時代でした。ここでは、それらの出来事を中心に、さらに、当時の雰囲気をつたえるような日本国内のブログやインタビュー記事をまとめることで、C10K 問題が、さまざまな側面から解決されていく流れを説明したいと思います。 書き足したいと

                                                          • マイクロソフトの調査にみるコードのオーナーシップと品質の関係 - mtx2s’s blog

                                                            ひとつのソフトウェアコンポーネントが多くの開発者によって変更されると、品質に悪い影響を与えると経験的に感じている。設計に一貫性が失われることや、知識の浅い状態で変更することによるバグ混入の可能性が高まるからだ。 2011年9月に公開されたマイクロソフト社の調査結果、"Don’t Touch My Code! Examining the Effects of Ownership on Software Quality" は、この「コードのオーナーシップはソフトウェアの品質を左右する」という経験則を裏付けるものだった。全体のコミット数のうち5%未満の貢献にとどまる開発者が多いコンポーネントは、リリース前後における故障が増加するというものだ。 本稿では、このマイクロソフトによる調査結果を紹介し、それを踏まえた上で、ソフトウェアプロダクトの品質悪化を抑えるための組織やプロセス、アーキテクチャについ

                                                              マイクロソフトの調査にみるコードのオーナーシップと品質の関係 - mtx2s’s blog
                                                            • プロと読み解く Ruby 3.0 NEWS - クックパッド開発者ブログ

                                                              技術部の笹田(ko1)と遠藤(mame)です。クックパッドで Ruby (MRI: Matz Ruby Implementation、いわゆる ruby コマンド) の開発をしています。お金をもらって Ruby を開発しているのでプロの Ruby コミッタです。 本日 12/25 に、ついに Ruby 3.0.0 がリリースされました。一昨年、昨年に続き、今年も Ruby 3.0 の NEWS.md ファイルの解説をします。NEWS ファイルとは何か、は一昨年の記事を見てください(なお Ruby 3.0.0 から、NEWS.md にファイル名を変えました)。 プロと読み解く Ruby 2.6 NEWS ファイル - クックパッド開発者ブログ プロと読み解くRuby 2.7 NEWS - クックパッド開発者ブログ Ruby 3.0 は、Ruby にとってほぼ 8 年ぶりのメジャーバージョンア

                                                                プロと読み解く Ruby 3.0 NEWS - クックパッド開発者ブログ
                                                              • Datadog メトリクスモニター作成入門

                                                                Datadog はモニタリング関連の SaaS ではおそらく最も利用されているサービスでしょうが、公式ドキュメントが豊富にある割には何から読み始めれば良いかわかりにくく、慣れるまでの道が険しい印象です。 本エントリーでは、Datadog が既に導入されている組織で、Datadog モニターを使って監視をしたいけど、モニターの設定方法がよくわからないといった方を対象に、メトリクスモニターの作成に焦点を絞って解説していきます。なお、あくまで Datadog の使い方についての解説であり、どのようなモニターを設定すべきかについては触れません。 メトリクスの収集についても触れたかったんですが、力尽きたので、メトリクスの収集については気が向いたら別エントリーを書きます。 アジェンダ メトリクスモニターの作成方法の基本 クエリの定義について クエリの評価期間・評価方法・アラート条件の指定 クエリの結果

                                                                  Datadog メトリクスモニター作成入門
                                                                • Amazon ECSで動かすRailsアプリのDockerfileとGitHub Actionsのビルド設定 - メドピア開発者ブログ

                                                                  CTO室SREの@sinsokuです。 Dockerイメージのビルドを高速化するため、試行錯誤して分かった知見などをまとめて紹介します。 AWSのインフラ構成 assetsもECSから配信し、CloudFrontで /assets と /packs をキャッシュする構成になっています。 Rails on ECS デプロイ時にassetsが404になる問題 以前の記事に詳細が書かれているため、ここでは問題の紹介だけしておきます。 Rails等のassetsファイルをハッシュ付きで生成し配信するWebアプリケーションの場合、ローリングアップデートを行うと、アップデート時に404エラーが確立で発生してしまいます。 引用: メドピアのECSデプロイ方法の変遷 Dockerfile 実際のDockerfileには業務上のコード、歴史的な残骸などが含まれていたので、綺麗なDockerfileを用意しま

                                                                    Amazon ECSで動かすRailsアプリのDockerfileとGitHub Actionsのビルド設定 - メドピア開発者ブログ
                                                                  • GitHubのIssueやPull requestsにアップロードした画像の削除 - coincheck tech blog

                                                                    はじめに サイバーセキュリティ推進部の吉田です。普段は、CSIRTメンバーとしてAWS環境や各種端末のモニタリング、セキュリティインシデント対応、社内からのサイバーセキュリティに関する相談対応などの業務を行っています。 2023/05/10 追記 GitHubのアップデートによって、プライベートリポジトリのIssueやPull Requestsに新たにアップロードされたファイルは、権限を持たない外部からは参照できなくなったようです。詳細につきましては、以下のGitHubのブログをご確認ください。 https://github.blog/changelog/2023-05-09-more-secure-private-attachments/ 概要 GitHubのIssueやPull requestsに添付した画像はWebにアップロードされ、パブリックなURLが割り当てられます。このURLは

                                                                      GitHubのIssueやPull requestsにアップロードした画像の削除 - coincheck tech blog
                                                                    • React Server Components 総まとめ

                                                                      先日、React Server Componentsについてまとめる機会がありました。 この記事では、React Server Componentsの概要と、デモを触る中で感じたことについてご紹介します。 React Server Componentsとは React Server Componentsは、Reactコンポーネントをサーバーサイドでレンダーする新しい技術です。 一部のコンポーネントをサーバーサイドでレンダーしてしまうことで、アプリケーションのパフォーマンスを上げることを目的とします。 図は、デモの画面のうち、サーバーでレンダーされる部分を青で、クライアントでレンダーされる部分を赤で示したものです。 ページ全体をサーバーでレンダーするのではなく、一部のコンポーネントはクライアントにレンダーさせていることがわかります。 また、React Server ComponentsはCo

                                                                        React Server Components 総まとめ
                                                                      • パスキーとは何か、そしてその課題

                                                                        パスキーはフィッシングに強く、テクノロジーに詳しくないユーザーでも使いやすい新しい認証方式で、いずれパスワードを置き換えると言われています。この記事では、パスキーの基本と、これからのウェブにとってパスキーがどういう意味を持つのかについてまとめてみます。 パスキーとは何か # 2022 年 12 月 9 日に Google が Android 版 Chrome でパスキーがサポートされたとのアナウンスが出ました。Apple もすでに最新版の macOS Ventura、iOS / iPadOS 16 で Safari がパスキーに対応しています。 パスキーは Apple、Google、Microsoft が協調して使う FIDO クレデンシャルの名前です。エンドユーザーのみなさんがパスワードの代わりとして認識し、直感的にログインできるよう「パスキー」というブランドとアイコンが決まりました。ウ

                                                                          パスキーとは何か、そしてその課題
                                                                        • Datadogの活用ノウハウを一挙に公開・それを支える全社管理者の工夫とは #datadog_japan_meetup - ZOZO TECH BLOG

                                                                          こんにちは。ECプラットフォーム基盤SREブロックの高塚と巣立(@tmrekk_)です。 ZOZOTOWNはクラウド化・マイクロサービス化を進める中で、監視SaaSのDatadogを採用しました。この数年で多くの知見が蓄積され、今では様々なシーンでDatadogを活用しています。この記事ではそのノウハウを惜しみなく公開します。 ※本記事は、先日開催されたDatadog Japan Meetup 2022 Summerにて発表した内容を書き起こして再構成したものです。 当日の発表資料 speakerdeck.com 目次 当日の発表資料 目次 はじめに マイクロサービス基盤に必要な監視の要件 第1部 ZOZOTOWNにおけるDatadogの活用 1. どこで障害が起こっているのか分からない → APM 2. アラートやダッシュボードや外形監視が欲しい → Monitors, Dashboar

                                                                            Datadogの活用ノウハウを一挙に公開・それを支える全社管理者の工夫とは #datadog_japan_meetup - ZOZO TECH BLOG
                                                                          • aws-sdk-ruby配下すべてのgemにRBSが含まれた状態でリリースされました - スペクトラム

                                                                            みなさまに、RBSに関する重要なニュースを発表できることを嬉しく思います。 私の目標の一つにはRBSを当たり前の世界にするというものがあります。 この目標に対して大きなインパクトを残せたことに大変興奮しています。*1 aws-sdk-ruby配下すべてのgemにRBSが含まれた状態でリリースされました こちらは公式blogからのアナウンスです。 aws.amazon.com aws-sdk-rubyはrubygemsでの累計ダウンロードランキング2位に乗るほどの人気gemです。(aws-sdk-core) aws-sdk-rubyは現状370以上のgemのあつまりです。 このすべてのgemにRBSが含まれた状態でリリースされました。 そうです。すべてです。 rbs v3.4.0以上でご利用いただけます。 steep + vscodeの例。etagがStringであることがわかる え、なにが

                                                                              aws-sdk-ruby配下すべてのgemにRBSが含まれた状態でリリースされました - スペクトラム
                                                                            • Terraformモジュール構成のベストプラクティス - ENECHANGE Developer Blog

                                                                              VPoTの岩本 (iwamot) です。 この記事では、Terraformモジュール構成のベストプラクティスをご紹介します。Terraformドキュメントに書かれているものですが、従わずに時間を溶かした失敗談をまじえてお伝えすることで、同じ轍を踏む方が減ることを願っています。 取り上げるのは下記のベストプラクティスです。 Module Composition(フラットなモジュールツリー) Dependency Inversion(依存性の逆転) Module Composition(フラットなモジュールツリー) Module Compositionは、モジュールをフラットに並べられるよう構成すべし、という話です。Terraformドキュメントでは下記の例が挙げられています。 module "network" { source = "./modules/aws-network" base_c

                                                                                Terraformモジュール構成のベストプラクティス - ENECHANGE Developer Blog
                                                                              • Railsでブラウザテストを「正しく」行う方法(翻訳)|TechRacho by BPS株式会社

                                                                                Rubyでテストがこれほど盛んな理由のひとつはRailsの存在にあると私は信じています。Railsフレームワークはテストをできる限り楽しく書けるようにしてくれます。ほとんどの場合、網羅的なRailsテスティングガイドを参照すれば事足ります(少なくとも最初のうちは)。しかし物事に例外はつきものです。私たちの場合「システムテスト」がそれでした。 テストをページのマークアップから切り離す方法については、「Railsシステムテスト」シリーズの次の記事『System of a test II: Robust Rails browser testing with SitePrism』をご覧ください。 Railsアプリケーションでシステムテストを書いたりメンテしたりするのは、正直「楽しい」からほど遠い作業です。この問題に対処するために用いた私のアプローチは、今を去ること2013年に初めてCucumber

                                                                                  Railsでブラウザテストを「正しく」行う方法(翻訳)|TechRacho by BPS株式会社
                                                                                • zstd 圧縮したコンテナイメージを使用して AWS Fargate の起動時間を短縮する | Amazon Web Services

                                                                                  Amazon Web Services ブログ zstd 圧縮したコンテナイメージを使用して AWS Fargate の起動時間を短縮する この記事は Reducing AWS Fargate Startup Times with zstd Compressed Container Images (記事公開日 : 2022 年 10 月 13 日) の翻訳です。 AWS Fargate は、Amazon Elastic Container Service (Amazon ECS) および Amazon Elastic Kubernetes Service (Amazon EKS) 上で動作するコンテナワークロードのためのサーバーレスコンピューティングエンジンです。コンテナオーケストレーターがコンテナワークロードをスケジューリングすると、AWS Fargate はそのワークロードを実行するた

                                                                                    zstd 圧縮したコンテナイメージを使用して AWS Fargate の起動時間を短縮する | Amazon Web Services

                                                                                  新着記事









                                                                                  ApplySandwichStrip

                                                                                  pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


                                                                                  --- a PPN by Garber Painting Akron. With Image Size Reduction included!

                                                                                  Fetched URL: http://b.hatena.ne.jp/q/.tech

                                                                                  Alternative Proxies:

                                                                                  Alternative Proxy

                                                                                  pFad Proxy

                                                                                  pFad v3 Proxy

                                                                                  pFad v4 Proxy