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
Diagram as Code
Diagram as Code6 different ways to turn code into beautiful architecture diagrams
じゅじゅ @jujulife7 完全無料で学べる有名企業のエンジニア研修資料（最新版）をまとめました。 エンジニアの方にお勧めなのは勿論ですが、総合職・デザイナー職がエンジニアと円滑にコミュニケーションとるための基礎知識が求められる時代かと思うので、文系職の方も是非保存して勉強みてください。 pic.twitter.com/sDek1U43q5 2022-07-21 22:50:52
Cloudscape offers user interface guidelines, front-end components, design resources, and development tools for building intuitive, engaging, and inclusive user experiences at scale.
はじめに 2020年10月、Githubがデフォルトのメインブランチ名をmasterからmainに変更しました。理由は、masterがslave（奴隷）を背後に連想させるため。 旧来の価値に根差した既存の用語を置き換える動きは、2020年を契機としてますます勢いを増し、その影響は仕様の策定から命名規則などのコーディング面にまで幅広く及んでいます。 こうしたアメリカのテック界の様相をInclusive Writingの切り口から、Google, Appleのスタイルガイドを摘要しながら概観するのが本稿の趣旨です。 Inclusive Writingとは？ Inclusive Writingはかんたんには、多様な読者を意識した書き方、といえます。 Inclusiveは日本語でも「インクルーシブ教育」等、ダイバーシティの文脈でカタカナ語として定着しつつありますが、強いて訳せば「包含、包み込む」と
分析 運営面と集客面を主に考えていきます。 厳密に言えば違うこともありますが、私の使用感で評価します。 Zenn 検索はしにくい そこそこに認識はされてきている Qiitaの規約に疲れた人が使っているイメージ 主な集客はGoogle検索か Qiita 検索がしやすい ユーザーが多い (エンジニアリング初心者の)信頼度が高い 悲しいことに、公式サイトやリファレンスで情報収集をする初心者はいません… アドベントカレンダーなど記事投稿のイベントがある 貢献度でユーザーの信頼情報がわかる note ユーザーが圧倒的に多い エンジニアリング以外に強い 個人ブログ 管理（特にメンテナンスなど保守）が大変 広告を自由自在につけられる 複数サイトを作るのが大変 ユーザー動線を誘導できる 番外：StackOverFlowやteratailなど質問サイト ユーザーは多くないが、常連が多い 投稿者に対して非常に
リリースノート管理術
みなさま、OSSの変更履歴、要するにCHANGELOGやリリースノートはどのように管理しておられるでしょうか。自分はというと、抱えるリポジトリも数百個に増えてきて、まあ要するに細かく管理するのがだるく、最近は変更履歴の管理方法も変わってきました。 CHANGELOGからGitHub Releasesへ 昔は、おおよそKeep a changelogの方式に準拠したCHANGELOG.mdを書いていました。semantic versioningでバージョン管理をしながら、個々のバージョンごとに次のセクションを設けて変更内容を説明するような感じです。 Added Changed Deprecated Fixed Removed Security 今は、新規につくるリポジトリではCHANGELOG.mdは用意せず、GitHub ReleasesにKeep a changelogに似た形式で変更内
Djot is a light markup syntax. It derives most of its features from commonmark, but it fixes a few things that make commonmark's syntax complex and difficult to parse efficiently. It is also much fuller-featured than commonmark, with support for definition lists, footnotes, tables, several new kinds of inline formatting (insert, delete, highlight, superscript, subscript), math, smart punctuation,
ゼロトラストの概念は近年のテレワークやクラウド利用の普及により注目を集めていますが、いざ自組織に実装しようとしたときにはさまざまな課題に直面することが予想されます。また、ゼロトラスト移行の効果を最大限発揮するためには、ゼロトラストに対する担当者の理解が不可欠になっています。 そこで本書ではゼロトラストの概念を自組織に実装する際に必要となる検討の流れや、得られるメリット、ソリューションの導入順序とその際のポイントについてまとめました。これからゼロトラスト移行を検討している組織の担当者に参考にしていただけると幸いです。
GitHub - gogitdb/gitdb: Distributed Embeddable Database
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
今年も技術研修資料と動画を公開します！MIXIの新卒技術研修の方針や、LayerX様との合同研修についても紹介します！ 研修資料・動画一覧Git研修（ 動画 / スライド ）データベース研修（ 動画 / スライド1, 2 / SQL演習環境 ）設計・テスト研修（ 動画 / スライド ）コンテナ研修（ 動画 / スライド1, 2 ）iOSアプリ開発研修（ 動画 / スライド / リポジトリ ）Androidアプリ開発研修（ 動画 / スライド / リポジトリ ）フロントエンド研修（ 動画 / スライド / リポジトリ ）ゲーム開発(Unity)研修（ 動画 / スライド1, 2, 3, 4, 5, 6 / リポジトリ ）Flutter研修（ 動画 / スライド / リポジトリ ）AI研修（ スライド1, 2, 3, 4 / リポジトリ ）セキュリティ研修（ スライド ）チーム開発研修（ スラ
障害報告書を書こう！ - Qiita
担当しているITサービスなどに何かしらのインシデントや障害が発生した時に、対処後のアクションとして報告書を提出して事象の内容を報告（レポート）する場合がある。 提出先は会社の偉い人だったりクライアントだったり。場合によってはユーザー向けに発表したり。事の顛末を報告して「今後同様のことを起こさないように努力します、ごめんなさい」をするのだ。どのように再発防止の努力するのかを書くものでもある。 主にクライアント向けのビジネス内容ではあるが、自分が使っているテンプレパターンを共有するので参考にしてもらえればと思う。1 全般的なポイント 心得のようなもの。次の点は留意してて欲しい。 淡々と冷静な説明をこころがける 当然のことながら事実は脚色しない。無駄な修飾も要らない。客観的な事実を簡潔に述べる。 例： ❌「一生懸命頑張って対応したが…」 ❌「寝ないで対応したが…」 ❌「本当の原因は…」 できるだ
仕様起因の脆弱性を防ぐ！開発者向けセキュリティチェックシート(Markdown)を公開しました - Flatt Security Blog
はじめに こんにちは。株式会社Flatt Securityセキュリティエンジニアの村上 @0x003f です。 これまで弊社ブログでは様々な「仕様とセキュリティ観点の解説記事」を発表してきました。今回はいままでの記事を改めて紹介しつつ、読者の皆様が開発中のサービスでセルフチェックを行えるよう「仕様とセキュリティ観点チェックリスト」を作成しました。ご活用いただけると幸いです。 ダウンロードは下記のGitHubリンクよりどうぞ。 また、株式会社Flatt Securityではお客様のプロダクトに脆弱性がないか専門のセキュリティエンジニアが調査するセキュリティ診断サービスを提供しています。料金に関する資料を配布中ですので、ご興味のある方は是非ご覧ください。 はじめに アプリケーションの仕様起因の脆弱性とは アプリケーションの仕様起因の脆弱性を防ぐために 仕様の脆弱性によく見られる共通点 1. ク
セキュリティ英単語帳
2022年6⽉ 独⽴⾏政法⼈ 情報処理推進機構 産業サイバーセキュリティセンター 第5期中核⼈材育成プログラム 「セキュリティエンジニアのための English Reading」プロジェクト 動詞 単語 意味 関連語 使用例 include ～を含む 【名】inclusion: 包含、含まれるもの 【形】inclusive: すべてを含んだ the email including a malicious macro 悪意のあるマクロを含むメール steal ～を盗む steal sensitive information 機微な情報を盗む exploit (脆弱性) を突いて攻撃する 【名】エクスプロイト (コード) 【名】exploitation: (脆弱性を突く) 攻撃 【形】exploitable: 悪用可能な actively exploited vulnerability よく攻
政府情報システムにおける 脆弱性診断導入ガイドライン 2022（令和 4）年 6 月 30 日 デジタル庁 〔標準ガイドライン群ＩＤ〕 DS-221 〔キーワード〕 セキュリティ、脆弱性、脆弱性診断 〔概要〕 政府情報システムの関係者が脆弱性診断を効果的に導入するための基準及 びガイダンスを提供する。 改定履歴 改定年月日 改定箇所 改定内容 2022年6月30日 - 初版決定 1 目次 １ はじめに ......................................................... 2 １.１ 目的とスコープ .............................................. 2 １.２ 適用対象 .................................................... 3 １.３ 位置づけ ...
Companies Using RFCs or Design Docs and Examples of These
RFCs - requests for comment - or Design Docs are a common tool that engineering teams use to build software faster, by clarifying assumptions and circulating plans earlier. There are some similarities between writing automated tests for your code, and writing RFCs before you start working on a non-trivial project: Software engineers who write tests for their code - and ask for code reviews on it -
AWSがアーキテクチャ決定レコードのガイドを公開
Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
Effects are an escape hatch from the React paradigm. They let you “step outside” of React and synchronize your components with some external system like a non-React widget, network, or the browser DOM. If there is no external system involved (for example, if you want to update a component’s state when some props or state change), you shouldn’t need an Effect. Removing unnecessary Effects will make
市野川 @irsaitama IT業界に居ると、海外製品の日本語ドキュメントが無くなったり機械翻訳になったりして、年々ローカライズが手抜きになっていく点に我が国の経済的な没落を実感する 2022-06-26 12:09:56
Defensive CSS
Defensive CSS Practical CSS and design tips that helps in building future-proof user interfaces. @DefensiveCSS Introduction to Defensive CSS An explanation of the concept of defensive CSS, what it means, why it's useful and how it applies to different areas in the design process.
概要 Design Documentと聞くと何を想像しますか？ 一般的にDesign Documentが指すのは設計書であることが多いのではないでしょうか。 設計書、簡単に説明するのであればソフトウェアを「どうやって作るの？」を説明したドキュメントです。 Googleではソフトウェアエンジニアリング文化における重要な要素として、今回お話ししていくDesign Docsと呼ばれるものがあります。 Design Docsとは？ Design Docsとは、開発者がコーディングに着手する前にソフトウェアシステムまたはアプリケーションの開発する人が作成するドキュメントです。 => ソフトウェア設計における仕様書や設計書とは別物と捉えた方がよいです。 仕様書、設計書は作成した上でのDesign Docsの作成となるようです。 このドキュメントには、高レベルの実装戦略と主な設計の決定事項がまとめられて
GitHub - Azure/Azure-standardization-guideline: Repository for Azure standardization guideline
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
Real World HTTPでも紹介したネタですが、お仕事で受けている技術コンサル中に質問をいただいた時に、微妙に本で紹介した内容では少し足りなかったので、改めて整理のためにブログ記事にしてみました。次回、本が改訂されることがあればこのブログエントリーの内容も入れて加筆したいと思います。 Real World HTTPだとGoを使っていましたが、フロントとサーバーを同時にいじるので、本エントリーではNext.jsをサンプルに使います。Next.jsでプロジェクトを作って（npx create-next-app@latest –ts)、適当なプロジェクト名を入れてアプリケーションの雛形を作っておいてください。 Next.jsでは、1つのスクリプトファイルを作成すると、それがサーバーAPI(/pages/api以下)と、フロントの画面(/pages/以下のapi以外)になります。Next.j
みなさんこんにちは、電通国際情報サービス（ISID）Xイノベーション本部ソフトウェアデザインセンターの佐藤太一です。 少し前になりますが4/23に、私はGo Conference 2022 SpringにおいてGo で RDB に SQL でアクセスするためのライブラリ Kra の紹介というタイトルで登壇しました。 登壇時の資料はこちらです。 このエントリでは、スライドを作成する際に私が考えていることや、情報を整理する方法について説明します。 伝えたいメッセージを作りこむ アイディア出し 初期のアイディア出し例 アイディアの統合 アイディアの統合例 メッセージの絞り込み メッセージの例 今回のメッセージ 伝えたい情報を構造化する 構造のテンプレート 論理の順序を整理する まとめ 伝えたいメッセージを作りこむ 私が技術系のイベントに登壇する際に最も重視しているのがメッセージの作りこみです。
私 (@kossmori) が働くアメリカのスタートアップでは、どんな会話においても ”Is there a design doc?” (デザインドックはないの?) という質問が連発します。 会話のコンテクストを合わせるため、取り組みの背景を理解するための必須資料として位置づけられています。 デザインドックは技術詳細を書いた仕様書ではありません。 取組みに関わる Why, What, How と、ハイレベルな実装戦略、主要な設計上の決定、決定の際に考慮されたトレードオフに重点を置いて文書化したもので、それをもとにエンジニアは必要に応じてTech docを書き、デザイナーはデザインを始めます。 追記: その2も書きました。最後の方に記事へのリンクを貼っています。 追追記: 思った以上に反響あり、この記事のおかげでこれまで非常に多くの スタートアップの方々とお話しさせていただく機会をいただき
ドキュメントに固執せよ - gfnweb
どうして人間集団はこんなにも知見の共有を円滑にできないのか？ 改善にはドキュメントにまつわる各個人の心構え・制度設計・技術的解決の全部が必要だという話をしたい． ここでテーマにしているのは，著名OSSなど世の中にいくらでも知見が転がっている対象ではなく，特に企業内の十数人のチームでクローズドに開発しているなどして集合知に頼れない状況下でのドキュメントについてである． 非常に乱暴な言い方をするなら，「コードとか大部分は誰でも書けるようになるものなんよ，そんなところにマッチョイズムとか感じなくてええねん，我々の知的体力や組織性が真に試されるのはドキュメントちゃうんか」という気持ちです — 画力・博士号・油田 (@bd_gfngfn) June 3, 2022 ドキュメントに書く内容の必須項目或るシステム（ソフトウェアなど）について，そのシステムのことを全く知らない人を想定読者としたドキュメント
「論文入門」というより「学問全般への入門」・小熊英二『基礎からわかる論文の書き方』 - そういちコラム
このあいだ小熊英二『基礎からわかる論文の書き方』（講談社現代新書、2022年）を読みました。 本書の話をする前に、著者の小熊英二さん（1962～）について。それが本書を語るうえで大事なのです。ご存じの方も再確認ということで。 ＊＊＊ 小熊さんは著名な社会学者で慶応義塾大学教授。東京大学の農学部を卒業後、岩波書店に数年勤務しましたが、東大の社会科学系の大学院に入りなおして博士号を取得。 大学院在学中に、修士論文を書籍化した『単一民族神話の起源』（1995年）が出版され、評判となる。 その後は博士論文にもとづく『〈日本人〉の境界』（1998年）や、『〈民主〉と〈愛国〉』（2002年）、『１９６８（上・下）』（2009年）などを著す。これらの代表作はいずれも、近現代の日本の社会・思想を扱った学術的な大著です。このほかにも、話題になったいくつもの著作がある。 それらの仕事は高い評価を得ていますが、
ハンドブック
目次 はじめに 会社 人事 エンジニアリング セキュリティー マーケティング 営業 財務 プロダクト リーガル コンテンツサイト はじめに GitLabチームハンドブックは、会社を運営の仕方を集めた場所です。 印刷したら2,000ページ以上になります。 透明であるという価値観のもと、ハンドブックを世界に公開しています。またフィードバックを歓迎しています。改善や説明の追加を提案するときは マージリクエスト をしてください。 質問するときは Issues を使ってください。 社内に固有な情報は、社内ハンドブックもあります。 会社 GitLab 会社概要 沿革 バリュー ミッション ビジョン 戦略 コミュニケーション YouTube Zoom ウェビナー カルチャー オールリモート おすすめ リモートワーク10類型 (日本語版note) リモートワークで成果を出すために必要なバリュー カルチャー
わかりにくいシステム構成図とは こんなシステム構成図を書いてないでしょうか？ このシステム構成図のわかりにくい点が３つあります。それは 製品名は書いてあるが「役割」が書いていない データと処理が区別できない データの流れと制御の流れが区別できない の３つです。 わかりやすいシステム構成図 これら３つのわかりにくい点を改善したわかりやすいシステム構成図が↓です ポイントを解説していきます ポイント1. 製品名称ではなく「役割」を書く システム構成図には製品名称ではなくシステムコンポーネントの「役割」を書きます。 役割とは、例えば〇〇データや〇〇処理といったことであり、それを読むだけでシステムの動きを理解できる文字列です。役割をかかずに製品名称のみを書いてしまうと、その製品を知らない人が見たときに理解できません。例えば「Cloud Pub/Sub」という製品はGCPというパブリッククラウドの分
Web 技術解体新書「第二章 Cache 解体新書」リリース Intro 「Web 技術解体新書(Web Anatomia)」の第二章として「Cache 解体新書(Cache Anatomia)」をリリースしました。 これで予定している八章のうち二章が終わりました。 第一章: Origin 解体新書 第二章: Cache 解体新書 Cache 解体新書 以下の Response Header Field がどういう意味を持つか正確に説明できますか? おそらく多くの Web 開発者が一度は見たことがあり、これを「1 時間キャッシュする」という意味で指定している人もおおいでしょう。 では、どこから 1 時間で、 1 時間経ったらなにが起こるのか、これが Response でなく Request に付与されたらどう変わるのか、きちんと把握できていますか? そもそも、一般的にキャッシュ機構における
テクニカルライティングの基本を学べます。サイボウズの新入社員向け研修資料です。業務マニュアル、報告書、仕様書、技術解説書などのドキュメントを書く機会がある方向け。 Twitter：https://twitter.com/naoh_nak 2023年度のアップデート版もあります：https://speakerdeck.com/naohiro_nakata/technicalwriting2023
RFC 9114: HTTP/3
Stream: Internet Engineering Task Force (IETF) RFC: 9114 Category: Standards Track Published: June 2022 ISSN: 2070-1721 Author: RFC 9114 HTTP/3 Abstract The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over Q
2018年6月1日に株式会社メルペイに入社して、4年が過ぎました。入社当時は、定年が60歳と聞いていたので、1年半の勤務だと思っていましたが、実際の定年は65歳であり定年まであと2年半です。 ソフトウェアエンジニアにとって重要な能力と（私は考えるが）、身に付けるのが難しいのが現実だと、この4年間で再認識したのは次の三つです。 開発の最初にAPI仕様をきちんと書けるソフトウェアエンジニアは少ない テストファースト開発を行っているソフトウェアエンジニアは少ないか、いない Tech Blogなどの執筆で、読み手を意識して、分かりやすい文章を書く、ソフトウェアエンジニアは少ない API仕様については、このブログでも何度か書いています（「API仕様を書く」）。テストファースト開発についても、「テストファースト開発」を書いています。分かりやすい文章については何も書いていないですが、「伝わる技術文書の書
データベースのテーブル定義の仕様書を自動生成しよう | CyberAgent Developers Blog
AI事業本部 DX本部の黒崎(@kuro_m88)です。 社外(取引先など)向けに作成する仕様書を自動生成する取り組みを試しているので、アイデアを紹介します。今回はSnowflakeで構築されているデータ分析基盤のテーブル定義の仕様書を例に紹介していきます。ツールはGoを使って開発しました。 仕様書の運用コストを減らしたい DX本部でのプロジェクトは、開発環境を社内向けに別途用意することが大半なので、取引先に許可を取らないと何かを試すことができないということは今のところほとんどありません。 そのため、実際の開発フローとしては詳細な仕様書を書き起こしてから実装することはあまりなく、大まかな方針を決めてから軽く実装してみて、うまくいきそうであればそれを仕様としてまとめつつ実装することが多いです。 データベースのテーブル定義であれば、それらの定義はGitHub上で管理されており、リリース時に自動
Meet the modern standard for public facing documentation. Beautiful out of the box, easy to maintain, and optimized for user engagement.
【OpenAPI】Stoplight Studioを活用して快適＆高速にAPI定義を書く方法｜Offers Tech Blog
概要 Offers を運営している株式会社 overflow の磯崎です。弊社は新規プロダクト開発でスキーマ駆動開発を取り入れており、API 定義とは楽しくお付き合いさせていただいております。その全体像については、以下の記事でまとめておりますので、是非ご一読ください。今回は、ポチポチいじるだけで誰でも簡単に API 定義できる神ツール「Stoplight Studio」を活用した API 定義について紹介していますので、ぜひ参考にしてください。 Stoplight Studio とは？ Stoplight Studio とは、 OpenAPI 定義ファイルの作成と管理ができる GUI エディタです。これだと少々分かりづらいので、簡単に一言で表すと「ポチポチと誰でも簡単に API 定義ができてしまうツール」です。Stoplight Studio は、GUI で直感的な操作ができるため、高速に
Improved REST API documentation
ProductImproved REST API documentationWe’re excited to announce some big improvements to our REST API documentation. We know developers rely on this documentation to integrate with GitHub, and we are committed to making it trustworthy, easy to find, and easy to use. We’re excited to announce some big improvements to our REST API documentation. We know developers rely on this documentation to integ
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【保存版】リクルートやサイボウズといった大企業が新人研修用の資料を公開。→「学び直そう」「非エンジニアの方にも」
Cloudscape - Cloudscape Design System
やさしくて難しいInclusive Writing入門 ～GoogleとAppleのスタイルガイドを読む
結局ZennかQiitaかnoteか個人ブログをどうやって使い分けると良いのか
GitHub - jgm/djot: A light markup language
ゼロトラスト移行のすゝめ：IPA 独立行政法人 情報処理推進機構
今年もミクシィの22新卒技術研修の資料と動画を公開します！
政府情報システムにおける 脆弱性診断導入ガイドライン
セキュリティエンジニアのための English Reading.pdf
You Might Not Need an Effect – React
IT業界に居ると海外製品の日本語ドキュメントが無くなったり機械翻訳になったりしていて我が国の経済的な没落を実感する
GoogleのDesign Docsから学ぶソフトウェア設計 - Qiita
ファイルダウンロード完全マスター | フューチャー技術ブログ
技術系イベント登壇における資料作成のコツ - 電通総研 テックブログ
プロダクトマネージャーの必須スキル: デザインドックの書き方 - Design Doc｜kosuke mori
ニコニコ生放送 WebフロントエンドのKubernetes移行ハンドブック 2022
次世代Web通信プロトコル「HTTP/3」がついに標準化 ～有志による無償解説本が話題に／PDF形式の電子書籍がGitHubで公開中！ 今後も更新される模様【やじうまの杜】
わかりやすいシステム構成図の書き方 - Qiita
Web 技術解体新書「第二章 Cache 解体新書」リリース
テクニカルライティングの基本
伸ばすのが難しい能力: 柴田 芳樹 (Yoshiki Shibata)
Mintlify - The modern standard for documentation