« 2018年12月 | トップページ

2019年1月

2019/01/11

GitHubが無料でプライベートリポジトリも使えることで小説家にもGitが必須になってきたのではないか

GitHubが無料でプライベートリポジトリも使えるニュースが届いた。
とても素晴らしい。
このニュースは、小説家にもGitが必須になってきた事実を示唆していると思う。
以下、ラフなメモ書き。

【参考】
GitHub、無料ユーザーもプライベートリポジトリを使い放題に - ITmedia NEWS

【1】GitHubが無料でプライベートリポジトリも使える最大のメリットは、プライベートなドキュメントは全てGitHubで管理できることだ。
僕は、この恩恵は計り知れない、と思う。

たとえば、ブログの元ネタのメモ、Excelで作った家計簿、執筆原稿用のWord、プレゼン資料のパワポなど、全てGitHubに入れてしまえばいい。
そうすれば、日々更新するファイルは全てGitHubの履歴として管理でき、いつでもどこでも復元できるようになる。
よって、「yyyyMMdd_ファイル名」みたいなExcelファイルを一時的に作ったり、他の共有ファイルサーバーに逐一手動でバックアップしたりする作業は不要になる。

また、GitHubにはIssue管理(チケット管理と呼ばないんだね笑)、Wikiの機能も付いているので、日々のタスクをIssueにメモしたり、常に参照すべき共有情報はWikiにまとめることができる。

つまり、個人のドキュメント管理と情報管理は、今後、GitHub中心に回るようになるだろう、と思う。
プライベートPCを切り替えても、GitHubにドキュメントがあるなら、いつでも自分だけの環境を復元できるわけだ。

【2】最近の最先端の小説家は、どうやら、GitHubを使っているらしい、という記事を見かけるようになった。
文系の人達も、プログラミングしない人達も、Gitが必須になってきたように思える。

「Githubで小説? そんな時代なの?」そうなのだ。 - 景虎日記

GitHubをコーディング以外で活用する7つの方法 | readwrite.jp

世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだ - Qiita

Web小説のリリース自動化 - Qiita

【1】小説家がGitHubを使うメリットは2つあると思う。
一つは、小説というドキュメントがGitHubの構成管理の配下になることで、成果物の履歴管理の恩恵を受けられること。
もう一つは、GitHubのワークフローを受け入れることで、プルリク機能が使えて、ソーシャルコーディングならぬソーシャルライティングが可能になること。

【2-1】1点目の利点は言うまでもない。
出版業界でも、Word主体が多いが、たぶんもう時代遅れだと思う。
Wordの変更履歴機能もあるが、正直使いにくいと思う。

【2-2】2点目の利点は、小説の推敲作業にもプルリクを使うことで、小刻みな改善がスピーディに行えるようになることだ。
僕も4冊ぐらい出版したので経験があるが、1冊の本を書くには10万~20万文字くらいの分量がいる。
それだけの文章にチェックを入れて、フィードバックを反映する作業は正直面倒だ。
その反映作業を漏れなくスピーディに行うのは、GitHubのような構成管理とチケット管理の両方の機能がなければ難しい。

その時に、プルリクが使えると便利だ。
編集者は、修正すべき該当箇所を指摘するチケットを起票するだけでなく、修正パッチをプルリクで提供すれば、Masterを管理する小説家はそのプルリクを吟味した後、取り込むだけで済む。
つまり、編集者は小説を改善する開発者、小説家は小説を管理するコミッターの役割で置き換えられる。

【2-3】他に、世の中の小説作家と編集者は今すぐ Word や G Suite を窓から投げ捨てて Git と GitHub の使い方を覚えるべきだ - Qiitaで共感する箇所は、「過去に書いた文章を再利用しやすい」部分だ。

