並び順

ブックマーク数

期間指定

  • から
  • まで

81 - 120 件 / 1168件

新着順 人気順

ベストプラクティスの検索結果81 - 120 件 / 1168件

  • 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ

    前提 この記事は内製開発をしているSaaSの中の人であるエンジニアが、SaaSの内製ソフトウェア開発をする上での話として書いています。 前ふり 「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」 「何が原因なんですか?どうすればいいんですか?」 という相談を受けました。 NDAを書いてから、どれどれとチームの状況を見てみました。 該当チームのスプリントゴール 該当チームのスプリントゴールはこんな感じでした。 QAフェーズのプロジェクトAを、QA作業を完了してリリースできる状態まで進める 実装フェーズのプロジェクトBを、フィーチャーの実装率を50%まで進める 設計フェーズのプロジェクトCを、要確認な点を除いて実装レディーな状態まで進める スプリントゴールが3つありますね。とても面白いですね。 思わずボンドルド卿みたいな反応をしたくなりますがここは先に進みましょう。

      「スクラムで生産性は上がらないしリリーススケジュールが狂いまくりなんですよ」とか言うお前らに告ぐ
    • 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io

      Intro CSRF という古の攻撃がある。この攻撃を「古(いにしえ)」のものにすることができたプラットフォームの進化の背景を、「Cookie が SameSite Lax by Default になったからだ」という解説を見ることがある。 確かに、現実的にそれによって攻撃の成立は難しくなり、救われているサービスもある。しかし、それはプラットフォームが用意した対策の本質から言うと、解釈が少しずれていると言えるだろう。 今回は、「CSRF がどうして成立していたのか」を振り返ることで、本当にプラットフォームに足りていなかったものと、それを補っていった経緯、本当にすべき対策は何であるかを解説していく。 結果として見えてくるのは、今サービスを実装する上での「ベース」(not ベスト)となるプラクティスだと筆者は考えている。 CSRF 成立の条件 例えば、攻撃者が用意した attack.examp

        令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io
      • プログラマーのための原則(2 万字) - Qiita

        はじめに 今でも語り継がれる「原則」は、それだけ価値のあるコンセプトです。 歴史を振り返ることは、失敗を防ぐための効率の良い方法になります。 👑 DRY (Don't repeat yourself) 「同じことを繰り返すな。」 Andy Hunt と Dave Thomas の著書『達人プログラマー』(1999 年)で提唱された原則で、プログラミングに関する最も重要な原則といっても過言ではありません。 DRY 原則だけでなく、どんなデザインパターンやベストプラクティスでも、同じ処理が重複することは基本的に許されていません。 これにはどういう意図が込められているのでしょうか。 🔖 表面的な理由 この原則は、コードの再利用性を高め、そのために疎結合な状態を保つことは、極めて有用なことを示唆します。 1 箇所を直せば済むべき箇所をあちこちに分散させてしまうのは、自分で事故を招いているのと同

          プログラマーのための原則(2 万字) - Qiita
        • 【令和最新版】令和のWebスクレイピング(クロール)【ベストプラクティス】

          こんにちは、株式会社FP16で結構コードを書いている二宮です。 最近Webスクレイピングのコードを色々な方法で書いているので、そこで得た知見をここに残しておこうと思います。 ほぼ毎日なにかのWebスクレイピングコードを書いています。 Webスクレイピング手段 Webスクレイピングには色々な方法があります。 私が最近主に使っているのはこの5つの手段です。 cheerioでHTMLを解析 Playwrightなどで要素指定でデータを取得する APIを見つけて叩く(バックエンドとの通信を再現してデータを取得) LLMでサイト構造を解析してデータを取得する Next.jsからのレスポンスに含まれているデータを解析して取得する これが令和のWebスクレイピングのベストプラクティスだと思っています。 これらの方法を、目標に合わせて使い分けています。 使い分け方 CheerioでHTML解析 JavaS

            【令和最新版】令和のWebスクレイピング(クロール)【ベストプラクティス】
          • 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
            • サイバーエージェントとメルカリにみる組織強化システムの構造的分解

              これはなにか サイバーエージェントとメルカリの「採用前〜退社後」という一連のエンプロイー・ジャーニーに内包されている組織強化システムを構造的に分解するポストです。 メルカリのCuture Doc公開に際して、実際に起きたことを懐かしく思いツイートしたら予想外の反響をいただいたのですが、その中で私のもうひとつの古巣でもあるサイバーエージェントのことを引き合いに出して貶すような引用リツイートも見られました。 退職時、進太郎さんに1 on 1の時間もらって最後の挨拶したときに貰った「まあ株式会社インターネットみたいなものだから」という言葉を忘れない。2年半前のことなので、今に始まったポーズじゃなくて昔からのスタンス。 Culture Doc | 採用情報 株式会社メルカリ https://t.co/1kTYHh0wVN pic.twitter.com/d3qJwUExcB — きょすーけ | D

                サイバーエージェントとメルカリにみる組織強化システムの構造的分解
              • [2021年版]AWSセキュリティ対策全部盛り[初級から上級まで] というタイトルでDevelopersIO 2021 Decadeに登壇しました #devio2021 | DevelopersIO

                [2021年版]AWSセキュリティ対策全部盛り[初級から上級まで] というタイトルでDevelopersIO 2021 Decadeに登壇しました #devio2021 DevelopersIO 2021 Decadeで登壇した動画や資料を掲載、解説をしています。AWSのセキュリティについて網羅的に扱っています。ちょー長いのでご注意を。 こんにちは、臼田です。 みなさん、AWSのセキュリティ対策してますか?(挨拶 ついにやってまいりました、DevelopersIO 2021 Decade!私は「[2021年版]AWSセキュリティ対策全部盛り[初級から上級まで]」というテーマで登壇しました。 動画と資料と解説をこのブログでやっていきます。 動画 資料 解説 動画はちょっぱやで喋っているので、解説は丁寧めにやっていきます。 タイトル付けの背景 今回何喋ろうかなーって思ってたら、2年前のDeve

                  [2021年版]AWSセキュリティ対策全部盛り[初級から上級まで] というタイトルでDevelopersIO 2021 Decadeに登壇しました #devio2021 | DevelopersIO
                • 文章生成AI利活用に関するガイドライン.pdf

                  文章生成AI 利活用 ガイドライン Version 2.0 令和6年(2024年)4月 東京都デジタルサービス局 2 はじめに このガイドラインは、東京都で初めてとなる文章生成AI の利活用ガイドラインです。 ChatGPTをはじめとする文章生成AIは、都職員の業務 のあり方を大きく変革する可能性を秘めている一方、 様々なリスクも指摘されています。このため、業務での 活用にあたり期待する効果を得るためには、その特性を よく理解し、正しく利用することが重要です。 東京都では、デジタルサービス局に検討プロジェクト チームを設置して、文章生成AIの利活用について議論を 重ね、令和5年8月、検討の成果をガイドライン (Version 1.0)としてまとめ、文章生成AIの全庁利用 を開始しました。 その後、10月に利用状況についてアンケートを行った ところ、活用事例やプロンプト例を求める声が多かった

                  • シェルスクリプトで安全簡単な二重起動防止・排他/共有ロックの徹底解説 - Qiita

                    はじめに シェルスクリプトで二重起動防止やロックをする方法を検索すると、いろいろな方法や書き方が見つかりますが、どれを使えばよいのか、本当に正しく動くのか、不安になりますよね? ディレクトリ (mkdir) やシンボリックリンク (ln) を使った独自実装の例も見かけますが、エラー発生時や予期せぬ電源断、CTRL+C で止めたときなどでも問題は発生しないのでしょうか? まず、ディレクトリやシンボリックリンクを使った独自実装はしない。これを肝に銘じてください。シェルスクリプトでのロック管理はとても難しく、一般的な排他制御の知識に加えて、シェルスクリプト特有の問題、シグナルやトラップ、サブシェルや子プロセスの問題、さらには特定のシェル固有の仕様やバグなどさまざまな問題に対処する必要があり大変です。独自実装の例では古いロックファイルが残ってしまい、それをいつどのタイミングで片付ければ安全なのか?

                      シェルスクリプトで安全簡単な二重起動防止・排他/共有ロックの徹底解説 - Qiita
                    • 君はまだ平成のアーキテクチャを使ってるのか?僕はFirebaseと令和の時代に行くぞ。 - Qiita

                      Help us understand the problem. What is going on with this article? メリークリスマス! この記事はFirebase Advent Calendar 2019の25日目の記事です。 これはなに? この1年、本を書いたり勉強会で登壇したりいろいろやってみた結果を振り返ってみると、本当に多くの人がFirebaseにふれるようになったなぁと思います。圧倒的な開発者体験の良さをもってバックエンドの関心事を一手に引き受け、アプリケーション開発を劇的に高速化してくれるソリューションとして、Webアプリでもモバイルアプリでもバックエンド第一の選択肢として確固たる地位を確立しつつあるのではないでしょうか。 それ自体はとてもいいことなのですが、Firebaseの強さを活かすためのアーキテクチャに関するアイデアはあまり表に出てきていないのではな

                        君はまだ平成のアーキテクチャを使ってるのか?僕はFirebaseと令和の時代に行くぞ。 - Qiita
                      • 英語学習2か月間360時間でやったことと分かったことまとめ|Hoheto (仮想通貨botter)

                        ※トップ画像は話題の「Stable Diffusion」 でAIに描かせた「Beautiful portrait of a Japanese man studying English」。 こんにちは、Hohetoです。 ここ2ヶ月間、本業から離れて英語の学習を進めてきました。 ひとつ区切り目を迎えたので、ここまでの学習の内容を記録に残しておきます。 なお、アフィリエイトの類は一切いれてないし、紹介する本やプログラムに対して金銭的な利害関係は一切持ち合わせていません。 英語をこれから学習しようとしている皆さん、英語学習に完璧な正解というものはありませんが、この情報が何らかの手がかりになれば幸いです。 筆者のことをよく知らない方は、「たまたま一時的にアーリーリタイア状態になっているアラフォーのおっさん」だと思っていただければほぼ間違いないです。 全て詰め込んだら、30000字近くになってしまい

                          英語学習2か月間360時間でやったことと分かったことまとめ|Hoheto (仮想通貨botter)
                        • 【AWS】ぼくのかんがえたさいきょうの運用・監視構成 - Qiita

                          AWSのインフラを運用・監視する上で使いやすいと思ったサービスを組み合わせて構成図を作成しました。それぞれのサービスの簡単な説明と類似サービスの紹介、また構成の詳細について説明していきます。 (開発で使用するようなサービスも紹介しますが、あくまでも運用・監視だけの構成です。) 各個人・企業によって環境は違うと思いますし、使いやすいと思うサービスは人それぞれだと思うので、これが正解という訳ではありませんが、参考にしてただければ幸いです。 参考になった教材を紹介した記事も作成しました。是非読んでみてください! 【AWS】さいきょうの運用・監視構成を作成するのに参考になった書籍 インフラエンジニア1年生がプログラミングを勉強するのに使った教材 全体図 こちらがAWSにおける"ぼくのかんがえたさいきょうの"運用・監視構成です。複雑で分かりづらいかと思うので、詳細に説明していきます。最後まで読めばこ

                            【AWS】ぼくのかんがえたさいきょうの運用・監視構成 - Qiita
                          • ShellScriptで自動化を楽にしたい時に知っておいても良いこと | sreake.com | 株式会社スリーシェイク

                            はじめに こんにちは、皆さん。今日は、シェルスクリプトを使った高度な自動化のベストプラクティスとパターンについて解説します。これらは、ちょっとした知識で実行でき、作業を大幅に効率化できるTipsです。シェルスクリプトは、特にUNIX系システムでの自動化タスクに欠かせないツールです。適切に使用すれば、複雑なタスクを効率的に、そして信頼性高く実行できます。 トイルとは、反復的でマニュアルな作業のことを指します。これには、例えば、手動でのシステムのスケーリングや、エラーのトラブルシューティング、ルーティンなメンテナンス作業などが含まれます。トイルを特定し、それを自動化することで、エンジニアはより創造的なタスクやプロジェクトに焦点を合わせることができます。 トイルを判別する方法としては、以下のような基準が挙げられます: 手作業であること 完全な手作業だけでなく、「あるタスクを自動化するためのスクリ

                              ShellScriptで自動化を楽にしたい時に知っておいても良いこと | sreake.com | 株式会社スリーシェイク
                            • 本当は速くならない「Webサイトの表示高速化アンチパターン」10選|榊原昌彦

                              ベストプラクティスや「高速化につながる!」と紹介されている記事では、逆効果、もしくは効果があるシチュエーションがあまりに限定的な手法が紹介されていることが多いので、アンチパターンとして紹介します。 本記事は「Webパフォーマンス Advent Calendar 2019」2日目の記事です。 https://qiita.com/advent-calendar/2019/web_performance 本記事はWebパフォーマンス高速化の専門家である株式会社Spelldataの竹洞 陽一郎氏にアドバイスをもらいました。HTTP/2の伝送の画像など一部資料のご提供もいただいております。誠にありがとうございます。 https://spelldata.co.jp/ ほとんどの場合で間違い 1. すべての画像をCSSスプライトその昔、画像をすべて1枚にまとめて、DOMのbackground-image

                                本当は速くならない「Webサイトの表示高速化アンチパターン」10選|榊原昌彦
                              • 「ChatGPT」に使われる言語モデル「GPT」からうまく答えを引き出すためのOpenAI公式ガイド

                                対話型AI「ChatGPT」は人間の言葉を受けて自然な文章を返してくれますが、人間が求める答えをうまく引き出すにはちょっとしたコツが必要です。ChatGPT開発元のOpenAIは「GPTのベストプラクティス」と題し、ChatGPTに使われるモデル「GPT」からより良い結果を得るための6つの戦略をまとめて公開しました。 GPT best practices - OpenAI API https://platform.openai.com/docs/guides/gpt-best-practices OpenAIが提唱する戦略は以下の6つです。 ・明確な指示を書く ・参考テキストを提供する ・複雑なタスクをよりシンプルなサブタスクに分割する ・GPTに考える時間を与える ・外部ツールを利用する ・パフォーマンステストを実施する ◆1:明確な指示を書く 関連性の高い答えを得るには、ユーザーは文章

                                  「ChatGPT」に使われる言語モデル「GPT」からうまく答えを引き出すためのOpenAI公式ガイド
                                • Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス

                                  読者対象 ある程度データベースに関する知識を持っている,経験年数 1 年以上のバックエンドエンジニア 特定のプログラミング言語に依存する部分は含めないため,すべての SQL 使用者を対象とする また,ゼロからの丁寧な説明というよりは,リファレンス感覚で使える記事という形にまとめる。 RDBMS の対象バージョン PostgreSQL: 9.4 以降 MySQL: 8.0.28 以降 id (データ型と INSERT 時のデフォルト埋め) 導入 一般的に採用されやすいプライマリキー用の値として,以下を考える。 連番整数 MySQL では AUTO_INCREMENT, Postgres では IDENTITY や SERIAL と呼ばれるもの UUID v1: ハードウェアごとにユニークな単調増加値 UUID v4: ランダム値 UUID v7(ドラフト): 単調増加であるタイムスタンプとラ

                                    Postgres と MySQL における id, created_at, updated_at に関するベストプラクティス
                                  • ウクライナ発個人プロジェクトGitLabが1兆円規模のIPOへ、その4つの教訓 | Coral Capital

                                    月間10万人が読んでいるCoral Insightsのニュースレターにご登録いただくと、Coral Capitalメンバーによる国内外のスタートアップ業界の最新動向に関するブログや、特別イベントの情報等について、定期的にお送りさせていただきます。ぜひ、ご登録ください! ウクライナのソフトウェア開発者Dmitry Zaporozhets氏が2011年10月に、たった1人で開始したオープンソースプロジェクト「GitLab」。それが、ちょうど10年を経て時価総額1兆円もうかがうほどの大成功したDevOpsのSaaSプラットフォームへと進化することになると想像した人は、ほとんどいなかったと思います。GitLabのライセンス・SaaSビジネスを展開するGitLab Inc.は9月17日付けで米国証券取引委員会(SEC)に対してFORM S-1を提出し、IPOへ向けて最終段階に入りました。 開発初期か

                                      ウクライナ発個人プロジェクトGitLabが1兆円規模のIPOへ、その4つの教訓 | Coral Capital
                                    • 今いちばんオススメしたいPython本 2022 - 初心者からプロまで仕事に活かせる3冊 + α - Lean Baseball

                                      2021年も数多くのプログラミングやPythonを扱った素晴らしい書籍とたくさん出会いました. 私はリアルの本屋さんに行くのがとても好きで(ECの本屋さんも好きですが), 技術書のコーナーには必ずと言っていいほど足を運ぶのですが, 年々「Python」というラベルが付いた棚の領域が広がっている気がします. プログラミング初心者でPythonからやりたいけど何から読めばいいのか🤔 実務に役立つような参考書籍ってどうやってみつければいいかわからない😇 よりビジネスに役立つ, 実践的な事例をしりたい💪🏻 という, 割とありそうなニーズにお応えすべく, 2022年いや, 今この瞬間に読んでおきたい・抑えておきたいPython関連書籍をまとめました! 2011年頃からPythonを使って仕事をし始め, 今もエンジニアリングからコンサルティング, マネジメントをやっている私独自の視点で, オス

                                        今いちばんオススメしたいPython本 2022 - 初心者からプロまで仕事に活かせる3冊 + α - Lean Baseball
                                      • 【決定版】2022年~2023年で必ず確認するべきGitHubリポジトリ 40選

                                        はじめに 今回の記事では、個人の独断と偏見で2022年~2023年で必ず確認するべきGitHubのリポジトリを紹介する。私のTwitterでこれまで紹介したものもあれば、そうではないものもある。 GitHubはプログラマーにとって、普段の学習・開発を進めるうえでもっとも重要な情報源の1つである。本記事では、分野ごとに確認するべきGitHubリポジトリを紹介する。 なお、今回の記事で紹介するGitHubリポジトリの分野は以下の通り。内容はWeb開発に特化している。 確認必須 Web Python JavaScript TypeScript ちなみに、「確認必須」は分野を問わずすべてのプログラマーに役立つGitHubリポジトリを紹介している。 今回の記事を通して、年末年始の学習・開発に大いに役立ててもらえたら幸いだ。 確認必須 freeCodeCamp 世界最大規模のプログラミングメディア「f

                                          【決定版】2022年~2023年で必ず確認するべきGitHubリポジトリ 40選
                                        • Re: Rails を主戦場としている自分が今後学ぶべき技術について

                                          この記事は、 Rails を主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ についてのアンサー記事です。 うなすけ君が Ruby on Rails で育ってきたように、僕も JavaScript とともに育ってきたという自覚があります。なので、これについて書くことは、ポジショントークは避けられない、という感覚があります。 冷静に比較しようとも思いましたが、やっぱり開き直って思いっきりポジショントークをすることにしました。そっちのほうが面白いと思うので。 自分の基本的な主張は、こちらの記事にあるとおりです。 Frontend Study #1: 基調講演 - Frontend 領域を再定義する 自分と Ruby on Rails 僕は、キャリアとしては Rails の会社で JavaScript を書いてきたことが多かったです。学生の頃は socket.io

                                            Re: Rails を主戦場としている自分が今後学ぶべき技術について
                                          • Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか

                                            Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか https://d.potato4d.me/entry/20220405-nodejs/ へのアンサーソング。 プログラミング言語としての JavaScript の話をする。 2010年頃、Python 2 でプログラミングを学習した自分にとっては Node.js + CoffeeScript が Better Python だった。 CoffeeScript は当時の JS(ES3~5) に足りない機能を補ってくれて、Python と同じく空白制御のオフサイドルールなのが気に入った。見た目が少しだけ Ruby っぽいので当時全盛だった Rails の人間に訴求するにも有利だった。 Node.js のモジュールシステムである Commonjs は Pytho

                                              Re: 僕らを縛る Node.js という呪いについて - あるいはなぜ TypeScript 以外が真っ当な選択肢にならなかったか
                                            • 2022 年に学んで良かった技術

                                              雑に書いていきます。 バックグラウンド自分のバックグラウンドスキルは以下の通り。専門はリアルタイムな通信プロトコルを利用したサーバーの設計と開発とマーケティング。 Erlang/OTPWebRTCEnd to End Encryption細かいのはこちら。 SQLGo で sqlc を使うために学ぶことにした。sqlc を採用したのは複数人数で開発するときの共通言語としては SQL の方がいいだろうというのと、SQL はどんなデータを持たせたいのかを伝えるのに便利と判断したため。 今までずっと通信系ミドルウェアの開発をしてきたこともあって SQL を学ぶ必要が無かったが、今回いい機会なのでちゃんと学ぶことにした。 まずは利用データベースを完全にしぼって TimescaleDB (PostgreSQL ベース) で利用する SQL だけを学ぶことにした。 書籍は元 SIer のガチ SQL

                                              • 冴えないAWS環境の育てかた α | DevelopersIO

                                                中山です ソリューションアーキテクトとして、AWS環境の利活用をお手伝いするお仕事をしています。 まれによく見るAWS環境 とりあえずこれを見てほしい。 これが絶対にだめと言いたいわけではないです。 一時的な検証環境だったり、とにかくスピード重視でサービスをデリバリーさせる必要があったり、サービスの提供者側が何ら責任を負わない・障害時のビジネスインパクトが無い(そんな状況あるのか?)という前提があったり、状況次第ではこれで十分な時もあると思います。 しかし、一般的な業務システムやサービスの場合にはいろんな意味で不十分でしょう。 では、このような環境をどのように育てていくとよいでしょうか。 この記事では、そんな育てかたの一例を紹介していきたいと思います。 なお、本記事はくっそ長いです。 ちなみに、最終的にはこうなります。 文字が小さすぎて読めない! ちょっとそこのハ○キルーペ貸してくれーw

                                                  冴えないAWS環境の育てかた α | DevelopersIO
                                                • モダンアプリケーション開発ホワイトペーパー(日本語改定版)が公開されました | Amazon Web Services

                                                  Amazon Web Services ブログ モダンアプリケーション開発ホワイトペーパー(日本語改定版)が公開されました 皆さん、こんにちは! モダンアプリケーション開発スペシャリスト ソリューションアーキテクトの福井です。 私が執筆したモダンアプリケーション開発のホワイトペーパー(日本語版)がAWSホワイトペーパーサイトで公開されましたので、その内容を紹介させて頂きます。このホワイトペーパーは、以前こちらのブログで紹介させて頂いたModern Application Development on AWS(英語版)の日本語版になります。 ホワイトペーパーの内容 公開されたホワイトペーパードキュメントは、「AWS モダンアプリケーション開発 – AWS におけるクラウドネイティブ モダンアプリケーション開発と設計パターン」(日本語版)というタイトルの51ページのドキュメントで、 はじめに

                                                    モダンアプリケーション開発ホワイトペーパー(日本語改定版)が公開されました | Amazon Web Services
                                                  • 日本人が生成AIに苦手なことをやらせるのはアトムのせい

                                                    おれたちは生成AIに苦手なことをやらせがち〇〇について教えて系の質問は全部ダメ。堂々と嘘をつくのは勿論、回答が抽象的すぎて役に立たないことが露呈した。 この批判がまさにそうなのだが、どうもわれわれ日本人は「ChatGPTが一番苦手なこと(≒自分が知らないことを教えてもらう)にChatGPTを使おうとする」という傾向があるらしい。日本の経営者に聞いたChatGPTの使い道のアンケートでは、「仕事で調べものをする時に活用する」が39.3%でトップだ。これが米国の職場でのChatGPT利用法の調査だと、上から順に、 アイディアを出すコンテンツを作成するメールに返信するプログラムコードを書くレジュメやカバーレターを書くプレゼンテーションを作成する となっていて、情報検索や調べもののタスクは上位5位に入っていない。総じて米国の働き手は、ChatGPTを自分に情報をインプットするためのツールではなく、

                                                      日本人が生成AIに苦手なことをやらせるのはアトムのせい
                                                    • Docker入門資料「入門 Docker」を5年ぶりにアップデートしました。 - y-ohgi's blog

                                                      TL;DR 「最短でプロダクションで扱うため」のコンセプトはそのままに 入門 Docker がv2になりました 5年ぶりにのアップデートで、古くなった情報を消し最新の情報の追加をしてほぼ書き直しました。 現代でも残ってしまっているような古いプラクティスについても言及しているので、再読もオススメです。 概要 入門 Docker を5年ぶりにアップデートしました。 deprecatedな部分だけは綺麗にするかと思い、git cloneしたところ筆が乗りだいぶ様変わりしてv2になりました。 変更点 古くなってしまっている情報を修正したことがメインです。 特に以下3点です。 1. DockerfileのDSL 2. compose v2対応 3. Dockerfileのベストプラクティス 他にもいくつか。 現在でも使用されている非推奨な使い方への言及 古くなってしまっているが、現在でも使用されてい

                                                        Docker入門資料「入門 Docker」を5年ぶりにアップデートしました。 - y-ohgi's blog
                                                      • GraphQLを導入する時に考えておいたほうが良いこと | メルカリエンジニアリング

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

                                                          GraphQLを導入する時に考えておいたほうが良いこと | メルカリエンジニアリング
                                                        • 個人開発・スタートアップで採用すべき最強のアーキテクチャを考えた - Qiita

                                                          結論 「アジリティ」「コスト最適化」「スモールな構成」「開発スピード」という観点でWebアプリケーションのアーキテクチャを考えてみました。 ServerlessFrameworkを使い倒す フロントエンドはS3 hosting + CloudFrontで。SSRもLambda@Edgeでできます データベースはRDSは使わずにDynamoDBで APIは基本的にGraphQL。必要に応じてRESTも簡単に追加できるよ。 補足(2022/04/12) 最近個人開発しているこちらのWebサービスはこのアーキテクチャに沿って作られています。 このアーキテクチャでどんなものができるのよ、という視点で見ていただくと面白いかもしれません。 ↓ 背景 アーキテクチャに絶対の正解はない アーキテクチャには絶対の正解はありません。 なぜなら、プロダクトやフェーズによって求められる要件が異なり、それに適したア

                                                            個人開発・スタートアップで採用すべき最強のアーキテクチャを考えた - Qiita
                                                          • 破綻したドキュメント管理、増え過ぎたプロダクトバックログ… 「Jira」「Confluence」などの活用失敗から学ぶツール運用のコツ

                                                            Jira SoftwareやTrelloなどを中心としたPMが経験してきたプロダクト管理ツールの失敗や改善を語る「本当に使いこなせてる?プロダクト管理ツールの失敗&改善PMトーク【開発PM勉強会 vol.20】」。ここで株式会社ビズリーチの菊池氏が登壇。ドキュメント管理とプロダクトバックログの失敗から学ぶツール運用のコツについて紹介します。 菊池氏の自己紹介 菊池信太郎氏(以下、菊池):ビズリーチの菊池から、10分枠で話をします。今日のテーマは「失敗から学ぶドキュメントとチケット運用のコツ」ということで、今まで経験したところで「こういうアンチパターンがあったよ」「こういう改善をしたよ」というようなところをお話しできればと思っています。 自己紹介を軽くすると、(私は)2018年からビズリーチで働いています。ビズリーチサービスを作っていて、プラットフォーム開発部の部長をしています。また、201

                                                              破綻したドキュメント管理、増え過ぎたプロダクトバックログ… 「Jira」「Confluence」などの活用失敗から学ぶツール運用のコツ
                                                            • オンプレエンジニアがAWSを触って思ったのと違うと感じたこと - Qiita

                                                              はじめに この仕事を始めた当初(約20年前)はオンプレミスという言葉がありませんでした。いや厳密には私の周りではパブリッククラウドとオンプレミスを分けて話す人はおらず、インフラ構築といえば今でいうオンプレミスが中心でした(世の中的にはパブリッククラウドがサービスとして存在していました)。オンプレミスみたいに新しい概念が出てきた時にそれまでの概念を説明するためにできる言葉をレトロニムというそうです。 私が本格的にパブリッククラウドの仕事をし始めたのは約3年前でAWSでした。研修ではAzureを先に触れていたのと、この本を読んでいたという知識があった程度です。 ここではずっとオンプレミスのインフラ構築をしていた私がAWSに触れて最初に戸惑ったことを記事したいと思います。また、戸惑いましたということだけ書いても学びがないため対応したことも併せて記載します。AWSに慣れている人からすれば常識ですが

                                                                オンプレエンジニアがAWSを触って思ったのと違うと感じたこと - Qiita
                                                              • Railsを主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ

                                                                Rails の問題は Rails のベストプラクティスがフロントエンドのベストプラクティスの邪魔になるどころか全く逆方向で相反してる点です。DHHの思想がフロントエンドと根本的に逆行してる。そういう人が作るフレームワークなのでwebpackerの抽象化を根本的に間違ったりする。 — prev.js (@mizchi) December 1, 2020 昨日もリプライで少し書いたけど、DHH自体が直近のHeyの開発でも明確にJavaScriptというものを触れないようにすることを是としているような主張をしているので、DHH wayが色濃く反映される以上この状態はもう避けられない気がしている — potato4d / Takuma HANATANI (@potato4d) December 1, 2020 Railsがフロントエンドの最先端をゆく人々1から良く思われないのは事実として。 Vie

                                                                  Railsを主戦場としている自分が今後学ぶべき技術について(随筆) | うなすけとあれこれ
                                                                • NewsPicksにCTOとして入社して1年でDX Criteriaを大幅改善した話 - Uzabase for Engineers

                                                                  こんにちは。このブログでは初めまして。2020年の2月にNewsPicksに入社した高山です。 今回は僕がNewsPicksのCTOになってからの1年でやったお仕事について書いていきます。 CTO最初のミッション DX Criteriaについて 「デプロイ回数」を定点観測 やってきたチャレンジ 1年経ってみて CTO最初のミッション NewsPicksは2013年に誕生し、5年ほどの壮大な創業期の間にたくさんの新しい領域に挑戦しており、僕が入社したときには既に事業面でもシステム面でも「それなりの複雑さ」という感じでした。 前任CTOの杉浦さん(今はグループ内でアメリカでの新規サービスの立ち上げをしています)からバトンを受け取って最初のミッションが「DX Criteriaを上げること」だと聞いたときにそのあたりの事情を全て察しました。😅 結論から先に書くと、1年で大幅改善を達成することがで

                                                                    NewsPicksにCTOとして入社して1年でDX Criteriaを大幅改善した話 - Uzabase for Engineers
                                                                  • 2.4GHz帯無線LANのチャネルはぶつけてしまった方がよい - hgot07 Hotspot Blog

                                                                    もう少し正確に書くと、 「2.4GHz帯無線LANのチャネルは、少しずらすよりは、ぶつけてしまった方がよい(スループットが上がる)」です。 無線LANがよく設計されたホテルや会議場、空港などでは、下の図のように1-6-11chに綺麗に山が立っています。 1-6-11ch 上はシドニー空港(SYD)の例ですが、おそらく無線LANコントローラの自動割り当てによるものでしょう。12chに居るAPはダメな子です。あと、8ch付近にチャネルボンディングが有効なAPが居ますが、2.4GHzでこれをやられると、周囲が大迷惑です。 次の例はどうでしょう? bad channel assignment よく見ると1-6-11chにホテルWi-Fiが見えますが、持ち込みのAPが隙間に入っていて、かなり酷い電波状況です。実際、この時の無線LANはまともに使える品質ではありませんでした。 なぜ1-6-11ch構成

                                                                      2.4GHz帯無線LANのチャネルはぶつけてしまった方がよい - hgot07 Hotspot Blog
                                                                    • 今さら聞けないDocker入門 〜 Dockerfileのベストプラクティス編

                                                                      今時のアプリ開発において、コンテナは避けて通れないものになっています。そして数多くあるコンテナ実行環境の中でも、デファクトスタンダードと言えるのがDockerです。そんなDockerのイメージですが、皆さんは正しくビルドできていますか? そのコンテナは無駄に太っていませんか? 効率よく最短時間でビルドで…

                                                                        今さら聞けないDocker入門 〜 Dockerfileのベストプラクティス編
                                                                      • バックエンドに興味を持つ学生にオススメするクラウド系メインのリンク10選 - y-ohgi's blog

                                                                        概要 学生氏に適当なことを言い過ぎ反省しているので、バックエンドのいま覚えてる良かった記事の共有です。 まっさきにみるやつ Web 系エンジニアの学習ロードマップです。 とりあえずこのロードマップにのってる"紫のチェックマーク"がついたものを順番にこなしていけば良いとおもいます。backend のロードマップを紹介しましたが他にもfrontend やdevops などもあります。しかも毎年更新してくれます。 この記事はこのロードマップ以上の情報は提供できません。おわり。 roadmap.sh その他 エンジニアリングについては雑に調べると歴戦のエンジニア各位が紹介してくださってるので、クラウド系をメインに紹介します。 一般的なやつ タイトルママ。 バックエンドというよりエンジニアリング全般。 japan.googleblog.com 技術記事に特化したキュレーションサービスです。 追いたい

                                                                          バックエンドに興味を持つ学生にオススメするクラウド系メインのリンク10選 - y-ohgi's blog
                                                                        • 氷河期世代独身が感じる最近のNISA推しへの疑問

                                                                          これまで株とか投資信託、外貨とかの投資は一通りやっていて、旧NISAや新NISAも当然やっているわけだが、最近のNISA推し、特に「脳死でオルカン積み立てておけばいい」という風潮には違和感がある。 脳死でリスク資産にお金を突っ込んでいたら、文字通り死ぬのでは? 20年先、30年先の未来は無い前提として、お金は使うために貯めるのであって、使う時には現金化する必要がある。 子供や配偶者がいれば、マイホームとか教育資金で早めに必要になるけど、40代独身中年がターゲットにするのは、定年や再雇用のタイミングの60歳〜65歳。 そうすると、短ければ10年ちょっと、長くてもあと20年しかないわけで、暴落しても20年、30年待てばいいということにはならない。 現金化するタイミングで底が来たらゲームセットワーストケースとしては定年直前に株価のピークとリセッションが来るケース。その場合にリスク資産が100%だ

                                                                            氷河期世代独身が感じる最近のNISA推しへの疑問
                                                                          • 【AWS】 代表的なクラウドデザインパターン紹介

                                                                            はじめに AWSの豊富なサービス群を活用することで、高可用性かつ高スケール性を実現するシステムを構築することが可能です。 しかし、クラウドサービスの特性を最大限に活かすためには、適切なデザインパターンを理解し、実践することが重要です。そこで今回は、AWSを利用して「高可用性」かつ「高スケール性」を実現するための代表的なクラウドデザインパターンを紹介します。 1. EC2インスタンスを利用した動的コンテンツの配信 動的コンテンツとは? 動的コンテンツとは、ユーザーのリクエストに応じて生成されるコンテンツのことを指します。たとえば、ユーザーのログイン状況や入力内容に基づいて異なるページを表示するようなケースです。 AWSサービスの簡単な解説 Amazon EC2 (Elastic Compute Cloud): スケーラブルなコンピューティングリソースを提供するサービスです。必要に応じて、イン

                                                                              【AWS】 代表的なクラウドデザインパターン紹介
                                                                            • CSSでメディアクエリはもう必要ないかも -メディアクエリなしで実装するテクニックのまとめ

                                                                              Webサイトやアプリをレスポンシブ化するためにメディアクエリに頼っているのであれば、CSSの機能を見直して、昔ながらのブレークポイントを新しい流動的なアプローチで実装ができないか検討する時期かもしれません。 CSSの実装はデバイスベースからコンテンツベースに移行しているのが現状です。grid, flexbox, vh, vw, calc, clamp, min, maxなど、CSSの機能を使用してレスポンシブ対応にするテクニックを紹介します。 You Probably Don't Need Media Queries Anymore by Kathryn Grayson Nanz 下記は各ポイントを意訳したものです。 ※当ブログでの翻訳記事は、元サイト様にライセンスを得て翻訳しています。 はじめに 大局的なgridとflexbox 活躍するCSSのプロパティ 完全に機能するCSSの数学関数

                                                                                CSSでメディアクエリはもう必要ないかも -メディアクエリなしで実装するテクニックのまとめ
                                                                              • エンジニア3年目までに読んで良かった書籍 - Yuki Watanabe's Blog

                                                                                未経験からエンジニアになり3年が経ちました。 この3年間はベテランエンジニアとの差を埋めるべく、プライベートの時間の大半を学習に充ててきました。幸い少しずつ成長を感じられ、業務では難易度の高い仕事を任せてもらえるようになったと感じます。このキャッチアップのために100冊以上の技術関連書籍を読んだことでしょう。 ここ最近、知人やTwitter経由で知り合った方から、私が学習に使った書籍について質問を頂くことが多いです。そこで、今後参照していただきやすいように、これまで私が読んで良かった書籍を1つの記事にまとめようと思います。 前提:エンジニアとして経験した技術 書籍について 全エンジニア向け Web / インターネット イラスト図解式 この一冊で全部わかるWeb技術の基本 (★) HTMLコーダー&ウェブ担当者のための Webページ高速化超入門 (★) Webを支える技術 -HTTP、URI

                                                                                  エンジニア3年目までに読んで良かった書籍 - Yuki Watanabe's Blog
                                                                                • 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コンテナ系アーキテクチャの選択肢を最適化する | 外道父の匠