反省

無限に反省しててすごい。ちゃんと活かされてるのか怪しくてただの後悔なんじゃと思わないでもないな。

www.pixiv.net

小説なんか初めて書いたね。絶対書かないと思ってたのに……

以前小説は、絵と違ってパット見で質が測りにくい分、流入は安定しているんじゃないかという予測を立てたことがあった。それが本当かはわからないけど、現実には小説の流入数がそもそもめちゃめちゃ少ない。ジャンルによる気もする(多分それは本当にそう)けど、ミリオンライブの小説に限れば、3,4作品/dayくらいのペースっぽい。

それでこれが一番衝撃だったんだけど、基本的に閲覧数が異常に少ない。デフォルト閲覧数が三桁いくかいかないところにあって、ブクマが10行ったらすごいみたいな世界である。漫画でもミリオン界隈はまだ比較的活発でないけど、本当にほそぼそとしているな、という印象だった(参考までにfgo界隈を除くとめちゃめちゃアクティブだった)

今回小説を描いたのが、とりあえず思いついたノリでプロットを書いたら気分が乗ったというのと、今の自分の漫画力ではこの作品を描きたくないという気持ちの折衷案として書いたものなので、まあクラウドに上げたメモのようなものである。なので、評価数は望めなくて全然良い(まあ実際はそりゃ普通に悲しいけど)。

とにかく、まあ多分竜頭蛇尾になってると思うんだけどおよそ四時間くらいかな、でちゃんとお話を書ききれたのはまあ良い。練習として小説を写経した甲斐があった。また続けよう。

昨日上げた、あんまり見られなったな~~~って漫画でさえこの小説に比べればめちゃめちゃ見られてることを考えるともう一回初心に帰る機会にはなったのかもしれない。これからもクラウドメモくらいの気持ちで書くのはいいかな、という気になった。これ反省じゃねえな。

関係ないけど先輩がSSの方でそれなりにコンスタントに成果残しているのを今までしらなくて少しびっくりした。

ついき: 思考法が変わってこれはこれで新鮮なので、月1くらいで書いてもいいような気がしてきた。感覚はクラウドメモで良いので。そういえば文章が欠ける人間にもなりたかったんだったな…… それはそれとして、おそらく二次創作SSとしてはあまり適切なものではない形を目指すことになりそうだけど(それ自体が苦手なので)、そのへんは理想と現実との折り合いで適宜調整することにしたい。

内容

全く中身の反省をしていなかった。ダラダラ書いていく。

  • 開幕訴求力が無い

最初から結構だらだらと作品を知っている人には割と自明な説明が続いている。SSも漫画も根本は変わりなく、常に「そこで閲覧を切られないか」ということは考えないといけないことで、さっさとこの話がどういう雰囲気の話なのか、みたいなのは出してもいい気がする。それか、自然な文章を紡ぐか(読者はキャラクターコンテンツを摂取しに来ているのだ、という考えに基づくと後者は次善の策でしかないけど、あんまりそういう文章を書きたくないので個人的にはそっちに寄せたい)

  • 描写がまだまだ少ない

以前と比べればおお、文章になっているというだけで感動したけど、まだまだ心情の描写のみで光景描写が足りて無く、書いてる側が脳内で収めてしまっているだけになる。あとで読み返すとわかることなので、これは推敲時間を設けることによってある程度は解決しそうな気もする 月一感覚なら焦ることもないのでできそう?(漫画はさっさとあげたくなってしまうので)

  • 句点が多い

なんでなんだろうね。

  • よく読むとおかしいところがある

推!敲!

しかし描こうとしたテーマというか話自体は良かったと思うんだよなあ……とにかくコツコツ写経を続けて使える表現増やすのと一日くらいは置いて推敲しようねという落ちになるんだった。漫画と一緒やんけ!(そりゃそうだ)

反省

www.pixiv.net

あんまりない。ちょっと絵がうまくなった気がする。あと自分のこういうちょっとした短編のセンスがニッケルオデオンとめっちゃ近いところに有る気がする。(読み直してて気づいた)

これもあんまりウケなさそうな気がするけど、これはこれでいいかな。描きたいものを描きたいから描いてるので、良いと思えるのであれば良いということを忘れないようにしたい。

少しばかり出力欲が落ち着いたので一週間くらい入力しようかなという気分。某長編についての作業は少しするかもしれないけど。

追記:ウケとかいう以前に閲覧数の伸びが笑えるほど悪い。1p目がひどすぎるせいな気がする。読んでもらわないと内容以前の話なんだったなあ、という反省。とくにほっといても良質なマンガが毎日流れてくるシンデレラにおいては、アピールの必然性は他より高いと思っても良さそうだ。個人的に好みな雰囲気の話になったので、小さな話をまとめて本で清書する際に供養してあげたい。

反省

www.pixiv.net

