Skip to content

Instantly share code, notes, and snippets.

@arctanx93
Last active November 13, 2018 08:28
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save arctanx93/c17bf4667ffd315dd2061858c702ccff to your computer and use it in GitHub Desktop.
Save arctanx93/c17bf4667ffd315dd2061858c702ccff to your computer and use it in GitHub Desktop.
勉強会メモ(2018/11/06 : ssmjp)

勉強会メモ

2018/11/06 「Outputする人だけが参加出来る」ssmjp

(不完全な) メモ書きです。 抜け漏れ間違いもあるかと思いますが、ご容赦ください。 発表内容は登壇者のスライド等をご覧いただくのが良いのではないかと思います。


発表内容と登壇者

JAWS-UG コミュニティ運用と SSMJP との比較あれこれ : @Typhon666_death さん

登壇者スライド

  • ssmjp での登壇は今回で 7 回目
  • JAWS-UG の紹介
    • 支部がたくさんある
    • Slack もある
    • Security-JAWS : 定員 40 人にキャンセル待ち 150 人だったことも
    • X-Tech JAWS
      • FinTech とか
      • X-Tech (エクステック) と xTech (クロステック)
  • ssmjp
    • Slack が活発
  • 運営比較 (ssmjp / Security-JAWS / X-Tech JAWS)
    • 比較観点
      • コミュニティ参加者
      • リーダー
      • 開催頻度
      • 1回の登壇者数 : ssmjp は人数に幅がある
      • ジャンル
      • 配信 : Amazon Chime で (X-Tech JAWS) ⇒ 海外からも参加した事例あり
      • 前説担当
      • 前説内容 : Security-JAWS は名刺交換の時間がある
      • 運営メンバー数
      • メディア
      • 創設の歴史 : ssmjp が他の2つよりかなり長い
      • Slack
      • twitter
      • コラボ回数
      • コラボ回の決まり方
      • 登壇者オファー方法
      • オファー時の観点
      • 過去最高収容人数 (ssmjp 178 人、Security-JAWS / X-Tech JAWS は 120 人)
      • ドタキャン率 ⇒ どうやって減らすかが運営サイドの課題
      • 運営で定常的に発生する困ったこと
      • マニフェスト ⇒ ssmjp も登壇規範はある
      • 金銭問題 ⇒ 有償 / 無償問題
      • 大規模参加者勉強会
  • コミュニティに関わって変化したこと
    • Give & Take の連鎖 ⇒ Output への連鎖
  • DevRel やっていきたい
    • Developer Relations
  • 総括
    • コミュニティマネジメントとアウトプットとの関係

感想

比較観点が多岐に渡っていて、勉強会によって色々と特徴があることが分かりました。 マネジメント面での課題はコミュニティによって異なる場合もあるようですね。


Promotion of SphinxCon JP 2018 : @usaturn さん

登壇者スライド

  • Sphinx
    • ドキュメンテーションコンバータ
    • マルチインプット、マルチアウトプット
  • SphinxCon JP
    • 世界でも珍しい Sphinx のカンファレンス
    • 今年が 6 回目の開催

感想

以前のプレゼンでも気になっていた Sphinx なので、早く勉強に着手したいところです。


「正しい」運用手順書を作る : @tcsh さん

登壇者スライド

  • JAWS-UG CLI 専門支部
    • JAWS-UG 初の専門支部
    • 120 回実施
  • みんな大好き「運用自動化」←→みんな大苦手「運用手順書」
    • 矛盾しているのでは?
  • 工数の谷
  • 設計なき実装 → 仕様バグ
  • みんな大好き「運用手順書」になろう!
  • 正しい運用手順書とは
    • 論理的に正しい
      • 論理矛盾や論理的な欠陥が存在しない手順書
        • 三段論法(大前提と小前提から結論を導出)
        • 演繹的推論(理論や知識から導出)
        • 集合論(論理演算、述語論理、証明など)
        • バリデータや lint
    • 実質的に正しい
      • 手順書通りにやれば、本来の目的を果たせる手順書
      • 形式手法、ホーア論理
    • 読み手にとって正しい
      • 読み手が手順書を正確に理解し、記述の真意を容易に把握することができる手順書
      • 伝承的、人を育てることができる
  • おまけ
    • 運用手順書の隠れた役割

感想

運用手順書を一行一行の書きっぷりではなく、大きな枠組みで勘所が整理されていて、いつも勉強になります。


技術書典 当日のレポート : ssmjp 同人部

登壇者スライド

  • 技術書典での経験
  • 書籍を平積みするときに、表表紙が上と裏表紙が上で反応が違う
  • 目線の動きにいろいろバリエーションが
  • 声掛け

感想

他にも興味深い知見が多くありました。


技術書典5 参加レポート : ssmjp 同人部

登壇者スライド

  • 書籍執筆支援システム ReVIEW
  • github に ReVIEW 記法 (markdown ライク) で書いたファイルを push すると CircleCI が走って、DropBox に PDF ができあがる仕組み
  • 実質 3 日で一冊できちゃうよ (?)
  • サークルスペース作りや売り上げ在庫管理のコツ・テクニック
  • 感想 / 反省
    • 決め台詞を目立つように上段に持ってきたのは成功だった(看板の話)
    • 勉強会 (ssmjp) に来る層と、技術書典でささみのほんを買う層は違う
  • カイゼン
    • 看板の高さを稼ぐための三脚やスタンドが重要
    • 旧作を PDF 販売でも用意しておく
    • 「手にとったけど買わなかった人」からのフィードバックが一番大事
  • 技術書典 6 に向けて
    • ReVIEW の使いこなし
    • 頒布数を増やす (損益分岐点を超える)
    • 余裕を持ったスケジュールで記事の品質をよくする
    • 記事の寄せ集め → コンセプトや目的を添えて
    • 執筆者をどうやって増やすか
    • コンセプトの具現化

感想

今回得られた知見を次回以降に活かすために、どのように知見をドキュメントとして残すべきかも、観点の 1 つかも知れないと思いました。


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment