並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 40 件 / 1255件

新着順 人気順

ロギングの検索結果1 - 40 件 / 1255件

  • N予備校プログラミング入門コースで学べること - Qiita

    私 is 誰 今年の7月にドワンゴの教育事業部に異動し、N予備校でプログラミング講師をやることになりました。 現在は週2回ニコ生やN予備校上にてプログラミング入門コースの授業放送をしています。 ドワンゴ自体は7年目となり、ニコニコ動画の開発を4年、エンジニア教育やエンジニア採用を2年ほどやってきました。 この記事で書きたいこと 現部署に異動後、教材のインプットを兼ねて『N予備校プログラミング入門コース』を履修したのですが、明らかに難易度が僕の想像した "入門コース" から外れたガチ編成になっていて衝撃を受けたことが記事を書こうと思ったきっかけです。 中身としてはとても良い教材になっているので、僕のような勿体無い誤解が少しでも減れば幸いです。 入門コースはいわゆる入門コースではない 『プログラミング入門コース』のゴールは ドワンゴがエンジニアとして採用したいレベル や IT企業のエンジニアイ

      N予備校プログラミング入門コースで学べること - Qiita
    • 【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG

      Googleでの「Design Docs」とは 2007年の Google Developer Day Tokyo での鵜飼氏のプレゼンによると「Google で必ず書くことになっているドキュメント」であり、「プロジェクト立ち上げ時の 1~2週間をかけて書く」ものです。 今回は Google のソフトウェアエンジニアである @cramforce 氏が自身のブログで「Googleでの Design Docs」について解説している記事を公開されていたため、氏の許可を得て翻訳しています。 原文: www.industrialempathy.com 関連書籍: Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス オライリージャパンAmazon 読了目安:11分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ

        【翻訳】Googleのエンジニアがソフトウェア開発する時に必ず書くドキュメント「Design Docs at Google」 - BppLOG
      • 人生を仕組み化していったら結婚できた件 - Amosapientiam

        この記事は妻にレビューしてもらっています。 概要 この春結婚しました。 我々二人の生活は、多くの仕組み化・組織化を実行しているという点でかなり変である、ユニークだと思います。この記事では我々が導入している仕組み化を紹介していきたいと思います。 経緯 妻とは一年ほど前から人生をよりよく生きるためのアドバイスをし合う朋友・盟友的関係を築いていました。 お互いの人生には課題が山積しており、それを抜本的に改善する必要があったのです。 そのために我々は仕組みの力に頼ろうと、さまざまな人生の仕組み化を図りました。 改革は功を奏し、我々の抱えていた諸問題は対処可能になっていきました。 また、お互いの課題解決的なコミュニケーションが大いに促進され、相互理解が深まっていきました。 我々の協力関係が実り多いものであることを深く確信した我々は、お互いの人生に貢献したい、二人三脚でこの人生を楽しんでいきたい、一緒

          人生を仕組み化していったら結婚できた件 - Amosapientiam
        • 【2020年】AWS全サービスまとめ | DevelopersIO

          このエントリは、2018年、2019年に公開したAWS全サービスまとめの2020年版です。これまではいくつかに分割して公開していましたが、1エントリにまとめてほしいという要望をもらっていたため、今年は1エントリに集約してみました。 こんにちは。サービスグループの武田です。 このエントリは、2018年、2019年に公開した AWS全サービスまとめの2020年版 です。これまではいくつかに分割して公開していましたが、1エントリにまとめてほしいという要望をもらっていたため、今年は1エントリに集約してみました。どちらがいいのか正直わからないので、フィードバックなどあれば参考にさせていただきます。 2020-01-08 リクエストがあったためAmazon Mechanical Turkを追加。 2018年まとめ 【2018年】AWS全サービスまとめ その1(コンピューティング、ストレージ、データベー

            【2020年】AWS全サービスまとめ | DevelopersIO
          • ロギングベストプラクティス - kawasima

            #翻訳 https://www.scalyr.com/blog/the-10-commandments-of-logging/ CC BY 4.0 @Brice Figureau 1.自分でログの書き出しをしない printfをつかったり、ログエントリを自分でファイルに書き出したり、ログローテションを自分でやったりしてはいけない。運用担当者にお願いして、標準ライブラリやシステムAPIコールを使うようにしよう。そうすれば、実行中のアプリケーションが他のシステムコンポーネントと適切に連携して、特別なシステム設定なしに適切な場所またはネットワークサービスにログを記録できるようになる。 ロギングライブラリを使いたければ、特にJavaの世界にはLog4j, JCL, slf4j, logbackなど多くのものが存在する。私はslf4jとlogbackを組み合わせて使うのが好きだ。とてもパワフルで、設

              ロギングベストプラクティス - kawasima
            • システム運用アンチパターン

              上層部がDevOpsに理解のない組織で働き、組織構造を変える権限を持っていない開発者であっても、チームにDevOpsを導入するための現実的な方法を紹介します。 重厚な承認プロセス、可視化されていない運用、プロセスの最後でのみ行われるソフトウェアテスト、ノイズだらけのアラート、インシデントから学習しない習慣、時間外のデプロイ、情報のため込みなどを取り上げ、ソフトウェアシステムの開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして紹介します。そして管理職やマネージャでなく、エンジニアが実行し、繰り返すことで改善できる具体的な行動を解説します。 組織で必要とされる変化を、エンジニアが行動することで実現する本書は、ソフトウェアシステムをよりよく開発運用したいエンジニア必携の一冊です。 目 次 序文 本書について 1章 DevOpsを構成するもの 1.1

                システム運用アンチパターン
              • ChatGPTを業務に組み込むためのハンズオン.pdf

                ChatGPTを業務に組み込むためのハンズオン 2023/06/26 一般公開用 デジタル庁 Fact&Data Unit 大杉直也 ↑マイナンバー交付数のダッシュボードを作っているところです 「Microsoft でテストされたアイデアのうち、改善を示すメトリクスを実際に改善できたのは3分の1にすぎない」 (Microsoft社 元Vice President) 「もしあなたが実験主導のチームにいるなら、70%の仕事が捨てられることに慣れてください。それに応じてプロセスを構築しましょう」(Slack社 Director) A/Bテスト実践ガイド p14より 一方で 「アイデアの価値を見積もることは難しい。このケースでは、年間1億ドルの価値ある単純な変更が何か月も遅れていた。」(同著 p5より) こともあります 午前中のアイデアソンで出たアイデアはちゃんと検証するまで価値があるかは不明です

                • 機械学習システムの設計パターンを公開します。

                  メルカリで写真検索とEdge AIチームに所属している澁井(しぶい)です。機械学習のモデルを本番サービスに組み込むための設計やワークフローをパターンにして公開しました。 GithubでOSSとして公開しているので、興味ある方はぜひご笑覧ください! PRやIssueも受け付けています。私の作ったパターン以外にも、有用なパターンやアンチパターンがあれば共有してみてください! GitHub:https://github.com/mercari/ml-system-design-pattern GitHub Pages:https://mercari.github.io/ml-system-design-pattern/README_ja.html なぜ機械学習システムのデザインパターンが必要なのか 機械学習モデルが価値を発揮するためには本番サービスや社内システムで利用される必要があります。そのた

                    機械学習システムの設計パターンを公開します。
                  • しずかなインターネットの技術構成

                    こんなWebサービスをリリースしたので、技術的な話をまとめておこうと思います。 元々このサービスは、趣味の延長線のような感じで開発を始めました。競合にあたるnoteやはてなブログなどのサービスが確固たる地位を築いているということもあり、「お金にはならないだろうけど、自分の趣味を詰め込んだものにしよう」というゆるい気持ちで開発を続けています(楽しい)。 選定の方針 趣味と言っても文章投稿サービスなので、ユーザーが少数であったとしても長期間運営しなければなりません。そのため、ユーザー数が少なければランニングコストが数千円/月以下、ユーザー数が増えたときは段階的にコストが上がるように選定を行いました。 アプリケーション フルスタックNext.jsアプリケーションをCloud Runにデプロイしています。各APIエンドポイントはNext.jsのAPI Routesで生やしています。 Next.js

                      しずかなインターネットの技術構成
                    • AWS全資格の概要と主な学習コンテンツをまとめてみた | DevelopersIO

                      本ブログは、2021 AWS Partner Ambassadors で構成するアドベントカレンダー Japan APN Ambassador Advent Calendar 2021 の 24 日目のエントリです。 こんにちは。CX事業本部MAD事業部のYui(@MayForBlue)です。 年の瀬も迫った12/24ですが、みなさん資格勉強してますか?(挨拶 さて、IT系の資格の中でも人気の高いAWSの資格ですが、数も多いし何から取ったらいいのかわからない・・・という方も多いのではないでしょうか。 この記事ではAWSの全資格を紹介するとともに、2021 ALL AWS Certifications Engineers ホルダーとして資格取得やAWSの学習に有用なコンテンツをまとめてみました。 本ブログをご一読いただくことでAWSの資格取得の一歩を踏み出していただければ幸いです。 想定読者

                        AWS全資格の概要と主な学習コンテンツをまとめてみた | DevelopersIO
                      • ヤフー全社横断「Webパフォーマンス改善」の取り組み (Core Web Vitalsスコアの向上)

                        ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、第11代黒帯(ヤフー内のスキル任命制度/Webフロントエンド領域)の浜田(@narirow)です。今回はヤフー全社で実施してきた、「Webパフォーマンス改善プロジェクト」についてお話ししたいと思います。 長期に渡る活動の結果、多くのサービスのWebパフォーマンスが徐々に向上しています。この記事では、取り組みの経緯や、多くのサービス分析を通してわかったコスパの良い施策(比較的簡単に実施できてスコアも上がりやすい施策)などをご紹介します。 全社横断でWebパフォーマンス改善を実施する経緯 さかのぼること2021年、Googleから以下のような案内がありました。 「Core Web VitalsがGoogle検索の検索順位に

                          ヤフー全社横断「Webパフォーマンス改善」の取り組み (Core Web Vitalsスコアの向上)
                        • エンジニアのスキルマップ・テックリードへの途 - 電通総研 テックブログ

                          みなさんこんにちは。電通国際情報サービス(ISID) 金融ソリューション事業部の水野です。 これは電通国際情報サービス Advent Calendar 2022の16日目の記事です。 今回は、ISID金融事業部で運用しているスキルマップについてご紹介します。 テックリードとは 実は、ISIDの少なくとも金融事業部にテックリードと言うポジションはありません。 実在するのはチーフアーキテクトと言う職種のみで、各プロジェクトでリードエンジニアやテックリードという仮想的なロールがあるのが実態です。 一時期はフルスタックエンジニアと呼んでいる時期もありましたが、近年このワーディングが好まれない印象なので、大々的に使っていません。 主観ですが、フルスタックエンジニアはインフラ知識/運用系の知識のウェイトが高いエンジニアで、テックリードはソフトウェアアーキテクチャ、Webアプリケーション実装技術寄りのエ

                            エンジニアのスキルマップ・テックリードへの途 - 電通総研 テックブログ
                          • GraphQLを導入する時に考えておいたほうが良いこと | メルカリエンジニアリング

                            はじめに こんにちは、ソウゾウSoftware Engineerの@sue71です。連載:メルカリShops 開発の裏側 Vol.2の13日目を担当させていただきます。 以前メルカリメルカリShopsの技術スタックと、その選定理由でBFFの実装にGraphQLを採用していることをお伝えしました。メルカリShopsをリリースしてから約半年たった今、これまでを振り返ってGraphQLサーバーを実装する上での課題やあらかじめ考えておくと良い項目をまとめてみました。また、本記事ではメルカリShopsでGraphQLの実装としてApolloを採用しているため、Apolloの利用が前提の話もいくつか混在しています。予めご容赦ください。 GraphQLの説明や、メルカリShopsの実装方法に関しては以前こちらの記事で紹介しています。こちらも是非ご覧ください。 パフォーマンス課題 GraphQLは、アプリ

                              GraphQLを導入する時に考えておいたほうが良いこと | メルカリエンジニアリング
                            • DBMSをGoで実装してみた - Sansan Tech Blog

                              こんにちは。プロダクト開発部の荒川 id:ad-sho-loko です。突然ですが、皆さんはこんな疑問を持ったことはありませんか? データベースの内部実装はどうなっているのか? トランザクションとはどのようなアルゴリズムで実現されているのか? NoSQLが遅いのはなぜか? 古典的なデータベースとは内部的にどのように違うの? データベースを何かしらの形で利用しているのにも関わらず、意外と内部の仕組みを理解していない場合が多いかと思います。僕もそうです。*1 しかし、エンジニアたるもの、その仕組みを知ることは非常に重要です。僕もデータベースについて勉強しようといくつかの本やサイトを調べていたのですが、なかでもCMU(カーネギーメロン大学)のDatabase System Groupがアップロードしている講義が最も勉強になりました。 www.youtube.com そして本ブログでは、上記の講義

                                DBMSをGoで実装してみた - Sansan Tech Blog
                              • AWSアカウントを作成したら最初にやるべきこと -セキュリティ編- - Qiita

                                JAWS-UG 初心者支部 #22 ハンズオン用の資料です。 目的 AWSアカウントを不正利用されないために、アカウントを作成したらまずやるべきセキュリティ周りの設定を行います。 前提 AWSアカウントを作成済みであること AWSアカウントにログインしていること リージョンは東京リージョンを利用します ハンズオン手順 アカウント周りの設定 ルートアクセスキーの削除 ※ルートアカウントのアクセスキーは、デフォルトでは作成されておりません。アクセスキーを作成済みの方を対象とします。 ルートアカウントは全てのサービスへのアクセスが出来てしまうため、ルートアカウントは使用せず、IAMユーザーを使用しましょう。 CLI等のプログラムアクセスも不要なため、アクセスキーを削除します。 https://console.aws.amazon.com/iam/home#/security_credential

                                  AWSアカウントを作成したら最初にやるべきこと -セキュリティ編- - Qiita
                                • レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ

                                  技術部の外村(@hokaccha)です。今回はクックパッドのウェブサイトのフロントエンドを Next.js などを使って作り直している話を書きます。 この記事で紹介する新システムは、スマートフォン向けのレシピページで確認することができます。もし興味があるかたはレシピページをスマートフォンのユーザーエージェントで開いて DevTools などで確認してみてください。 Next.js と GraphQL で動いているのがわかると思います。 ご存じの方も多いかもしれませんが、クックパッドのウェブサイトはモノリシックな Rails で作られていて、10年以上 Rails で開発を続けてきました。10 年以上同じシステムで開発を重ねれば当然レガシーな部分が大量に生まれてきますが、特にフロントエンドはその影響が顕著でした。 どこから使われているかわからない CSS が大量にある、JS のコードは昔なが

                                    レシピサービスのフロントエンドを Next.js と GraphQL のシステムに置き換えている話 - クックパッド開発者ブログ
                                  • [2020年版]最強のAWS環境セキュリティチェック方法を考えてみた[初心者から上級者まで活用できる] | DevelopersIO

                                    「AWS環境のセキュリティが不安だ…」そんな方にはセキュリティチェック!AWSでは定量的にチェックすることができる機能があります。いくつかあるので長短などを説明しつつ私が思う最強のセキュリティチェックを伝授します! こんにちは、臼田です。 みなさん、AWS環境のセキュリティチェックしてますか?(挨拶 全国のAWSのセキュリティについて悩んでいるみなさまのために、今回は僕の考える最強のAWS環境セキュリティチェックについて情報をまとめ・伝授します。 初心者向けに、比較的AWSの経験が浅くても始めやすいように、かつ上級者が応用するために活用できる情報もぜんぶまとめていきます。 この記事は2020年の決定版となるでしょう!(それ いいすぎ。 ながーくなってしまったので最初は適宜飛ばして読むといいかもしれません。 AWS環境のセキュリティチェックの意義 AWS環境でセキュリティチェックをすることは

                                      [2020年版]最強のAWS環境セキュリティチェック方法を考えてみた[初心者から上級者まで活用できる] | DevelopersIO
                                    • 【2021年】AWS全サービスまとめ | DevelopersIO

                                      こんにちは。サービスグループの武田です。このエントリは、2018年から公開しているAWS全サービスまとめの2021年版です。 こんにちは。サービスグループの武田です。 このエントリは、2018年から毎年公開している AWS全サービスまとめの2021年版 です。昨年までのものは次のリンクからたどってください。 AWSにはたくさんのサービスがありますが、「結局このサービスってなんなの?」という疑問を自分なりに理解するためにまとめました。 今回もマネジメントコンソールを開き、「サービス」の一覧をもとに一覧化しました。そのため、プレビュー版など一覧に載っていないサービスは含まれていません。また2020年にまとめたもののアップデート版ということで、新しくカテゴリに追加されたサービスには[New]、文章を更新したものには[Update]を付けました。ちなみにサービス数は 205個 です。 まとめるにあ

                                        【2021年】AWS全サービスまとめ | DevelopersIO
                                      • 6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない?となった話 - データエンジニアの酩酊日記

                                        ここ半年ぐらい、かなり久々にクラウド使ってアプリやバッチの基盤作ったりしてきて、色々と思ったことを書き捨てる。 「ちょっと検証してみた」程度のものも含めれば、AWSとGCPは一通り主要なマネージドサービスを触ったし、実際に複数のアプリやらバッチやらをマネージドサービス上で本番稼働させて今も運用してるけど、結局DB以外は基本全部Kubernetesに乗せるのが一番楽だと強く思うようになった。 Kubernetesは学習コストや運用コストがそれなりに高く付くから安易に採用するのはどうなのか、みたいな論調もあるし、つい半年前までは自分もそう思ってた。サーバレスなマネージドサービスが色々出てきているのに、なんでわざわざKubernetesクラスタなんていう設計、運用に手間のかかるクラスタリングサーバーを立てて管理しないとならんのかと。 だけど、実際にいくつかのマネージドサービス使ってアプリやバッチ

                                          6年ぶりぐらいにクラウド使った結果、Kubernetes以外のマネージドサービスとか基本要らなくない?となった話 - データエンジニアの酩酊日記
                                        • Amazon API Gateway は何をしてるのか | DevelopersIO

                                          アプリケーションをユーザに公開する場合, それがGUIであってもCUIであってもインタフェースが必要になります. Webアプリケーションを公開する場合にはWeb APIを利用するのが一般的であり, AWSもAPIをフルマネージドで活用するためのAPI Gatewayを提供しています. 非常に簡単に活用できるのですが細かい機能などを今一度洗い直す機会があればと思っており, 社内勉強会の機会があったのでAPI Gatewayについて話しました. 今回の記事では社内向け勉強会で登壇した内容をブログ向けに再編しています. 資料はSpeakerDeckで公開していますが, 内容についてより細かくこのブログで説明しますので, 是非ご閲覧ください. What is API まず最初にAPIが何かを確認します. 大雑把に伝えるとアプリケーションが呼び出せば予期した結果を返されるような仕組みです. 名前にあ

                                            Amazon API Gateway は何をしてるのか | DevelopersIO
                                          • 社内無線LAN環境改善のためにやったこと (2019/Summer) - astamuse Lab

                                            こんにちは。並河(@namikawa)です。 すっかり秋の足音が聞こえてまいりました。秋といえば食欲の秋。ラーメンの秋です。 会社では最近新しい方がたくさん入社してきてくれていて嬉しい限りで、エンジニアやデザイナーも増えてきています。 面接をしていても「社内の雰囲気ってどんな感じなんですか〜?」なんて聞かれることも多いので、ちょっと最近入社されたエンジニアの方のデスクを紹介してみようと思います。 弊社では、入社される方全員に、業務で使うマシンの希望を伺っているのですが、エンジニア・デザイナーは MacBook Pro を選択される方がほとんどです。エンジニアの場合はそれに 32 インチの 4K モニターを一緒に貸与することが多く、デザイナーは EIZO のモニター(27インチ、2枚等)とか希望を伺いながら決める感じです。 参考までに、池田さんが書いてくれた、4Kモニターを使っているレポート

                                              社内無線LAN環境改善のためにやったこと (2019/Summer) - astamuse Lab
                                            • 2019年のDevOps/MLOpsエンジニアの標準的スキルセット - Qiita

                                              ちなみに、IT業界全体のシェアとしてはMicrosoftのAzureの方がGCPを上回っていますが、Web業界においてIaaSにAzureを採用している企業さんは2019年時点ではまだまだ少ないので、現状ではとりあえずAzureへのキャッチアップは後回しにしておいて問題ないと思われます。 クラウドアーキテクチャ設計 前述したAWSやGCPの各種マネージドサービスを適切に組み合わせてアーキテクチャ設計を行い、それを構成図に落とし込める能力は必須となります。 いわゆる「アーキテクト」という職種の担当領域でもありますが、「サービスを安定稼働させたまま、バリューをユーザに迅速に届ける」ためには、自動化のしづらい構成が採用されてしまったり、無駄な機能が開発されてしまったり、アンマネージドなツールやサービスが使用されて管理工数が肥大化したりしないように、アーキテクチャ設計の段階からDevOpsエンジニ

                                                2019年のDevOps/MLOpsエンジニアの標準的スキルセット - Qiita
                                              • ブラウザバック時の表示を最適化する Yahoo!ニュースの取り組み事例

                                                ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは。Yahoo!ニュース を担当しているエンジニアの喜楽です。 今回は、Yahoo!ニュースが取り組んでいるブラウザバック時の表示最適化手法について紹介します。 なぜブラウザバック時の挙動に注目するのか ユーザーがYahoo!ニュースのページを閲覧し、別のページに遷移する方法は大きく分けて以下の2つが考えられます。 (A) リンクをたどってページを遷移する (B) ブラウザーのナビゲーションボタンまたはスワイプ操作によって遷移する 「戻る」による遷移(ブラウザバック) 「進む」による遷移(ブラウザフォワード) Yahoo!ニュースでは総PVのうち一定程度が(B)のブラウザバックまたはブラウザフォワードによるページ遷移時のも

                                                  ブラウザバック時の表示を最適化する Yahoo!ニュースの取り組み事例
                                                • 10年以上のノウハウを詰め込んだ「自走プログラマー」を執筆しました - Make組ブログ

                                                  自走プログラマー表紙 「自走プログラマー」という本が出ます! この本は僕と清水川さん、tell-kさんで、株式会社ビープラウドの仕事として書いた本です。 自走プログラマーには僕の10年来の開発ノウハウを詰め込みました。清水川さんtell-kさんに至ってはもっと長い経験があります。その3人が、入門本ではない本を本気で書きました。さらにビープラウドのつよつよメンバーが何度も何度もレビューしてくれました。 僕は自走プログラマーを多くの人にぜひ読んでほしいと思っています。ですが、「とにかく買ってほしい」とはあまり思っていません。 なぜかというと、普段、 僕(著者全員)が伝えたいこと・伝えてきたことを書いた本 だからです。 なので「多くの人に読んで欲しい」、「これで助けになってほしい」と思っています。むしろビープラウドでは自走プログラマー(とPythonプロフェッショナルプログラミング)を読んでもら

                                                    10年以上のノウハウを詰め込んだ「自走プログラマー」を執筆しました - Make組ブログ
                                                  • [社内資料公開]営業向けAWSセキュリティ勉強会 | DevelopersIO

                                                    クラスメソッドでは、定期的にエンジニアから営業向けの勉強会を行なっています。先日、セキュリティに関する勉強会を行いました。せっかくなので、皆さんにも資料を共有します。 クラスメソッドでは、定期的にエンジニアから営業向けの勉強会を行なっています。先日、セキュリティに関する勉強会を行いました。せっかくなので、皆さんにも資料を共有します。 セキュリティはなぜ難しいのか? セキュリティに関するAWSサービスはたくさんあり、またパートナー製品も数多くリリースされています。 セキュリティのために何をすればいいのかよくわらない方も多いかと思います。 なぜセキュリティは複雑で難しいのでしょうか? 私たち自身のセキュリティについて考えてみる AWSのセキュリティを考える前に、私たち自身のセキュリティについて考えてみましょう。 私は今、会社の会議室に同僚といます。 皆さんも会社の会議室にいるシチュエーションを

                                                      [社内資料公開]営業向けAWSセキュリティ勉強会 | DevelopersIO
                                                    • マイクロサービスに次に来るかもしれない言葉について - arclamp

                                                      2021年9月18日に開催されたXP祭り2021で「マイクロサービスに至る歴史とこれから」という講演をしました。資料は次の通りです。本来は75分ぐらいかかるのを45分で話そうとして、余裕で時間オーバーしてすみませんでした。 テクノロジーとテクニックによる進化の流れ テクノロジーやテクニックは、ITの改善サイクルを向上させるために進化を続けています。「技術そのもの」であるところのテクノロジーに対して、テクニックというのは「人による技術の活かし方」を示します。なので、基本的にはテクノロジーが生まれ、それを使いこなしたテクニックが登場することになります。 テクノロジーとテクニックの進化の歴史現在、進化中のテクノロジーであるCloud NativeやServerlessを前提としたテクニックを示す用語、つまり、マイクロサービスに次に来るかもしれない言葉というのは、時間軸からすると再来年ぐらいに出て

                                                        マイクロサービスに次に来るかもしれない言葉について - arclamp
                                                      • 【レポート】AWS における安全な Web アプリケーションの作り方 #AWS-55 #AWSSummit | DevelopersIO

                                                        この記事では、5月12日に行われた AWS Summit Online 2021 のオンラインセッション『AWS における安全な Web アプリケーションの作り方(AWS-55)』の模様をレポートします。 セッション概要 情報処理推進機構(IPA) の公開している「安全なウェブサイトの作り方」をはじめとしたセキュリティを考慮した安全なウェブアプリケーションの設計ガイドラインがいくつか知られています。本セッションでは、アプリケーション開発者向けにガイドラインに則ったアプリケーションを AWS 上でどのように実装するのかを AWS プラットフォームレイヤーとアプリケーションレイヤーのそれぞれの観点から項目ごとに解説し、アプリケーション導入前、または導入後のセキュリティ対策の指標となることを目指します。 登壇者 アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテク

                                                          【レポート】AWS における安全な Web アプリケーションの作り方 #AWS-55 #AWSSummit | DevelopersIO
                                                        • Webフルスタックエンジニアになるためのチェックリスト

                                                          Webフルスタックエンジニアになるためのチェックリスト Zennでの投稿にあたって この記事は、2020/03/22に自分のgithubリポジトリで公開していた内容を、Zennのgithubリポジトリ連携機能を用いて一般公開したものです。 投稿にあたって、Zennの記事連携フォーマットに準拠する以外の修正は加えておりませんので、一部Zennというプラットフォームの方針や雰囲気に合わない内容などあるかもしれません。あらかじめご了承ください。 はじめに 日本のWeb開発業界で「フルスタックエンジニア」になるために必要な知識を、個人的経験からまとめました。 フルスタックエンジニアの定義ですが、ここでは、 企業で開発リーダー/テックリードとして、Webブラウザアプリケーションを前提としたサービスの立ち上げからリリース、運用まで面倒を見られる。 というロールと仮定し、前提条件としては、どちらかという

                                                            Webフルスタックエンジニアになるためのチェックリスト
                                                          • 「Pragmatic Terraform on AWS」が神本だったので紹介する - Qiita

                                                            はじめに Pragmatic Terraform on AWS、控えめにいって神本です。 AWSの知識がある程度ある人が、IaC入門するのに最適すぎる。 今週中にやり終わりそうなので、金曜あたりにレポ書きます。 — nari@エンタメ系エンジニア (@fukubaka0825) June 1, 2019 予定より、ちょっと遅くなってしまいましたが、宣言通り書評書いていこうと思います。。 ただただ「Pragmatic Terraform on AWS」を褒めちぎるだけの記事になってしまうことをご了承ください。。 こんな人にオススメ AWSの知識がある程度あって、IaC(Infratecture as Code)に入門してみたい人 他のIaCのツール(CloudFormationとか)を使っていてterraform使ってみたい人 AWSもIaCも全くわからん、、だとちょっと進めるのが辛いかもし

                                                              「Pragmatic Terraform on AWS」が神本だったので紹介する - Qiita
                                                            • GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita

                                                              概要 Design Documentと聞くと何を想像しますか? 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの?」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは? Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する人が作成するドキュメントです。 => ソフトウェア設計における仕様書や設計書とは別物と捉えた方がよいです。 仕様書、設計書は作成した上でのDesign Docsの作成となるようです。 このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられて

                                                                GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita
                                                              • Webサービスの障害対応のときの思考過程 - ぱいぱいにっき

                                                                起こってほしくはないのですが、あらゆるWebサービスは完璧に動作する状態を維持することは難しく、やはり障害対応・トラブルシューティングといった作業が発生します。 筆者は普段仕事で障害対応を不幸なことによくやるのですが、障害対応のスキルというのはスピードや判断の正確さが求められるせいか、今までやったことがある人・ノウハウがある人に集中し、それ以外の人は眺めるだけ・あとからログを見返すだけの状態によく陥ることがあります。 これはWebサービスを開発・運用するチームとしてみたときにそういった苦労が特定の人に集中するのは良くないので、それを緩和する目的として、筆者が障害対応時に考えていることを記述してみます。なお、これが唯一の正解ではないとは思っているので、ツッコミや、自分はこう考えているよというのを教えていただければ幸いです。 具体的な手法を避けて思考の方法を述べているのは、障害というのはパター

                                                                  Webサービスの障害対応のときの思考過程 - ぱいぱいにっき
                                                                • スワップの弁護:よくある誤解を解く

                                                                  (This post is also available in English.) この記事は In defence of swap: common misconceptions を 著者の Chris Down さんの許可 を得て Hiroaki Nakamura が日本語に翻訳したものです。 原文のライセンス は CC BY-SA 4.0 であり、翻訳のライセンスも同じく CC BY 4.0 とします。 長文を読みたくない方への要約: スワップを持つことは正しく機能するシステムのかなり重要なポイントです。 スワップが無ければ、まともなメモリ管理を実現することは難しくなります。 スワップは一般的に緊急事態用のメモリを取得するためのものではなく、メモリの回収を平等に効率的に行うためのものです。 実のところ「緊急事態用のメモリ」は一般的に盛大に悪影響を及ぼします。 スワップを無効にすることは

                                                                    スワップの弁護:よくある誤解を解く
                                                                  • 5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる

                                                                    はじめに 本稿は、オープンソースの可観測性(Observability)プロジェクトである OpenTelemetry を取り上げた書籍「Learning Opentelemetry」の読書感想文です。従来の可観測性の課題であったデータの分断を解消し、トレース、メトリクス、ログなどの様々なテレメトリデータを統合的に扱うことができる OpenTelemetry は、可観測性の分野における革命的な存在と言えます。 過去10年間で、可観測性はニッチな分野から、クラウドネイティブの世界のあらゆる部分に影響を与える数十億ドル規模の産業へと発展しました。しかし、効果的な可観測性の鍵は、高品質のテレメトリデータにあります。OpenTelemetryは、このデータを提供し、次世代の可観測性ツールと実践を開始することを目的としたプロジェクトです。 learning.oreilly.com 本書の想定読者は、

                                                                      5年後には標準になっている可観測性のこと - Learning Opentelemetry の読書感想文 - じゃあ、おうちで学べる
                                                                    • Pythonで作るサーバーレス環境 AWSのスペシャリストが教えるLambdaの基本

                                                                      「みんなのPython勉強会」は、Pythonを中心として、プログラミングを仕事、研究、趣味など、さまざまなシーンで生かす方法を一緒に学ぶ勉強会です。56回の今回は、サーバーサイドエンジニアをテーマに学びます。 AWSソリューションアーキテクトの西谷圭介氏が、前半ではサーバーレスについて説明しましたが、後半はいよいよその実行環境であるAWS Lambdaの基本について解説します。関連資料はこちら。 イベントドリブン 西谷圭介氏:Lambdaには、イベントドリブンという言葉があります。イベントドリブンをちょっと簡単に説明したいと思うんですが、Lambdaとかサーバーレスアプリケーションにおける非常に重要なキーワードなんですね。先ほどのサーバーレスのスタックに置き換えたときにLambdaというものがようやく出てきたんですが、このイベントドリブンをキーワードにしたサービスと言えます。 イベントド

                                                                        Pythonで作るサーバーレス環境 AWSのスペシャリストが教えるLambdaの基本
                                                                      • MySQL 5.7 から 8.0 にしたらテストが激遅になった - Qiita

                                                                        この記事は、株式会社カオナビ Advent Calendar 2023 の3日目です。 はじめに 株式会社カオナビの高橋(@kunit)です。 今回は MySQL バージョンアップ(5.7 -> 8.0) で起きた問題とそれに対してどのように対処したのかを書いていこうと思います。 何が起きたのか MySQL 5.7 から 8.0 にバージョンアップをするにあたって、CI およびローカル環境でテストができるように MySQL 8.0 のイメージを作成し、それをつかって各機能の担当者にテストを開始してもらっていたのですが、以下のような事が起きました。 接続を MySQL 5.7 から 8.0 に切り替えただけでテストの時間が3倍くらいかかるようになった そこを変更するだけで3倍遅くなるってやばいぞということで報告してくれた担当者と同じテストを自分でも実施してみると再現性があり、それが以下のどの

                                                                          MySQL 5.7 から 8.0 にしたらテストが激遅になった - Qiita
                                                                        • ZOZOTOWNのWebホーム画面をNext.jsでリプレイスして得た知見 - ZOZO TECH BLOG

                                                                          はじめに ZOZOTOWN開発本部の武井と申します。ZOZOTOWNのフロントエンドリプレイスプロジェクトを主に担当しております。ZOZO DEVELOPERS BLOG でも「ZOZOのリプレイスプロジェクトで得られる唯一無二の経験。大規模サービスを進化させるやりがいとは」というインタビュー記事を掲載しておりますので、もしよろしければこちらも併せてご覧ください。 さて、本題です。現在ZOZOTOWNではオンプレミスかつ、モノリスだった既存システムをマイクロサービスAPIに責務を分割したり、インフラをクラウドに移行したりしています。しかし、いわゆるWebのUIを構築するためのシステムは現在も既存システムに新機能開発や機能改修を行なっており、リプレイスに着手できていませんでした。 そこで、まずホーム画面から段階的にリプレイスすべく設計・開発を昨年から行ない、無事リリースできました。ZOZOT

                                                                            ZOZOTOWNのWebホーム画面をNext.jsでリプレイスして得た知見 - ZOZO TECH BLOG
                                                                          • ミラティブのサーバサイドをGo + Clean Architectureに再設計した話 - Mirrativ Tech Blog

                                                                            こんにちは、テックリードの夏です。 今年4月にCTOからテックリードに肩書が変わり、ガリガリコードを書くようになりました。 背景については、こちらをご覧ください。 www.wantedly.com 普段はプロダクト側の機能開発と、サーバ側の基盤開発を半々ぐらいの割合で仕事しています。 一口にサーバ側の基盤開発といっても定義が曖昧なのですが、基本的にはこんな感じのタスクをやっています。 インフラコストの最適化 不正なアクセスからの防御 障害の再発防止 新技術の導入やアーキテクチャの整備 今回はこのうち「新技術の導入やアーキテクチャの整備」の中で、サーバサイドをGo + Clean Architectureで再設計したことについてお話したいと思います。 背景 ミラティブは2015年春頃に開発が始まり、同年8月にサービスがリリースされ、2020年8月で5周年を迎えました。 その過程で組織やプロダ

                                                                              ミラティブのサーバサイドをGo + Clean Architectureに再設計した話 - Mirrativ Tech Blog
                                                                            • Only My Rails Way

                                                                              これは何 「Rails Wayに沿って〜」とはReview欄などでよく言われるが、定義が人によってぶれている気がするので俺のRails Wayを示した記事です。 もはや本来のモノとは別物かも知れませんが、俺はこういう観点でRailsをみて、コードを書いているよ、ということを知ってもらう意味でもこの記事を公開することにしました。 前提として、「数人以上のチームでプロダクトを実際に開発して運用する」場合の自分のスタンスを示したものです。(私も仕事では独自DSLは書きませんが自由研究用途なら自分も独自DSLを書いたりします。) それでは、いってみましょう。 Model層 データベースの操作およびビジネスロジックを記述する。 テーブルの属性は原則NOT NULLにするべき。どうしても要件上NULLを許容しなければならない場合のみNULLを許容する。 Controllerからparamsを無思考で渡

                                                                                Only My Rails Way
                                                                              • PayPayがAWSを使い続ける理由 日本No.1のQR決済サービスを支えるインフラ構成

                                                                                ZOZO×一休×PayPay AWS Nightは、2020年7月22日に開催されたZOZOテクノロジーズ・一休・PayPayの3社による合同イベントです。各社それぞれAWSの活用事例を紹介します。PayPay株式会社プラットフォームチームの西中氏がPayPayのインフラの概要について話しました(記事内の情報はイベント開催時点のもの)。 日本のNo.1 QRコード決済サービス 西中智樹氏(以下、西中):「PayPayでのAWS活用事例について」と題して、PayPay Platformチーム・西中が発表いたします。 簡単に自己紹介します。西中智樹と申します。2018年12月よりPayPayで仕事をしていまして、現在、AWSなどのPayPayのインフラを所管するPlatformのチームに所属しています。好きなAWSサービスはEKSです。 本日のセッションのアジェンダになります。この順番でお話を

                                                                                  PayPayがAWSを使い続ける理由 日本No.1のQR決済サービスを支えるインフラ構成
                                                                                • インフラど素人が1ヶ月半でKubernetes本番環境を作るまでの失敗の軌跡(奇跡) - Qiita

                                                                                  タイトル通りですが、1年目エンジニアのインフラのイの字も知らなかった私が1ヶ月半かけてKubernetesで環境構築するまでの失敗の軌跡です(そして環境構築できたのが奇跡)。 理想的にはこれを読めばインフラ初心者でもKubernetes(以下k8s)で環境構築できるところまで説明することですが、そういうわけでなく、環境構築の解説というより自分の失敗やつまづきポイント、役に立ったことをただただ書き連ねていきます。ただ他の初心者の方も同じようなところでつまづくこともあると思うので少しでもお役に立てたら嬉しいです。 バックエンド側で使った技術は以下になっています。 言語:Ruby(RoR) API:GraphQL インフラ:Azure その他:Docker、k8s 実際の実装でハマったところは各章の最後に教訓として簡単にまとめてはいますが、大事なことは先に結論として述べておきます。 Docker

                                                                                    インフラど素人が1ヶ月半でKubernetes本番環境を作るまでの失敗の軌跡(奇跡) - Qiita