良かった所

  • MMDを使うことで背景が結構マシに描ける様になり、構図にだいぶ広がりが出た。これからは積極的に利用したい。

  • ぶち抜きとかを使ったりで、漫画の画面的にもメリハリが出てたと思う。今まで描いた中で一番それっぽい感じのページだったと思う

  • 斜線でトーンするの、結構悪くない感じだったと思う。トーンワークがクソ下手な割に手間かけてるので、サッと描くならこれくらいで良い(ただし、それはそれとして練習する必要があるけど)

悪かった所

  • 内容がないのはまあ良いとして、キャラ選択が適当すぎて片方が出てる意味がまるでないのが見ててかなり辛い。雑に描こうと思って雑に描いた漫画だからいいは良いんだけど、やっぱりキャスティングにもそれなりの理由があるべきだな、とは思った。

  • アップロードサイズ、見開き問題について やっぱり2ページ分を一気に作るのには無理があった? pixiv見開きをもっかい利用してみるか……二頁に分けるのめんどくさいけど……

ララランドという映画を見て大変良かったんだけど、アレを見て自分の漫画は文書を使いすぎかもなって思った。もっとキャラクターの演技で描写しないといけないなあ……

反省

www.pixiv.net

即日の反省

良かった所

  • ネームは割りと練れたというかまだ我慢が効いてたと思う
  • 描いてる途中に顔描き慣れてきた気がする

悪かった所

  • 最後は我慢が効かず突っ走ってしまった
  • 絵が汚い(これは諦めても良い気がする。後述)
  • セリフが微妙に浅い

ちゃんと描く機会として本を出すというのがあるんだからpixivにあげるやつはちゃんと描かないでいいのではないか。

ただ、それならそれでもっとやりようが有ると思う。今のやり方は労力と出来上がるものの質が噛み合ってない。手を抜いた作画の漫画を見て真似る。ネーム以外には時間は描けないようにしたい。

セリフは……写経かな……

そういえば前のうどんのやつが微妙に伸びてて(うどんだけに?)世の中何が受けるかわからんな……ってなった。

個人的には今回のもののほうが伸びて欲しい気持ちは有るけど、そう思ったとおりにすすまないのが世の中だと思うのでそういうつもりでいたい。しかしミリオンはほんとに漫画が少ないな……

追記

オチの付け方がワンパになってる気がしないこともない。そもそもオチってそういうものでは…とも思うけど、ちょっと意識的に色々試してみるようにしたい

顔漫画がすぎるので(なんか座って話してる漫画しか描いてない……)全身書けるような漫画を描きたい。表情ももうちょっと崩したい……練習にならない

評価数というFBを受けて

まあ結局思ったより伸びてない。話も前のやつと比べて地味なので、ありちょっとくらいじわ伸びして30ちょいくらいで止まるという感じだろう。

改めて見返してみるとやっぱりネーム良くないな。退屈にならないように色々カットを割ったつもりだったけど、まだメリハリがなくてなんとなく絵が並んでる、という印象が強い

平均コマ数を0.5コマ/pほど下げたほうが良いのかもしれない。最大6,基本4,5くらい。今3*3の9からの一部中ゴマでデフォルト7くらいの感覚になってる気がする

咲特訓で何か変わるか。三日間ほど修行します。

そういえばA4横向きで描けばいいじゃんということがわかった。次からそうする。

そういえばメリハリという概念ではうどんの話が実は結構イケてるのではという気がしてきた。あらゆる意味でどうしてあんな漫画が描けたのかわからん。

2/17

明日は早めに京都にのぼることになりそうだったから先に原稿の方を二日分やった。あと論文修正作業。だるい……

明日は勉強に割くかなあ。毎日参考にしたい漫画を読み返すとかをやってもいいかもしれない。表現技法の勉強とネームの勉強は別にすべきっぽいよなあ……たいへん。

2/16

昼寝とかで一日の区切りが曖昧なのであくまで日付は適当 好きなときに昼寝できるって素晴らしいなー

TCP/IP

NOCについて詳しい情報を調べたけどあんまり見つかんない。セルフで運用してる人もいるみたいだけど。

IXもこれはISP同士を接続する事業ということで、あんまり一般利用者は意識する必要が無いように思える。

しかしPI(provider independent)アドレスを扱う際はそういうわけにも行かなさそう。もうちょっと調べてみる。

歴史的経緯を持つプロバイダ非依存アドレス(歴史的PIアドレス)について - JPNIC

そこからIPアドレスの話。復習込み。

まずIPアドレスは所属するネットワークを表すネットワーク部とホスト部に分かれている。その2つを組み合わせて一意なアドレスとして機能する。

このネットワーク部とホスト部の組み合わせについて、過去は4つのパターンしかなかった。上位8,16,24,32bitをそれぞれ使うクラスA,B,C,Dである。これらは先頭の4bitで区別される。