(引用開始)
小説書きにはあるあるだと思うんですが、あるとき「ここ全部要らない!」となってバッサリ切り捨てることがあります。
そして後になって「あ、ここはあの時の文章が使えるのでは?」という時が必ず来ます。1割くらいの確率ですが。
そんな時のために退避場所として「退避ファイル」を作るのもひとつの手ですし、片倉もそうしていますが、切り捨てる際に「退避させなかった」文章は掘り返せません。
でも Git なら大丈夫。全部記録しているからね。
(引用終了)

1冊の本を書く時、最初に当然、目次と構成をラフに決めてから、書き出す。
しかし、良い本を出版しようとする時、必ず1回は、目次や構成をビッグリファクタリングするタイミングが訪れる。

そのビッグリファクタリングでは、目次や構成が大幅に変わってしまうので、今までの文章をざっくり削ったり、大幅に入れ替えたりする必要が出てくる。
一度削った内容を参照したり、一部だけ取り出すこともあったりする。
すると、Gitのような構成管理ツールで管理していなければ、こんなビッグリファクタリングの作業は怖くてやってられない。

こんなビッグリファクタリングが発生する理由は、自分が書きたい内容を書き出していくと、想定以上の分量になってしまい、出版媒体という箱の中に入れるには、大幅に削るしかない状況に陥るからだろう。
僕の経験上、そんなタイミングを数冊の本で経験したので、たぶん、他の人もそうではないだろうか。
書きたい内容がいくらあっても、それを一連のストーリーに論理的に配置して、読みやすい分量に収納するには、ビッグリファクタリングで大幅に削ったり、構成を見直す事が必要だから。

一方、それを最初から計画するのもあまり意味がないように思う。
やはり、執筆するのはかなりのパワーを浪費するので、最初は多少論理がずれていても、とにかく書き出しておけばいい。
その後で、Gitで履歴管理しているのだから、少しずつ修正すればいいだけ。

【3】さらなる利点は、GitHubとCIツールを連携することで、小説を多種多様なフォーマットに出力して、色んな媒体で公開できることだ。
Web小説のリリース自動化 - Qiitaに、こんな一節がある。

(引用開始)
動機
なぜ小説をいくつものフォーマットで発表する必要があるのだろうか。これにはふたつの理由がある。
第一に、作品を発表する場所が増えれば増えるほど、人の目に触れる可能性が高くなる。
特に、小説投稿サイトには小説を読むことを目的とした人が集まっている。
第二に、特定のプラットフォームに依存しなくて済む。
たとえば、小説投稿サイトには、突然規約が変わったり、サービスが終了したりするリスクがある。
そうしたリスクは分散させておいたほうがよい。
しかし、作品を発表する場所が増えれば増えるほど、運用が大変になる。作品の変換やアップロードに時間を取られれば、肝心の作品を書く時間が減ってしまう。
また、運用に失敗すると、場所によって内容が違い、どれが正しいかわからないという事態にもなりかねない。
逆に、更新作業が面倒だからという理由で誤字脱字等を放置するようになれば、それこそ本末転倒だ。
運用作業を自動化してしまえば、そうしたことに頭を悩ませる必要がなくなる。

方針
自動化の理想は、原稿を書いたり修正したりするだけで、はじめに挙げたすべてのフォーマットで小説が公開・更新される状態である。
この記事では、それに限りなく近いものとして「作品をGitリポジトリとしたとき、origin/master を更新するとすべてのリリース作業が自動的に行われる」という状態を目指す。
これはソフトウェアの世界でいう「継続的デプロイ」の一形態である。
(引用終了)

Web上で自分が書いた小説を公開する時、BlogやカクヨムのようなWebサービスは確かに良いが、閉鎖されるリスクはゼロではない。
閉鎖されると、自分の作品が消えてしまうリスクがある。
だから、リスクゼロのためには、GitHubに小説本体のソースは一括管理しておき、Blogや有償サービス、AmazonのKndleに配布するような手段を確保した方が良い。

