まとめの限定公開に「リンク限定」が追加されました。URLを伝えてまとめを共有しよう!
342
ところてん @tokoroten
某所の原稿をgoogle docsで書いて編集者に送ったら、 勝手にgithubに取り込まれて、 プライベートレポジトリにinviteされ、 編集者がいじりまくった原稿がプルリで送られてきて確認を求められ、 github issueで方針相談 これだよこれ、現代の編集者は
ところてん @tokoroten
これが現代の編集者ですよ。 先日の某飯田橋の出版社の案件と比較して考えるに、 ウェブ出版ではこれが当たり前になるので、 旧来の紙メディアの出版社で編集者をやってて、 Wordの編集機能+電子メールで原稿を回している連中(これでもまだマシ)はどんどん置いてかれる感じある。 pic.twitter.com/ZEgYhNDrvf
 拡大
 拡大
ところてん @tokoroten
某所の原稿、編集者のとメディアの許可を取れたら、編集者が手を入れる前の生原稿(?)を #マッハ新書 で配布しようかと思っている。 編集者のガチの力と、何がスポイルされるのか、メディアに合わせた文章の擦りあわせ、みたいなのが伝わればと思う。 適当にスクリーンショットを張り付けておく。 pic.twitter.com/nG7evmO8qP
 拡大
 拡大
 拡大
 拡大
ところてん @tokoroten
あーそうか、ウェブメディアの寄稿とか、本の寄稿とか、原稿料がクソ安い問題。 未編集の生原稿を売ればいいのか。 そうすれば、クソ安いライター案件でも、回収できる可能性が高くなる。 あれ?工数かけたもののほうが安いってどういうことだ??? 大量生産は悪なのでは。
ところてん @tokoroten
よく考えたら、生原稿の価値というものと同時に、プロの編集者が何をやっているのか、という情報も非常に高い価値なので、 実はgithubのコミットログを販売するのが、おもしろいんじゃないのか? 生原稿、コミットごとのdiff、修正済み原稿 という、三つが付いた、電子書籍
ところてん @tokoroten
ちなみに「仕事ではじめる機械学習」を書いたときは、@chezou がdockerで原稿のビルドシステムを用意してくれて、GitLabで書いて、コミットするとCIで電子書籍をビルドしてました。 商業版はオライリーのビルドシステムと接続して、これもCIでビルドして確認してました。 blog.team-ai.com/ai-people-vol7… pic.twitter.com/CSaBFDqNle
 拡大