しかし、これでは柔軟性がないということで、その2つの組み合わせを任意のbit数ずつでできるようにし、どこまでがネットワーク部でどこまでがホスト部かということを表現するサブネットマスクを併記する方式になった。これをCIDRという。

これの導入以前IP管理機関から直接に割り振りを受けたIPアドレスをPIアドレスというらしい。CIDRの導入とIPの配給にプロバイダーが噛むようになったことに対する因果関係はよくわからない。

ipvx.info

いろいろ調べたがまとまらない。経路情報決定プロトコルあたりの知見が足りてないのでその辺を明日もぼちぼち

コンピューター科学

2の補数 => all 1を-1とする整数表現法。他に、表したい範囲の一番下をall 0に設定するエクセス記法というのもあるらしい。

ハミング距離を用いた誤り訂正について、何bit変わったかということが分かってないと意味が無いような気がしてよくわからんな、ってなった。そんなこと言い出したら仕方がないのかもしれないけど……

漫画の勉強

f:id:lastcat:20170217093826p:plainf:id:lastcat:20170217093831p:plainf:id:lastcat:20170217094353p:plain

これは今の自分には無いなと思った表現を縮小簡易模写で勉強。でもこれめっちゃしんどい。この3ページで三時間位かかってると思う。一日最低1ページ(およそ2,3表現くらい?)、MAXで3ページとかかなあ。参考にする漫画は作品ごとにがっちりやっていく方が良いのか、コロコロ回して行ったほうが良いのか。飽きっぽいのでとりあえず後者にしてみようと思う。

あと、学んだ表現はなるべくすぐ練習として使う機会を持ちたい。とはいえ一日1pとかのペースで描いてるとむずかしいのだけど…… これも課題として考えておく。

2/14のメモとか

TCP/IP

L1層について

L1層の機器として取り上げられてるのはリピーター(ハブ)という信号の減衰を回復する機器であった。L1層はデータとして扱われてないようなただの電気信号なので、せいぜいそれくらいしかできないという理解でいいのかな。

あとリピーターハブという機器は、おそらく受けた信号を単にコピーして各配線に流す機器である。当然セキュリティ的にあれなので、L2層でちゃんと行き先を仕分けてくれるスイッチングハブが安価に手に入るようになった今は廃れた物であるとのこと。

L1層でスイッチングするL1スイッチというものも有るとのことだけど、これはいまいちまだ意義がわからなかった。オンプレで大量のサーバーを管理している際に、トラブルシューティングのためにL2の前段階にもスイッチング機器を用意しておくと良いことがあるという理解で良いのかな。

nosa.cocolog-nifty.com

L2層

MACアドレスで直接繋がってる機器同士を区別してパケット(フレーム)を転送する。ここでようやく信号のスイッチングの概念が出て来る

L3層

ここがルーターとかの領域にあたる。ここで見るのはIPアドレス

L4~L7

ここから先は信号情報の中身が意味を持ってくるのでそれを使ったフィルタリングとかの話になってくる。ロードバランサーとかファイヤーウォールとかにあたるらしい。ファイアーウォールとかロードバランサーをアプリケーションでしかみたことないからいまいち実感はわかんないけど。

一応貼っておく:

eng-entrance.com

コンピューター科学

XORについてあんまりイメージがわかなくて毎回ググってるんだけど、ベン図のイメージはわかりよいかもしれない。

gyazo.com

フリップフロップが記憶領域を持ってないのにメモリみたいな役割を持つこと(というかこれこそが記憶領域の素材なのでそりゃそうだが)もなんとなくの理解なので整理しておく

d.hatena.ne.jp

ここのサイトがわかりよい。値を保持するのにループの回路を使い、OR、ANDをON,OFFに使うという話がしっくりきた。

ASCIIコード表

ASCIIコード表

その他

lsのmanを読んでてsetuidあたりのパーミッションのことをわかってないので調べた

setuid - Wikipedia

スティッキービット - Wikipedia

setuidは、作成者のユーザーidで実行できるという情報。setgidはグループについて同様。

スティッキービットについて。

スティッキービットの最も一般的な使用法は、ディレクトリに対して使う場合であり、セットされるとディレクトリ配下のファイルのファイル名変更や削除はそのファイルの所有者、ディレクトリの所有者、スーパーユーザーのいずれかしかできなくなる。スティッキービットがセットされていない場合、書き込みおよび実行のファイルパーミッションを持つユーザーなら誰でも改名や削除が可能である。一般にこれは /tmp ディレクトリに使われ、一般ユーザーが勝手にファイルを改名したり削除したりできないようにする。この機能は1986年の4.3BSDで導入され、現在ではほとんどのUNIXシステムで採用されている。

削除権限を所有者に限定するというということらしい。

kazmax.zpp.jp