インプットのすゝめ | 外道父の匠
絶賛成長期にあるだろう若手エンジニアは、どういう流れで自身の成長を促したら良いのだろうか、とふと思いつつ口頭で説明してみたけどよくわからんくなったので整理してみたいお気持ちです。 当ブログではアウトプットの効用みたいなものは書いてきましたが、インプットそのものについてはお初なので、自身を振り返る良い機会にもなりそうです。 はじめに これは私が二十数年間、プログラマー・インフラ・SRE といったエンジニアとして通ってきた中で、どのようにインプットをしてきたかを整理してみるチラ裏です。 自分は一般(?)と比べれば少々特殊な経歴で、情報学を学んだことも、新卒研修を受けたことも、IT系資格も、転職したこともない…… ほぼ独学による野良エンジニアとして生息してきましたので、あまり参考にはならないかもしれません。 それでも一応長く生き抜いてきたエンジニアの経験として、インターネットに数多くある参考例の
ADR を1年間書いてみた感想 - 一休.com Developers Blog
宿泊開発チームでエンジニアをしている @kosuke1012 です。チームで ADR を書き始めて1年くらい経ったので、その感想を書いてみたいと思います。 この記事は 一休.comのカレンダー | Advent Calendar 2023 - Qiita の13日目の記事です。 ADRとは アーキテクチャ・ディシジョン・レコードの略で、アーキテクチャに関する意思決定を軽量なテキストドキュメントで記録していくものです。 出典はこちらで、 Documenting Architecture Decisions わかりやすい和訳は以下の記事が、 アーキテクチャ決定レコードの概要 | Cloud アーキテクチャ センター | Google Cloud アーキテクチャ・デシジョン・レコードの勧め | 豆蔵デベロッパーサイト アーキテクチャの「なぜ？」を記録する！ADRってなんぞや？ #設計 -
RAGにおけるドキュメント検索精度向上について(概要編)
はじめまして。損害保険ジャパン株式会社 DX推進部の眞方です。普段はリードエンジニアとして、新しいサービスのアーキテクチャ検討からローンチまでの作業や、新規技術を用いたアプリのプロトタイプ実装などを行なっています。 弊社では、LLM（Large Language Models）を活用したアプリケーションの開発を積極的に検討し、既に社内でいくつかのプロトタイプをローンチしています。 本記事では、その最も一般的？なユースケースの一つとも言えるRAG（Retrieval Augmented Generative）の構築において、ドキュメント検索精度の向上にどのように取り組んだ内容の概要を紹介させていただきます。実際の詳細な手法および結果については、別記事（実践編）で解説予定です。 はじめに RAGとは？ この記事を読まれている方の中にはご存知の方も多いでしょうが、RAGとはRetrieval A
社内ドキュメントはなぜ更新されないのか？情報の鮮度を最小限の運用負荷で維持する「イミュータブルドキュメントモデル」のススメ - KAKEHASHI Tech Blog
はじめに こんにちは。カケハシの各プロダクトを支えるプラットフォームシステムの開発チームでテックリードを担当しているkosui(@kosui_me)です。 プロダクト開発の世界では、明瞭な社内向けドキュメントを書くための方法が数多く提案されてきました。読者の中には、製品要求を明瞭にするためにPRD (Product Requirements Document、製品要求仕様書) を書き、プロジェクトの背景から全体の設計やその代案について明瞭にするためにDesign Docsを書き、アーキテクチャに関する意思決定の記録を明瞭にするためにADR(Architecture Decision Record) を書いてきた方も数多くいらっしゃると思います。 しかし、どんな素晴らしいドキュメントも、何故か更新されなくなります。新メンバーへのオンボーディングのためにインフラ構成図を検索したあなたが見つけた
デザイナー向けに行なったHTML勉強会の資料を公開します｜sakito
今回はChatwork株式会社のデザイナー向けに行なったHTML勉強会で使用した解説資料をお伝えします。私は3年ほど前からChatwork株式会社の開発のサポートやデザイン基盤活動のアドバイザーとして参画しており、その活動の一環で会を開催しました。 開催の意図と目的開催概要は@emimさんが、UI設計はHTMLの理解からというタイトルでnoteに書いてくれています。企画の意図は下記のとおりです。 企画の意図 根本としては、情報整理（情報設計）の基礎概念にHTMLがとてもマッチしている、と考えているからです。 ところが、業界的にも昨今よく聞く話ではありますが、最近意外にHTMLに触れる機会がなくプロダクト開発の現場に入る人が多いのが現実です。これは、デザイナーだけでなく、なんならフロントエンドの開発者であっても。 個人的には、HTMLはマークアップ言語であること以上に、構造化のフレームワーク
令和最新版エンジニアのリーダーシップ論 - エムスリーテックブログ
エムスリーエンジニアリンググループ製薬企業向けプラットフォームチーム（「Unit1」）の三浦 (@yuba)です。乗り物大好き男の子ですので好きなテレビ番組は銀河鉄道999とナイトライダーです。 さて「フラットな組織」だとよく言われるエムスリー、特にわがエンジニアリンググループなのですが、そのフラットってどういう感じなんでしょう？ 上意下達の体制でない中では、人々はどう組織としての目標を共有して一緒に動いているんでしょう？ この疑問への、（管理職でない）一般エンジニアとして5年半やってきた私なりに得た答えをご紹介したいというのが今回のお題になります。これは エムスリー Advent Calendar 2022 の5日目の記事です。前日は id:hsasakawa による グローバルサービスの開発における技術的な意思決定 - エムスリーテックブログ でした。 そしていきなり最初に結論から言っ
ER図の作図について、 Draw.io, PlantUML, Mermaid を比較してみる。（VSCode拡張機能など） - Qiita
※ 参考記事「PlantUML を VSCode で利用したいけど、プレビューが表示されずエラーが出る」 参考（PlantUML 導入後の編集中画面） 2-2. ER図 今回作成したER図 Qiita記事でも、コードブロック内でPlantUMLの構文がそのまま使えます。（このER図は、Qiitaのコードブロックで表示させています） 今回作成したER図のPlantUMLの表記 @startuml yonde ' hide the spot hide circle ' avoid problems with angled crows feet skinparam linetype ortho entity "families" as families { id -- name nickname introduction created_at updated_at } entity "users
Goの初心者が見ると幸せになれる場所 #golang - Qiita
公式サイト A Tour of Go Web上で実行しながら学ぶことができる公式のチュートリアルです。 チュートリアル 公式のチュートリアルです。初学者向けからジェネリクスのチュートリアルなども用意されています。 A Tour of Goが終わった後に取り組むと良いでしょう。 Go Wiki Go Code Review Commentsなどが掲載されているGitHub上のWikiです。 パッケージドキュメント 標準パッケージやサードパーティ製のパッケージのドキュメントが見れるサイトです。検索もできます。 入門 プログラミング言語Go完全入門 筆者が作っている巨大なGoの入門資料です。なぜGoが作られたのか、から最新のジェネリクスの情報、静的解析まで扱っています。 Gopher道場 Goを体系的に学べる場です。10時間くらいある動画教材（自習室から入手可）もあります。 Go の最初の手順
ドキュメントに固執せよ - gfnweb
どうして人間集団はこんなにも知見の共有を円滑にできないのか？ 改善にはドキュメントにまつわる各個人の心構え・制度設計・技術的解決の全部が必要だという話をしたい． ここでテーマにしているのは，著名OSSなど世の中にいくらでも知見が転がっている対象ではなく，特に企業内の十数人のチームでクローズドに開発しているなどして集合知に頼れない状況下でのドキュメントについてである． 非常に乱暴な言い方をするなら，「コードとか大部分は誰でも書けるようになるものなんよ，そんなところにマッチョイズムとか感じなくてええねん，我々の知的体力や組織性が真に試されるのはドキュメントちゃうんか」という気持ちです — 画力・博士号・油田 (@bd_gfngfn) June 3, 2022 ドキュメントに書く内容の必須項目或るシステム（ソフトウェアなど）について，そのシステムのことを全く知らない人を想定読者としたドキュメント
BigQuery リモート関数で Natural Language API を使って、SQL でお客様レビューの感情分析してみた。 | DevelopersIO
BigQuery リモート関数で Natural Language API を使って、SQL でお客様レビューの感情分析してみた。 こんにちは、みかみです。 Google Cloud 認定 Data Engineer の勉強してたら思ってた以上に ML 要素が強そうで現実逃避したくなってきたので、大好きな BigQuery と遊ぶことにしました。。（ML わけがわからないよ。 はじめに リモート関数とは BigQuery から SQL を実行する時に呼び出せる外部関数で、ユーザー定義関数（UDF）と同じように使えます。 API コールなど、BigQuery 内で完結できない処理もリモート関数を使えば実装できちゃいます。 2022/05/20 現在、まだプレビューの機能ですので、利用する際にはご留意ください。 リモート関数の操作 ｜ BigQuery ドキュメント Extending Bi
Draw.io（diagrams.net）で作成したインフラ構成図をコードで管理する、GitHubで編集差分を確認する | DevelopersIO
こんにちは、CX事業本部 IoT事業部の若槻です。 Draw.io（diagrams.net）は、JGraph Ltdにより提供されているオンラインのダイアグラム作成サービスです。無料で利用可能です。 Diagram Software and Flowchart Maker 今回は、Draw.io（diagrams.net）で作成したインフラ構成図をコードで管理し、GitHubで編集差分を見る方法を確認してみました。 やってみた VS Codeプラグインの導入 Draw.ioの構成図のデータは、Draw.io Integrationというプラグインを使えばVisual Studio Codeで編集できます。とても便利なプラグインなので導入します。 Draw.io Integration - Visual Studio Marketplace Draw.ioで構成図を作成する Draw.io
本当に実践的なデザインドキュメントの書き方 第1回：なぜ渡されたワイヤーフレームは分かりにくいのか？ | アドビUX道場 #UXDojo
本当に実践的なデザインドキュメントの書き方 第1回：なぜ渡されたワイヤーフレームは分かりにくいのか？ | アドビUX道場 #UXDojo 連載 本当に実践的なデザインドキュメントの書き方 いきなり渡されたワイヤーフレームをデザインするよう言われて戸惑った経験は、デザイナーなら誰でもあるのではないでしょうか？これはディレクターとデザイナーの分業という状況に起因する問題ですが、分業が一般的なのにはもちろん理由があります。そこで、この連載では、現在の分業体制を前提に、情報設計に関わる『デザインドキュメント』をきちんと制作することで、この問題を解決する手段を探ります。 第1回は、受託のWeb制作における一般的な分業体制を詳細に分析し、よりデザイナーが貢献できる役割分担について考えていきます。 なかなかはじめられないUXデザイン これはGoogleトレンドで、「Webディレクター」「Webデザイナー
【翻訳】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分 (目次) デザインドキュメント の解剖学 文脈と範囲 目標と非目標 実際のデザイン システ
プロジェクトに浅瀬を作る
はじめに プロジェクトに参加しているメンバーがうまく環境に適用できずに離脱することがあり、ともすれば、身体を壊してしまうケースもあります。これは新規メンバーに限定されず、既存のメンバーでも、プロジェクトや本人の状況、その役割が変われば発生し得ると思っています。 そういったことを回避できた状態を想像した時にプロジェクトに浅瀬があったら良いのではというイメージからこの言葉が浮かんだのだと思います。2年ほど前のメモ書きにこのタイトルが残されていて、今見直した時にすごくしっくり来ました。 メモ書きを発見したツイート この「プロジェクトに浅瀬を作る」とは、どういうことなのか、改めて深堀したいと思います。 どういうこと？ 溺れないようにするのが目的 監視員が必要のない状態が理想 溺れないようにするのが目的 溺れるというのは、闇雲に時間がかかってしまい心身ともに疲弊してしまうイメージです。不慣れなため必
【汎用ソフトスキル】ドキュメンテーションの続け方
この記事の目的 最近「良いドキュメントが作れているな」と思う機会が増えてきたので、その知見をアウトプットしたくなった。 想定読者 今所属してる組織(会社/プロジェクトなど)のドキュメントがイマイチで悩んでいる人 そもそもドキュメントが無い組織に所属していてつらい思いをしている人 「ドキュメントを作れ」という漠然としたタスクを振られて困っている人 想定読者ではない人 メンテなブルなドキュメンテーションのエコシステムが完成している組織で更によいやり方を模索している人 私もまだ模索中なので、いいやり方があれば教えてほしいです👀 顧客提出などの「納品が必要」なドキュメントの管理方法を模索している人 この記事では「社内の情報共有」にスコープを切って話をしています 書いている人のスペック(参考) 歴５年くらいのなんちゃってフルスタックエンジニア 普段は Node.js / React.js or R
はじめに - アルゴリズムとデータ構造大全
はじめに このドキュメントは，主に競技プログラミングで出題される問題を解く際に利用できるアルゴリズムやデータ構造をまとめたものです．特定の問題にはあまりフォーカスしないため，問題を解く際の考察の仕方等の内容はありません．詳しく，正確に，分かりやすく書いていこうと思っています． このドキュメントは執筆途中です． 想定する読者 C++を用いたプログラミングに慣れている方を読者として想定しており，C++言語の仕様や，文法にはあまり触れません．また，計算量という用語についても説明しません．ただし，償却計算量など，計算量の見積もりが複雑なものについては必要に応じて説明します． コードについて このドキュメントで登場するコードは，可読性向上のため，以下のようなコードがファイルの先頭に記述してあることを前提としています．また，適切な問題を用いてコードの検証がなされている場合は，コード周辺にのように，検証
仕事ですぐに使えるTypeScript — 仕事ですぐに使えるTypeScript ドキュメント
注釈 本ドキュメントは、まだ未完成ですが、ウェブフロントエンドの開発を学ぶときに、JavaScriptを経由せずに、最初からTypeScriptで学んでいく社内向けコンテンツとして作成されはじめました。基本の文法部分以外はまだ執筆されていない章もいくつもあります。書かれている章もまだまだ内容が追加される可能性がありますし、環境の変化で内容の変更が入る可能性もあります。 書籍の原稿はGitHub上で管理しております。もしTypoを見つけてくださった方がいらっしゃいましたら、 GitHub上で連絡 をお願いします 1 。reSTファイルだけ修正してもらえれば、HTML/PDFの生成までは不要です。フィードバックなども歓迎しております。 1 https://github.com/future-architect/typescript-guide/pulls
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
テクニカルライティングの基本 2023年版
テクニカルライティングの基本
脱ExcelしたいMarkdownテンプレート目次 - Qiita