すると、その手法は、継続的ビルド、継続的デプロイのような仕組みと一致するだろう。
僕もそういう考え方は以前から持っていたし、既に多くの人も同じようなことは既に考えているわけだ。

電子書籍の作り方: プログラマの思索

電子書籍の作り方part2: プログラマの思索

epub出版システムの作り方: プログラマの思索

Pandocでテキストファイルからドキュメント生成: プログラマの思索

Web小説のリリース自動化 - Qiitaでは、Webサイトへの変換にJekyllを使う事例まで載っている。
JekyllはRuby製の静的ジェネレータなので、使い方は簡単。
また、Jekyllプラグインには、カクヨムと小説家になろうへの投稿のための「jekyll-deploy-shosetsu」、電子書籍の作成のための「jekyll-build-ebook」など色んなGemが使える。

他に、達人出版会のReVIEWも有名だろうか。

ReVIEW記法 基本文法最速マスター - 達人出版会日記

TeXとRubyだけでWindowsにRe:VIEW環境を構築した話 - Qiita

【3】以上の話は、プログラマには無関係だろうと思われるかもしれない。
しかし、プログラマは技術書同人誌を書いてみよう、という記事もあり、ネタさえあれば簡単に出版できるらしい。

技術書同人誌を書きましょう! - Qiita

いろいろ試してみる。

【追記】
@8amjpさんのRedmine小説も流行していましたね。

Redmineを主題にした小説「Redmineで始める異世界人心掌握術」が流行しているらしい: プログラマの思索

「Redmineで始める異世界人心掌握術」を連載中です。 | at 8 AM, JP.

他に、@akiko_pusuさんの本「Redmineでやってみた」もありましたね。

Redmineでやってみた - うさぎまんじゅう - BOOTH

| | コメント (0)

【告知】2019/3/2にSEA関西で「気象予報システムを支える技術」の見所 #seakansai

【見所】
今年度のSEA関西では、2月・3月に3回連続で、ビッグな講演が目白押しです。
第3弾は、3/2土に気象庁 予報部 数値予報課の技術者の方が来て下さって、「気象予報システムを支える技術」を講演される。

実は、この講演の発端は昨年のRedmine大阪で、気象庁の方が講演してくださったのがきっかけ。

第66回 SEA関西プロセス分科会&第18回 Redmine大阪 「チケット管理システムによるソフトウェア開発支援と今後の課題」 - connpass

昨年のRedmine大阪では、気象庁の数値シミュレーションシステム開発において使われている、Redmineの複数インスタンス運用がメインテーマだった。

一方、今回の講演では、気象庁内において、スーパーコンピュータを使った天気予報の数値シミュレーション開発の話そのものがメインテーマになる。
気象予報のシステム開発に、並列計算や機械学習など数多くの技術を紹介してくれる。
この部分だけでもとても興味がある。

また、システム開発の運用基盤に関わる話の一つとして、RedmineやGitなどの話も含めてくれるらしいので、Redmineユーザも要チェックでしょう。

そう言えば、昨年のRedmine大阪の講演では興味深い内容がいくつかあった。
たとえば、気象庁では「プログラマ」という官職があり、給与人事制度があるので、プログラミングに専念する技術者という地位が認めらている。これは、官公庁という発注者の環境でも存在できる、という点で興味深い。
また、そういうプログラマがいる雰囲気のせいだろうか、気象庁内ではFortrunだけでなく、インフラ運用などでRubyが頻繁に使われている、という話もあった。
最近は、海外の技術者の影響を受けて、Pythonにも挑戦している、という話もあったな。

気象庁の技術者の講演を聞くチャンスは少ないので、興味のある方は是非お越しください。

【参考】
第70回 SEA関西プロセス分科会 気象予報システムを支える技術 - connpass

(引用開始)
気象予報システムを支える技術
講師: 
 雁津 克彦 氏(気象庁予報部数値予報課プログラム班)

