並び順

ブックマーク数

期間指定

  • から
  • まで

41 - 80 件 / 491件

新着順 人気順

ベストプラクティスの検索結果41 - 80 件 / 491件

  • 【完全保存版】OpenAIが教えるChatGPTからより良い結果を得るためのプロンプトのコツ - Qiita

    OpenAIの公式ページに、ChatGPTに使われているモデルである「GPT」を使う上でのベストプラクティスが公開されていました! そこで、ここでは、そのベストプラクティス集を参考に、ChatGPTからより良い結果を得る方法を解説していきます! 原文を読みたい方はこちらの記事をご覧ください! 以下の記事では、おすすめのChatGPTのプラグインを紹介しているので、こちらもぜひご覧ください。 1.明確な指示を出す ChatGPTは非常に優れたAIですが、さすがに私たちの考えを読み取ることはできません。 したがって、ChatGPTから希望する回答を得るためには、私たちの考えを詳細に伝えるために明確な指示を出すことが大切です。 OpenAIは、この「明確な指示」を出すための具体的なアドバイスを以下の6つのポイントで紹介しています。 詳細な説明をする ペルソナを設定する デリミター(区切り記号)を

      【完全保存版】OpenAIが教えるChatGPTからより良い結果を得るためのプロンプトのコツ - Qiita
    • デザイン作業のスピードアップ

      1 pixel|サイバーエージェント公式クリエイターズブログ サイバーエージェントのクリエイターの取り組みを紹介するオフィシャルブログです。最新技術への挑戦やサービス誕生の裏話、勉強会やイベントのレポートなどCAクリエイターの情報が満載です。 はじめまして、ゴラクログのデザインを担当をしている鬼石広海と申します。 弊サービスは現在大幅リニューアル中ですので、UI周りはリニューアル後、又機会があればご紹介させて下さい。 今回は、駆け出しのデザイナーさん達の多くが課題にあげる、デザイン作業のスピードアップについてお話します。結論から言いますと、細部から作らずに土台作りを頑張ることが、結果的にスピードにつながるというお話です。 では実際にバナーデザインを例に紹介します。 1.構成要素を全部置く まずはプランナーやプロデューサーと話し合って決めた構成要素を、とりあえず全部キャンバスに置いてみます。

        デザイン作業のスピードアップ
      • API設計スキルを次のレベルに引き上げるベストプラクティス22選 - Qiita

        本記事は、Mohammad Faisal氏による「22 Best Practices to Take Your API Design Skills to the Next Level」(2021年4月15日公開)の和訳を、著者の許可を得て掲載しているものです。 REST API設計のための実践的アドバイス Photo by Andrea Piacquadio from Pexels はじめに すべてが分かりにくく、ひどいAPIに不満を感じたことはありませんか?私はそうです。 マイクロサービスの世界では、バックエンドAPIの一貫した設計が不可欠です。 今日は、知っておくべきベストプラクティスについて、簡潔に説明します。さあ始めましょう! 用語 API設計は、リソース指向設計というものに従います。3つの重要な概念で構成されています。 リソース:データの一部(例:ユーザー) コレクション:リソー

          API設計スキルを次のレベルに引き上げるベストプラクティス22選 - Qiita
        • 至高のDockerイメージ生成を求めて -2019年版- - Qiita

          この記事は@yugui氏の書いた至高のDockerイメージ生成を求めてに感謝しつつ、記事が投稿された当時には無かったさまざまな事情を組み込んで再度まとめたものである。 良いDockerイメージ 良いDockerイメージとは何だろうか。Dockerの利点は次のようなものだから、それを活かすイメージが良いものであるに違いない。 ビルドしたイメージはどこでも動く 適切にインストールされ、設定されたアプリケーションをそのままどこにでも持っていける。 コンテナ同士が干渉し合うことはないので、任意のイメージを互いに配慮することなく柔軟に配備し実行できる 必要のないサービスがコンテナ内で走っていないので、セキュリティの向上に資する イメージの転送が効率的である ベースイメージ部分は一度送ればいちいち再転送する必要がないので、ベースイメージを共有する複数のイメージを効率的に転送できる 標準のレジストリAP

            至高のDockerイメージ生成を求めて -2019年版- - Qiita
          • MSDN ホームページ

            This browser is no longer supported. Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

              MSDN ホームページ
            • 変数とメソッドの命名ベストプラクティス15 - 杉風呂2.0 - A Lifelog -

              この記事は、Cagdas Basarane 氏のブログ、 CodeBuild から 2012年2月20日の記事 "15 Best Practices of Variable & Method Naming" を翻訳したものです。 原文URL http://codebuild.blogspot.com/2012/02/15-best-practices-of-variable-method.html 十分短く十分長い変数名をスコープごとに使用する。一般的に、ループカウンタには1文字、条件やループ変数には1単語、メソッドには1-2単語、クラスには2-3単語、グローバル変数には3-4単語を使用する。 具体的な(specific)名前を使用する。例えば、"value"、"equals"、"data"といった変数名はいかなる場合も有効ではない。 意味のある(meaningful)名前を使用する。変数

                変数とメソッドの命名ベストプラクティス15 - 杉風呂2.0 - A Lifelog -
              • 14のjQueryベストプラクティス[to-R]

                14のjQueryベストプラクティス 原文:14 Helpful jQuery Tricks, Notes, and Best Practices 良かったので翻訳してみました。かなりの意訳で、上手に訳せてない箇所も多いので詳しくは原文を参照してください。 1.メソッドはjQueryオブジェクトを返す ほとんどのメソッドがjQueryオブジェクトを返すのが重要です。 これにより次のようなメソッドチェーンが可能になっています。 $someDiv .attr('class', 'someClass') .hide() .html('new stuff'); jQueryオブジェクトを返すのがわかっていれば次のように分割して書くことも出来ます。 var someDiv = $('#someDiv'); someDiv.hide(); 次のように一行で書くことも出来ます。 var someDiv

                  14のjQueryベストプラクティス[to-R]
                • なぜプロダクトに Vue.js を採用したのか? 運用してみてどうっだった? という話 | Nagisaのすゝめ

                  2018年2月6日 なぜプロダクトに Vue.js を採用したのか? 運用してみてどうっだった? という話 余り知られていませんが Nagisa ではアプリだけでなく Web のプロダクトやサービスもあります。マンガZERO や UPTOON! や 月刊コミックジヘン 辺りがそうです。 何れも Vue.js で作られている SPA で、社内・外両方から “なんで Vue.js なの?” とかよく聞かれます。そこで、今回はどうして Vue.js を選択したのか、Vue.js の何がいいのか、Vue.js で運用してみてどうだったかの話をしたいと思います。 はじめに Vue.js を導入する前のマンガ ZERO Web は 2.0系の Riot で作られていました。今ある SPA のような形ではなくサーバサイド (Go) にてメタタグを生成、空のマウントポイント <div id="app"><

                    なぜプロダクトに Vue.js を採用したのか? 運用してみてどうっだった? という話 | Nagisaのすゝめ
                  • 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 に関するベストプラクティス
                    • JavaScript開発者が一度は読むべきStackOverflow - Qiita

                      10.How do JavaScript closures work? http://stackoverflow.com/questions/111102/how-do-javascript-closures-work JavaScriptのクロージャーについて 結構とっつきにくい「クロージャー」に苦労されている人も多いかもしれませんが、サンプルコードが多いので英語わからなくても助かります 個人的にはQuestionの「Like the old Albert Einstein said: ... 」というくだりが好きw 9. What does “use strict” do in JavaScript, and what is the reasoning behind it? http://stackoverflow.com/questions/1335851/what-does-use

                        JavaScript開発者が一度は読むべきStackOverflow - Qiita
                      • SLOBSERVER - L'actualité de Second Life

                        This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.

                          SLOBSERVER - L'actualité de Second Life
                        • IDEA * IDEA

                          ドットインストール代表のライフハックブログ

                            IDEA * IDEA
                          • FINDJOB!終了のお知らせ | FINDJOB!

                            FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ

                              FINDJOB!終了のお知らせ | FINDJOB!
                            • 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
                              • コマンドによる「負荷」の原因切り分け

                                You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

                                  コマンドによる「負荷」の原因切り分け
                                • 【M1 Pro/Max対応】M1 Mac環境構築ベストプラクティス - Qiita

                                  Mac OS初期設定 開発用ソフトをインストールする前に、まずはMac OSの設定を整えて使いやすいデスクトップ環境を構築します。 初期設定 電源を入れると、色々と初期設定が求められます。基本的には指示に従って進めればOKです デスクトップ設定 まず電源を入れて目につくのが、下のDockが大きくて邪魔だということです。 その他にもスクロールの向きがWindowsと逆だったり、Finder(Windowsでいうエクスプローラ)が使い辛かったりするので、 以下のYouTubeチャンネルを参考にして設定し直すと、使いやすくなるかと思います。 OSアップデート 購入直後のOSはバージョンが古くなっていてセキュリティ的に脆弱なことがあるので、アップデートします。 基本的には初回起動時に自動でアップデート画面が出てきますが、以下の方法で手動アップデートも可能です ・Dockから「システム環境設定」を開

                                    【M1 Pro/Max対応】M1 Mac環境構築ベストプラクティス - Qiita
                                  • 「WebAPI 設計のベストプラクティス」に対する所感 - Qiita

                                    「翻訳: WebAPI 設計のベストプラクティス」を読んで色々と思うところがあったので書きました。 上記の記事は訳文でありますので、正しくは「Best Practices for Designing a Pragmatic RESTful API」に対する所感と述べた方が良いのかもしれませんが、日本語で通して読めるよう Qiita に投稿された訳文に対する所感として書いています。 以下では「翻訳: WebAPI 設計のベストプラクティス」並びに「Best Practices for Designing a Pragmatic RESTful API」は「当該記事」と表現します。 観点 当該記事では「○○とした方がよい」との意見に対してそうすべき理由が明らかになっていないか、もしくは表現が曖昧な場合が目立っていると感じました。設計は実装のようにプログラム言語仕様が制約を与えられないため、意図

                                      「WebAPI 設計のベストプラクティス」に対する所感 - Qiita
                                    • シェルスクリプトの罠を避ける三つの tips

                                      シェルスクリプトは、Unix 系環境で仕事をするエンジニアなら誰もが一度は書くであろうにもかかわらず、書き方や特性を熟知している人が少ない言語です。この記事は、シェルスクリプトを書くときに罠を踏まないようにするために最低限あなたが気を付けるべき tips 集です。「たかがシェルスクリプト」とは思わないでください。生半可に書かれたシェルスクリプトはあなたの (チームの) 生産性をかえって低下させます。 Shebang に bash を明示しろ Bash でしか使えない機能のことを俗に Bashism と言います。Bashism はもちろん Bash 以外のシェルでは動きません。これに関するありがちな罠は、以下のように発生します。 Bash が /bin/sh として使われている環境でシェルスクリプトを書く。うっかり Bashism がシェルスクリプトに含まれていても、 /bin/sh は何も

                                        シェルスクリプトの罠を避ける三つの tips
                                      • Microsoft の「クラウドアプリケーションのベストプラクティス」が良かったので紹介したい | DevelopersIO

                                        こんにちは。CX事業本部MAD事業部のYui(@MayForBlue)です。 最近調べものをしている中で見つけたドキュメントが良かったのでご紹介したいと思います。 先にまとめ Microsoft の RESTful Web API の設計 のドキュメントが API 設計を考える上で勉強になった 関連する クラウド アプリケーションのベスト プラクティス のドキュメントもアプリケーションを設計する際の指標として良さそう RESTful Web API の設計 最近 API 設計やパス設計について考える機会があったのですが、これという正解がなかったり、人によって思想やこだわりが違ったりして結構難しいなと感じていました。 そんな中で下記のドキュメントを見つけてひとつの指標として良いなと思ったのでご紹介します。 内容(項目) REST とは何か リソースを中心とした API 設計の整理 HTTP

                                          Microsoft の「クラウドアプリケーションのベストプラクティス」が良かったので紹介したい | DevelopersIO
                                        • 新卒エンジニアが1年間で得たベストプラクティス

                                          メルカリに新卒入社して1年間学んだことについて話します。

                                            新卒エンジニアが1年間で得たベストプラクティス
                                          • Googleがコードレビューのガイドラインなど、ソフトウェアエンジニアリング実践のためのドキュメント「Google Engineering Practices Documentation」を公開

                                            Googleがコードレビューのガイドラインなど、ソフトウェアエンジニアリング実践のためのドキュメント「Google Engineering Practices Documentation」を公開 ライセンスはクリエイティブコモンズの「表示 3.0 非移植 (CC BY 3.0)」で、複製や再配布、営利目的を含めた改変や翻案が可能になっています。 Googleで一般化されたエンジニアリングプラクティス Googleはこのドキュメントを次のように紹介しています。 Google has many generalized engineering practices that cover all languages and all projects. These documents represent our collective experience of various best practic

                                              Googleがコードレビューのガイドラインなど、ソフトウェアエンジニアリング実践のためのドキュメント「Google Engineering Practices Documentation」を公開
                                            • 2020 年の Python パッケージ管理ベストプラクティス - Qiita

                                              この記事は Python Advent Calendar 2019 の 19 日目の記事です。 🐍 あらすじ Python のパッケージ管理。特にここ数年で新しいツールが多く出たこともあり、一体何を使うべきなのか、少し調べただけでは分からないと思います。本記事では、新しめの管理ツールを独断と偏見で比較します。著者は Poetry 信者なのでバイアスが掛かっているので悪しからず。 本記事で書いていること Pipenv、Poetry、Pyflow の違いと使い方 本記事で書いていないこと Pyenv、Venv、Virtualenv などの既存ツールの説明 著者の環境は以下の通り。 Ubuntu 18.04 Python 3.8.0 Pipenv 2018.11.26 Poetry 1.0.0 Pyflow 0.2.1 特に Poetry と Pyflow は開発途中なので、本記事の内容と違う

                                                2020 年の Python パッケージ管理ベストプラクティス - Qiita
                                              • Efficient data transfer through zero copy

                                                IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.

                                                  Efficient data transfer through zero copy
                                                • クラウドシステム構築時に活用できる非機能要件チェックリストを公開しました | クラスメソッド株式会社

                                                  クラスメソッドのAWS総合支援 コスト最適化からセキュリティ、構築支援、運用保守まで、AWS活用を支援します。

                                                    クラウドシステム構築時に活用できる非機能要件チェックリストを公開しました | クラスメソッド株式会社
                                                  • コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita

                                                    課題 数年前と比較すると、GKEやECSを始めとするコンテナ実行環境でのアプリケーション運用を行うサービスはかなり増えてきた印象があります。 コンテナを運用する上では、アプリケーションのイベントを追跡する上でログをどう扱うかが課題になります。今までのように古いログを定期的にローテートして別のストレージに転送するといった手法はクラウドネイティブなアーキテクチャには最適とは言えません。 アプリケーション開発の方法論として、Twelve Factor App ではログをイベントストリームとして扱うためのガイドラインが示されていますが、近年のWebアプリケーションではシステムを疎結合に連携するマイクロサービスという考え方が主流になりつつあります。 アプリケーションログはサービスごとにフォーマットを整形した上で、ログ収集サービスに配送。必要に応じてリアルタイム分析や異常データの通知、そしてデータの可

                                                      コンテナ運用におけるログ基盤設計のベストプラクティス - Qiita
                                                    • 『ソフトウェアアーキテクチャ・ハードパーツ』 - Don't Repeat Yourself

                                                      『ソフトウェアアーキテクチャ・ハードパーツ』を訳者の方からご恵贈いただきました。ありがとうございます。献本については基本的にすべて書評を書こうと思っているため、今回も記事にします。発売は10/27のようです。 ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析 作者:Neal Ford,Mark Richards,Pramod Sadalage,Zhamak DehghaniオライリージャパンAmazon おことわり まず指示語についてです。記事中で「本書」「この本」と書く場合は『ソフトウェアアーキテクチャ・ハードパーツ』を指します。また、「著者」は本書を執筆した人を指すものとします。「筆者」といった場合、それは私のことです。 いわゆるスキミングをした状態で一旦書評をするため、本書の細かい議論の見落としや用語の誤認識が含まれる可能性があります。この書評は

                                                        『ソフトウェアアーキテクチャ・ハードパーツ』 - Don't Repeat Yourself
                                                      • Goのアンチパターン

                                                        Go書いててなんとなく見えてきた Goでやっちゃいけないパターン WAF導入してらくらくWebアプリ WAF自体が現在群雄割拠状態。 WAF毎にハンドラインターフェースが違うので既存コードつなぐにはラッパーが必要。 どのWAFもLL言語に比べるとまだまだフィーチャーの網羅範囲が狭い。 なのでもちろんLL言語ほど楽には書けないことが多い。 リフレクション使いまくりでトータル性能はLL言語並みに遅いのもある。 Go1.7のcontextパッケージの導入で標準のHTTPハンドラが復権する可能性があり更に荒れる予想。 追記: 楽できるのを期待してWAFを導入するの「やっちゃいけない」とまでは言い過ぎだったかもしれないけれど例のsqlでPrepareを正しく使えていないで性能出なかった件とか、当面WAFを使うなら自分で概ね中身を理解して使う覚悟が必要。 構造体メソッドにロジックを詰め込む Goの思想

                                                        • DHH流のルーティングで得られるメリットと、取り入れる上でのポイント - KitchHike Tech Blog

                                                          はじめに こんにちは。KitchHikeエンジニアの小川です。KitchHikeでは主にサーバーサイドを担当しています。 少し前のものですが、「DHHはどのようにRailsのコントローラを書くのか (原文)」というすばらしい記事があります。Railsのコントローラ分割の(DHH流)ベストプラクティスについて解説した記事なのですが、私はこの記事に大変感銘を受け、KitchHikeのルーティング定義にもこのプラクティスを取り入れるようになりました。 本日はこのDHH流ルーティングを取り入れることで得られるメリット、実際の routes.rb でのルーティング定義のしかたについて紹介したいと思います。 DHH流ルーティングとは?何がうれしいの? 詳しくは元記事を是非とも読んで下さい・・・なのですが、かいつまむと、ここで示されているのはたったひとつの単純明快なルールです。 コントローラはデフォルト

                                                            DHH流のルーティングで得られるメリットと、取り入れる上でのポイント - KitchHike Tech Blog
                                                          • Dockerfileを書くためのベストプラクティス【参考訳】v18.09 - Qiita

                                                            概要 Docker Documentation にある、Best practices for writing Dockerfiles の参考日本語訳です。ドキュメントは、2019年5月31日現在のカレントである Docker v18.09 (current) です。 背景 ―― 以前の翻訳から時間が経過し、全体的に手直ししたいものの、差分が大きすぎる状況です。そのため、リファレンスや重要性の高いものから優先的に着手することにしました。 スライド資料 背景やヒント、図解などを追加した補足用スライドを作成しました Dockerfile を書くためのベストプラクティス解説編 BuildKitなどの最新機能や Dockerfile の記述例については、こちらのスライドをご覧ください。 Dockerfileを改善するためのBest Practice 2019年版 Dockerfile を書くためのベ

                                                              Dockerfileを書くためのベストプラクティス【参考訳】v18.09 - Qiita
                                                            • 【Vue.js】Web API通信のデザインパターン (個人的ベストプラクティス) - Qiita

                                                              はじめに Vue.jsを使用したアプリケーションでのWeb API呼び出しのデザインパターンについて調べてみました。 しかし検索して出てくるチュートリアルやサンプルは、コンポーネント内でaxiosをインスタンス化していたり、Vuexの中でaxiosを使用するというサンプルがほとんどでした。 しかし実際のプロダクトでこれをしてしまうと コンポーネント内でAPIアクセスの直書きによって単体テストが困難に Vuex(actions)の肥大化(使い回さない処理はStoreに記述しないほうがいいとする文献もある) API通信部分をPureJSでモジュール化しても依存度がイマイチ下がらない(コンポーネントでモジュールをインポートするため)。 などなど問題になることが多そうでした。 ある日、Jorge氏が投稿した「Vue API calls in a smart way」という記事にたどり着きました。

                                                                【Vue.js】Web API通信のデザインパターン (個人的ベストプラクティス) - Qiita
                                                              • 「それ、どこに出しても恥ずかしくないTerraformコードになってるか?」 / Terraform AWS Best Practices

                                                                2021年9月30日AWS Dev Day Online Japanの登壇資料 動画はこちら: https://www.youtube.com/watch?v=0IQ4IScqQws

                                                                  「それ、どこに出しても恥ずかしくないTerraformコードになってるか?」 / Terraform AWS Best Practices
                                                                • 2017末時点での React Component 設計のベストプラクティス - Qiita

                                                                  どう考えているか、というのを聞かれたので、記事に起こしておきます。個人の意見です。 Prettier を使う 気づけばコードの整形を人間がやる時代は終わりました。 細かいコーディングスタイルでレビューの時間を取るぐらいだったら、一貫した自動整形ルールを適用すべきです。 人によっては細かいこだわりがあって prettier の規則が気に食わないかもしれず、僕も最初はそうでしたが、Atomで保存する度に自動整形を走らせる prettier の強烈な開発体験によって、最終的にそれらのこだわりを全て捨てることが出来ました。 生産性を求めるなら、現時点では最優先で導入すべきものです。 React.createClass を使わない v16 で削除されたのでいわずもがな。 同様に、 createClass でしか使えなかった mixin 周辺機能も丸ごと deprecated です。 「可能な限りは」

                                                                    2017末時点での React Component 設計のベストプラクティス - Qiita
                                                                  • Dockerfileのベストプラクティス8選

                                                                    はじめに Dockerfileを書く上で、Docker社の推奨するベストプラクティスを8つにまとめました。 ベストプラクティスに従うことによって、簡単・安全・効率的な、Dockerfileの作成を目指します。 Dockerのガイドライン コンテナは、必要最小限(エフェメラル)であるべき。 Dockerfile で定義されたイメージを使って作成されるコンテナは、可能ならばエフェメラル(短命;ephemeral)にすべきです。私たちの「エフェメラル」とは、停止・破棄可能であり、明らかに最小のセットアップで構築して使えることを意味します。 Dockerfileベストプラクティス 1. Baseイメージは、公式の信頼できるものを使おう 特定の言語などを扱う場合は、公式が言語が入ったイメージを配布してくれている場合が多いので、そちらを使おう。

                                                                      Dockerfileのベストプラクティス8選
                                                                    • JavaScript ベストプラクティス Part 1 | POSTD

                                                                      ThinkfulはWeb/スマートフォンアプリの技術などを学ぶことができるオンラインスクール。プロフェッショナルな開発者がメンターとして1対1で伴走するため、他の同様サービスよりも続けることができる。 Javascript ベストプラクティス パート1 2つのパートに分けてお届けする「ベストプラクティス」のパート1では、MozillaのWebエバンジェリストであるChristian Heilmannが提供する人気のスライドショーから内容を抜粋しています。JavaScriptにはひどく扱いにくい特徴がいくつかありますが、それはこれまで以上にソフトウェア開発において重要になっています。この「ベストプラクティス」ではより読みやすく、効率の良いコードを書く手助けとなるサンプルコードやその使用例を紹介していきます。 もしWeb開発についてもっと学びたいと思うのであれば、私たちが提供しているフロントエ

                                                                      • AWSのネットワーク設計をしくじって復旧に苦労した話

                                                                        2019年8月2日、インフラストラクチャエンジニアやネットワークエンジニア向けの勉強会「インフラ・ネットワークエンジニア勉強会」がアイスタイル株式会社で開催されました。同会では、AWSに関するインフラ・ネットワーク視点の話や、オンプレ環境の話など、過去の事例を共有。6人のエンジニアが成功・失敗談をシェアしました。「ネットワークしくじり先生」に登壇したのは、kaga氏。講演資料はこちら ネットワークしくじり先生 kaga氏:それでは、「ネットワーク設計アンチパターン」という話をさせていただきます……と思ったんですけれども、ちょっとタイトルが堅いので「ネットワークしくじり先生」に、ちょっとやさしい雰囲気に変えたので、肩の力を抜いて聞いていただければなと思います。よろしくお願いします。 (会場拍手) 自己紹介です。kagaといいます。もともとQAを5年やって、サーバサイドを3年やって、今はインフ

                                                                          AWSのネットワーク設計をしくじって復旧に苦労した話
                                                                        • Dockerfileのベストプラクティスとセキュリティについて - エニグモ開発者ブログ

                                                                          こんにちは、主に検索周りを担当しているエンジニアの伊藤です。 この記事は Enigmo Advent Calendar 2020 の 17 日目の記事です。 みなさんは適切なDockerfileを書けていますか?とりあえずイメージのビルドが出来ればいいやとなっていませんか? 今回は自戒の意味も込めて、改めてDockefileのベストプラクティスについて触れつつ、 そもそもDockerfileを書かずにコンテナイメージをビルドする方法とコンテナセキュリティに関する内容についてまとめてみました。 Dockerfileのベストプラクティス イメージサイズは極力小さくしよう ビルドキャッシュを活用しよう Dockerfileに関する悩みどころ Dockerfileを書かないという選択肢 Buildpack Cloud Native Buildpacks CNBの仕組み デモ CNBのメリット セキ

                                                                            Dockerfileのベストプラクティスとセキュリティについて - エニグモ開発者ブログ
                                                                          • GitHub Actions のベストプラクティス

                                                                            1 フロー 1 ワークフロー 一連のフローがある場合は 1 つのワークフローにまとめる。 トリガーしたイベントの JSON が使える needs での制御がしやすい 全体を追える グラフが表示される ファイルを分割したい ファイルを分割したい理由として以下が挙げられると思います。 行数が増えて読みづらい 処理を共通化したい 複合実行ステップアクション や workflow_run トリガー や Reusable workflow 🆕 を使うことになると思いますが、基本的には一連のフロー制御はメインのファイルに書いてその下を Reusable workflow や複合実行ステップアクションで外部ファイルへ分離するのが良さそう。 workflow_run はログが分断するのでおすすめしません。

                                                                              GitHub Actions のベストプラクティス
                                                                            • シンプルなHTMLで、モダンなWebサイトをすばやく簡単に作成できるクラスレスの超軽量CSSフレームワーク -Simple.css

                                                                              その名の通り、シンプルなHTMLで、Webサイトをすばやく簡単に作成できるクラスレスの超軽量(4kB)CSSフレームワークを紹介します。 シンプルなWebページ、ポートフォリオやブログなどをすばやく作成したい時に便利で、レスポンシブにもダークモードにも対応しています。また、CSSリセットとして利用するのもありかもしれません。 Simple.css Simple.css -GitHub Simple.cssとは Simple.cssのデモ Simple.cssの使い方 Simple.cssとは Simple.cssは、セマンティックHTMLをすばやく簡単に見栄え良くするクラスレスのCSSフレームワークです。「クラスレス」とは、CSSまたはHTMLのどこにもCSSのclassがないことを意味します。 MITライセンスで、商用プロジェクトでも無料で利用できます。 classのないプレーンなHTM

                                                                                シンプルなHTMLで、モダンなWebサイトをすばやく簡単に作成できるクラスレスの超軽量CSSフレームワーク -Simple.css
                                                                              • あなたのDockerfileはベストプラクティスに従っていますか?(ベストプラクティスとチェックツール) - Qiita

                                                                                Dockerfileのベストプラクティス ベースイメージには公式のレポジトリを使用する FROM命令において、使用するベースイメージは公式のリポジトリのものを使用し、軽量なものが推奨されている。 例えば、Debian イメージなど。 FROM [--platform=<プラットフォーム>] <イメージ名> [AS <名前>] FROM [--platform=<プラットフォーム>] <イメージ名>[:<タグ>] [AS <名前>] FROM [--platform=<プラットフォーム>] <イメージ名>[@<ダイジェスト>] [AS <名前>]

                                                                                  あなたのDockerfileはベストプラクティスに従っていますか?(ベストプラクティスとチェックツール) - Qiita