リンク Team AI Blog 47 users 85 『仕事ではじめる機械学習』著者座談会:前編 きっかけは「没原稿の供養プロジェクト」だった【AI people:vol.7】 | Team AI Blog Team AI Blogの更新情報。人工知能(AI)・機械学習・ディープラーニングについて、リサーチに基づいた最新の情報を日々更新します。
くらん @sempre_calando
言われてみれば当たり前だけど、目から鱗って感じ。 そういや論文もgitで管理するといいって昔言われたっけ。 バージョン管理は別にプログラムだけのものじゃない。 twitter.com/tokoroten/stat…
ヒカミリュージ(詳細は固定ツイ記載) @int_know
@tokoroten 個人的には、小説や漫画の没ネタ、没原稿を安く売ってほしいと思います。 ファンは、あのシーンは、こうなる予定だったのか、と創作の裏側を知り、作者も、アイディアが無駄にならずにすみます。 また、なぜこれをボツにした(ボツにされた)のか研究材料になります。 リサイクルっぽいですね。
vmconverter @vmconverter
これは本当に面白そう且つ価値がある試みでは。 編集者が何をしてるかって外からは分かりにくいし、編集者の良し悪しはもっと分かりにくいから。 twitter.com/tokoroten/stat…
Sangmin Ahn @gijigae
githubのプライベートレポジトリを使った英作文の添削サービスも良いと思う。英作文は内容だけでなく、書くのにかかる時間も重要。各課題に対し、チェックアウトとチェックインの時間で所要時間がシステム的に測定できる。すると、「単語数 / 所要時間」で書くスピードの可視化が可能となる。 twitter.com/tokoroten/stat…
hidesuke @hidesuke
これ、うちのサークルでもやりたいけど普通のおじさんおばちゃんにgitは無理だ……ってなる。何か代わりのいいソリューションがあればなぁ twitter.com/tokoroten/stat…
河畔騎士エルベリバー @chokuryu
へー。文筆業でもgithub使ってたりするんだ。。 編集者の作業と作家の作業を別ブランチに分けて同時並行作業、みたいなのもあるのだろうか…? (`・ω・´)🍵 twitter.com/tokoroten/stat…
hark @hark_jp
こういうのがモダン! こういう風にうちも! …と、上司へ共有してみた。 さて、今後どうなる。 twitter.com/tokoroten/stat…
スティーブオースチン@宇宙飛行士 @maywolfster
こーゆーの本当に素晴らしいと思うんだけど、いまだにメールの添付ファイルにまごつくような執筆者にどうやってgithubを理解させるかの段階でつまづくんだよなあ。Word編集でもオーバーテクノロジーなのでプリントアウトに赤字入れてスキャンして返送とか馬鹿馬鹿しいことやってる。 twitter.com/tokoroten/stat…
サースズキ @nonesuzuki5515
一つの理想が。データやり取りないしそれによりバージョン間違えることもないし、変更履歴や経緯も残せる。 twitter.com/tokoroten/stat…

コメント

kazken @kakenx 5月9日
それが全員使いこなせるかって言うとね
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 5月9日
専用機か専用フロントエンドを作って誰でも使えるようにならないと難しいんじゃないかな。ASCII主導でEWBみたいにシステム構築すればワンチャンある?
メラ @vprjct 5月9日
git管理は思っている以上に簡単だし、githubが専用フロントエンドみたいなところあるんで誰でも使えるかと(個人開発なら全部masterブランチにぶち込めばいいだけだし)
北邑直希 @naoki_ng08 5月9日
kakenx もしこれが主流になれば、使いこなせない著者と編集者が淘汰されていくだけなのでは。変化なんてそんなものでしょう。
Tsuyoshi CHO @tsuyoshi_cho 5月9日
オープンにしていいタイプだとgitbookもオススメ
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 5月9日
naoki_ng08 雑誌のライターはそれで済むかもしれないなー。
endersgame @endersgame3 5月9日
所詮はツールの話だしなあ。まあwebみたいに即応性のあるものであれば利はあるだろうけど。結局はコンテンツの力に左右されてしまう。
ik @space_sk4500 5月9日
何でそんな面倒くさいことしてんの??
RENOWAN @renowan 5月9日
gitHubのGUIクライアントを使えばそんな難しくないだろう。ソーシャゲーの運営チームにjson書かせてgitにあげてもらって日々の運営を丸投げしたことがあるから非エンジニアでもgit運用はありと思う。
ささみくん @3_3_me 5月9日
これよこれ。これからは成果物は全部バージョン管理してぇよな。デザインとかもabstractがpsd読めるようになるし。
ささみくん @3_3_me 5月9日
space_sk4500 1つのファイルをメールで投げあって、修正点をメールに引用書きしてやりとりする方がめんどくせぇわ
榊 俊裕 ☆ 一般Jimgineer @Toshihiro_SKK 5月9日
このやり方が広まると様々な業種の中間業者が何をしてるか丸裸になって 単なる中抜き「だけ」してた業者は絶対賛成しない面白い企画だよ。
ヘルヴォルト @hervort 5月9日
俺の感想「ツール統一しろや」
ささみくん @3_3_me 5月9日
space_sk4500の言う「面倒くさくないやり方」っていうのはつまり、連絡はメールでお互い返信の時はきちんとメール本文に全文引用でやりとり重ねていって、タイトルは「Re:Re:Re:Re:Re:Re:Re:Re:」になっていって、ファイルは都度ダウンロードするから原稿_20170508みたいにやりとり毎にきちんと保存しておくみたいな…おえーーーー!!!!!
akiran @akiran32748624 5月9日
5年毎くらいにツールの主流が変わって行って、編集毎に使っているツールが異なり、編集毎の俺ルールでぐっちゃぐちゃにならないことを祈ります
ささみくん @3_3_me 5月9日
akiran32748624 バージョン管理の概念は絶対に死なないので祈らなくても大丈夫です
endersgame @endersgame3 5月9日
Toshihiro_SKK ディレクターの仕事は残るけどプロデューサーの仕事は残らないやり方だけどなこれは。
エリ・エリ・レマ・サンバディトゥナイ @mtoaki 5月9日
契約を切られるとBANされて原稿データは全て編集部に取られる
鮎麻呂 @aymro 5月9日
「この著者と組んだこの編集者がどうコミットしたか」が透視できるのはお互いの同業者にとって利用価値が埋まってる。雑誌とか単行本とかウェブメディアとかアウトプット媒体の差に対応する思考を外して「組版まではgithubで詰めよう」と言えるのが肝。
鮎麻呂 @aymro 5月9日
「組版からは任せろ」と言えるためには編集者側はレイアウトのスキルを伸ばしたい。中小規模の印刷・製版・製本サービスが速攻でサービスメニュー作って出版社窓口でなく編集者個人に営業掛けたらいい。特に編プロやフリー編集者ならサバイバル方法を模索している(そういう人ほど時間が無いものだが)。
endersgame @endersgame3 5月9日
まあ今も既にgoogleDocs、dropbox、Wordの編集履歴、github等々、会社や編集者によってツールが違うので対応するライターは大変だろなと思う。なお大先生には編集側が合わせる。
yuki🌾4さい⚔ @yuki_obana 5月9日
むしろ今までなかったのが不思議な(ry(´・ω・`)
男爵モッチィ @mocchi78 5月9日
ITの出版はこの形式の編集が主流になりつつある。ノウハウもそこかしこで共有されてるし。
男爵モッチィ @mocchi78 5月9日
知られているようと思っていたが、そうでもなかったのか。 ひょっとしてビジネスチャンス?
DzyyVO46 @DzyyVo46 5月9日
gitも使えないで何がいいのおじさんは辞めて田んぼでも耕してろよ
しわ(師走くらげ)@多忙は続くよいつまでも @shiwasu_hrpy 5月9日
お互いの作業場に居ながらリアタイで共有が出来る。移動などの無駄時間や経費をカットできるし〆ギリギリまで詰めることが出来たりとメリットは多いね。ただ誰かが言ってたが、OSやソフトのバージョンアップが怖い。けど、それを抜きにしてもかなり良いコストカットだと思う。   機械音痴でさえなければという大前提つくけど。
ICHIKAWA Kento(おにぎり) @kentosho 5月9日
文書管理をgitでやるなら、組版はTeXですよね!
kusano @t_kusano 5月9日
gitは非エンジニアには(いやエンジニアにとってさえ)難しすぎると思うがなあ
佐吉 @sakichi01 5月9日
google docsと適当なTodo共有だけでも回るような気がしたけど、複数の著書になるとGithubがいいのか。
Daregada @daichi14657 5月9日
BANされてー、って当然手元にはcloneされたローカルリポジトリがあるのでは
稟@馬主ライフ @Rin_chaaaaaaaan 5月9日
中途半端に知識がついた時に酷い事故が起きそう。「なんかpushできねーなー、ググるか」→git push -fとか(gitの特性上、取り返しがつかないことはまず無いけど)
ɐǝɹpuɐ‾ǝuoq @bone_andrea 5月9日
>Wordの編集機能+電子メールで原稿を回している連中(これでもまだマシ) それ以下ってなんなんだろう。全部印刷して赤ペンでバイク便? デンワ?ww「5行目のアレホラアレ」 ああ、faxか。芸能人専用の。
tamama @tamama666 5月9日
endersgame3 文芸や大衆小説の先生だと今でも手書き原稿の方多いですしね 大先生だと編集や出版社が合わせるしかないと言うw
胡上奈生(こがみん) @nowkogami 5月9日
sshキー登録が一番高い難関だと思う
トェェェェイ @lvbZJFV1MlN6YTF 5月9日
めんどくさいと言う人に辛辣に当たらんでもいいと思うけどなぁ わかりやすいマニュアル作って売ればまあまあ稼げそうな気がするね
さとうあきひろ @akihirosato1975 5月9日
真面目な話として、commitを非表示にする(commitそのものは有効だが内容を表示しない)ってgitってできたっけ? MediaWikiでいうところの版指定削除みたいなやつ。メディアだと「commit内容にプライバシー侵害・名誉毀損等の内容が含まれる場合にそれを表示しない」機能がいろいろな事情で必要になるので。
さとうあきひろ @akihirosato1975 5月9日
あ、強引にgit rebaseでsquash or fixupして当該commitを消しちゃえばいいのか>commit非表示
飛竜 @bsb_hiryu 5月9日
3_3_me リプライ先の人は別にそんなことは言ってないのでは?
飛竜 @bsb_hiryu 5月9日
3_3_me バージョン管理の概念が死ぬ死なないの話はしてなくて、ツールが変わるとか編集によってルールが違うとかの話をしてるのでは?
りんこ・エレオスキー @linco_motte 5月9日
わーこれいいかも。導入してみよう。
ぺんぎん @chimi_skrg 5月9日
たくさんのライターを長期的に抱えてるうちみたいなところは、これがなかなか難しいんだよな…ライターがついていけない。ライターの層にもよるだろうな。
ika @ika2989 5月9日
SVNのほう使ってたけど、複数人でプロジェクト進めるのにバージョン管理は便利だし合理的だね。ただ自分もだけどIT音痴だと導入~慣れるのにかなり手間取るので「みんな使ってる」レベルの普及までにはいろんな壁がありそうだ。
おろろ @fYe39CoQsPrbZVK 5月9日
慣れたら戻れないくらい便利やで
(=゚ω゚)ねこすけ@コピミスト @Bikenekosuke 5月9日
githubでやると、場合によっては情報流出(プライベートリポジトリにpushするものをパブリックリポジトリに誤pushでござる)というのがあるので、gitlub等のOSSがいいかもね。 操作が難しいのはもうしょうがないので、その辺りはツールの開発等で簡素化するとかが良いと思われ。
🌲🌲🌲 🌲🌲@芸カ18プ05 @KiKiKi_KiKi 5月9日
複数人から何度も修正版のword添付メィルが送られてきて、どれが最新版か分からなくなったことあるので、git管理してくれ。gitが無理ならメィル添付はマスターがコピーされてしまうのだからクラウドとかに置いてマスターは1つにしてくれーって思ったことが多々あるので個人的には良い傾向だと思いますん。 同人誌の翻訳とかはグーグルドライブのスプレッドシートで行ってます。json編集でコミットしてもらうのハードル高いので
HENTAI紳士@たつき監督を返せ! @animefigure3d 5月9日
スケジュールさえ許せば、紙に赤ペン青ペン鉛筆付箋で赤を入れて、編集者が集積するのが一番効率がいい。
fukken @fukken 5月9日
Git(Hub)を使う利点は、変更履歴と、その理由と、場合によっては議論が全部集約されるところかな。コミットログだけでいいならGitならなんでもいいのだが、Issueまで使うならgithubが欲しくなる。Pullreqがあるので、元データの管理者(この場合著者)が、コラボレーター(編集者)の変更点を気軽に取り込めるのも利点。
komacchi @komacchi 5月9日
masterブランチは話の本流としてブランチ切って作業すればdiff取れるし、過去のコミットハッシュまで戻したりcherrypickで取り込んだりできるんだし、編集はこれいけるだろ。あとリポジトリのremote設定は向き先1つだけじゃなくて複数いけるんだぜ。originはgithub、hogehogeはgitlabやbitbucketの個人privateリポジトリ、みたいに何かあった時のバックアップとして別リポジトリにも向けて追加すればいいだけ。
Cook⚡骨髄バンクまとめピン留中 @CookDrake 5月9日
最後のアイデアが面白いw そういうの需要ありそう。
新しい名前が思いつきません @NewName_NoIdea 5月9日
git環境構築する時点で詰まる人が続出すると思うんやな 上でGUIクライアント使えば難しくないと言っている人いるけど、そもそもGUIとかCUIとかなんのことかわからん人の方が多数だろう 特にこの先PC使える人全体では減っていくだろうし
たる @taruwo 5月9日
面白いやり方だとは思うけど、文章だけ書きたいだけの人にとっては、gitの導入とかバージョン管理システムの使い方を覚えるコストが高いんではとは思う。まだGoogle Docsとかで編集の共有使って作業するとかの方がいいのでは?あれも履歴残って便利だし
NAL / ナルサワトモアキ @wastedays 5月9日
円城塔がGithubで小説を書きたい、永遠に改訂し続けてその過程自体を作品にしたい、というネタで小説書いてましたな。
ざ_な_く&890P@ミラクルライト工場ユニオン @z_n_c_890_P 5月9日
ていうか、まとめ元のソースツリーって、privateですよね?!
原稿を落とした @rlyeh_safehouse 5月9日
サービスによったらブラウザからもバージョン管理できるのか、面白そう
せんたく @senn_taku 5月9日
「rebaseしたらpushできなくなっちゃったんで、-fつけてmasterにpushしときました」
❧ღ Mai ღ❧ @Naganegicco 5月9日
まとめを更新しました。
せんたく @senn_taku 5月9日
締め切り過ぎたあたりから、編集者自身のプルリクとマージ履歴が増えてきたり、執筆者の名前を残したまま内容が改変されてコミットされたり
hem +9.5k @ex_hem 5月9日
この方法が広まったとして、日本人はあくまで人力の編集と研鑽に注力して、アメちゃんが編集機能の自動化に注力とかそういう流れになりそうだなと思った。
KAMO nang-bang @dead_san 5月9日
やめて下さい! 未だに原稿用紙に読めない字で殴り書いてヘタすりゃ感熱紙使ってるレベルの時代物Faxで原稿送ってくる著者さんもいるんですよ!
せんたく @senn_taku 5月9日
国会も、法案リポジトリとか作ってくれないかな
まうみん @maumin66 5月9日
え、「カルネージハートについて」って何?あの名作AI構築ゲーについての記述があるの?読みたい。読みたい。超読ませて。
yositosi @yositosi 5月9日
昔、日本国憲法をGithub上でPullreqを使って修正依頼をかけてブラッシュアップしていくっていうアート的な取り組みがあった気がする。
まうみん @maumin66 5月9日
使えたらクッソ便利だろうけど最低限作家さんに何を教えればいいんだろうか。ブランチやらリモート/ローカルリポジトリやらの概念とcommit, push, pull,diff,revertあたりの使い方が分かれば案外いける...?
アオカビさん @Penicillium_ch 5月9日
taruwo Google Docs良いと思うんだけど、会社とかだと「Googleにデータを渡したくない」っていう警戒心が働くので、使えない場合がある。
lammythepopstar @lammythepopstar 5月9日
gitの機能全ては要らないので、TowerやSourcetreeをもっともっと簡略化したようなライター/編集者用のフロントエンドやSaaSがあればいいなとは思う。
lammythepopstar @lammythepopstar 5月9日
ただ、「Wordの編集機能+電子メールで原稿を回している連中」とかいうウエメセは、プログラマにありがちな勘違いの万能感が炸裂してて嫌いだわ。
ビッター @domtrop0083 5月9日
個人的には、GitよりMercurialが好き。
yybbjjeehh @yybbjjeehh 5月9日
bsb_hiryu 3_3_me svnからgitに主流が変わった時、リポジトリの移行とか死ぬほど面倒でしたしね。5年後にgitに変わって、また別のバージョン管理システムが流行っても特に驚かないし、その時にgitリポジトリを移行する手間はかなりのものでしょう。ただ、いちいちメールでやり取りする手間を考えれば、導入する方がメリットは大きいと思います。
yybbjjeehh @yybbjjeehh 5月9日
ちょっとした原稿ならgitじゃなくてDropbox Paperとかのコラボツール使うって手もあるのでは。
Daregada @daichi14657 5月9日
maumin66 git使えない向きには、「原稿を書いているアプリでファイルを保存すると自動的にコメントが生成されてローカルリポジトリにcommitされる」とか、「リモートリポジトリとのpull/pushは原稿を書いているアプリの起動と終了に連動して自動的に行われる」ようにしてら、書いている側はブランチ等を気にしないでいい(編集側で管理)する感じかなぁ
mmmmmtttt37 @mmmmmtttt37 5月9日
できる人、分かる人から順次取り入れていけばいいのであり、できない人、分からない人にみんながみんな合わせることもないと思う。
ジョーオンウォーター @suohsonic 5月9日
ITドカタなのになに言ってるのかわからないマン。コンセプトはまあわかるんだが。ツールの習熟は本当に大変。ことと次第によっては一生使わない機能とかてんこ盛りだし。
葵真碧(mao aoi) @maochin39blue 5月9日
gitは、正直すげー簡単だから楽。これとredmine開発した奴は、ノーベル賞あげていいと思うわ。リモートで進捗確認しつつレビューも出来るし、全てがスムーズよね。
鹿 @a_hind 5月9日
紙にしがみついてるおじさん達でも抵抗感なく使いこなせる様なツールが出てくればいいのかしら。 正直メールに糞重い添付ファイル張り付けて中身弄ってないのに添付したまま何回も返信し合っててブチ切れそうになることよくあったからそういうのそろそろやめない?とは思ってる。
nbtnk @nbtnk 5月9日
githubは使うだけならそんなに難しくないけど、むしろ共同編集の概念が無いと無理。「私指摘する人、あなた直す人」だったら不要なわけで。
Destroyer Rock @hondapoint 5月9日
cvs登場時「すげぇぇぇぇ!便利!」 svn登場時「すげぇぇぇぇ!便利!」 git登場時「すげぇぇぇぇ!便利!」 で変わってないだろ!と思われがちですけどちゃんと進化してますから。
denev @_denev_ 5月9日
簡単に導入できてアホでも使えるようなバージョン管理ツールだれか作って
neologcutter @neologcut_er 5月9日
やっぱり一貫性のない現場ってやりにくいやね。コンセンサスは相手に逃げ場を与えない意味でも(責任の所在を含め)しっかり取りましょう。
毛海王 @masu_ooyama 5月9日
20年以上昔だけど参加したばかりの職場で終電間際に当時の職場で使ってたバージョン管理システムにコミットして帰ろうとしたらコンフリクトエラーになったんだけどメッセージが英語で原因がわからなくて終電が迫って焦りまくったことがある。今のバージョン管理システムなら慣れないユーザがよくわからないエラーで戸惑うことないのだろうか。
葵真碧(mao aoi) @maochin39blue 5月9日
PCが介在するあらゆる分野の現場は、gitとredmineで管理できると思ってる。文章だろうが絵だろうが動画だろうが音楽だろうがプログラムだろうが、全部だね。あとは好き嫌いを言わないだけ。Backlogとかtoreloとか言ってる奴は全員ビンタでおk。
佐吉 @sakichi01 5月9日
たぶんGit導入時に「コマンドラインって何?」とか「クライアントをインストールするの面倒」とかあると思うので、とりあえずGoogleDocsだけでもいいんじゃないかな。版管理もあるしコメントでIssue管理っぽいこともできるよ。ブラウザがあれば出来るし今どきスマホ持ってるならGMailぐらいあるでしょ。
navyfox @navyfox 5月9日
契約切ったらBANされて~のあたり作家がリポジトリ立てて出版社側がアクセス権もらうようにしないと引き揚げるとき面倒なことになりそう
佐吉 @sakichi01 5月9日
maochin39blue いや、相手によってはTrello意外と効果的ですよ。製造業はトヨタ生産管理でいうカンバンが浸透してるのであのインターフェイスが馴染み深かったりします。
(=゚ω゚)ねこすけ@コピミスト @Bikenekosuke 5月9日
さっきのコメントで忘れてたんだけど、是非作家さんたちにはgitをただのツールとして扱うのではなくて、トーパルズと愉快な仲間達が引き起こした愉快な内輪揉め(日常)からのgitを開発するサクセスストーリーでお話を作ってみて欲しいのです。 (確実に本一冊にはなると思う。)
asa @asa0625 5月9日
公文書を全てgitで管理してくれ。
急急如律令 @99nyorituryo 5月9日
markdownからEPUBにも変換できるしな。
Tsuyoshi CHO @tsuyoshi_cho 5月9日
まあ、WordはWordで、コメントと表記ゆれとアウトラインの意味でそれはそれでいいんだけどね...
たる @taruwo 5月9日
Penicillium_ch GitHubで編集をやり取りしているようなところだったら、それがGoogle Docsに変わってもあんまり気にしないような気はします。ただ、そういうのが本当に気になるんだったら、オンプレでSharePoint Serverあたりを立ててバージョン管理するのがいいんじゃないですかね。
あごにー @Agony_01 5月9日
IT土方的にはバージョン管理して議題はチケット切るってすごーく当たり前のことだと思っていたんだが、ほかの業界ってこうゆうの使ってないの・・・?
Osafune @Osafune_ 5月9日
その頃ロシアでは原稿用紙に鉛筆で執筆していた
Harusame 毛涯 @Harusamehuman 5月9日
こういう「手法」で他人を置いていこうとするマウンティングは、自己愛の正当化や詐欺の臭いがする。 いいんですよ、手書き原稿だって。
佐渡災炎 @sadscient 5月9日
原稿がTeXとかPSとかのプレーンテキストならまだわからんでもないが、diff取れないファイルでGit使う意味はよく分からん。
kazken @kakenx 5月9日
Harusamehuman 各々がやりやすいやり方でいいんだよね。別に新しいことが正義でもないし。
lion5557 @lion55571 5月9日
プルリクで紛糾しそうだな。正直gitよりsvnのが楽な気するけどね……
ざの人(togetter用垢) @zairo2016 5月10日
そういう専門用語を多用して俺かっこいいと思ってるのかな?でもって、いかにもわかったように他の人もそれにコメントつければ、俺もそれなりにわかってるぜアピールできるとおもってるの?とは思った。儂は正直 ぜんぜんわかりましぇ~ん。google docsだけはわかるとして レポジトリだってリナックスやりだすとそちらでは使われる言葉だけど、プログラム開発技術者って、そういう専門用語を多用して書くことをかっこいいと錯覚していない?
lion5557 @lion55571 5月10日
あ、これ構成管理の文脈で話すことじゃなかったのか。それにしてもgithub使うほどのものか知らんけど。ofiice365とかそういうのでもいい気がする(有料だけど)。
coilcoils @coilcoils 5月10日
わかる。小説書くのとコーディングって似てるからITツールと物書きは相性がいいと思う。昔プロット考えるときUMLシーケンス図とか使ってたし。近いうちに複数の書き手で議論しながらつくる長編小説とか出てくるんじゃないの?
lion5557 @lion55571 5月10日
zairo2016 どれが専門用語? linuxってスマホにも使われてるよ。リポジトリだとかギガとかメガとかいうのも最近よく見るけど、それも専門用語なの? IT系は敷居が下がってきているので、専門用語(?)使う人が増えてくるのはアタリマエかと思いますが。
Daregada @daichi14657 5月10日
文豪の手書き原稿が再発見されて、著名な作品の変更点(推敲の跡)が明確にわかるようなものだと、研究者や熱心なファンにとって役に立つでしょう? 後から追加された部分や、削除された部分や、置換された言葉など。gitを使うってことは、デジタルデータに対しても、そういった変更点点を後からでもわかるように記録するってことだよ。文豪じゃないので、情報を利用するのは書いている当人や編集者ぐらいかもしれないが。「ここは以前の表現の方が良かったな」みたいなこと、あるでしょう?
J0i3gsrMJQRDkYc @J0i3gsrMJQRDkYc 5月10日
GitHub使えば円滑にファイルのやりとりができて履歴が残ってノウハウが貯まっていいことづくし. ただし学習コストはそれなりにあるので重い仕事とかで導入してみるといいかも.
ざの人(togetter用垢) @zairo2016 5月10日
旧来の紙メディアの出版社で編集者をやってて、Wordの編集機能+電子メールで原稿を回している連中(これでもまだマシ)はどんどん置いてかれる感じ、 → これに関して言うならば紙印刷、出版世界では、印刷フォントはもうMACの土壇場で、刷業界に限っては、マッキントッシュのシェアは9割ほど。だからそれに渡すまでは、ワード程度かテキストエディターで十分だってことなんじゃないかと、だってどのみちMAC通すときに余計な編集も邪魔になるだけだから、とも思った。
ざの人(togetter用垢) @zairo2016 5月10日
あくまでプログラマーをどうとか言うつもりはありません。 私は素人ですし、ただ?業界用語多様の知ったかカッコマンってよくいますから、そういうの見ると虫酸が走るだけです。
ビーフジャーキー @_beafJerky 5月10日
ちょっと棘ではまとめられないタイプのオタク(といっていいと思う)だからちょっと鼻白むだろうけど、フォトショって便利だよねくらいの話だからそんな温度感で見てればいいと思います
さとうあきひろ @akihirosato1975 5月10日
zairo2016 出版業界こそむしろWindowsの方がマシンコストが安いし、今時Macでしか動かないDTPソフトなんてないし、フォントもTrueTypeで標準化が進んだ結果どっちでも使えるしって理由でめっちゃWindowsに回帰してるんですけど(少なくとも自分が知るIT系出版社はそう)。今MacにこだわってるのはWebとスマホアプリ系の開発者で、特にiPhoneアプリやってるとMacがないと仕事にならん。
coilcoils @coilcoils 5月10日
Pixiv辺りでgit機能を持った二次創作のWeb小説エディタを造ってくれたらいいのにね。文章エディタを中心に据えて、プロット、キャラクターの公式設定、キャラクターに関する人気ツイート、といった情報が参照できると良い。修正箇所をマークしたり、ToDoをクイックに登録したり、共同編集者とのチャットができたり、工夫次第で色々と捗る気がする。
saku @sakuuuuuuune 5月10日
稀にgit神話を信じてる人がいるけど、テキストならいいんだけど、バイナリ触り出すともうgitじゃ手に負えない git-lfs安定してないし、そもそも非プログラマにとって設定やら使うのめんどくさいし、絵や音楽、動画の場合はリポジトリサイズがすぐに爆発するし、そもそもローカルに全履歴は必要ない けどgitみたいにブランチで管理したいしgithub使いたいよね、ちょうどいいツールないのかね
saku @sakuuuuuuune 5月10日
あと主にJIRAとRedmineはもっと軽くなれ… 一挙動一挙動が重いんじゃ
ざの人(togetter用垢) @zairo2016 5月10日
lion55571 だったら、 「githubに取り込まれて、プライベートレポジトリにinviteされ、編集者がいじりまくった原稿がプルリで送られてきて確認を求められ、github issueで方針相談」 この文章を万人にわかるように説明できる? これらは検索すればわかるけど、プログラムに無縁な人は理解しないし。コメント欄でもめったに見かけない。分かる人はそれなりにWEB構築とかやった人はわかるだろうから、この話題に食いついた人は相応の知識はあるって見てはいる。私は見たこと無いから。
くまむし@丸の内にゃんにゃんOL @kumamushi_sop 5月10日
lion55571 リポジトリもプルリもgithubもどちらかと言えば専門用語じゃないですかね……。非エンジニアですが、日常では使わないですよ……。
ざの人(togetter用垢) @zairo2016 5月10日
ギガ メガだけに限定するなら、数学でも普通に使われる単位、製造業やってる人なら普通に使うでしょ。文系は使わないかもだけど。引用が幼稚すぎ。如何にもそういうレベルまでしらないのか?って馬鹿にする意図がミエミエ。
ざの人(togetter用垢) @zairo2016 5月10日
で、少なくとも、これらの単語を用いてコメントで食いついている人は、相応の知識はある人達なんだなあ。という、一つの尊敬の目で見てはいます。他に相応のスキルはあるんだなと、コメント欄で論じている人に違和感はありません。本当に判って書いてるんでしょうし。 ただ?ツイートや日常生活においてとなると?個人的には(と 限定しておきますが) 「業界人しか知らない言葉を多用して、いかにも業界かぶれと自慢する 業界かぶれ 芸能関係かぶれ の嫌な姿勢として見えたもんですから、そこはすみません。
湯飲み @sencha_inYunomi 5月10日
githubなんて30分レクチャー受ければ基本的な事は出来るようになるし良いと思うんだけどなぁ。ぶっちゃけFacebookとかよりシンプルだしバージョン管理まで勝手にされるおまけ付き
denev @_denev_ 5月10日
kakenx 新しいことが正義ではないが、効率の良い仕事は正義でしょ。働く時間も短くて済むし。
denev @_denev_ 5月10日
zairo2016 そんなこと言ったら、たとえば校正と校閲の違いなんて一般人は知らないでしょう。でも編集者や物書きなら常識です。専門業界で働くひとが専門用語を使うのは別に責められたことではないと思いますが。
denev @_denev_ 5月10日
これを「一般人をバカにしてる」とか感じてしまうのは、あまりにも劣等感が強すぎなのでは‥。専門用語でしか表現できない概念だから専門用語を使ってるのであって、グローバルなベストプラクティスを実践していただくグローバルなオポチュニティとはわけがちがいますよ。
denev @_denev_ 5月10日
もちろん現状では、これらのツールは出版業界に(というかIT業界以外には)馴染みのないものですが、共同作業におけるバージョン管理という概念自体は、出版業界においても理解されやすい(かつ極めて有効な)ものと思いますので、ツール導入の障壁さえ解消されれば、普及も期待できると思います。
腐ってもエビ @kusattemoevill 5月10日
coilcoils そもそも合作小説自体がマイナーだから出てくるとしてもムーブメントとしてはかなり局所的かも。映像作品の脚本などひとつ上に陣頭指揮を取る役職がある場合なら既に一部で導入されてる可能性はある
ちいさいおおかみ〜クリアカード編〜 @siu_long 5月10日
lion55571 問題はその"敷居が下がった"事で、これ迄の"常識"って奴が通用しなくなって、それ迄の"周囲の無知無関心と云う現実"を突き付けられる事なんだよなぁ。
ちいさいおおかみ〜クリアカード編〜 @siu_long 5月10日
_denev_ 最大のツール導入の障壁は、トップページ含むGithubの全ての頁が英文記述されている事と、パスワード及びユーザ名の設定が煩いやり方になっている事。おかげで俺は未だにGithub登録出来ていない…orz。
りおちゃん @riochan_org 5月10日
gitで始める原稿編集のhow toまだですか?
佐吉 @sakichi01 5月10日
siu_long この辺のどれか見ながらやれば出来るかも。 https://qiita.com/search?q=github+アカウント
乾也春海 @kanbaru 5月10日
自分の主な仕事とは違うことを覚えなくていいレベルにしなければ、流行らないかなと思う。 世の中はできない人にツールを合わせることができないなら、その使用方法は衰退していく。 できる人というのは使いにくいツールを使いこなす人ではなく、使いやすくするツールを作る人。
Pzkpfw4@Sd Kfz 161/1 @Pz_4 5月10日
自分は素人ですと言いつつ、知ったかぶりがどうのこうのと言い出すような奴なんてほっといていいよ。 お前のためにしてる話でもないのに、なんでそんなに自意識過剰なんだ。
ギゴガゴン @gigogagon 5月10日
会社で急に「会社公用語を英語にしまーす」で対応しきれる人が、対応しきれない人を「自己努力が足りない」と言うのと同じようなニホイがするコメはご勘弁だな。それはさておきgithubから機能コミットと用途最適化したGUIツールで敷居下げるのは、まずはgithubを触ろうって人増えるので良いよね
トェェェェイ @lvbZJFV1MlN6YTF 5月10日
上の方でオエーって吐いてる人や耕してろって言ってる人は少なくともバカにしてるよね
Pzkpfw4@Sd Kfz 161/1 @Pz_4 5月10日
煩雑で想像したくもないから、オエーなんだよ。
飛竜 @bsb_hiryu 5月10日
「お前は誰と戦ってるんだ」ってコメントがTogetterにはたまにある。敵対してる相手がその人で合ってるならまだわかるが、「お前の敵はその人じゃないだろ」ってコメントがここにもある
堀石 廉 (石華工匠) @Holyithylene 5月10日
これ、中規模出版社に社内SEの仕事の口が出来たっていうはなし?
VERDURES @Run_Death_March 5月10日
どれか一つメンテナンスとかで使えなくなると混乱が加速しそうだから早めに統一しろって言いたい。これがメンテナンス中だから代わりにこっちを使うとかやると代替ツールが増えてエライ事になるぞ。
totoko@ピュアモンは仮屋美希ですわ @totoko00 5月10日
で、ここまでコメントたくさんされているけど、導入と実際の使い方に関しては誰も言ってないのだが……。 簡単に使えるとか、わかりやすいとか言うなら、トリセツを書きなさい、トリセツを。
ちょろ @tyoro 5月10日
メールやFAXから比べて進歩ではあるけど、github 日本語の diff ゆるふわだし適正かっつーと うーん?ってなるな。 / 最初に Google Docs で書いてんだし、顧客に必要だったのは Google Docs の編集提案モードの延長にある気がしないではない。
lion5557 @lion55571 5月10日
zairo2016 所詮は単語なのでそんな単語使っているからと言ってバカにされてると感じるのがどうかしてる。
lion5557 @lion55571 5月10日
kumamushi_sop 非エンジニアから見るとそうかも。まだ万人が使いやすいと感じるようなツールではないかもしれないので、ツイッターのように使いやすくなれば一般化していくでしょうね。
(=゚ω゚)ねこすけ@コピミスト @Bikenekosuke 5月10日
totoko00 取りあえず「わかばちゃんと学ぶgit使い方入門」と、「始めてのMarkdown」あたりを読んでみるヨロシ。
lion5557 @lion55571 5月10日
siu_long ま、まぁ、これまでも繰り返されてきたことで、それによって洗練化(?)されてきているので悪いことではないと思うけれども。
佐吉 @sakichi01 5月10日
totoko00 それはTogetterじゃなくてQiitaの方へ行ってほしいんだ。
通りすがりのだいこん @KansaiF 5月10日
その、超便利そうな機能付きのナントカってのを、投稿SNS並みの使い勝手にしたプログラム開発をどっかがしてくれたらチョー嬉しいナ。
たまに喋る @tuka_wa_nai 5月11日
ここに技術職以外のサラリーマンの人達もいるだろうし、社長とかに説明して会社に導入してもらえばいいのでは? サラリーマンに広まれば自然と社会全体にも広まるでしょ。
さーたん@もふもふ @tripleodd 5月11日
git for windowsならguiでいじれるが、このguiは独特の作法がある。それにgitはバイナリーを扱うと悲惨なことになるからバージョン管理したいならonedriveとかgoogledriveの方がいい。gitだとコメントを残せるという利点があるけどね…
ヒロセジロウ✏️ @denjiro13 5月11日
完成までに時間がかかる書籍なら有効そうですね。短いの1本ずつ書いて編集者まるなげのボクには縁がないか。でも、学んでおかなければならなそうな気がする…
ハーミッセイーニヨッ @ishiyuriniwa 5月11日
私は少しやってみようと思った。勉強というほどのことではない。少しの体験を。
CAW=ZOO@高津娼会 @CAWZOO 5月11日
慣れたら戻れないくらい便利。 それ、アナログもそうだからな?FAX、メール、そういうことだから。
Ichigo Mayo@ Vケット2/出ません @15my 5月12日
GitHubなら手元にツール導入しなくても、とりあえずファイル詳細画面で編集ボタン押したら編集できて、コメント書いて保存ボタン押したらコミット作成されたと思うんだけど...
kumonopanya @kumonopanya 5月13日
これから20年はgit中心になると思うし取得したほうが得だと思っている、怒っているやつは時代が読めてないんだろうなぁっとも思っている。
tAkihiko @ATA911 5月13日
なんか数年前のgit(hub)事情をベースに語っている人がいるような。 別にクライアントソフトを導入しなくてもGithubならブラウザ上から直接テキストを触れるので、gitを使えなくても利用可能になり学習コストはかなり低くなりました(無いわけじゃない)。 それでいて修正方針と具体的な修正案を示せて、OKであればボタン一つで取り込めるし議論も残せる利点は得られるので、お互いが納得の上ならそれなりに良い取り組みなのでは。
tAkihiko @ATA911 5月13日
とはいえプライベートリポジトリが出版社持ちでブラウザの編集のみだと、原稿を持ち逃げされる可能性もあるってのも事実。
飛竜 @bsb_hiryu 5月14日
これから何年は〇〇中心になるって話は、今まで出てきたいろんな革新的な技術全般に言えることで、どんなに便利と思ってる技術でもいつさらに便利な技術が生まれるかは予測できないものなのよね…
さーたん@もふもふ @tripleodd 5月14日
ATA911 挿絵とかだとどーすんでしょうか。イラストもブラウザー突っ込めますが、それを繰り返してるとリポジトリが肥大化して悲惨なことになります。github lfsはただではないです
佐渡災炎 @sadscient 5月14日
_denev_ 一般論ではそうだけど、本件(出版原稿をgitで管理)って効率良いの?ってのが本題かと。単にバージョン管理だけ(ブランチとかマージとかdiffとかしてない)ならdropboxでもいいわけだし。つーか、差分比較できないプルリクとかacceptしねえっしょ。
トリニガス @torini311 5月14日
_denev_ それ以上一般化できないとか自明だとか(=専門用語でしか言語化できない)じゃなく、「抽象的な概念を示す語にも、限定的な意味内容を持つ語にも成り得るものを、発言者の心の中だけで意味を区別して使ってて、聞いてる方は区別できず混乱」とか「言い換える必要の無いもの(「データ」と「情報」など)を1つのセンテンス内において何故か態々使い分けるせいで、まるでそれぞれ別の概念を指してるみたいになって無駄に混乱/説明不能な矛盾が発生」とかも結構ある気がしますけどね。話者の語彙/表現力の問題?
トリニガス @torini311 5月14日
「みんなでいじれて、履歴全部残せるやーつ」を「リモートリポジトリをプルするとクローンできて、コミットしたブランチをプッシュもできるバージョン管理システム(適当)」みたいに表現したら、そら分からんっていう。あと〝専門用語〟っていうか、「『そのソフトなり何なりの装置や技の名前』が英語だと往々にして一般語を流用してる(ネイティブだと感覚的に理解・区別できる?)」のは「専門用語でしか言語化できない」のとはまた違うような。「パワー → 主電源」みたいな翻訳を一々全部にやってられないのも分かるけど
佐渡災炎 @sadscient 5月14日
ATA911 原稿がTeXとかPostScriptとかで書かれてるならその通りだけど。通常、出版原稿てプレーンテキストで書かれてることはあんまり無い。
ジャカルタ読み専ブラザーズ @_oinarisan_ 5月14日
どうしてもカタカナ語が嫌ならまあ訳してもいいけど、んじゃ「3.5型駆動装置」みたいな単語になったら分かりやすいのかよ、って感じはある
tAkihiko @ATA911 5月14日
tripleodd 問題になるほど肥大化するぐらい出したり引っ込めたりするなら選ぶべきではない、というだけでは。SVGでなんとか出来るならともかく、そうでは無いことの方が多いでしょうし。僕は取り組みとしてはアリ、ぐらいにしか思ってないです。
tAkihiko @ATA911 5月14日
sadscient 「お互いが納得」と予防線張ったのは欠点も多くて万人向けではないとも思ったからです。実際、自分は「通常の出版事情」は知りませんし、バイナリではdiffは見れてもマージが出来ず利点が減るのは間違いないので。ただ、自分のTLで商業・同人含め本を出版している人はMarkdownという形式のテキストデータで書いてCSSやLaTeXで組版の人が多く、そういう人向けには良い取り組みなんじゃないかと思っています。
msky @msky026 5月14日
Crystal-JPで同人誌書いてるときは、さらにRedPenをCIで回すとこまでやってたな。(組版はasciidoc)
親知らず @Boeq 5月14日
いんじゃね?困る奴は相手にしない
アルビレオ@炙りカルビ @albireo_B 5月14日
少人数しか関わらない、コードではなく主に文章といったことを考えるとgitよりwikiの方がとっつきやすいかも
lion5557 @lion55571 5月14日
zairo2016 パケットだって通じるし、wikiだって通じるじゃん? ネット使っといてそこらに転がってるサービスの名前じゃない。ただ君が知らないだけで専門用語とか騒ぐとか幼稚すぎですね。
佐渡災炎 @sadscient 5月15日
ATA911 「gitを有効に使うにはソースがプレーンテキストであることが望ましい」→「プレーンテキストのみをソースとした出版プロセスなら有効」ってgit使うのが目的になってるじゃんよ。目的と手段が逆転しとる。
tAkihiko @ATA911 5月15日
sadscient そうですか?そんな意識は有りませんでした。僕としては、単にプレーンテキストを出版データとして使う人が周りに居るので、そういう人向けへの新たな取り組みとしてgitの利用はアリなのでは、という感覚です。
tAkihiko @ATA911 5月15日
ATA911 gitじゃなくてgithubですかな。
佐渡災炎 @sadscient 5月15日
ATA911 「プレーンテキストから最終成果物を作れる著者」を対象とするならgit使うのは新たな取り組みでもなんでもないです。プレーンテキストのバージョン管理ソフトなんて前世紀からあるんだから。
J0i3gsrMJQRDkYc @J0i3gsrMJQRDkYc 5月16日
gigogagon 英語公用語化もgit導入もそのハードルに見合う価値があるなら良いんじゃないですか.出版社は絶対あると思います.ただしツールの敷居がもうちょい下がる必要もあると思いますが.
佐渡災炎 @sadscient 5月16日
「プレーンテキストで組版できる」って本の中身を書くのとは別のスキルが必要なんだけど(TeXの本を書くんでなければ)、本の著者にTeXだのgitだののスキルが必須になるのってそんなに幸せなことかしら。
危篤前@彼女募集東北提督 @kitokumae 5月16日
法律作るとか、社内ルール構築するとか、そう言った方面にも使えるのか。これは慧眼をえたり、だな。
tAkihiko @ATA911 5月16日
sadscient 「こういう著者向けならいいんじゃね?」って話はたしかにしましたが、僕は「著者にgitを使わせる(プレーンテキストで書かせる)」ことを指して取り組みとは呼んでいません。
ギゴガゴン @gigogagon 5月16日
J0i3gsrMJQRDkYc やった方が良いと考える施策をやるのは良いんですよ。ただ、会社公用語も出版社にしろ「今までのやり方を貫く層(主に高年齢層)」が居て、そちらの売上貢献だの立場だのが大きい場合もあって…という「現実」のパターンも示唆しておりまして…周り見ると、gitの敷居はまだNWエンジニア脳持ち以外には高いみたいですね。
佐渡災炎 @sadscient 5月21日
ATA911 「著者にgitを使わせるのが現代の編集だ(ドヤァ」ってのが本編の話なので。
J0i3gsrMJQRDkYc @J0i3gsrMJQRDkYc 5月27日
gigogagon できる人からやっていけばいいんですよ。できない人はやらなくていい。 問題はアナクロニズムや物質至上主義な人による反対とどう戦うかです。
ギゴガゴン @gigogagon 6月1日
J0i3gsrMJQRDkYc 戦う必要なんてないですよ。アナクロニズムと物質至上はそれが前提となる技術なんてのもあるわけだし、お互い有効な点を認め合って、使える所を押し付けずに使えばいいだけです(出来るかは別)。例えば、文字校正の速度精度が高い人は紙でやらないと上手くいかないなんて例も、身の回りでは結構ありますしね
J0i3gsrMJQRDkYc @J0i3gsrMJQRDkYc 6月2日
gigogagon 日本のアナクロニズムや物質至上主義者がそうである所以は、自分が生きてきた高度経済成長期にできた物質的なものに自信やアイデンティティを持ち過ぎて、それ以降に生まれた非物質的な情報技術を否定していることにあります。 だからそういう人間と戦わなければ未来は見えてきません。
ギゴガゴン @gigogagon 6月3日
J0i3gsrMJQRDkYc なるほど。日本のアナクロニズム・物質至上主義とはなんたるかの話になりますとそれぞれの現実的な経験や知見での認識の違いになりがちですし、話がずれてらっしゃいます。また、それに対する認識や対応の方法は千差万別かと思われます。各々の範囲で対応する事を行うのであれば、個別にできる範囲で対応が適切かと。
J0i3gsrMJQRDkYc @J0i3gsrMJQRDkYc 6月3日
gigogagon その定義の話は長くなるのでしませんが,落合陽一の脱近代の話と大体同じです. その近代という共通認識を持てば一般的な議論ができるだろうと思います. gitやらが出版業界に普及しない原因は突き詰めると近代のマインドが根底にあり,それは破壊的にアップデートされるべきだというのが私の主張です.
ギゴガゴン @gigogagon 6月3日
J0i3gsrMJQRDkYc そのスタンスは認識しております。こちらはアナクロ手法による世の中へすでに伝わっている普遍性・有効性を全無視した上で、刷新というのはいささか難しいと考えております。新規事業立ち上げた若い出版社や、ワンマン社長でも居ない限り現実的には難しいと思われるので、まずは一部からでもアップデート受け入れさせて、ジワジワと…と考える次第です。お互いアップデートは必要と考えているわけですから手法の考え方の違いですね。
alan smithy @alansmithy2010 12月3日
t_kusano 少なくともエンジニアはgit位できないと就職できないっす
ログインして広告を非表示にする
ログインして広告を非表示にする