概要: 
 気象庁では、風や気温などの時間変化をスーパーコンピュータで計算し、将来の大気の状態を予測する「数値予報」を用いて、日々の天気予報や防災気象情報の作成を行っています。

気象庁はTop500で28位・29位(2018/11現在)のスーパーコンピュータを整備して数値予報を行っており、運用中のスーパーコンピュータシステムについて紹介した後、C, Fortran, Ruby等で内製している数値予報のプログラムについて、並列計算やソフトウェア技術といった側面を中心に紹介します。併せて、予測結果を天気予報に利用できる形に翻訳する「ガイダンス」では各種機械学習を用いたプロダクトを作成しており、こうした機械学習の利用についても紹介します。

また、これらのソフトウェアは複数の課室で開発を分担していますが、実行プログラムや読み込む定数ファイルなど多くの部分を共有して利用しており、これらを齟齬なく維持管理する現在のルーチンシステムの管理手法や、バッチ処理のためのスケジューリングソフト(ROSE)、開発管理としてのRedmine, subversion, git 等の利用についても併せて紹介します。

主催:  ソフトウェア技術者協会(SEA)関西支部 (http://sea.jp/)

開催日時:  2019年3月2日(土)14:00~16:45

開催場所: 
 〒540-0031 大阪市中央区北浜東3-14
 エル・おおさか(大阪府立労働センター) 7階 701号室
 http://www.l-osaka.or.jp/index.html
(引用終了)

| | コメント (0)

【告知】2019/2/16にSEA関西でIPAの方の講演「IoT時代のシステム開発アプローチ」の見所 #seakansai

【見所】
今年度のSEA関西では、2月・3月に3回連続で、ビッグな講演が目白押しです。

第1弾は、2/09(土)に、Node-REDのワークショップ。
Nodeから手が出るNode-RED - connpass

第2弾は、2/16に、IPAの方が大阪まで来て下さり、「IoT時代のシステム開発アプローチ」の講演会です。

1本目の講演は、IOTシステム構築に必要な要件であるセキュリティ要件や信頼性の観点のお話。
2本目は、IOTシステムが、組込製品からクラウドシステムまでも含むシステムズ・オブ・システムズの観点であることから、システムエンジニアリングのアプローチが有効である、というお話。

IPAの最近の活動をネットで見ると、日本の製造業の技術力強化には、組込製品のソフトウェア開発だけでなくIOTシステムも重要、という認識の元、製造業と密接に関わるソフトウェア開発の話が多いように思う。

「日本のモノづくりは高品質」という神話があったけれど、現代は、ハードウェアよりもソフトウェア開発の方がはるかに重要になってきてる。
だから、日本の製造業はもっとソフトウェア開発に目を向けるべきだ、というメッセージが込められているように思える。

IPAの方の講演は関西ではそう簡単に聞けないので、興味のある方は是非お越しください。

第3弾は次のブログで紹介予定。

【参考】
第69回 SEA関西プロセス分科会 IoT時代のシステム開発アプローチ - connpass

(引用開始)
IoT時代のシステム開発アプローチ
講師: 
 宮崎 義昭 氏(独立行政法人情報処理推進機構 社会基盤センター 産業プラットフォーム部 研究員)
 端山 毅 氏 (独立行政法人情報処理推進機構 社会基盤センター イノベーション推進部  主任研究員)

概要: 
本セミナーでは、IoT製品の開発者が開発時に考慮すべき安全性やセキュリティ観点でのリスクや対策と、品質の確保・維持に必要な考慮ポイントを説明したうえで、多様な専門領域にわたる取組みが求められるIoTの開発に役に立つ開発アプローチである、システムズエンジニアリングについて、その基本的な考え方を解説します。

主催:  ソフトウェア技術者協会(SEA)関西支部 (http://sea.jp/)

後援:  独立行政法人 情報処理推進機構(IPA)

開催日時:  2019年2月16日(土)13:30~16:45

開催場所: 
 〒530-0001
 大阪市北区梅田1-2-2-500 大阪駅前第2ビル5階
 大阪市立総合生涯学習センター 第1研修室
 http://osakademanabu.com/umeda/

講演1: つながるシステムの安全安心に向けた課題と対策

講師: (独)情報処理推進機構 社会基盤センター 研究員 宮崎 義昭 氏

IoTと呼ばれる製品・サービスの普及が進み、個人生活や生産現場など様々な場面での 活用事例が報告されています。一方で、IoTシステムは、セキュリティやセーフティの観点で、これまでとは異なるリスクを含んでおり、システム提供者には、開発や運用の場面において、十分なリスクの洗い出しと対策が求められます。本講演では、IoTの安全安心に対する課題と高信頼化に向けた考慮ポイントや品質確保の取り組み方について、具体的な事例を交えて解説します。

講演2: 成功事例に学ぶシステムズエンジニアリング

講師: (独)情報処理推進機構 社会基盤センター 主任研究員 端山 毅 氏

IoT時代における製品やサービスは、利用者からの要請や期待に応えるため、製品やサービス自体が複雑化・高度化し、その実装には多様な専門領域にまたがった取組みが求められます。
このような状況には、航空宇宙分野で培われてきたシステムズエンジニアリングのアプローチが役に立つと考えられます。本講演では、特にシステムズエンジニアリングの考え方を理解する上で重要な4つのポイント(「目的指向と全体俯瞰」、「多様な専門分野を統合」、「抽象化・モデル化」、「反復による発見と進化」)や、システムライフサイクルプロセスの上流プロセスについて、実践的な解釈と事例を交えて解説します。 また、システムズエンジニアリングのアプローチが有効に機能したと評価できる日本企業の開発事例を紹介します。
(引用終了)

| | コメント (0)

2019/01/04

PlantUML Example for モデルベース要件定義テクニックの記事のリンク

@ogomrさんのPlantUML Example for モデルベース要件定義テクニックの記事がとても参考になるので、リンクしておく。
以下は、論理的でないラフなメモ書き。

【参考】
PlantUML Example for モデルベース要件定義テクニック - Qiita

akipiiさんのツイート: "この発想は面白いな。RT @ogomr: PlantUML はテキストだけど意外と表現力があって モデルベース要件定義テクニック のUMLを拡張した図も描ける。GitLab なら RDRA をブラウザで表示できて便利 https://t.co/IpCRFQ4XDu"

akipiiさんのツイート: "後で試す。RT @zenzengood: PlantUML Example for モデルベース要件定義テクニック https://t.co/IpCRFQ4XDu #Qiita テキストベースでRDRAモデルを書きたい方はとても参考になります。"

歴史の流れをPlantUMLのシーケンス図で書き起こす事例のリンク: プログラマの思索


【1】最近、PlantUMLに着目していて、色々試しているのだが、@ogomrさんのPlantUML Example for モデルベース要件定義テクニックの記事がとても参考になった。

ストーリーは、モデルベース要件定義テクニック(RDRA)で使われるUML技法を、PlantUMLを使って書いてみよう、という流れ。
モデルベース要件定義テクニックは、UMLの技法をプロファイルで拡張していて、Enterprise Architectにはそのテンプレートがあるが、astahでは使えないので、いつも残念に思っていた。
だから、PlantUMLでモデルベース要件定義テクニックの技法を使えるのは非常に嬉しい。

記事では、コンテキスト図、概念モデル、ユースケース、データモデルなどがPlantUMLで紹介されている。

【2】RDRA(モデルベース要件定義テクニック)については過去に色々試していた。
僕は、UMLを要件定義に使う場合にRDRAの技法や考え方が非常に役立つ、と思っている。

さくさく要件定義(リレーションシップ駆動要件分析RDRA)セミナーの感想 #RDRAセミナー: プログラマの思索

リレーションシップ駆動要件分析による実践的な要件定義手法の記事のリンク: プログラマの思索

理由は、UMLを要件定義に使おうとすると、要件を複数の観点で分析したい時に、粒度やトレーサビリティがバラバラになりやすい弱点があるが、モデルベース要件定義テクニックを使えば、その弱点を克服できるから。

実際、UMLやオブジェクト指向分析の技法を使うと、中間成果物が多い割には、結局、どんな要件が決まったのか、という事が分かりにくい時がある。
一方、モデルベース要件定義テクニックでは、システム地図の一部にUMLの各種ダイアグラムが埋め込まれ、それらがどんな粒度でどのように関連しているか、システム地図を鳥瞰する観点で要件を整理できる。

僕は、下記の記事にあるシステム地図の中で、「システム外部環境」「システム境界」の部分が一番重要と思っている。

要件定義支援ツール「要件のツボ」によるRDRAの実践 (1/3):CodeZine(コードジン)

なぜなら、人とシステムが相互作用するI/Fは、それら2つの観点で整理でき、相互に関連させることで、トレーサビリティを確保できるからだ。

結局、モデリングで一番重要で、かつ、難しい部分は、各モデルの粒度を揃えてレイヤ化することと、各モデルのトレーサビリティを保証することだと思う。
だから、モデルベース要件定義テクニックのような考え方を、具体的な技法で表現できると非常に心強い。

【3】PlantUMLには非常に可能性があると思う。
システム開発がプログラミング主体であるのと同じく、設計書もテキスト化して、構成管理の配下に置きたい野望があるから。
そのイメージは1年前に書いていた。

PlantUMLを使ってExcel設計書をテキスト化するアイデア: プログラマの思索

仕様書にもExcel脱却が求められている: プログラマの思索

一般ユーザやプログラマへ業務イメージや技術イメージを説明する時に、何らかの図や絵を描いた資料を作るが、それらはExcelやパワポでは作りたくない。
そこで、PlantUMLを使えば、プログラミングと同じ感覚で書けるし、Webで情報共有もしやすい。

さらに、PlantUMLで描いたモデルも、モデルベース要件定義テクニックのように、各モデルの粒度やトレーサビリティを意識した規則に当てはめれば、その精度も上がるだろう。

PlantUMLが普及すれば、UMLは中間成果物が多すぎて使いものにならない、という声よりも、プログラミングの概念設計の一部として普通に使う、という考え方に変わるだろうと期待できる。
@u6k_yu1さんと同意見だ。

akipiiさんのツイート: "すごくいいね!RT @u6k_yu1: なんかこう、PlantUMLとか、モデルベース要件定義テクニックとか、ICONIXプロセスとかが広まることで、UMLが背負ってしまったトラウマとか業とかが払拭されて、みんな気軽にUMLを使えるようになるといいと思う。"

そして、最終的には、モデリングの根本問題の一つである「モデルの粒度を揃えてレイヤ化すること」「モデルのトレーサビリティを保証すること」も、PlantUMLとモデルベース要件定義テクニックを併用することで、具体的な解決方法を持って解決できそうな気もしている。
そのアイデアも試してみる。

astahで設計書とモデル、プロセスをつなぐ為の資料のリンク: プログラマの思索

モデル間のトレーサビリティと粒度、変更管理に関するastahのあるべき姿: プログラマの思索

モデルの粒度とトレーサビリティ、変更管理の問題は、モデリングツールではなくUMLそのものに真因があるのではないか: プログラマの思索

【追記】
u6k_yu1さんのツイート: "PlantUMLのパーサーが欲しい。モデリングツールとして機能させたい。"

u6k_yu1さんのツイート: "はい、そうですね。と最初は思っていたのですけど、どうも私のイメージはPlantUMLのIDEっぽいです。VSCodeにPlantUMLのプロジェクト管理機能とモデル間のトレーサビリティ検証やバリデーションやチェック機能が欲しい、みたいな。… "

| | コメント (0)

« 2018年12月 | トップページ