HackMD
  • Prime
    Prime  Full-text search on all paid plans
    Search anywhere and reach everything in a Workspace with Prime plan.
    Got it
      • Create new note
      • Create a note from template
    • Prime  Full-text search on all paid plans
      Prime  Full-text search on all paid plans
      Search anywhere and reach everything in a Workspace with Prime plan.
      Got it
      • Options
      • Versions and GitHub Sync
      • Transfer ownership
      • Delete this note
      • Template
      • Save as template
      • Insert from template
      • Export
      • Dropbox
      • Google Drive
      • Gist
      • Import
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
      • Download
      • Markdown
      • HTML
      • Raw HTML
      • Sharing Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Note Permission
      • Read
        • Owners
        • Signed-in users
        • Everyone
        Owners Signed-in users Everyone
      • Write
        • Owners
        • Signed-in users
        • Everyone
        Owners Signed-in users Everyone
      • More (Comment, Invitee)
      • Publishing
        Everyone on the web can find and read all notes of this public team.
        After the note is published, everyone on the web can find and read this note.
        See all published notes on profile page.
      • Commenting Enable
        Disabled Forbidden Owners Signed-in users Everyone
      • Permission
        • Forbidden
        • Owners
        • Signed-in users
        • Everyone
      • Invitee
      • No invitee
    Menu Sharing Create Help
    Create Create new note Create a note from template
    Menu
    Options
    Versions and GitHub Sync Transfer ownership Delete this note
    Export
    Dropbox Google Drive Gist
    Import
    Dropbox Google Drive Gist Clipboard
    Download
    Markdown HTML Raw HTML
    Back
    Sharing
    Sharing Link copied
    /edit
    View mode
    • Edit mode
    • View mode
    • Book mode
    • Slide mode
    Edit mode View mode Book mode Slide mode
    Note Permission
    Read
    Owners
    • Owners
    • Signed-in users
    • Everyone
    Owners Signed-in users Everyone
    Write
    Owners
    • Owners
    • Signed-in users
    • Everyone
    Owners Signed-in users Everyone
    More (Comment, Invitee)
    Publishing
    Everyone on the web can find and read all notes of this public team.
    After the note is published, everyone on the web can find and read this note.
    See all published notes on profile page.
    More (Comment, Invitee)
    Commenting Enable
    Disabled Forbidden Owners Signed-in users Everyone
    Permission
    Owners
    • Forbidden
    • Owners
    • Signed-in users
    • Everyone
    Invitee
    No invitee
       owned this note    owned this note      
    Published Linked with GitHub
    Like BookmarkBookmarked
    Subscribed
    • Any changes
      Be notified of any changes
    • Mention me
      Be notified of mention me
    • Unsubscribe
    Subscribe
    # クリーンアーキテクチャ読書会 in 鳥取 - 参加者 - キックオフ - kmt-t(発表者) - こーへい氏(発表者) - ちんも氏 - すずむら氏 - tomitakeFoo氏 - ふとなか氏 - OZBOSE氏(残念不参加) - 第二回 - kmt-t - こーへい氏 - すずむら氏 - tomitakeFoo氏 # アジェンダ(キックオフ) - 概要 - https://www.amazon.co.jp/dp/B07FSBHS2V/ - クリーンアーキテクチャのオンライン読書会です - キックオフなので最初の方と全体の話になると思います - 読書メモ、感想文を書いたことのある人は開示お願いします - 時間がないので読むところは絞ります - 基本的な進め方 - ファシリテーターが章ごとに要約を説明する - 参加者のレベルに合わせて前提部分はすっとばす - わからないところの質疑応答 - わからないところを本で確認する - 時間割 - 15:03〜 自己紹介 - 15:20~ 参加者のレベル感の確認 - 15:30~ 進め方の話 - 15:40~ 予習すべき内容の提示 - ~3部まで - 俺の考えるクリーンアーキテクチャ - 発表者募集中! - 15:50~ @kmt_t - 16:10~ @kou029w氏 - 16:30~ 質疑応答・フリーディスカッション # アジェンダ(2回目) - 時間割 - 14:03〜 自己紹介(新規参加者のみ) - 14:05~ 参加者のレベル感の確認(新規参加者のみ) - 14:10~ 進め方の話 - 14:20~ まとめ(22章) - 14:40~ 依存関係逆転の法則(11章) - 15:00~ コンポーネント(12~14章) - 15:20~ 現実へようこそ(21章) - 15:45~ 質疑応答・フリーディスカッション # 質問リスト - Q. IDDD本とは - A. https://www.amazon.co.jp/dp/B00UX9VJGW 実践ドメイン駆動設計 - SOLID原則 - > これらの原則は、アメリカのソフトウェアエンジニアでインストラクタでもあるRobert C. Martin(英語版)により提唱された多数のソフトウェア設計の原則の一部を集めたものとなっている[1][2][3]。SOLIDはどんなオブジェクト指向の設計にも適用できるが、アジャイル開発や適応的ソフトウェア開発(英語版)などの方法論の中心的な考えにもなっている。SOLIDの原則の理論は2000年に公開されたMartinの論文Design Principles and Design Patternsで発表された[4]ものであるが、SOLIDという頭字語自体は後にMichael Feathers(英語版)によって導入されたものである[5]。 https://ja.wikipedia.org/wiki/SOLID より - 依存性逆転ってどういう実装になるだろう? - ファクトリクラス? - ポイントは下位レイヤーを参照しない、依存しないという点 - 上位レイヤをビルドするとき切り離されているので下位レイヤのビルドが不要 - 図について、どれが上位? - 円の内側 = 上位 - レイヤーの境界にとにかくインターフェースを切り出せばOK? - 設計原則としての話であって、最重要ポイントはコストの最小化。全部インターフェースとして切り出せばよいというのはおそらく間違い - クリーンアーキテクチャなるものがあって、このルールに従え、という話ではない。あなたのアーキテクチャの問題を見つける、解決する手立てを提供 # 次回以降の読書会で読みたいところリスト - 依存関係逆転の法則(11章) - コンポーネント(12~14章) - 現実のWebの話 - 綺麗ではない現実世界では - みんなクリーンにしようとして苦労している - 良い事例ネタないか探す # 予習および復習に最適な動画 - 世界一わかりやすいClean Architecture #csharptokyo - https://www.youtube.com/watch?v=pbCRHAM5NG0 - 情報まとめてから動画見たらほぼ言ってることが一緒だった # Zoomチャットのメモ fukuta > Uncle Bob もGUIのアプリ作るの得意じゃないと思ったりする suzumura > GUIの部分は「UI」だけに押し込んでますしね > 扱うアプリの規模の前提があるように思います fukuta > 階層型アーキテクチャの時点で、レイヤーをすっ飛ばすのは基本を外しているので特に新しい話でもない > シンプルな話をbobおじさんがした結果、WebエンジニアたちがヒーってなっててCleanなWebアプリってなんやねん、こうじゃないかああじゃないかってやるけどbobおじさんは多分そんなことはしたことがないはず > bobおじさんは人の作ったフレームワーク嫌い fukuta > アーキテクチャとアーキテクチャスタイル 特定のシステムの構造=アーキテクチャ RESTみたいなもの=アーキテクチャスタイル fukuta > 依存性逆転、Inversion of Control, Dependency Injection の話は、ちんも的には 2000年ごろhotだったと記憶している。その後、Javaとかフレームワークという道具にDIの機能とかが入ってきた。 fukuta > 夏にモノリスからマイクロサービスへという本の翻訳のレビューをしていて良書だと思うんだけど、最初っからマイクロサービスとかコンポーネントとか考えても無駄で、railsとかでさらっとモノリシックに価値を提供しつつ、他サービスで利用できる価値が発見されたらサービスの分割に移っていく話だった 分ける目的がないと、分けたコストがそのまま残る そう言えばボブの本に出てくる、RDB絶対使わないぞって戦ってその会社やめた話、いろいろ思うところがあった。 fukuta > Clean* は、単にボブの本・講演のタイトルの頭につくやつだから、そういうアーキテクチャがあると思うと迷う気がする。依存性逆転の原則イイよ!若造もちゃんと理解しとけよ!くらいに受け取るべきw この次の本は、Clean Agile でした。 その前の本は、Clean Coder, さらにその前は Clean Code アーキテクチャってデザインの領域、つまり人のArtga Artな要素が出てくる領域だから、「このルールを使えばできる!」というより、小さな原則や大きな本人のこだわりを、現実に対して駆使するようなことだと思う fukuta > 本人動画でも言ってたけど、「Clean hogehoge」とか偉そうだけど、俺も十分年取ったから偉そうにしてもいいだろと思ってつけたhahaha って言ってた アーキテクトがふにゃふにゃしてちゃダメだと思うから、ボブおじさんは素晴らしいアーキテクトだと思う 何か原則を見つけたら、それを全ての事例に当てはめて、美しい構造を作れるのではないか、という夢を多くの人に見せて、Web界隈がこうすれば、こうすれば、という記事をたくさん産んだと思った そして多くのエンジニアが、依存性逆転の原則を駆使するようになって、レベル+1した、という業界への貢献があったと思う でも依存性逆転の原則は21世紀の最初で語られてて、そこからJavaEEとかSOAPとかActivbeTemplateLibraryとかスンゲーインターフェイスの世界に突撃した歴史がある fukuta > エンティティが見つけられないとドメインモデル貧血症に陥るんだけど、ボブはどうやってビジネスドメインを作るかは一切話してなくて、章としてもビビるほど薄い。 まあ端的にこの本は依存性注入をフラクタルに適用できるぞ。それがアーキテクチャで変わらないルールだ、ってことを言いたいはず 入江くんはまだ基本OFFにしてるのかなJS fukuta > Webはハイパーメディアから、あるところでプラットフォームになったんですよね by 山本陽平 # 第二回の話題 ## まとめ(22章) - BCEとこの本のエンティティは違う - アーキテクチャの原則 - 既存のアーキテクチャが全て満たしている原則がある - クリーンアーキテクチャも同様 - 4つのレイヤ - エンティとユースケースの分割 - エンティティの方が抽象、不変 - エンティティは業務ルールの仕様 - ユースケースはアプリケーションの振る舞いの仕様 - 小規模ではそこまで明確にわけなくていいかも - 外の二層 - みんなMVCなどで馴染み深い - そんなに軽い話ではない - あくまでレイヤ分割の例なのでそこまでこだわらない - レイヤ分けは4つでなくてもいいよ - 境界 - 依存関係を分離するところでレイヤの境界ができる - 境界はレイヤ以外にもある - 同じレイヤでも関心事で境界はある - 境界をこえるデータ - DTOを使う - 欲しいデータは内側のレイヤで定義する - 動的型付言語だとデータ型を定義する必要がなくて楽 - 静的型付言語VS動的型付言語 - 動的型付言語のいいところ - 典型的なシナリオ - MVCフレームワークでは馴染み深いので割愛 - まとめ - 単純なルール=依存性の話 - 結局これだけ ## 依存関係逆転の法則(11章) - 依存性逆転の法則はわかるが実装がわからない - AbstractFactoryを何故用いるのか - どう実装するのか - 普通にやると面倒 - kmt-tが試した範囲ではDependencyInjection使った - 実装のハマりどころが多いけどよくわかってない - 次回勉強会するなら実装の話をする ## コンポーネント(12~14章) - リリースが分かれる - リリースが分かれるならコンポーネントもわかれる - チームが別 - チームが分かれているのはやりやすいから - 同じリポジトリで作業するなら同じチーム、組織は別でも問題ない - テンション図 - ここに集約される、非常に良い図 ## 現実へようこそ(21章) - Webって小さい? - 小さくないがそれでも言い切る - 立場、経験、スコープ、大局観 - 経験の差で言うことが変わってくる - ボブおじさんはかなり長いスパンの話をしている - フレームワークに依存するメリット - フレームワークは重要だがそれでも言い切る - 価値の提供が優先される場合がある - 価値の提供はテーマ - テスト大事 - kmt-tはWebの技術を取り入れたい(テスト、デプロイ、CI/CD、運用) - ちょっとでもいいのでテストは書いていみよう - 予算を確保しよう - お金の話をしよう - お金で納得する人はわかりやすい # 俺の考えるクリーンアーキテクチャ ## こーへい氏 ### 自己紹介 渡邉浩平 @kou029w - 2001- 家にインターネットがつながる - 2005- ひきこもり不登校、ほぼ毎日Web - 2016- ソフトウェアエンジニアとしてWebアプリケーションの開発などに携わる ### 本題「クリーンアーキテクチャ」 クリーンアーキテクチャ自体は、ビジネス固有の構造(エンティティ)と方針(ユースケース)があり、そこから同心円状に構成される被依存関係、非循環依存グラフのこと 詳しいことは本書またはkmt-tさんの説明をご覧ください 以下は本書を読んで自分の思ったこと ### 疑問 1. そもそもどうやってエンティティを発見するんだろう 2. React Componentの位置づけ ### そもそもどうやってエンティティを発見するんだろう いろいろな観点で全体最適を目指して評価し続けることが大切 変更の軸の話、テスト容易性とか単一責任の原則とかコンウェイの法則とか ヒントは本書にたくさんあるのでご覧ください ### React Componentの位置づけ Web、特にフロントエンドの視点から #### 背景 現代のWebはもはやJSが中心 たとえばブラウザーの設定からJSを無効化すると、ほとんど機能しない Amazonはボタンを押してもカートに入らず、YouTubeは何も表示されず、Google検索(の一部)くらいしか機能しない テンプレートエンジンはJSX/TSX、デザインシステムはPostCSS/CSS-in-JSなど、JS前提という流れが存在 従来のWebページのようなHTML(構造)/CSS(見た目)/JS(制御)での分割とは異なり、コンポーネント(機能)での分割の存在 #### 疑問と答え 個人的に疑問だったのは、標準的なHTML/CSS/JSで済むならそれが単純で良いし、あるいはSVG/JSで済むならそれが単純で良いが、それだけで上手くいかなかったのはなんでなんだろう、という点 その答えの1つとしては、Webデザインもアーキテクチャの中の詳細に過ぎなくて、コンポーネント、つまり開放/閉鎖原則の観点でデプロイ可能なレベルに上手に整理できていれば、詳細はどうでも良いよな、ということなんだろうなと、本書を読んでて思いました ## kmt-t ### 自己紹介 松永卓也 @kmt_t - 画像処理、信号処理、機械学習、OSミドルウェア、検査機が専門分野 - WebはわからないのでASP .NET MVCしか使えない。PHPはトラウマ - 最近デスクトップアプリ開発のためPrism覚えた - 経歴 - 就職氷河期到来 - 1999 たんなるニートだったが就職氷河期だったので就職浪人と言って逃げ切る - 2000-2005 VB/C++/C#/鳥取の工場で前半は製品開発関連、後半は検査機開発 - 2006-2009 C言語/転職、難しい開発をした気がするが暗黒期で記憶喪失 - リーマンショック到来 - 2010 たんなるニートだったが仕事のないフリーランスと言って逃げ切る - 2010-2012 C言語/大阪に転職、製品開発 - 2012-2017 C++/PHP/Ruby/Python(機械学習)/鳥取に戻って業務システム開発 - 2018- C/C++/C#/転職、鳥取の工場で製品開発、最近検査機開発始めた - 2005年の前まではマーチンファウラーのファンだった。当時DDDはスルー。不覚 - 今検査機をクリーンアーキテクチャで開発中。クラス図は読書会で公開できるかも ### 全体 本には書いてない自分の感想(そのように解釈したのも含む)は章節項の頭に「(感想)」と書く #### (感想)読書のモチベーション - 昔からデスクトップアプリの開発が苦手 - 今はC#でもPrismとかあって非常に良い - それでもしんどいのでこれさえ守っておけばオッケー的な定石を知りたい #### (感想)自分の今の結論 ![勘違いしやすい図](https://i.imgur.com/soH76BV.jpg) - 超要約 - レイヤアプローチ - 外側は直近の内側にのみ依存する - 依存関係が逆にならないように「依存関係逆転の法則」を用いる - 内側、外側に入る固有名詞は重要ではない(システムで違う) - 何が内側で何が外側かを見極めるのは実は難しい - クリーンアーキテクチャとはメタアーキテクチャである - メタアーキテクチャはすべてのソフトウェアで同じである - クリーンアーキテクチャとは依存関係の話である #### (感想)なぜ自分がメタアーキテクチャと呼んでいるのか - ユースケースが内側にくるのが一般的だが、何が内側で何が外側でも問題ない - 一般的なアーキテクチャは構造について言及している - クリーンアーキテクチャは構造のルールについて言及している - 良いアーキテクチャの構造を示すための定理が「原則(ルール)」 #### (感想)書籍は以下について書かれている - モジュール - オブジェクト指向の原則 - コンポーネント - コンポーネントの原則 - アーキテクチャ - 境界 - バウンダリとも呼ぶ。どこでレイヤを分けるか? - クリーンアーキテクチャ(自分の言うメタアーキテクチャ) - クリーンアーキテクチャにおける設計の勘所と俗説の嘘(書籍の1/3) - ソフトウェアの歴史(書籍の1/4) - 読むのが大変なのはコンポーネントのところまで(がんばろう) ### 内容 #### 前ふり - ソフトウェアアーキテクチャの真理 - 「アーキテクチャの【ルール】はすべて同じである!」 #### モジュール - (感想)よく知られているので「依存関係逆転の法則」だけおさらい - オブジェクト指向の原則 - 単一責任の原則 - 開放閉鎖原則(Open-Closed Principle) - リスコフの置換法則 - インターフェイス分離の法則 - 依存関係逆転の法則 - 依存関係逆転の法則 - ![依存関係逆転の法則](https://i.imgur.com/vrdhy7m.png) - レイヤの境界をまたがる矢印の向きが逆なのに注目 #### コンポーネント - (感想)コンポーネントの善し悪しの議論はされないことが案外多い - コンポーネントの原則 - よく知られていないので次回以降で解説 - 再利用リリース等価の原則(REP) - 閉鎖性共通の原則(CCP) - 全利用の原則(CRP) - 三すくみでトレードオフになっている - ![テンション図](https://i.imgur.com/yJLvPnE.png) - コンポーネント図の使い方 - (感想)クリーンアーキテクチャでは重要な図 - コンポーネント間の依存に問題がないか - 循環依存の検出 - 循環依存があるとビルドできねえよ - (感想)某社で.NETのシステムで問題になっているのを聞いた - 安定依存の法則 - 依存するなら安定した方に依存 - 外側から内側に依存するのがクリーンアーキテクチャなら内側が安定してないとダメ - 安定度・抽象度等価の原則 - 抽象度が高いほど安定度が上がる - 安定度の高い内側を改変する場合は「開放閉鎖原則」を使う - 安定度と抽象度のマトリクス - ![主系列](https://i.imgur.com/MblxTZq.png) - 物事には程度がある - 抽象度が低く安定度が低すぎるとしんどい - 安定度が高く抽象度が高すぎると無駄 #### アーキテクチャ - 方針と詳細 - 方針=アーキテクチャ、アーキテクチャは安定度の高い抽象レイヤに存在する - 詳細=実装、実装は安定度の低い具象レイヤに存在する - フレームワークのような詳細の決定は遅延させる - 独立性 - アーキテクチャがユースケースの意図を表現する - ショッピングカートのアーキテクチャはショッピングカートに見える - アーキテクチャはシステムの振る舞いに影響しない #### 境界 - (感想)何が内側で何が外側かという判断の難しい話につながる - いつ何に境界線を引くか? - UIはビジネスルールにとって重要ではない(外側の存在) - データベースも外側 - ビジネスルールは内側なので切り離す - フレームワーク、ライブラリは外側なので後で決める - 境界線は変更の軸のあるところに置く - データの受け渡し - インターフェイス、データの定義は呼び出される側(つまり内側)にある ### (まとめ)クリーンアーキテクチャの全体像 #### 全体像 ![勘違いしやすい図](https://i.imgur.com/soH76BV.jpg) - レイヤアプローチ - 外側は直近の内側にのみ依存する - 依存関係が逆にならないように「依存関係逆転の法則」を用いる - 安定度と抽象化の話 - 抽象度が高いほど安定度が上がる - 内側ほど抽象度が高いことになる - 境界の話 - 標準的なレイヤの「あくまで例」 - UIとかWeb、RDBMS、デバイスはIOなので外側 - IOを抽象化、制御するレイヤがその内側 - ビジネスルールを制御するのがユースケースでその内側 - ビジネスルールをエンティティと呼び、最も内側 #### (感想)ちなみに - 組み込み開発でも適用可能なアーキテクチャ - MVVMがクリーンアーキテクチャである例示 - ![MVVM](https://i.imgur.com/rzVJy0l.png) - クリーンアーキテクチャの例の図を参照 - ビューが一番外の青い部分 - ビューモデルとモデルが緑の部分(密結合が許される) - サービスが赤い部分 - サービスから呼ぶビジネスロジックが黄色の部分 - モデルのうちRDBMSアクセスはORM(またはDAO)を介して青い部分に戻る - 依存関係と抽象度、安定度を確認すること - MVVMはクリーンアーキテクチャに含むことができる - つまりMVVMとクリーンアーキテクチャはアーキテクチャのメタ度のレベルが違う - BCE、3階層アーキテクチャとの違い - BCE - ![BCE](https://i.imgur.com/KwTcTal.png) - メロンを左に倒した図形が「バウンダリ(B)」 - 再読み込みボタンみたいな図形が「コントロール(C)」 - 丸の下に棒がある図形が「エンティティ(E)」 - 3階層アーキテクチャ - ![3階層アーキテクチャ](https://i.imgur.com/ym8g2wX.png) - 非常に見慣れているので詳細割愛 - これらはレイヤアプローチだが、依存の方向の考え方が違う - これらだとUI(BCEで言うバウンダリor3階層のプレゼンテーション層)が最上位になる - 依存の観点がないと古い人にはクリーンアーキテクチャは直感に反す - 書籍の中ではBCEはクリーンアーキテクチャに含まれると言及 - 書籍の中では3階層はアーキテクチャでなくトポロジだと言及

    Import from clipboard

    Advanced permission required

    Your current role can only read. Ask the system administrator to acquire write and comment permission.

    This team is disabled

    Sorry, this team is disabled. You can't edit this note.

    This note is locked

    Sorry, only owner can edit this note.

    Reach the limit

    Sorry, you've reached the max length this note can be.
    Please reduce the content or divide it to more notes, thank you!

    Import from Gist

    Import from Snippet

    or

    Export to Snippet

    Are you sure?

    Do you really want to delete this note?
    All users will lost their connection.

    Create a note from template

    Create a note from template

    Oops...
    This template is not available.


    Upgrade

    All
    • All
    • Team
    No template found.

    Create custom template


    Upgrade

    Delete template

    Do you really want to delete this template?

    This page need refresh

    You have an incompatible client version.
    Refresh to update.
    New version available!
    See releases notes here
    Refresh to enjoy new features.
    Your user state has changed.
    Refresh to load new user state.

    Sign in

    Forgot password

    or

    By clicking below, you agree to our terms of service.

    Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in via Google

    New to HackMD? Sign up

    Help

    • English
    • 中文
    • Français
    • Deutsch
    • 日本語
    • Español
    • Català
    • Ελληνικά
    • Português
    • italiano
    • Türkçe
    • Русский
    • Nederlands
    • hrvatski jezik
    • język polski
    • Українська
    • हिन्दी
    • svenska
    • Esperanto
    • dansk

    Documents

    Tutorials

    Book Mode Tutorial

    Slide Mode Tutorial

    YAML Metadata

    Contacts

    Facebook

    Twitter

    Feedback

    Send us email

    Resources

    Releases

    Pricing

    Blog

    Policy

    Terms

    Privacy

    Cheatsheet

    Syntax Example Reference
    # Header Header 基本排版
    - Unordered List
    • Unordered List
    1. Ordered List
    1. Ordered List
    - [ ] Todo List
    • Todo List
    > Blockquote
    Blockquote
    **Bold font** Bold font
    *Italics font* Italics font
    ~~Strikethrough~~ Strikethrough
    19^th^ 19th
    H~2~O H2O
    ++Inserted text++ Inserted text
    ==Marked text== Marked text
    [link text](https:// "title") Link
    ![image alt](https:// "title") Image
    `Code` Code 在筆記中貼入程式碼
    ```javascript
    var i = 0;
    ```
    var i = 0;
    :smile: :smile: Emoji list
    {%youtube youtube_id %} Externals
    $L^aT_eX$ LaTeX
    :::info
    This is a alert area.
    :::

    This is a alert area.

    Versions

    Versions and GitHub Sync

    Sign in to link this note to GitHub Learn more
    This note is not linked with GitHub Learn more
     
    Add badge Pull Push GitHub Link Settings
    Upgrade now

    Version named by    

    More Less
    • Edit
    • Delete

    Note content is identical to the latest version.
    Compare with
      Choose a version
      No search result
      Version not found

    Feedback

    Submission failed, please try again

    Thanks for your support.

    On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

    Please give us some advice and help us improve HackMD.

     

    Thanks for your feedback

    Remove version name

    Do you want to remove this version name and description?

    Transfer ownership

    Transfer to
      Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

        Link with GitHub

        Please authorize HackMD on GitHub

        Please sign in to GitHub and install the HackMD app on your GitHub repo. Learn more

         Sign in to GitHub

        HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.

        Push the note to GitHub Push to GitHub Pull a file from GitHub

          Authorize again
         

        Choose which file to push to

        Select repo
        Refresh Authorize more repos
        Select branch
        Select file
        Select branch
        Choose version(s) to push
        • Save a new version and push
        • Choose from existing versions
        Available push count

        Upgrade

        Pull from GitHub

         
        File from GitHub
        File from HackMD

        GitHub Link Settings

        File linked

        Linked by
        File path
        Last synced branch
        Available push count

        Upgrade

        Danger Zone

        Unlink
        You will no longer receive notification when GitHub file changes after unlink.

        Syncing

        Push failed

        Push successfully