このドキュメントは、効率的なイメージ構築のために推奨するベストプラクティスを扱います。 Docker は Dockerfile に書かれた命令を読み込み、自動的にイメージを構築します。 Dockerfile はイメージを構築するために必要な全ての命令を、順番通りに記述したテキストファイルです。 Dockerfile は特定の書式と命令群に忠実であり、それらは Dockerfile リファレンス で確認できます。 Dockerfile の命令に相当する読み込み専用のレイヤによって、 Docker イメージは構成されます。それぞれのレイヤは直前のレイヤから変更した差分であり、これらのレイヤは積み重なっています。次の Dockerfile を見ましょう。 命令ごとに１つのレイヤを作成します。 FROM は ubuntu:18.04 の Docker イメージからレイヤを作成 COPY は現在のデ
公式ドキュメントの読み方
「公式ドキュメントを読め」というのが急に話題になっていたので自分なりに整理してみました。 注意: そんなに真面目に推敲していません。フィーリングで書いているので実態に即してない部分もあるかも…… 公式ドキュメントとは何か あなたが使おうとしている道具 (ライブラリ、フレームワーク、プログラミング言語、ミドルウェア、コマンドラインツール、etc.)[1] は必ず誰かによって作られています。ある程度成熟した道具であれば通常、その作った人・組織自身によって公開されているドキュメントがあるはずです。これが公式ドキュメントです。 公式ドキュメントは、OSSにおいてはソースコードと双璧をなす最も信頼できる資料のひとつです。ソースコードが非公開の場合は通常、公式ドキュメントが最も信頼できる資料でしょう。 (以降はOSSを主に想定して説明します) たとえば…… Python のソースコードはGitHub上
開発プロジェクトに新しく加わった時は、まずプロジェクトの理解が第一。しかし、全体像を把握できるようなドキュメントがなく、コードから断片的な情報をかき集めるしかない場合もあります。新参の開発者がスムーズにプロジェクトを理解できるよう、大規模なプロジェクトでは「プロジェクト全体のアーキテクチャ」を示した「ARCHITECTURE.md」を添えた方がよいと、エンジニアのAleksey Kladov氏が指摘しています。 ARCHITECTURE.md https://matklad.github.io//2021/02/06/ARCHITECTURE.md.html Kladov氏はオープンソースプロジェクトの開発に携わる中で、「プロジェクトのアーキテクチャに対する知識量」によって開発スピードに大きな差が生じると気づいたとのこと。アーキテクチャに関する知識がない開発者にとって、大量のコードは「バラ
Pythonで始める ドキュメント・インテリジェンス入門 / Introduction to Document Intelligence with Python
ビジネス文書をデータ化し構造や内容を理解するアプリケーションはドキュメント・インテリジェンスと呼ばれ、画像処理や自然言語処理といった複数の要素技術を組み合わせて開発する必要があります。何が必要でどう実現すれば良いのかといった第一歩を、Pythonでの具体的な構築事例とともに紹介します。 https…
ドキュメント駆動開発v2
前提 ここで言っているドキュメントは仕様書ではなく、顧客向け製品ドキュメント。 ミドルウェア製品を開発 小さなチーム パッケージ製品とパッケージ製品のクラウド版 そのため顧客に提供するドキュメントが必ず必要 GitHub を利用 自分で開発する場合のフロー 作りたい機能をぼんやりでいいので GitHub Issue に追加する feature ブランチを切る デザインドキュメントをリポジトリの doc/ 以下に書く デザインドキュメントに合わせてコーディングを進めてなんとなく動くところまで作る 動かなくてもいいのでイメージを膨らませるためにコードを書いてみる デザインドキュメントは書き捨て前提で、とにかくメモを書く 製品ドキュメントを書き始めて、一旦書き終える ブランチマージに向けてコーディングを進める 書ける範囲でテストを書く ドキュメントを平行して修正する プルリクエストをだしてレビュ
シンプルに自己アピールで勝負 ソフトウェアエンジニアのコニー・リー（33）は昨年、恋人と別れた後、ふたたびマッチングアプリを使うようになった。しかし、そこで出会った男性の多くはカジュアルな関係を求めているようだったので、彼女は違う方法を試してみることにした。 それは、記事1本分ほどもある長い履歴書のようなプロフィールを書くことだった。デート相手を探すために、レジュメのような長い自己紹介文を他人がオンラインで公開しているのを見たことがあったのだ。
本当に実践的なデザインドキュメントの書き方 第1回：なぜ渡されたワイヤーフレームは分かりにくいのか？ | アドビUX道場 #UXDojo
本当に実践的なデザインドキュメントの書き方 第1回：なぜ渡されたワイヤーフレームは分かりにくいのか？ | アドビUX道場 #UXDojo 連載 本当に実践的なデザインドキュメントの書き方 いきなり渡されたワイヤーフレームをデザインするよう言われて戸惑った経験は、デザイナーなら誰でもあるのではないでしょうか？これはディレクターとデザイナーの分業という状況に起因する問題ですが、分業が一般的なのにはもちろん理由があります。そこで、この連載では、現在の分業体制を前提に、情報設計に関わる『デザインドキュメント』をきちんと制作することで、この問題を解決する手段を探ります。 第1回は、受託のWeb制作における一般的な分業体制を詳細に分析し、よりデザイナーが貢献できる役割分担について考えていきます。 なかなかはじめられないUXデザイン これはGoogleトレンドで、「Webディレクター」「Webデザイナー
AWS Well-Architected ドキュメントが読みやすくなりました！！（AWS Well-Architected ドキュメントの歩き方2022） | DevelopersIO
AWS認定トレーニング講師の平野@おんせん県おおいたです。 さて、2021年に下記のような Well-Architected フレームワークのブログを書きました。 最近AWS Well-Architectedのドキュメントがアップデートされましたので、それに伴いブログも新しくリリースしました。 おもな変更点 ドキュメント構成の改善に対応 ドキュメント自体が読みやすくなりました（詳細は後述）。それに対応して、内容を変更しました。 新しい柱への対応 2021年12月に「持続可能性の柱」が追加されましたので、この新しい柱についての記事を追記しています。 尚、2022.1.9時点で日本語化されておりませんので ブログ内の見出しは、私の方で日本語訳したもの 各リンク先は英語ページ となっておりますので、ご了承ください。 はじめに AWS Well-Architected フレームワークとは AWSと
※2023.04.25 予想以上に見られているので追記 ChatGPTはAPIでの利用なので学習はされません。また入れてる情報は社内のだれでも見れてよい情報に留めており、顧客情報を始めとした個人情報などは一切含めていません。STORES サービスに関わる情報も含んでおりません。 入れているのは社内業務における経費精算などの各種申請の手順、オフィスの利用ルール、福利厚生の解説などに限定されています。 この記事は STORES PX Advent Calendar 2023 Spring 16日目の記事です こんにちは！STORES のPX部門IT本部でマネージャーをしている@howdy39です。 先日、社内向けにChatGPTを使ったアシスタントBot（Slack Bot）を開発しリリースしたのでそのご紹介記事になります。 リリースアナウンスのSlackメッセージどんなBOT？STORES
Web標準に新たなステータス「Baseline」が登場。変化し続けるWeb標準のうちWeb開発者が安心して使える機能群を示す。MDNドキュメントなどで表示開始
Web標準に新たなステータス「Baseline」が登場。変化し続けるWeb標準のうちWeb開発者が安心して使える機能群を示す。MDNドキュメントなどで表示開始 Web開発者の開発体験を改善することなどを目的としたW3CのWebDX Community Groupは、つねに新たな機能などが登場し変化し続けるWeb標準のうち、Web開発者が安心して使える機能群を示す新たなステータス「Baseline」を発表しました（Googleによる発表、MDNによる発表）。 現在、Web標準はリビングスタンダードとしてつねにアップデートが行われており、ChromeやFirefox、Safariなどの主要なWebブラウザは、Web標準で新たに策定される機能をそれぞれ実装し、最新版に反映させています。 そのため、それぞれのWebブラウザがWeb標準のどの機能をいつ頃実装し、最新版に反映させるのかは時期が異なりま
はじめに ドキュメントデータベースかリレーショナルデータベース、どちらを選ぶか。 この選択で、アプリケーションのパフォーマンス、コスト、コードの可読性など幅広い影響が出るため、慎重な判断が必要です。この記事では、自分が思う「考慮すべきポイント」を解説したいと思います。 考慮すべきポイント 1. どのデータモデルがアプリケーションコードに最適か スキーマ制約を課さずに、データレコードをドキュメント（つまりJSONオブジェクト）として保存すべきか？それともスキーマを正規化してデータをいくつかのテーブルに分けるべきか？ このような判断をするために、開発しているアプリケーションのモデルの関係性（例: UserとTaskの関係が1:N）と、一度に読み込むデータの種類を見た方がいいです。 ドキュメントDBがおすすめの時 アプリケーションのデータは、以下のような木構造で表現できますか？普段そのデータを一
エンジニアに英語力が必要な本当の理由を知ってますか？「英語でしか存在しないドキュメントを読むため？」「違いますね」→許したくない事案がココにある
米村歩@日本一残業の少ないIT企業社長 @yonemura2006 エンジニアが英語力が必要な本当の理由を知ってますか？英語でしか存在しないドキュメントを読むため？違いますね。ずばり、センスの欠片も感じられない変数名やメソッド名を付けないようにするためですよ。あれやるやつマジ許さん。
Googleドキュメントがフィッシングサイトとして利用される｜ozuma5119 / Yusuke Osumi
この2,3週間ほど、私のメールボックスにほぼ毎日bitFlyerのフィッシングメールが届くようになりました。 私はサイバーセキュリティ分野での調査研究をしており、このような詐欺メールはさして珍しいことではありません。しかしこのフィッシングメールが誘導する先のフィッシングサイトは、あまり他に見ない特徴を持っています。そして今後の脅威となる可能性が高いと感じ、この文章を書きました。 フィッシングメール 届いたフィッシングメール自体は、よくあるタイプのものでした。不正なログインがあったからすぐ確認しなさい、と人を慌てさせてリンクをクリックさせる、一般的な手口です。 しかしこのリンク先が、2週間ほど前からGoogleドキュメントへのリンクとなったのです。 リンク先はGoogleドキュメント Googleドキュメントで作られたフィッシングサイトがこちらです。 見て分かるように、厳密にはこれはフィッシ
マイクロソフト、GPT-4に任意のドキュメントなどを読み込ませて回答してもらえる「Azure OpenAI Service On Your Data」が正式サービスに
マイクロソフトは、GPT-35-TurboもしくはGPT-4に任意のデータソースを指定することでそのデータの内容を読み込み、質問に対して内容を基に回答できるようになる新機能「Azure OpenAI On Your Data」が正式サービスとなったことを発表しました。 例えば、社内規約や社内マニュアルなどを読み込ませると、「PCの修理を申し込むための社内手続きは？」といった、汎用の知識だけしか持たない従来のGPTでは答えられない質問にも回答できるようになります。 任意のドキュメントを読み込ませるための支援ツール「Azure AI Studio」には、Azure OpenAI On Your DataでカスタマイズしたAIを、チャットボットとして公開する機能も備わっています。 カスタマイズしたチャットAIのサービスを、社内や社外に簡単に公開できるようになります。 Azure OpenAI S
「ソフトウェアの「詳細設計書」とはなんなのか」というブログ記事を読んで考えたこと。設計に関するプロセスとドキュメンテーションの関係性についての考えの整理。SI屋的な視点で。 2024/8/18追記：文中にあった雑な文系disが不愉快というご指摘を受けました。ご指摘の通りだと思いましたので訂正しています。大変失礼しました。 「詳細設計書」とはなんなのか nowokay.hatenablog.com こちらの記事では詳細設計書とは以下のようなものであると整理されている。 表現を変えたコーディング（の一種） 机上プロトタイプ（の一種） 分析資料 保守（のための）資料 （水平作業の場合の）作業指示書 （委託している場合の）契約資料 上記以外で考えられるのは次のようなものがあるだろう 利害関係者が要求している たとえば受託開発において発注者が要求している場合 ほかには連携している相手先システム側から
オンラインドキュメントと日本語全文検索
自社では Sphinx というドキュメントツールを利用しているのですが、残念ながらこれに付属している検索機能の日本語検索はかなり厳しいです。また残念ながら Sphinx 開発側も検索周りを改善するという予定は直近ではないようです。 そして検索というのはとても難しい技術なため自分のような素人では導入して「普通に期待する動作」をさせるまでの距離はとても遠いです。 ただ、なんとかして日本語全文検索を実現したいという思いはここ10 年くらいずっと思っていました。これは自社の Sphinx テーマを作ってくれている社員ともよく話をしていたのですが、どうしてもリソースをつぎ込めずにいました。 まとめ日本語検索に対応している Meilisearch を採用したドキュメントスクレイパーの実行は GItHub Actions (Self-hosted Runner) を採用した自社 Sphinx テーマの検
こんにちは。クリエイション開発部の丸山@h13i32maruです。 みなさんドキュメント書いてますか？私はドキュメントを書くのは結構好きです。最近もプライベートで開発しているJasperというGitHub用Issueリーダーのユーザ向けドキュメント（マニュアル）を書きました。でも良いドキュメントを書くのって難しいですよね。 そこで、本記事では「ツールやライブラリなどを対象にしたユーザ向けドキュメント」を書くときに私が考える原則を紹介します。ちなみに私はテクニカルライティングの専門家ではなく、普通のソフトウェアエンジニアです。そのあたりはいい感じに汲み取っていただけると🙏 🕵️メンタルモデルの原則 良いドキュメントとはどのようなものなのでしょうか？私は「そのツールやライブラリに対して読者がメンタルモデルを構築できる」のが良いドキュメントだと考えています。これを「メンタルモデルの原則」と呼
Google、マイクロソフトらが設立、「Open Web Docs」を発表。MDNなど支援、Web技術のドキュメント化を推進
オープンソースやテクノロジーを中心としたコミュニティの維持や発展を支援する組織「Open Collective」は、Web技術のドキュメント化を長期的に支援する取り組みとして「Open Web Docs」を発表しました。 Open Web Docsはおもに既存のコミュニティによるドキュメント、特にMozillaのMDNをまずは優先的に支援するとしています。 We’re happy and proud to announce Open Web Docs, to support a community of technical writers around creation and long-term maintenance of web platform technology documentation that is open and inclusive for all.https://t
2023年3月17日に開催されたイベント「エンジニアのためのドキュメントライティング - Forkwell Library #19」の登壇資料です。 イベントURL：https://forkwell.connpass.com/event/276576
LAPRAS株式会社でSREをしていますyktakaha4と申します 🐧 私は 2021 年の 1 月に LAPRAS に入社 したのですが、 入社以来ほそぼそとやってきた、ドキュメンテーションに関する取り組みについて一年ほど運用し一区切りがついたので、その話をしたいと思います✍ ことのおこり 現在弊社には正社員・業務委託あわせて 18 名程度のエンジニアが在籍 していますが、 私が入社した頃はエンジニアが7名程度、かつ全体の人数に対して在任歴の長い人が多かったこともあり、 開発者が参照するドキュメント管理について、比較的牧歌的な運用がなされていました 🐑 具体的には、開発環境の構築方法が古い手順のまま放置されていたり、オンボーディングに使うドキュメントが口伝されていたりと、 ドキュメント自体は存在するものの、それらが 古くなっていたり一覧化が不十分であることが検知できず、時間経過に伴
LINE TECHNICAL WRINTING MEETUP Vol.8 2021.10.14 https://line.connpass.com/event/226589/ 「ドキュメントを改善するためのはじめの一歩」 株式会社ソラコム テクニカルライター 矢崎 誠 イベントレポ…
聞いてるポッドキャストでセキュリティ情報収集どうしているのかといった話題があった*1ので、いい機会だから自分の行っているセキュリティ関連の情報収集をまとめてみた。 前提 どんな人 セキュリティに興味あるWebアプリケーションエンジニア*2 興味の範囲 Webアプリケーションにまつわるセキュリティ全般 サービス開発・運用まわりに関するセキュリティ 知りたい情報 関係ありそうな脆弱性情報 興味範囲の最近の話題やトレンド その他セキュリティ関係で話題になっていそうなこと 話題やトレンドはキーワードを拾い後から調べられるように脳にインデックスを作っておくのが目的で、網羅や詳細に知ることはあまり意識していない。 情報ソース 前提に書いた知りたい情報を、各種サイト・ブログ、Twitter、Podcast から収集している。 Twitter は脆弱性情報などスピードが重要なものからトレンドまで幅広く知れ
Kazuho Oku on Twitter: "HTTP を使うサーバクライアントアプリ作ってる人が、HTTP 的にどうするのが正しいのかな、と迷った時、見るべきドキュメントは BCP56bis かな、という話をした。HTTP の仕様ではなく、どのように使うべきかを説明した文書… https://t.co/7ke9ePZtTn"
HTTP を使うサーバクライアントアプリ作ってる人が、HTTP 的にどうするのが正しいのかな、と迷った時、見るべきドキュメントは BCP56bis かな、という話をした。HTTP の仕様ではなく、どのように使うべきかを説明した文書… https://t.co/7ke9ePZtTn
架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late） - Qiita
このコンテンツ作成の背景 プログラミングを体験できるコンテンツは沢山存在していますが、開発プロジェクト全体を通した流れを体験したり、実務では不可欠となるドキュメント作成を体験（学習）できるコンテンツは少ないので作ってみました。 とはいえドキュメント作成についてはテンプレート見ながら「こんなもんです」と解説する感じになります。。。 免責事項（いいわけ） 元々は社内の非技術系な人向けに研修用資料として作っていたものを、どうせなら公開するかな。という感じで再編したものなので、足りない部分やオレオレな部分、ゆらぎ、不整合、誤字脱字とかも多いと思います。「間違い」や「こうしたほうがいいよ」というのがあれば、コメント等で"優しく"教えていただけると助かります。少しずつ修正していこうと思ってます。 オレオレな情報だけでは申し訳ないので、一般社会ではプロジェクト関連のドキュメントはどう書くのか？については
こんにちは、今回はデータ基盤構築を担当しているmarushoがお送りします。 今日はestieで実践しているデータベースのドキュメント管理方法をご紹介します。 はじめに 独自成長していくデータベースたち 失われたドキュメント どうすれば低コストなドキュメント管理ができるのか そして生まれた、schema collectorという自動化ツール SchemaSpy Mysql diff Priv Page ECS タスクスケジューラ ドキュメントを腐らせない おわりに はじめに estieはオフィスを中心とした不動産データを取り扱うスタートアップ企業です。 estie（オフィス探しサービス）とestie pro（不動産事業者向けデータプラットフォーム）の2つのサービスを運営しています。 詳しくは、こちらの記事をご覧ください。 inside.estie.co.jp estieでは、不動産に関する
『ダイソー商品だけ』約2,000円で壁に穴を開けずに棚を作る方法！（使用例も紹介） - 暇つぶしのドキュメント
「壁に棚を作りたい」と思っても、賃貸だとどうしても壁に穴を開けることに抵抗がありますよね。最近は穴が目立たない壁掛け用のピンなどはあるものの、それでもやっぱり開けないに越したことはないと思っている人も多いはず。 そんな人は必見！ なんとダイソー商品だけで、しかも約2,000円以内で棚を作る方法があります。調べてもなかなか出てこないアイデアかもしれないので良ければブックマークしてってください…！ 材料・作り方 使用例 メリット、まとめ 材料・作り方 用意するのはこちら。 つっぱり棒×４ 板材（枚数、大きさは任意） つっぱり棒：400円×4＝1600円 板材：100円×2＝200円 合計：約1800円（税抜き） 材料はこれだけ。 要はつっぱり棒の力で棚を作るわけだが、普通に考えるとダイソーのつっぱり棒では天井までの長さが足りない。筆者が住んでいる賃貸は床から天井までの高さが約235㎝だったので
OpenAI API ドキュメントの日本語訳をこちらでまとめます。文字量の多いドキュメントなので、セクションごとに記事を分割しています。 今回は「GET STARTED 」のセクションからIntroduction と Quickstart を抜粋した前編です。 基本 DeepLで翻訳して、気になるところだけ書き換えています(ほぼ気になるところがないのが、DeepLのすごいところ)。原文との突き合わせができるようにはじめに原文を入れてますので、間違いなど見つけられましたら、ぜひご指摘ください。ご指摘箇所は随時反映させていただきます。 原文のリンクが有効になってますので、それぞれ必要な場合は原文リンクの方を参照ください。 Introduction｜はじめに Overview｜概要The OpenAI API can be applied to virtually any task that i
[初心者向け]AWS Well-Architected ドキュメントの歩き方 | DevelopersIO
2022バージョンについて 新バージョンをリリースしています。 今後はこちらをご参照ください。 以下2021バージョン AWS認定トレーニング講師の平野@おんせん県おおいたです。 今日はWell-Architectedがテーマです。 はじめに AWS Well-Architected フレームワークとは AWSとAWSユーザの10年以上の経験からまとめられたベストプラクティクス集です。 いいかえれば、多くの失敗反省を元に作られています。 これからAWSを活用する際に、皆さんが同じ失敗をしないためのガイドラインとも言えます。 AWSを始めたら、まずは目を通してもらいたいドキュメントです。 とはいえ... とはいえ、このドキュメントなかなか読みづらいです。 私も正直最初は？？？という感じでした。 そこで、これからWell-Architected ドキュメントを読む方のサポートができないかと思い
![[初心者向け]AWS Well-Architected ドキュメントの歩き方 | DevelopersIO](https://cdn-ak-scissors.b.st-hatena.com/image/square/61b8033f05d1e5ba2c6b80dad8bd07c481d8078f/height=288;version=1;width=512/https%3A%2F%2Fdevio2023-media.developers.io%2Fwp-content%2Fuploads%2F2021%2F06%2FWA_guide-1.png)
Twitter、コードやドキュメント内の用語「Whitelist/Blacklist」「Master/Slave」「Dummy value」などを好ましい用語へ置き換え、具体例も発表
Twitter、コードやドキュメント内の用語「Whitelist/Blacklist」「Master/Slave」「Dummy value」などを好ましい用語へ置き換え、具体例も発表 Twitterエンジニアリングチームは、同社のソースコードやドキュメントで使われてる差別につながりかねない用語を、好ましい用語に置き換えると発表しました。 We’re starting with a set of words we want to move away from using in favor of more inclusive language, such as: pic.twitter.com/6SMGd9celn — Twitter Engineering (@TwitterEng) July 2, 2020 上記のように、同社のエンジニアリングチームは「インクルーシブな言語は、誰もが属する
宇多丸さんとコンバットRECさんが2023年4月7日放送のTBSラジオ『アフター6ジャンクション』の中でNHKで放送されたドキュメンタリー『ドキュメント「シン・仮面ライダー」』について話していました。 （コンバットREC）いや、本当にやっぱり田中邦衛の言うことは聞くもんだね。 （宇多丸）誰？ （コンバットREC）田中邦衛。「食べる前に飲む」って。やっぱりあれだけ何百回も言われてさ。やっておくべきだね。 （宇多丸）パンシロンだっけ？ （コンバットREC）大正漢方胃腸薬。（昨晩、お酒を飲みすぎて）今日、起きた時にもう胃腸が本当に調子悪くて。でも、食べた後でもやっぱり効くね。その後、飲んでみたらだいぶ復活したんでね。 （宇多丸）それは、なにも入れないよりはね。 （コンバットREC）やっぱり田中邦衛、すげえなって。 （宇多丸）でもさ、とにかくスタジオに入ってくるなりものすごい不機嫌で。「ううう……
むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。 実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。 使う 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも 詳細に書きすぎない 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい 管理者を置く ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要 個人的にはあんま
本記事の要約 ドキュメントを書かない事は、企業やチームの「負債」になる ドキュメントを書かない事は、自身の学びや振り返りの「機会損失」になる そういう文化が根付く前に、負の連鎖を断ち切ろう！ はじめに 世の中のプロジェクトには、ドキュメントが足りていない、と感じています。 でも残念な事に、ドキュメントをどうしても書きたい人は「ほとんどいない」と思います。 その一方で「ドキュメントを書いた方が良い」という事は、 何となく分かっている人も多いと思います。 やりたくない事をやらなければならないのは、嫌ですよね。 そんな気持ちは分かりますが、これを機に一度改めてみませんか。 何故なら、ドキュメントを書かない事はチームに「負債」を生むからです。 勤め人ならば少なからず一度でも、体験した事があると思います。 「どうして必要な過去の資料が無いんだ」って。 あるはずの歴史の一端がソースコードからしか分から
ドキュメント・東京から自転車で海に行く10時間の記録
1988年神奈川県生まれ。普通の会社員です。運だけで何とか生きてきました。好きな言葉は「半熟卵はトッピングしますか？」です。もちろんトッピングします。（動画インタビュー） 前の記事：あなたの知らない立ち食いそば屋めぐり～東急沿線さんぽ～ あれから13年、私は東京に住んでいる 親を離れ、一人で大都会東京に住んでいる。東京に住んでもう3年。先日、更新料を払った。10万円取られ、それが東京のやり方なのかと思った。 また、家の中にカギを置いたまま家を出てしまい、玄関のオートロックが開かず、外に締め出されたこともあった。東京は怖いところだ。 そんな日々を過ごしていたとき、ふと海を見に行きたいと思った。たぶん、いやしを海に求めていたのだ。 昔は悲しいことやつらいことがあるたびに海へ行き、ただ海を眺めて帰る、そんな日々を過ごしていた。あの頃はお金がないが、時間だけは無限にあったので、決してかっこよくはな
設計ドキュメント腐る問題、 Git管理で運用してみた 本当のところ 2023.12.5 真野隼記 ドキュメント管理を制する 陳腐化を防ぐための実践事例 Lunch LT
はじめに Domain Name System（DNS）はインターネットサービスを使用する上で欠かせない基幹サービスであり、DNSが関連するセキュリティインシデントへの対処は、健全なインターネットを維持するために重要です。本ブログでは、JPCERT/CCもメンバーとして参加しているFIRSTのDNS Abuse SIGが、2023年2月に公開したDNS Abuse Techniques Matrixについて、その日本語版をJPCERT/CCが主体となり作成および公開したので紹介します。 2023年2月、FIRSTのDNS Abuse SIGが公開したDNS Abuse Techniques Matrix - DNS Abuse Techniques Matrix https://www.first.org/global/sigs/dns/DNS-Abuse-Techniques-Matri
HashiCorp、ドキュメントの作成／レビュー／共有などを容易にする「Hermes」ドキュメントマネジメントシステムをオープンソースで公開
HashiCorp、ドキュメントの作成／レビュー／共有などを容易にする「Hermes」ドキュメントマネジメントシステムをオープンソースで公開 TerraformやVagrantなどで知られるHashiCorpは、「急成長するグローバル企業や遠隔地に拠点を置く企業にとって、書く文化は必要不可欠なものだと考えています（we also believe a culture of writing is a necessity for a fast growing, global, remote-oriented organization.）」として、同社内でも文書による情報共有文化が積極的に行われていると説明しています。 その同社が社内で開発し利用しているドキュメントマネジメントシステム「Hermes」を、オープンソースとして公開しました。 We are pleased to announce th
画像・PDF・TXT・メールなどの中身を読み取って検索できるようにするオープンソースのドキュメント整理ツール「Teedy」レビュー
Teedyはさまざまな種類のファイルの中身を読み取って検索できる状態にしてくれるドキュメント整理ツールです。受信したメールを自動で取り込む設定もできるとのことなので、実際にセルフホストして使い勝手を確かめてみました。 sismics/docs: Lightweight document management system packed with all the features you can expect from big expensive solutions https://github.com/sismics/docs TeedyのインストールにDockerを利用するので、下記のリンクから自分の環境に合った方法でDockerをインストールします。 Install Docker Engine | Docker Documentation https://docs.docker.com
AIでユニットテストを自動生成。リファクタリング、ドキュメントの生成、バグの検出なども行う「Refraction」登場
AIでユニットテストを自動生成。リファクタリング、ドキュメントの生成、バグの検出なども行う「Refraction」登場 ChatGPTに代表される自然言語やプログラミング言語のコードを理解するAIを用いてコーディングの支援を行うツールがまた新たに登場しました。 Refractionは、示されたコードから自動的にユニットテストを生成するほか、コードのリファクタリング、ドキュメントの生成、バグの検出などを行います。 Updates! https://t.co/9otFTI7nh0 is now https://t.co/MtN5JgnetI. Building out many utilities. You can... Generate unit tests Generate inline documentation Refactor your code Added a $5 / month
［速報］GitHub、組織のコードやドキュメントを学習しカスタマイズやファインチューニングが可能な「Copilot Enterprise」発表。GitHub Universe 2023
［速報］GitHub、組織のコードやドキュメントを学習しカスタマイズやファインチューニングが可能な「Copilot Enterprise」発表。GitHub Universe 2023 GitHubの年次イベント「GitHub Universe 2023」が米サンフランシスコで開幕しました。 1日目の基調講演で、Copilotが組織のコードやドキュメントを学習することで、カスタマイズやファインチューニングが可能になる「GitHub Enterprise」が発表されました。 Copilot Enterpriseは、外部に公開されていない組織内のコードやドキュメント、プルリクエストなどを追加でCopilotに学習させることで、組織内のコードベースに基づいたCopilotによるコードの生成や、Copilot Chatでの質問に対する回答が可能になるというものです。 さらに言語モデルそのものを組織
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Dockerfile のベスト・プラクティス — Docker-docs-ja 19.03 ドキュメント
プログラムの「アーキテクチャに関するドキュメント」は面倒でも書くべき、ではどのように書くべきか？
「マッチングアプリ」に疲れて「Googleドキュメント」に移行する人々が増加中 | もうスワイプする必要はない
ChatGPTを使った社内ドキュメントを読み込んで回答できるアシスタントBotを作りました！｜howdy39
ドキュメントDBかリレーショナルDBどっち使う？ - Qiita
ドキュメントとしての詳細設計書と、プロセスとしての詳細設計 - 勘と経験と読経
ドキュメントを書くときの「メンタルモデルの原則」 - クックパッド開発者ブログ
エンジニアのためのドキュメントライティング / Docs for Developers
HTTPキャッシュに学ぶ、無理のないドキュメント更新運用
ドキュメントを改善するためのはじめの一歩
自分の行っているセキュリティ関連の情報収集 - ドキュメントを見たほうが早い
データベースのドキュメント管理を自動化した話 - estie inside blog
OpenAI API ドキュメント 日本語訳｜#1 GET STARTED 前編｜ゑぐみかるちゃあ
日本語ネイティブのユーザーが英語ドキュメントを書く際に指針となるガイドが無料公開中【やじうまWatch】
宇多丸とコンバットREC『ドキュメント シン・仮面ライダー』の庵野秀明を語る
ドキュメントが更新されない問題 - Konifar's ZATSU
ドキュメントを書かないことは「負債を生む」ということ - Qiita
20231206_設計ドキュメント腐る問題、Git管理で運用してみた本当のところ
DNSの不正使用手法をまとめた技術ドキュメントの公開 - JPCERT/CC Eyes