始めに みなさま、アウトプットしてますか？ Twitter で日々情報発信する Qiita の記事を投稿する 勉強会で発表する などなど、アウトプットの方法はいろいろあります。エンジニアは日々のインプットが大事だけど、アウトプットも大事！というのはみなさまご存じの通りだと思います。 ・・・そうは言っても、アウトプットを多くするにはどうすればいいのかわからない！という方も多いと思います。私もその１人です。 そこで、私の知る範囲で圧倒的なアウトプットを生み出している山田展子さん（@e99h2121）に、「どうやったらたくさんのアウトプットを生みだせるんですか？？」という内容についてインタビューしてみました。 山田さんってどんな人？ 私にとっては、Works Human Intelligence の偉大な先輩です。Qiita のプロフィール（@e99h2121）を見るとわかる通り、ほぼ毎日何かし
OpenAPI や Protocol Buffers のおかげで開発がかなり捗っている話 | MEDLEY Developer Portal
2020-08-21OpenAPI や Protocol Buffers のおかげで開発がかなり捗っている話こんにちは、インキュベーション本部エンジニアの加藤です。 主に CLINICS アプリの開発を担当しています。 はじめにCLINICS アプリの開発では OpenAPI や gRPC を利用しています。 OpenAPI と gRPC の間には何の関係もないのですが、どちらも API の仕様をスキーマ言語で記述するという点では共通しています。 今回はこの API スキーマが開発にもたらすメリットについて紹介していこうと思います。 API ドキュメントとしてのスキーマ定義既存のコードに機能を追加する際や修正を加える際に気にすることの多い部分は API の仕様ではないかと思います。 「リクエストやレスポンスはどのようなデータなのか」「この値は必須なのか、任意なのか」「データの型は数値なのか
最初から強いやつの特徴 - Qiita
はじめに どんな仕事でも強い人は存在する。 でも最初から強い人は珍しい。 これは、web 業界に身を置いてみて、信じられないくらいムキムキになっていった人たちを見てきた私が送る こうしたら強くなれるかもしれない？指南書である。もしエンジニア職に興味があるのであれば、一考になるかもしれない。 最初から強いやつの特徴 平日の稼働時間以外も勉強 or 開発する 土日も勉強 or 開発する 公式ドキュメントをちゃんと読む 以上のような当たり前のことは、最初から強い人じゃなくてもやるので特徴に入れません。 1. 読解能力が異常に高い 国語の力です。 これは、ちゃんとドキュメントに書いてあることが理解できると同義です。 そしてこれが本当に大事です。 強い人に質問すると必ず「ん？ Docs 読んだ？」って聞いてきます。私は (...読んだわ！) って内心思ってますが、それは読んだだけです。内容をちゃんと
エンジニアが開発しやすい環境作りをする
はじめに 自分は渋谷のWeb系開発会社にて執行役員兼エンジニアをやっています。(新卒入社3年目) 直近では6~8名程のエンジニアがいるプロジェクトで、ディレクトリ設計やissue作成、コードレビュー、スケジュール管理、PMへのUI/UX及び機能提案などを行なっています。 その中で自分が「エンジニアチームにとって開発しやすい環境整備」を色々試し、実践してきたので整理していきます。 この記事の主な対象者 エンジニアチームの開発モチベーションを上げたい人 エンジニアにとって開発しやすい環境の作り方 おことわり 今回紹介するのは自分が実践してきた一例であり、必ずしも正解というわけではありません 「こうしなさい」ではなく「こうするとより良くなるかも」といったモチベで書いています 具体的な開発の設計を紹介するものではありません エンジニアが開発しやすい環境作り 5つのセクションに分けて紹介していきます
JSON Canvas
An open file format for infinite canvas data. Infinite canvas tools are a way to view and organize information spatially, like a digital whiteboard. Infinite canvases encourage freedom and exploration, and have become a popular interface pattern across many apps. The JSON Canvas format was created to provide longevity, readability, interoperability, and extensibility to data created with infinite
背景 ゴリゴリ系エンジニア、pageoです。 TwitterでMtgのあるべき姿についてツイートしたところ、ぼちぼちRT/いいねをもらえたので記事を書くことにしました。(お友達欲しいのでフォローしてください🙏) 最近大手クライアントとのPJに関わることが増えてきたのですが、事前アジェンダ共有なしに急にMtgが開催されるなどの無法地帯な場面に何度か遭遇したので、今回の記事では"Mtgの型"のあるべきについて自分の見解をまとめてみました。 はじめに Mtgの型 以下の章で紹介する"Mtgの型"はMtgというより議事録の書き方に寄っていますが、以下の章に書かれたことを実践することにより劇的にMtgの生産性は上がると思うので、この記事を機に是非自分/組織全体の"Mtgの型"について議論や検討をしてみてください。 いきなり結論 "Mtgの型"で説明する"教え"は以下の4つだけです 第一教: ~アジ
![[PM向け]死んだMtgを立て直せ~議事録から考える"Mtgの型"について~](https://cdn-ak-scissors.b.st-hatena.com/image/square/d4b118190a5bf163e1db49bbe20f392453552e68/height=288;version=1;width=512/https%3A%2F%2Fres.cloudinary.com%2Fzenn%2Fimage%2Fupload%2Fs--e1f08BaI--%2Fc_fit%252Cg_north_west%252Cl_text%3Anotosansjp-medium.otf_55%3A%25255BPM%2525E5%252590%252591%2525E3%252581%252591%25255D%2525E6%2525AD%2525BB%2525E3%252582%252593%2525E3%252581%2525A0Mtg%2525E3%252582%252592%2525E7%2525AB%25258B%2525E3%252581%2525A6%2525E7%25259B%2525B4%2525E3%252581%25259B~%2525E8%2525AD%2525B0%2525E4%2525BA%25258B%2525E9%25258C%2525B2%2525E3%252581%25258B%2525E3%252582%252589%2525E8%252580%252583%2525E3%252581%252588%2525E3%252582%25258B%252522Mtg%2525E3%252581%2525AE%2525E5%25259E%25258B%252522%2525E3%252581%2525AB%2525E3%252581%2525A4%2525E3%252581%252584%2525E3%252581%2525A6~%252Cw_1010%252Cx_90%252Cy_100%2Fg_south_west%252Cl_text%3Anotosansjp-medium.otf_37%3ARyuga%252520Irie%252Cx_203%252Cy_121%2Fg_south_west%252Ch_90%252Cl_fetch%3AaHR0cHM6Ly9zdG9yYWdlLmdvb2dsZWFwaXMuY29tL3plbm4tdXNlci11cGxvYWQvYXZhdGFyLzNkYTE4NjRiOTguanBlZw%3D%3D%252Cr_max%252Cw_90%252Cx_87%252Cy_95%2Fv1627283836%2Fdefault%2Fog-base-w1200-v2.png)
Kazuho Oku on Twitter: "HTTP を使うサーバクライアントアプリ作ってる人が、HTTP 的にどうするのが正しいのかな、と迷った時、見るべきドキュメントは BCP56bis かな、という話をした。HTTP の仕様ではなく、どのように使うべきかを説明した文書… https://t.co/7ke9ePZtTn"
HTTP を使うサーバクライアントアプリ作ってる人が、HTTP 的にどうするのが正しいのかな、と迷った時、見るべきドキュメントは BCP56bis かな、という話をした。HTTP の仕様ではなく、どのように使うべきかを説明した文書… https://t.co/7ke9ePZtTn
Tebiki社のWebアプリケーションエンジニアの中山と申します。前職では、SIerでAIアプリの開発を3年弱経験し、現職のTebiki社では、to B向けSaaSの機能開発を行なっています。好きな言語は、C++, Python, Ruby です！ この記事では、GitHub Discussionsの運用による知識のストック化と、新人オンボーディング時の負担軽減についてご紹介します！ Tebiki社のDiscussionsとは？Tebiki社では、エンジニアチーム内の知識を共有するツールとして、GitHubのDiscussions機能を活用しており、これまでチーム内で議論した内容や暗黙知であった内容をQ&A形式で記録しています。 TebikiのDiscussionsDiscussionsの運用ルールDiscussionsを運用するにあたって、以下のようなルールを作っています。 Discus
「文章を書ける人」になれば「仕事ができる人」になれる。大切なのは書く以前の “ある意識” - STUDY HACKER（スタディーハッカー）｜社会人の勉強法＆英語学習
noteやSNSやなどで発信力のあるビジネスパーソンに刺激を受け、「自分もそうなりたい」と思ったものの、実際にやってみると「書けない」「そもそも書くことがない」という経験をした人は多いはずです。 そこでアドバイスをお願いしたのは、SHOWROOM株式会社代表・前田裕二氏の著書『メモの魔力』（幻冬舎）など数々のベストセラーに携わってきた編集者でありブックライターの竹村俊助さん。「普段の意識を変えるだけで、いくらでも書くことは見つかる」と言います。 構成／岩川悟 取材・文／清家茂樹 写真／石塚雅人 【プロフィール】 竹村俊助（たけむら・しゅんすけ） 1980年生まれ、岐阜県出身。編集者、株式会社WORDS代表取締役。早稲田大学政治経済学部卒業後、日本実業出版社に入社。書店営業とPRを経験した後、中経出版で編集者としてのキャリアをスタート。その後、星海社、ダイヤモンド社を経て2018年に独立し、
架空プロジェクトを通してシステム開発とドキュメント作成を体験してみる（2022 Late） - Qiita
このコンテンツ作成の背景 プログラミングを体験できるコンテンツは沢山存在していますが、開発プロジェクト全体を通した流れを体験したり、実務では不可欠となるドキュメント作成を体験（学習）できるコンテンツは少ないので作ってみました。 とはいえドキュメント作成についてはテンプレート見ながら「こんなもんです」と解説する感じになります。。。 免責事項（いいわけ） 元々は社内の非技術系な人向けに研修用資料として作っていたものを、どうせなら公開するかな。という感じで再編したものなので、足りない部分やオレオレな部分、ゆらぎ、不整合、誤字脱字とかも多いと思います。「間違い」や「こうしたほうがいいよ」というのがあれば、コメント等で"優しく"教えていただけると助かります。少しずつ修正していこうと思ってます。 オレオレな情報だけでは申し訳ないので、一般社会ではプロジェクト関連のドキュメントはどう書くのか？については
ブログの文章やドキュメント作成など、さまざまなシーンで使われる記法に「マークダウン記法」があります。文字修飾の簡単さや読みやすさから使うタイミングは多々あると思いますが、みなさんは快適にマークダウンを書けていますか？ 筆者はVS Codeでドキュメントをマークダウンで書くことが多く、表の作成・編集やプレビュー表示など、めんどくさい・見づらい・使いづらいと思うことがあります。どうにか快適に書けないかと思いさまざまな拡張機能や設定を試しながら業務を行ってきました。 この記事では、筆者が試した拡張機能やVS Codeの設定の中で便利だったものを紹介します。①から⑥まではすべて無料で利用できるので気軽に試してみてください！ ①マークダウンの表をエクセルからコピペできる拡張機能 VS Codeでの表の作成に重宝しているのが「Excel to Markdown table」という拡張機能です。エクセル
テクニカルライターよ概念図を描くのです 〜テクニカルライターのためのイラストテクニック２〜 / cybozu illust technique2
ドキュメントでは、「モノや人の関係を明確に表わす」「複雑な流れをわかりやすく説明する」といった場面がたくさん出てきます。概念図は、言葉だけでピンとこない複雑な関係も、わかりやすく伝えることができます。 本セッションでは、テクニカルライター向けに概念図を描くテクニックをご紹介します。
AWS Well-Architected フレームワーク - AWS Well-Architected フレームワーク
要約 このホワイトペーパーでは、AWS Well-Architected フレームワークについて説明します。本書は、お客様が AWS 環境の設計、提供、メンテナンスを行う際にベストプラクティスを適用できるようにするためのガイダンスを提供します。ここでは Well-Architected フレームワークの柱とされる 6 つの概念領域における一般的な設計の原則と、特定のベストプラクティスおよびガイダンスを紹介します。 はじめに 定義 アーキテクチャ 一般的な設計の原則 フレームワークの 6 本の柱 運用上の優秀性 セキュリティ 信頼性 パフォーマンス効率 コスト最適化 持続可能性 レビュープロセス まとめ 寄稿者 注記 お客様は、この文書に記載されている情報を独自に評価する責任を負うものとします。本書は、(a) 情報提供のみを目的とし、(b) AWS の現行製品と慣行について説明しており、これ
Design Doc の書き方 / How to Write a Design Doc (Ja ver.)
「Design doc とは何か」・「何を書けばよいのか」を説明するスライドです。 関連するプレゼンテーション「読みやすいコードの書き方」: https://gist.github.com/munetoshi/65a1b563fb2c271f328c121a4ac63571 © 2023 Munetoshi Ishikawa, supported by LINE corporation
よりよい文書を書くための校正ツール「textlint」のSmartHR用ルールプリセットを公開しました！｜SmartHRオープン社内報｜株式会社SmartHR
おつかれさまです。プロダクトデザイングループのこぎそ（@kgsi）です。みんなのデザインシステムことSmartHR Design Systemプロジェクトの一環として、より良い文書を書くための校正ルール「textlint（テキストリント）」のSmartHR用ルールプリセットをオープンソースで公開しました！ SmartHR用ルールプリセット公開の背景 SmartHRのバリューには「一語一句に手間ひまかける」と、SmartHR Design Systemのデザイン原則の中でも「言葉からはじまるデザイン」と表されていますが、改めて、SmartHRは「言葉」をとても大切にしている会社ですよね。 UXライティングチームを中心に、日々文言ガイドラインが整備され、SmartHRの扱う言葉は進化しています。整備対象は各部署共通で使う文言から、ヘルプページ、プロダクトで使う文言まで多岐にわたっています。 ▲
【バックエンド】駆け出しエンジニアが目指すジュニアレベルのエンジニアとは【2024年版】 - Qiita
はじめに こんにちは。 普段はフロントエンドの開発をメインでやっておりますmamiと申します。 最近バックエンドの方の勉強や、少しずつですがDB設計やAPI作成などの業務もやらせてもらえるようになったので、自分のエンジニアとしてのレベル感や、この先目指すべき道筋を明確にしたいな〜という思いでこの記事を書いております。 これは自分のための記事であると同時に、同じように駆け出し中のエンジニアさんや、ミドル層を目指す手前のエンジニアさんにも刺さる内容になっているかと思います。 今、自分がどのようにキャリアアップしていくべきなのか、どのような道筋でスキルを磨いていけばいいのか。そんなふうに悩んでいる方は是非読んでみてください。 ※内容はバックエンドエンジニアが対象になりますが、フロントエンドの方もなにか通じるものがある…かもしれません。 ちなみにですがフロントエンドの方の記事は下記で執筆しています
FigmaとNotionでUML・経理処理・デザインまでAll in oneな仕様書を書いて、更新・共有を楽にしてる話 - Qiita
前提としての情報 単に「Figmaで要件定義のためのUMLも、外部設計のためのデザインも、内部設計のためのERDも全部つくるよ〜〜」という話をすると、ERD書くならデザインツールなんて使わないで、DBMSから自動生成できるツールとか使った方がいいじゃん、みたいな疑問が出るのは重々承知なので、そもそもこの形式に落ち着いた前提事項を書いておきたいと思います。 ご興味がなければ読み飛ばしてください。 筆者の仕事範囲 さて、冒頭で「事業会社でデザイナーとPMの狭間みたいな仕事をしてます」と書きました。キャリアの背景的には受託のPMっぽい仕事（厳密には違うんですが、本旨ではないので割愛します）→事業会社のインハウスデザイナー→現職という感じで、外渉から手を動かす所まで、必要ならなんでもします。 ざっくりいうと、機能の起案をして、経理などの関連部署に相談して、WBS引いて、UML書いて、画面遷移図書い
こんにちは、今回はデータ基盤構築を担当しているmarushoがお送りします。 今日はestieで実践しているデータベースのドキュメント管理方法をご紹介します。 はじめに 独自成長していくデータベースたち 失われたドキュメント どうすれば低コストなドキュメント管理ができるのか そして生まれた、schema collectorという自動化ツール SchemaSpy Mysql diff Priv Page ECS タスクスケジューラ ドキュメントを腐らせない おわりに はじめに estieはオフィスを中心とした不動産データを取り扱うスタートアップ企業です。 estie（オフィス探しサービス）とestie pro（不動産事業者向けデータプラットフォーム）の2つのサービスを運営しています。 詳しくは、こちらの記事をご覧ください。 inside.estie.co.jp estieでは、不動産に関する
Takramは、Notionで「知」を構造化する。学びの点と点をつなぐ、Notion活用法 | キャリアハック（CAREER HACK）
「Notionで、知の構造化を進めています」こう語ってくれたのは、デザイン・イノベーション・ファームTakramで働く野見山真人さん。プロジェクト単位や個々人に閉じてしまいがちな「学び」の点をつなぎ、「組織の知」として昇華しているという。Notionの使い方に宿る、Takramの思想とはー。 【プロフィール】Takram 野見山真人 Creative Technologist / Technical Artist 「感性 x エンジニアリング」をテーマに、サービスの設計からメディアアートの制作まで実用と象徴の軸を行き来しながら活動する。心の機微や人の行動原理を観察することで、感情に働きかける形を創造し、どこか捉えどころのない感性をエンジニアリングする。「感性 x エンジニアリング」を原動力に暮らしを豊かにするデザインを実現する。2018年に東京大学大学院（知能機械情報学）を修了。同年よりT
OpenAI API ドキュメントの日本語訳をこちらでまとめます。文字量の多いドキュメントなので、セクションごとに記事を分割しています。 今回は「GET STARTED 」のセクションからIntroduction と Quickstart を抜粋した前編です。 基本 DeepLで翻訳して、気になるところだけ書き換えています(ほぼ気になるところがないのが、DeepLのすごいところ)。原文との突き合わせができるようにはじめに原文を入れてますので、間違いなど見つけられましたら、ぜひご指摘ください。ご指摘箇所は随時反映させていただきます。 原文のリンクが有効になってますので、それぞれ必要な場合は原文リンクの方を参照ください。 Introduction｜はじめに Overview｜概要The OpenAI API can be applied to virtually any task that i
案件でAWSの構成図を作成する機会があったので備忘兼ねて投稿します。 ※約5分で読めます 1. グループの内側から作成していく AWSの基本的なグループ構成はこんな感じ 添付の場合、個人的には Public subnet or Private subnet > Availability Aone > VPC > Region > AWS Cloudの順番で作成することをオススメします。理由は内側のグループが肥大すると外側のグループの手直しが発生するためです。 今回作成した時に外側から作成してしまい、めっちゃ時間がかかってしまいました... 2. グループの左上を掴む 日本語が下手ですみません。 なぜ左上を掴まないといけないか？試しにPublic subnetをクリックしてドラッグをすると、添付の様になりました。 クリックをするとグループの外から選択されてしまうため、選択したグループ内に存在
社で何かキャッチアップするのがめちゃくちゃ上手い人がいる。 情報がまとまっているか、参照しやすいかといった社の状況にもよるのだけれど、上手い人には一定のパターンがある気がしていて、そのへんを雑にまとめておきたい。 検索対象の選択肢を持ち、最速を意識している Slackのやりとりを検索する、GitHubのIssueやPRを探す、Google Driveを検索するといった感じでまずシュッと探してみる癖が染み付いている どこに情報がまとまっているかを見極め、選択肢のうちどこからあたるかのが最速かを素早く判断している 検索条件を駆使している ワードでの検索だけではなく、日時の範囲指定、投稿者・メンション先といったフィルタリング、除外設定などを駆使している インデックスとなる人や聞く場所を作っている 人に聞いた方が早いことも多いので、どこで誰に聞けば辿れるかインデックスを作っている。人や場所がない場
ER図の自動生成について、dbdiagram.io, DBeaver, A5M2 を比較してみる。 - Qiita
はじめに データベース設計のER図について、自動で生成する以下３つのツールを比較した記事です。 dbdiagram.io DBeaver A5:SQL Mk-2（A5M2） 先日、こちらの記事をQiitaに投稿したところ、多くの方に記事を見ていただき、コメントも多数いただきました。 ER図に関するお勧めのツールをコメントいただく方が多くいらっしゃいました。 今回はその中から、無料でも利用できる3つのツールの「ER図の自動生成」の機能を試します。 比較の結論としては、〇〇が一番良いという感想ではなく、どのツールも多機能で、できることは違うので、今後使うときは用途や業務の環境によって使い分けていけたらと思っています。 目次 それぞれのツールについて、下記の内容を書いていきます。 1. dbdiagram.io 1-1. 始める 1-2. 使う 1-3. 感想 2. DBeaver 2-1. 始
AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ? - 変化を求めるデベロッパーを応援するウェブマガジン | AWS
こんにちは ! テクニカルトレーナーの杉本圭太です ! 最近読んで面白かった漫画は「海が走るエンドロール」です。 私は業務でお客様に AWS の様々なトレーニングを提供しているのですが、コースによっては AWS を利用したシステムのアーキテクチャ図を受講者自身に描いていただく演習を取り入れており、よくこんな相談を受けます。 「どうやって AWS のアーキテクチャ図を描くのが正解なんですか ?」 AWS のアーキテクチャ図を描く状況は以下のように様々な場面であり、同じような疑問や悩みをお持ちの方も多いのではないでしょうか ? 詳細設計で構成図が必要 チームで wiki などに図を貼り付けて残したい 構成検討フェーズなどで図を見てディスカッションしたい ワークショップを試しながら理解を深めるなど自分のために描きたい そこで今回は AWS アーキテクチャ図をどうやって描けば良いか悩んでいる方へ、
このブログは、 IVRy 紅白Advent Calendar 2023の白組・17日目の記事です。 白組16日目は PdM佐瀬さん「IVRyなら上流からUX/UIデザイン業務が実践できます！」でした。明日はIVRyのVPoE近藤さんの「IVRyにおける開発生産性へのアプローチ～SPACEフレームワークの視点から～」についての記事が出ます。乞うご期待。 この記事について タイトル通り、2023年に提案されて改善した事を発表するのですが、裏返すと「そんなこともできてなかったのか」と見える内容もあるかもしれません。ネガティブに受け取られる可能性もあるかもしれませんが、IVRyのオープンな社風や、常に改善と変革に前向きな姿勢をアピールするためにも、この記事を執筆することにしました。 なお、課題を発見・解決しながら会社を大きくしていきたいエンジニアの皆さんは、ぜひブログ一番下のIVRyの採用情報から
[初心者向け]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)
Becoming a Better Writer as a Software Engineer
Writing is an increasingly important skill for engineering leaders. Indeed, poor writing can hamper career progression, above a certain level. Tactics for more clear, more frequent and more confident writing. I’ve observed that my writing is not up to par with my peers. How can I improve my professional writing, as someone working in tech?I get this question from many people: senior engineers who
ECMAScript 2020の変更に対応したJavaScriptの入門書としてJavaScript Primer 2.0.0を公開しました。 JavaScript Primerのウェブサイトから閲覧できます。 ウェブサイト: https://jsprimer.net/ サマリIssue: ECMAScript 2020の対応 · Issue #1145 · asciidwango/js-primer 変更内容の詳細はリリースノートを参照してください。 Release 2.0.0: ECMAScript 2020対応 · asciidwango/js-primer 2.0.0の目的 JavaScript Primerは、継続的にメンテナンスするためにOSSとして開発しています。 ECMAScriptの仕様は年に一度アップデートされていて、現実でのJavaScriptの使われ方も変化していく
モダンな要件定義手法「RDRA」をRPGゲーム風にカスタマイズして説明してみた - Goodpatch Tech Blog
この記事はGoodpatch Advent Calendar 2022 18日目の記事です。 ソフトウェアエンジニアの 池澤です。 ここ最近はテクニカルディレクションとして仕事に関わることが増えました。その中で要件定義を作ったりデザイナーとエンジニアの橋渡しをする機会が多く、メンバーみんなが同じゴールを認識して制作できるようなより良い要件定義方法はないものかと探していました。 今回はそんな中で見つけたモダンな要件定義手法の一つ、RDRA（ラドラ）について、理解しやすくなるコツやカスタマイズしている内容についてお話しします。 なお、RDRAの詳細解説をするととても書ききれませんので、RDRA本体の詳細については公式サイト等をご参照ください。 RDRA（ラドラ）とは？ 概要 RDRAのバージョン これまでの要件定義でよくある問題 期待される要件定義の姿 公式サイト おすすめの学び方 実際のRD
yurinee @yurinee_IT Boxが社内に浸透して起きたこと。ファイル閲覧履歴が可視化されたことにより 担当者が毎月手間暇かけて作ってた資料が誰にも使われてなかった という事実が各地で表面化し、対策を打てるようになった 無駄だから作成廃止となったパターンでは、作成者は喜ぶより脱力してる事が多くいたたまれない 2022-12-17 20:03:49 リンク Box セキュアなリアルタイムのコラボレーション｜Box Notes Box Notesで情報共有をスムーズに アイデアの共有、プロジェクト計画の策定、情報源となるドキュメントの作成などの共同作業と情報共有を、デバイスを問わず、リアルタイムで行うことができます。 5 users 52
Send feedback Stay organized with collections Save and categorize content based on your preferences. Every engineer is also a writer. This collection of courses and learning resources aims to improve your technical documentation. Learn how to plan and author technical documents. You can also learn about the role of technical writers at Google.
テンプレートの特に重要な点の補足 上の表の「目的」にパーツに込めた設計意図は記載しましたが、特に重要な点を掘り下げてご紹介します。 おすすめ欄はできる限り書く 表を作る人が「自分はどれをおすすめするか」について印をつけることで、より自分ごととして調査できるようになります。 私もよく表を作ったはいいものの、いまいち深掘りできていないなと悩むことがあります。そのようなときに、「結局自分はどれがおすすめなんだっけ？」と印をつけることで、「この案をちゃんと説明するためにはこの観点や確認事項が漏れているな」と気づき、調査をもう一段階深掘りできることがよくあります。 もしチーム内での利用以外であえて自分のおすすめ案をアピールしなくても良い場合は、表を完成させてからカラムを抜くとよいかもしれません。 観点はカラム内で足して100%になるように心がける 調査対象に抜け漏れがないように分類は足して100%に
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 上記のように、同社のエンジニアリングチームは「インクルーシブな言語は、誰もが属する
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
Amazon Web Services ブログ AWS 初学者向けの勉強方法 6 ステップ！2022 年版！ 2024 年 4 月追記：本記事の内容は 2024 年 4 月に公開された AWS 初学者向けの勉強方法 6 ステップ！2024 年版！ という記事にてアップデートされています。リンクの最新化と勉強方法の追記を行っておりますので、アップデートされた記事をご確認ください。 こんにちは、AWS テクニカルトレーニング マネージャー の西村航です。 皆さん、もしくは皆さんの周りでこんな方はいませんか。「AWS を勉強したいんだけど何から勉強すればよいだろう。どこかに勉強方法がまとまってないかな？」という悩みを抱えている方、または「同僚や部下に AWS の勉強を促しているけど、ちょうど良い教材とか無いかな？」という悩みを抱えている方。本記事はそういった AWS を勉強する際の悩みを抱えた
むかし、この国が深い森におおわれ、そこに太古からの神々がすんでいた頃から語り尽くされているドキュメントが更新されない問題について雑に書く。 実態が変わったのにドキュメントが更新されない問題はいつどの時代も絶えない。これにいちいち憤りを感じるのは不幸になるだけなので、何かしら対処を考えておかねばならない。パッと思いつくのは次のようなものだろうか。 使う 使わないから更新もされなくなる。定期的に使われるように設計して、そもそも使わない場合は消した方がいい いっそ参照回数が少ないドキュメントは自動でアーカイブしちゃうみたいな硬派なスタイルの方がいいのかも 詳細に書きすぎない 細かいところを書きすぎると保守できない。骨組みだけ大事にして、細かいところはフロー情報として分けて書くのがよい 管理者を置く ちゃんと更新されるようロールを作る。属人化しないようにロールを引き継ぐ設計も必要 個人的にはあんま
ChatGPTプラグイン の作成方法｜npaka
1. ChatGPTプラグインの作成手順「ChatGPTプラグイン」の作成手順は、次のとおりです。 (1) APIの実装 (2) マニフェストファイルの作成 (3) OpenAPIドキュメントの作成 2. マニフェストファイルの作成2-1. マニフェストファイルの基本構成「マニフェストファイル」は、「ChatGPTプラグイン」のメタデータを記述するファイルです。APIのドメインの「/.well-known/ai-plugin.json」でホストします。 「マニフェストファイル」の基本構成は、次のとおりです。 { "schema_version": "v1", "name_for_human": "TODO Plugin", "name_for_model": "todo", "description_for_human": "Plugin for managing a TODO list.
宿泊開発チームでエンジニアをしている @kosuke1012 です。チームで ADR を書き始めて1年くらい経ったので、その感想を書いてみたいと思います。 この記事は 一休.comのカレンダー | Advent Calendar 2023 - Qiita の13日目の記事です。 ADRとは アーキテクチャ・ディシジョン・レコードの略で、アーキテクチャに関する意思決定を軽量なテキストドキュメントで記録していくものです。 出典はこちらで、 Documenting Architecture Decisions わかりやすい和訳は以下の記事が、 アーキテクチャ決定レコードの概要 | Cloud アーキテクチャ センター | Google Cloud アーキテクチャ・デシジョン・レコードの勧め | 豆蔵デベロッパーサイト アーキテクチャの「なぜ？」を記録する！ADRってなんぞや？ #設計 -
よくあるAWSサーバーレス構成のシーケンス図をMarkdown（Mermaid）で描いてみた | DevelopersIO
こんにちは、CX事業本部 IoT事業部の若槻です。 今までシステムのドキュメントなどでUML図を使用したい場合は、別途PlantUMLで書いて画像ファイルを生成し、MarkdownやAsciiDoc内に配置するということをしていました。 しかしこちらの記事の通り、Mermaidを使用すればMarkdown内で直接UML図の定義をコードで記述し、さらにGitHub上ではそのまま描画までしてくれるとのことです。知らなかった…！ GitHubでmermaid記法が使えるようになったのでアーキテクチャーの図を書いてみた | DevelopersIO そこで今回は、下記のようなよくあるAWSサーバーレス構成（API Gateway + Lambda + DynamoDB + α）のシーケンス図をMermaidで描いてみました。 描いてみた Mermaidにおけるシーケンス図の文法はこちらを参考にしま
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
日々息をするようにアウトプットしている人は何を意識しているのか？ - Qiita
[PM向け]死んだMtgを立て直せ~議事録から考える"Mtgの型"について~
GitHub Discussionsでチームの暗黙知を共有する
VS Codeでマークダウンを快適に書きたい！ オススメの拡張機能と設定6選 - ICS MEDIA
データベースのドキュメント管理を自動化した話 - estie inside blog
OpenAI API ドキュメント 日本語訳｜#1 GET STARTED 前編｜ゑぐみかるちゃあ
draw.ioを使ってAWSの構成図を作成するコツ - Qiita
社内の知らないことを探すパターン - Konifar's ZATSU
2023年・新しく入ったメンバーの提案で開発チームが良くなったこと5選
JavaScript Primer 2.0 - ECMAScript 2020に対応した入門書を公開しました
社内のファイル閲覧履歴が可視化された事によって残酷な現実が浮き彫りに「やらなくていい仕事だった…」
Technical Writing | Google for Developers
技術調査の結果を表にまとめる際のコツについて考えてみた | DevelopersIO
日本語ネイティブのユーザーが英語ドキュメントを書く際に指針となるガイドが無料公開中【やじうまWatch】
AWS 初学者向けの勉強方法 6 ステップ！2022 年版！ | Amazon Web Services
ドキュメントが更新されない問題 - Konifar's ZATSU
ADR を1年間書いてみた感想 - 一休.com Developers Blog