一般

KCSで行われた一般的な事柄

C97に別サークルで参加します(宣伝)

これはKCS AdventCalendar2019 24日目の記事です

←23日目  25日目→

どうも皆さんご無沙汰しております、毎日現実世界からログアウトしているk0buです。

今日は12月24日、世の中でいうところのクリスマスイブですね。町もクリスマス色に…なんかなってなかったので、正直現実ではほぼ日常と同じ感覚ですごしました。私が感じている日常との差異としては、この記事を今まさに書いているところですね…

さて、前回私が記事を投稿したのがちょうど一年前で冬コミケに出す内容についてでしたね。なんと、今年も同様にコミケについてのお話をさせていただきたいと思います。といっても、今回はKCSでのサークル参加ではなく、旧友と一緒に作った創作サークルでの参加となっておりますので、技術的なお話はなく、創作で触れた工程のいくつかをお話しできればと思います。

まず今回は自分で決めていた目標があり、それはBlenderで絵をレンダリングすることでした。そのため、なるべく詳細なモデルを多数作るのには時間が足りないことは想定していたため、なるべく少なくかつ納得する見た目ができるモノを作ることを心がけていました。

今回実際作成したものは「夜」と「道」をテーマにし、それぞれ画角に無駄なモデルを置かずに周辺がどこなのかをわかる程度の情報量分のモデルを作成し、合っているHDRIを環境マップに指定しました。後々わかると思うのですが後処理で絵をいじるときだったり、レンダリング時のブルームや被写界深度などをいじると簡単に綺麗になるので、何かしらの環境マップは入れた方が良いです。また悪知恵ですが、今回は詳細を省いたモデルを作っていたり、またメインで写す被写体がいたため、ブルームと被写界深度がモデルの細かい部分を誤魔化すのにかなり使えました。

テーマを決めた後は、実際に作る必要であるモデルを考えますが、大体は日常的にアンテナを張って、この一部は使えるなというメモを残しおくようなことをしました。他にもTwitterで個人的にフィットした絵の場所や、ジャンル的な場所をメモしたりし、後で時間がある際に他の同系列の資料も探していたりしました。資料をまとめる際には”PureRef”というアプリケーションを愛用していましたが、実際に一つのモデルを作成するときは資料としてBlenderの中に入れて作業をすることをお勧めします。悪い癖ですができないくせにトポロジーを気にしすぎて全然作業が進まないことがあるので、ほどよく脳死で資料通りに作りましょう。トポロジーをキチンと整えることができる人はそのままのあなたでいてください…

モデル作成後は、レンダリングでの調整、Photoshopでの調整、タイトル付け、全員の進捗管理と話し合いがあったりと色々ありましたが、私は夜になったら現実世界からログアウトするという人が日常的に行うべき、模範的行動を行うため、詳細に関しては話すことはせずにここで区切らせていただこうと思います。

最後に、今回のC97は12/30(月)の参加となっており、場所は南ヨ34aとなっております。僕を含んだ3人で作ったフルカラーのイラスト(?)本となっておりますので、ぜひ良ければ遊びに来てください。

イラスト本の宣伝ツイート

[k0bu signed out]

 

AICビジネスコンテストの反省

これはKCS AdventCalendar2019 22日目の記事です

←21日目 23日目→

どーも、まんたあにど(@anidomanta) です。

オリキャラの絵を横に(13日目)、調性のない音楽を聞きながら(18日目)この記事書いてます。(嘘です)

突然、私事を書いて恐縮ですが、AICの活動の一つで行われたAIビジネスアイデアコンテストにおいて、自分の所属していたチームが2位を受賞しました。自分は主に、チームの発表やその原稿内容、資料(パワポ)の作成を担当したので、今回はそれらを中心に、コンテストを終えて自分が思ったことや反省点を淡々と独り言でもつぶやくように書いていきたいと思います。

ただAIの機能を使ったビジネスモデルを考えるだけだったので、厳密には技術とは全く関係ありませんが、KCSと提携していること、一応AIを扱っていること他に書く所も機会もないことから、「たぶん」「おそらく」「もしかすると」KCSの活動と何らかの関係性がある「はず」「だろう」という独断と、この一年をちょっとだけ振り返ってみるという名目のもと、アドベントカレンダー3つ目の記事に臨みたいと思います。

画像もなく、ほとんど誰得な内容かもしれませんが、まわりまわって何かの役に立てられれば幸いです。


講座全体

全体のおよそ8~9割近くが理系学部の学生で埋まっていたPythonやUnityといった技術系の講座とは違い、全体の半分ほどが文系学部の学生として参加していた。講座内容はコンサル業に勤めている講師方を中心に、様々な業種の方からAIを使ったビジネスモデルや昨今のAIに関する話題、AIを使った研究内容などを教えてもらった。また、初回に4~6人程度規模のグループを作り、全ての講座を通して講座内容をもとにグループワークを行った。全体の出席率は非常に高く、どのグループも仲良く活発的に議論が行われ、 発表内容もどれもレベルの高いものだった。最後の講座では、AIを使った将来のビジネスモデルを提案するというお題で各々のチームが発表を行い、その中から発表内容やその姿勢など様々な観点のもとに総合点が高い順に、本番のコンテストに参加する数チームが選ばれた。

 


チーム

自分のチームは文理半々という、ある意味バランスの取れたものになった。個々の意見の共有は常に行われ、講座が終わった後もLINE上で議論が繰り広げられ、グループでよくありがちな、質問等をしても誰も反応しないということもなく、発表の際にも率先して色々サポートしてもらい、ワークをするうえで非常に恵まれたチームだった。(本当にありがとうございました。)

 


 

チームアイデア

需要のある製品を生み出すことがビジネスであると考え、まず、現状の日本社会が抱えている問題について意見を募り、主に高齢者の介護といった福祉系にまつわるものが多かったため、誰かの手助けを必要とする社会的弱者の需要に対するサービスの提供という方向性に絞った。そして講座を通して、膨大なデータ量から学習して結果を見出すというAIの特徴と結びつかせ、最終的に、医療と企業の提携によって病状を自己診断してくれるロボットペットという案に収まった。

 


最終日の発表

5分間の発表と時間が決められていたため、パワポのスライド一つに長くても2分以内には抑える必要があると考え、完成後は空き教室を占有してリハーサルを何回も行った。原稿はパワポを見れば話す内容は大体わかったため用意しなかった。リハーサルでは±10秒~30秒の誤差が目立ったが、本番では5分ちょうどに収まることができてよかった。他のチームが順番に発表者を変えながら発表していく中、自分のチームは発表者を一人に絞ったため余計なタイムロスもなく、制限時間の5分を超えるチームが数多く出る一方で、最も円滑な発表を行うことができたと思う。しかし、結果は自分の予想とは裏腹に3位に終わった。ひとまずコンテストへの参加の権利を得たため一安心はしたが、個人的には手ごたえを感じたため、少し残念だった。発表終了後はチームで問題点を分析し、講師からも助言をもらい、それらをもとにパワポや発表内容を作り直した。

 


コンテスト当日

前回同様、入念なリハーサルを行った。今回はチームのメンバーも一緒に付き合ってくれて、様々なアドバイスを頂いた。また、前回の発表では他のチームが聴衆を意識した発表姿勢を施す一方で、自分はパワポと面向かっていただけの姿勢に留まってしまっていたと感じていたため、メンバーにパワポの操作をお願いし、原稿も作成した。その影響で、経過時間がパワポを通して確認できなくなったため、ひたすら時間感覚を覚えることに集中した。本番では他のチームも発表のクオリティを大幅に上げてきてこれまで以上によりハイレベルなものになった。一番最初に順番がまわされたこともあり、手ごたえの確証はなかった。ただ、前回に比べて余裕をもって発表を行うことができ、発表も5分以内に終えることができた。質疑応答もメンバーに答えてもらい、目立ったミスもすることなく終えられたため、全体的に前回よりも完成度は高いものになったと思う。そのおかげか、順位は前回よりも成績の良い2位になれた。景品(戦利品)としてKeioの文字とロゴがあしらわれた腕時計やUSBメモリ、KPMGコンサルの水筒などをもらった。1位の発表はビジネス案は勿論、説明は数字を扱ったより具体的なアプローチで非常にわかりやすく、発表に関しても頭の中に入ってきやすいものだった。

 


反省点

まず、パワポのスライドが全体的に文字で埋め尽くされ、パワポを使う必要性が不透明にしか感じられないほど非常に見づらいものになってしまった。そのため、アイデアの概要が伝わりづらい部分も見受けられた。これに関しては講師からもコンテスト前に指摘され、改善を試みたがうまくまとめきることができなかった。内容に関してはビジネス的なアプローチが今一つ足りないものになってしまった。グラフ資料などを持ち合わせて数字も扱い具体的に説明することができたつもりだったが、1位のチームはそれ以上にフェルミ推定を用いた利益概算まで行い、さらに一歩踏み込んだ内容になっていて説得力も抜群であった。ロボットペットの単価や販売モデルは質問にも答えられるほど事前に具体的な把握はできていた上に、フェルミ推定という技法も当時すでに知っていて扱おうと思えば扱えたこと、何を言おうが自分のチームのアイデアが一番に決まっているという絶対的な自信をもっていたこともあり、自身による聴衆へのアイデアのアプローチの足りなさをひどく痛感した。

 


まとめ

元々、一留一休というブランクを明けたばかりで、少しでもその尻拭いになるような結果を何か一つでもいいから残したいと躍起になっていたところに耳に入ってきたものだったので、希望通り結果を出すことができた点は良かった。しかし、それ以上に講座を通してAIに関する知見を得ることができたこと、共通の目標をもち合いチームワークを行うという、今まで個人プレーが主だった自分からすれば貴重な体験ができたこと、授業の一環ではなく競争の中で適度な緊張感をもって大勢の前に立って発表をするという経験もできたことなど、結果を抜きにしても全体として得られたものが非常に多い、有意義な時間をおくることができた。当日は技術に関するコンテストも行われていたので、機会があれば今度はそちらにも挑戦できれば、と思う。

 

←21日目 23日目→

 

ゲートオブバビロン(Fateより)が見たかった

ゲートオブバビロンとは

みんな知ってるFate/stay nightに登場するキャラクターが使う技です。アニメやゲームでたびたび登場するこの「ゲートオブバビロン」、何とかblenderで再現できないかと思い、やってみることにしました。下画像がそれです。

「ゲートオブバビ...」の画像検索結果

ごめんなさい。バージョン管理とかしてなかったので、制作過程の写真がありません。

形状の作成

この技は上の画像の通り光る波紋の中から武器が飛び出てくるものです。まずはこの波紋の形を作ります。方法として考えたのは

  • 波打った円面を作り、その頂点の座標をアニメーションで動かすことで波を表現する。
  • 波を1周期分作り、その拡大、生成をアニメーションで入れて波にする。

こんな感じに二つ考えましたが、前者のほうがなんとなく後から色々するのが簡単そうだったので、そっちを採用しました。

マテリアルの作成

 

次に光ってる感じを出していきます。外側ほど透明で、また、透明な部分と色のついている部分をある程度まばらにする必要があります。また、波の山と谷でも透明感が異なります。法線データやオブジェクトデータを入力にとって、shaderや模様を混ぜて、なんとかそれっぽくしました。

武器

事前に作っていた別作品の武器を使うことにしました。本来は様々な武器が飛び出してくる演出なのですが、武器を複数作るところまで手が回りませんでした。

武器の透明化

ゲートから飛び出していない部分は見えないようにしなければなりません。これにはブーリアンを用いて、ゲートの裏側に設置されたキューブと重なれば見えなくなるようにしました。

コンポジット

マテリアルだけの設定ではぼかし等はできないのでコンポジットを使って調整しました。

 

summon_elucidator3

ここまででできたのがこんな感じです。(後ろの背景はただのテクスチャ)

なんかそれっぽいですね

コレクション管理

複数のゲートを設置する必要があったので、作ったもの一つのコレクションに入れてAssetとしました。これを複数インスタンス化して何個もゲートを作りました。

ここで一つ問題となったのが、アニメーションでした。私はゲートそれぞれのアニメーションをずらしたかったのですが、一つのオブジェクトをインスタンス化しているので、アニメーションが共通のものになってしまいました。一つ一つアニメーションをずらすのが面倒になってしまい、3つのアニメーションが異なるオブジェクトを作って、それぞれをインスタンス化して対応しました。

こんなかんじになった

 

三秒の動画、作るのに三日かかった。

おわりに

本物には程遠いかっこよさですが、まあ、よしとします。blenderでいろんな鯖の宝具演出がかっこよく作れるように頑張っていこうと思います。。。

聖地特定とかいう趣味について

これはKCS AdventCalendar2019 19日目の記事です

←18日目 | 20日目→

こんばんは。17日の夜に急遽アドベンドカレンダーを書くことになった4LDK ( @saki4ldk )です。案の定間に合いませんでした。

内容はある程度考えていたものの、少し急だったので、この記事は少しも情報とも数学とも、もはや任意のKCSの活動とあまり関係がありません。

なんの話かというと表題の通り、漫画/アニメ作品における聖地特定の仕方についてです。現実の写真については情報量がこれらよりも多いことの方が多いため、特に室外だとストーカーまがいのことをするのに必要な知識にもなってしまいますが、これを読んでいる方々は犯罪などには利用しないと信じています。

また、記事の内容の都合上、わりと著作権を無視しています。問題があればだれか消しておいてください。一応ある程度は気にしているので後半の実例までは写真を出さないようにしています。なので途中まではめっちゃ黒い記事です。

聖地とは

 

ここでは別に宗教的に大切な場所という意味で「聖地」という言葉を使っていません。自明ですね。ある作品において、背景の参考にされた場所のことです。

有名なところだと、2916年に公開された新海誠監督による長編アニメ映画「君の名は」の聖地として、作中に出てくる「糸守湖」の参考となった長野県諏訪市にある諏訪湖や「糸守町」の参考となった岐阜県飛騨市、2012年秋季から放送されたテレビアニメ「ガールズ&パンツァー」の聖地として、作中で名前もそのまま出てくる茨城県大洗町などがあります。

 

聖地特定について

 

本題に入っていきましょう。前述の「ガールズ&パンツァー」のように、作品内で出てきた名前のまま聖地になっている場合や、公式サイトや公式Twitterでここが聖地です、と宣言している場合はいいですが、大半の場合はそうではありません(とはいっても、最近は宣言してくれる場合が少しずつ増えている気がします)。

そうではない場合どうするか。もちろん自力で探す必要があります。いや、べつに必要ではないですが、探していると案外楽しいので探しましょう。基本的に探す場合はgoogleと長時間デートすることになります。あとで例としていくつかの聖地特定作業を紹介しますが、どれもgoogleくんのおかげで特定できています。意地でもgoogleを使いたくないひとはyahooでググってください。

 

特定困難なもの

 

具体的な探し方の前に、(ぼくが)諦めるポイントを先に紹介しておきます。

 

1.存在しない

 

どうしようもないですね。作品によっては、聖地がある背景が手書き、ない背景は3DCGだから慣れてくるとわかる、などといった場合はありますが、たいていの作品は聖地が存在しているかどうかの判断はほとんどできません。判断ができないので、探しながら、あまりにも見つからず、心が折れたタイミングで「こんなところ現実にはないんだ……」と言ってあきらめることになります。何度かこの経験がありますが、どうしても「僕の実力がないだけで、実はあるのでは……?」という思考が捨て去れないです。でもこれだけは言っておきます。

ないものはない

 

2.海外

 

こっちは1と比べて実際はどうにかしようがあります。例えば、2014年にアニメ化された「ご注文はうさぎですか?」の聖地はコルマール、リクヴィールといったフランスの都市や、ハンガリーの首都ブタペストと、ヨーロッパの都市が聖地となっています。諦めるポイントを紹介するのに、なんですでに見つかっている作品を?と思うかもしれませんが、街並みでヨーロッパとわかった時点で、あまりにも探す範囲が広すぎます。また、細かいところに対しても海外のものだと気づけない場合があります。そのため、あくまで僕はこれは国内だろうというものしか探しませんし、紹介する探し方は国内向けのものです。

 

3.あまりにも情報量が少ない

 

これは、2と似ているのですが、たとえば、一面草原の背景に対して、「これの聖地は○○だ」ということは厳しいです。他にもキャラクターが前面に出過ぎていて、背景がほとんど見えない場合もこれです。探すことが困難な他、合っているかどうかの判定が難しいです。

 

4.正確に描かれていない

 

ここまで読んで、実は自分が好きなあの作品の聖地とか探せないかな、とか思ったあなた、残念でした。多分無理です。

いや、無理ではないのですが、大半の場合は基となった風景に対して、描きやすいように物を減らしたり、単純化します。また、最近は聖地関連のトラブル(一番最後に書きます)も起きているため、わざとある程度現実の風景からずらしている場合が多いです。少しだけならばともかく、殆ど違ってくると、探す材料がないので、ほぼ運と制作会社への知識になります。幸いなことに、アニメやゲームならば制作会社ごとに、漫画ならば作者ごとに、どれくらい正確に描かれているかがほとんど決まっているので、これらが同じ作品の聖地の写真と作品での描写を見比べ、どれくらい正確に描かれているだろうかを推測してから探すことができます。

 

ここらへんに当てはまった場合(1は探して見つからなかった場合、最後に当てはめるものですが)、素直に探すのをあきらめましょう。諦めなくてもいいですが(実際海外聖地のものや描写が曖昧なものならばたくさん見つかっており、見つけることが困難なだけで不可能ではないので)、その分覚悟しましょう。

 

実際の特定作業

 

というわけで実際の特定作業に移っていきましょう。

まず、聖地は大きく分けて、当たり前ですが、室内のものと室外のものがあります。また、これはほとんどの場合、実際に見つけてからどちらだったかわかるものですが、そこに登場しているキャラクターや作品自体の設定にゆかりのある地かどうかという分け方も存在しています。東京の話をしているのに聖地が大阪にあるのが後者、実際に東京にあるのが前者です。基本的にこれらのキャラクターや作品の設定は優先的に利用していくので、前者は見つけやすいですが、後者はすこし難易度が上がります。また、設定に一切地理的な要素を含んでいない場合も後者に含みます。

 

1.室内かつ設定に準じた場所の場合

a

というわけでまずはここです。これは僕自身が特定した聖地なので、実際に特定に至ったまでの過程になります。

まず、彼女らは名古屋に住んでいる設定なので、ここが名古屋だと仮定します。

左端にゴミ箱のようなものが見えていることから、ここが一般公開されている場所と考えると、特徴的なものは階段についている灯りの形及び、螺旋階段です。

後は螺旋階段のついている名古屋市内の建物を調べるだけなので、googleに頼ります。

b

はい、見つかりました。あとはこのサイトに行って場所を調べれば終わりです。簡単ですね。10分かからなかったはずです。

このように室内の場合はgoogle mapではなく、特徴的な情報を片っ端から入力して画像検索したほうが見つかったりします。

 

2.室内かつ設定に準じていない場所の場合

いい感じの場所が見つからなかったので飛ばします。というか、この場合はだいたい諦めます。

 

3.室外かつ設定に準じた場所の場合

ここからがいよいよgoogle mapくんとのデートタイムです。

EI-yZfZUcAExHBM

こちらです。手前の子が小学生時代に横浜に住んでいた他、奥に小さく描かれている着物の子も横浜出身です。

ということでまずは横浜を仮定して探します。

まずわかることを整理しましょう。

  1. 奥に橋が見える
  2. 手前に手すりの付いている階段がある
  3. 左側には三つ建物が並んでいるほか、柵があるためそこに段差がある
  4. よってここは坂の途中で逸れた横道である
  5. 奥に掲示板が見える

あたりがぱっと出てくる情報でしょう。ということでまずは橋に注目します。

google mapで横浜の橋を調べてみましょう。とはなりません。川が見えているならまだしも、坂の多い横浜ではそうではない橋(跨道橋)が多く存在します(川が見えていたら川から調べます)。

なので、ここは先に有名な橋から潰していきたいところですね。

ということでトリップアドバイザーさんで調べてみます。このサイトはジャンルごとに観光地をまとめてくれているため、聖地を探すのにわりと向いています。

ここで横浜の橋を調べると12件ヒットします。ここからありえないものだけ除きます。ベイブリッジや、すこしマイナーですが、鶴見つばさ橋は規模が違いすぎます。

あとは残った10件をひとつずつgoogle mapで見ていき、上に書いたような情報に一致する点を探します。見つかったのでいいですが、見つからなかった場合は神奈川県が出しているかながわの橋100選あたりを参考にすることになると思います。これならまだgoogle mapで最初から橋だけで検索してローテーションしたほうが楽かもですね。しかし、google mapでは出てこないものもあるので、このようにある程度の数をまとめてくれているサイトが見つかったらできるだけ活用したいですね。

答えだけ書くと打越橋が奥に見えている橋です。本来はストリートビューを使って細かいところも見ていくのですが、これは実はストリートビューの入れない場所なので、雰囲気で伝わってくれればいいと思います。

cd

聖地の奥の坂から見たストリートビューです。4に書いたように手前が坂になっている他、奥に掲示板があることもわかりますね。

f

地図の黒マークからの風景と考えれば、左側の建物が三つ続いているように見えることもわかります。

ということで実際に行ったときの画像がこちらです。

g

ということでここが正解と考えていいと思います。

もっと広角だったり、上が写っていなかったり、いろいろずれているのですが、そこは許してください。

 

 

4.室外かつ設定に準じていない場所の場合

h

ということでここがかなりの問題です。まず、手前に大きく移っているキャラクターは現在東京在住、島根出身、奥の着物の子は先ほど言った通り横浜です。

先に答えだけ行ってしまうとここは伊豆なのでどちらとも全く関係ないですね。

ではまず先ほどと同じように情報を羅列していきます。

  1. 緩やかな川に沿った道
  2. 周りを山に囲まれている
  3. 川にかかっている線が、おそらく農業用のパイプなので、この近くで農業を行われている(規模不明)
  4. 奥に小さく井戸が描かれている
  5. 平らで出っ張った屋根の家or車庫(一番→)がある
  6. 斜めの電線がある
  7. 真空管温水器が設置されている家がある。
  8. 川のちかくの大きな石の上に像が立っている
  9. センターラインが道路にひかれていないため、道幅はそこまで広くない

あたりが見つかりますね。4番以降はまず気づくのが大変ですね。

ということで、まずは5番です。これはかなり重要です。屋根が平らということは、雪があまり積もらない地域ということです。雪が積もる場合はこんな建築したらつぶれますからね。

次が真空管温水器なのですが、本来真空管温水器やソーラーパネルは、一番日の当たる南の方向を向けるため、これだけで実際の方角がわかりそうですが、山に囲まれている場合はそれが適応できず、谷のほうを向けます。実際向けてますね。なので何の情報にもなりません。あえて情報になるとしたら、この真空管温水器のメーカーが島根県以外に営業所があるため、地味に島根県である可能性が下がったことくらいでしょう。

ということで、島根県と豪雪地帯でないこと以外は山間部であることくらいしかわかりませんでしたね。あとはどうするかというと、ほんとに地道に調べていきます。前述の通り、観光地の川を重点的に調べながら、あとはもう日本全国適当に探し続けるだけです。この作業をずっと続けていくといずれ見つかります。数時間どころか数十時間探しても見つからないことも覚悟しましょう。そして見つかったのがここです。

f44dad857a65bc0af5e14a6354360c05

ここも自分で撮った写真はあるのですが、このストリートビューと対して変わらないので省きます。

この通り、設定に準じていない場合、情報を使って地域を絞っていき、あとはローラー作戦になります。

そのような場合に考えたいポイントは、ここまでで書かなかったものとして

  • テレビのアンテナは、パラボラアンテナならば南西方向に向け、地デジのアンテナならばその地域の近くの放送局のほうを向けます。地域ごとの放送局は調べたら出てきます。方角がわかるのは大きい他、地域が一定以上に絞れればアンテナの方向でかなりその先絞りやすくなります。
  • 山の稜線がくっきりと見えていて地域がある程度絞れている場合はPeakFinderを使うこともオススメです
  • 鉄塔が見えている場合は塔マップを参考に探すことも可能です
  • google mapを地形図モードにすると高低感がわかるため、高低差の大きい場合はこのモードがおすすめです
  • あとは地理について詳しくなるしかありませんね。雪が多く降る地域は屋根が斜めな他に消雪パイプがあったり、日本海側の海岸は砂を止める柵がついていたり……
  • 背景から自分が予想するその風景を上から見た地図を手書きしましょう。地図は上からみたものなので、一回書いてみるとかなり情報がまとまります
  • 方向が確定していないときに決めつけないようにしましょう。別に奥が北じゃないです(あたりまえのことですが、実際やってみるとかなり大事です)
  • あとはもうgoogle mapとgoogle検索を反復していくだけです。google mapでは出てこない情報が載っている地図は実は結構あるので、そのような地図も使うといいです。使ったことないですが自販機mapとかもあります。

 

5.特定困難な場合の、作品背景的な特定

一応ある程度の手法は4に書いた方法をできるだけ試していくのですが、このような場合、もっと早く見つかることが2つあります。というかこの2つは背景がどんな背景であってもかなり強いです。

 

1.その場所を知ってる

ひどいと思うかもしれませんが、ここ行ったことある!やここ近所だ!で見つかる聖地は割と多いです。

 

 2.作者の出身地やよく使われる場所

作者の出身地はわりと聖地にされたりします。あと、例えば京アニならば京都やその周辺の都道府県だったりすることが多いです。あと聖蹟桜ヶ丘はわりといろんな作品の聖地になっています(シャニマス、わたてん、fate、一週間フレンズ、耳をすませば、etc…)。

はい。どっちもひどいです。でも実際これ除くとだいたいは運ゲーです。

 

最後に

ここまで真面目に読んでいる人がどれだけいるかわかりませんが、このような行為は問題になることがあります。いえ、別にストーカーとかの話じゃないです。実は、割と元となった背景の建物などに許可を取っていない場合があります。それで特定した結果、元の建物の所有者にも、その作品自体にも迷惑がかかることがあります。最近(?)だとゆるキャン△のキャンプ場や、エロゲで問題がありました。

あと実際に訪れる(=聖地探訪)際は、地元の住民の方々にほんとに迷惑かけないようにお願いします。一般の家の写真とか撮るのは文句言われたら普通にアウトなことなので……あと行った先でバカ騒ぎしないで……ほんとに……

十二技音法を使ってみた

これはKCS AdventCalendar2019 18日目の記事です

←17日目 19日目→

どーも、まんたあにど です。

前回(13日目)はうちの子がいると人生楽しくなるよ、という趣旨の記事を書きましたが、今回は音楽班らしく音楽に関することを簡潔に書きたいと思います。

作曲というと、コード進行やスケールといったことを思い浮かべるかもしれません。よく耳にするような、現在主流でつくられている曲にはそういった技法のほかに転調やハ長調といった調が存在します。

この調に対するアンチテーゼとして挙げられた音楽の一つである十二技音法について紹介したいと思います。この方法はコード理論のように複雑なものではなく、単純明快で非常にわかりやすく、且つ簡素で実践しやすいという点で初心者にもとっつきやすいものであると思います。

この記事が何かの役に立てられれば幸いです。

背景

音楽への試みは古来から行われ、モーツァルトやベートーヴェンで有名な古典派、ワーグナーやブラームスで知られるロマン派など、歴史的に幾多もの形式が誕生した。そんな中、20世紀初頭になるとこれら調性音楽とは違う方法で作曲を試みる機運が生まれ、シェーンベルクらによって調性に基づかない音楽、「無調音楽」が生まれた。十二技音法は無調音楽への試みの中で、主にそのシェーンベルクによって提唱された技法であった。しかし、無調音楽からはいわゆる名曲が生まれず、現在でも愛好家たちによって様々な試みがなされている。

概要

そもそも十二技音法とは何ぞや、という話ですが、簡単に言えば鍵盤一オクターブ分にある白鍵と黒鍵を全部用いて曲を作るという方法です。半音も含めてドレミファソラシを好きなように全部並べて旋律を作るという感じです。背景にもある通り、調性音楽への試みが長年行われ続け、その果てに登場した音楽による作曲方法でもあるので、その雰囲気は調性音楽のそれとは全くの別物で、なんだかグチャグチャしたような不可解な印象を受けるかもしれません。このような特徴を持っているので、ゲームでいうラスボス戦やホラーな場面に利用されることがあります。例えば有名なところでは、ドラゴンクエストの『大魔王』や『悪の化身』があります。(かなりわかりやすく紹介してくれている動画があるので貼っておきます)

https://youtu.be/CilIcnF8crI

この記事でも十二技音法を用いてホラーな感じの曲をなるべく、より雰囲気が出るように作り直すことを試みたいと思います。

実践

音源は、著作権を考えないで済むため以前自分が作った曲の一部を用います。

Before

この曲を構成する音のうち、一番最後に加わってきた金属音に注目します。MIDI上では以下のように鳴っています。

アドベント1

これを十二技音法で改めます。先ほどの動画で紹介されていたドラクエの曲での使われ方を見ると、おおよそ順番に、且つ高低差をつけるように音が並べられているように見えます。これを参考にして同様に自作曲の音も順番に、且つ高低差がつくように並べていきます。他の音色とも親和するように気を付けていきます。

無題

早速聞いてみます。

After

おわかりいただけただろうか

この曲自体、他の音についてもコードや和声をあまり考えずに並べられているので、ある意味無調音楽としての特徴を元々備えていたのですが、「十二技音法」という先人たちが編み出した技術を用いたことで、微妙かもしれませんがより曲の不気味さが出たと思います。

終わりに

コードや調性、和声といった難しいと感じるであろう部分を全て取っ払って曲を作り直してみました。勿論、無調音楽だけでは作られる曲の種類がかなり限られてきますので、幅広く様々な曲を作っていきたいとなるとやはり、調性音楽を勉強していく必要があります。ただ、今回紹介した技は無調音楽だけでなく、調性音楽の旋律などにも用いることができます。適宜用いてみることで、調性音楽だけを学ぶ以上に作曲の幅が更に広がると思います。

ここまで読んで下さり、ありがとうございました。

では。

←17日目 19日目→

Node.jsの役に立つお話(主にノンブロッキングIO, 非同期処理)

これはKCS AdventCalendar2019 17日目の記事です.

はじめに

こんにちは, yapattaです.

前回は限界感ある給湯器の記事を晒してしまいましたが, 今回はちゃんと技術的な記事を書きたいと思います!!

せっかく記事を書くならたくさんの人に読んでもらいたいわけで, 皆何かしらの理由で用いるであろうNode.jsのお話です.
Node.jsは他の言語と特性が違くて理解しづらいみたいな話を, 周りからちょいちょい聞きます.
今回はそんな人をターゲットにしたNode.jsが他と違うこと(主にノンブロッキングIO)について知る記事です. 広く浅く扱うので興味を持った方は適当な詳しい記事を読んで下さい.

Agendaは,

  1. Node.jsとは
  2. シングルプロセスとシングルスレッドのお話
  3. ノンブロッキングIOのお話
  4. コールバックのお話
  5. Promiseのお話
  6. Generatorのお話
  7. async, awaitのお話

についてですー

Node.jsとは

まずNode.jsとは何かについて
公式サイトを見ると,

Node.js はスケーラブルなネットワークアプリケーションを構築するために設計された非同期型のイベント駆動の JavaScript 環境です。

みたいなことが書かれています. よくわからないですね.
これは, サーバーサイドで使えるJavaScript環境みたいな感じだと思ってもらえるといい気がします.

でも, サーバーサイドで使うには少し注意が必要です.
これから, Node.jsのちょっと特殊だなーと思うところについて話していきます.

シングルプロセスとシングルスレッドのお話

WebサーバーにもなりうるNode.jsはシングルプロセス, シングルスレッドで動きます.
これは一つのプロセスと一つのスレッドで動くという意味です(文字そのまま).
全体的なリソース消費量が少ないとか, プログラムの読み込みが最小限で抑えられるとか, いろんなメリットがある気がします.
しかし, マシンパワーを最大限使いたいとかたくさんのIOとかをさばきたい人もいるわけで, そんな人のためにクラスタリングという手法があります. 脱線しそうなのでその話はのちのちに…

では次にノンブロッキングIOの話をしたいと思います.

ノンブロッキングIOのお話

ノンブロッキングIOの前に, 大まかにイベントの処理についての話をしていきます.

まずNode.jsでは, イベント(Socketとかファイルの読み込みみたいなIOリクエスト)が発生すると即座に実行されるわけではなくイベントキューというものにとりあえず突っ込まれます. そして, イベントループでイベントが検出されてそのイベントが実行されます. イベントが完了したらそのイベントのコールバックが実行されます. コールバックというのは, イベントが終了後に処理されるものといった感じでしょうか. 金魚のフンみたいな感じです.

まあこんな感じでイベント処理が実行されるわけなのですが注意が必要です. というのもイベントが発生した後, IO処理が完了しなくてもアプリケーション側に処理が戻ってしまうのです. 実際にコードを見てみましょうか.

これはファイルを読みこんだ後にファイルの中身を出力するというコードですが,

と出力されてしまいます.

なんだこれは!こんなんじゃIO使えねえじゃねえか!と思う人もきっといると思います. 僕も最初Node.jsの特性に苦しめられました. しかし, こうすることにはそれなりに理由があるんですねえ.

じゃあ次はその理由について見てきましょう.

まず, FileIOやNetworkIOというのは処理が遅いです. また, データを外部から取り出すためデータを取得するための待ち時間もどうしてもかかってしまいます. これでは後続の処理も遅れてしまうためシングルスレッドで処理するNode.jsにとっては致命的です.

そんなわけで, ブロッキングではなくノンブロッキングIOを採用しているわけです.
ある一定時間でできる処理をできる限り増やしたいぜ!みたいな意向が伝わってきますね.

しかし, IO処理が終了する前に他の処理が実行されて欲しくない場面もあるわけでそんなときにコールバック関数というのを用います.

では次にコールバック関数について話したいと思います.

コールバックのお話

先程話したとおり, あるイベントが発生した後の処理のことです. まあ実際にはIOが完了するとコールバック処理がキューに入り, イベントループがそのキューからコールバック処理を取り出して実行するみたいですが, 簡略化のためコールバック処理はあるイベントが発生した後に行われる処理とみなします.

実際にコードを見るのが早いと思うので, 以下を見て下さい.

今回fs.readFileの第3引数に書く関数がコールバック関数というのですが, 実行結果からわかる通りファイルを読み込んでからファイルの内容が出力されていることがわかりますね.

こんな感じでコールバック関数を用いると, イベント後の処理も安心して書けるのですが注意が必要です.
というのも, イベントが複数実行されたとき入れ子がエグいことになります. 以下の例を見てみましょう. 3つのファイルを読み込んで出力させるだけなのに入れ子が深いせいで, コードがすごくわかりにくく見えてしまいます.

気持ち悪いですね. こんなコードを書きたくないと思ってしまいます.

しかし, 世の中とはうまくできているもので解決策があるんですね.

Promiseのお話

その名もPromiseです!!(でーん!!). ES2015から使えるようになりました.

イベント終了後のコールバック処理をthenに書くことでネストが深くならずにすみます. 実際にコードを見てみましょうか. 0.1秒ごとに1を足して出力するプログラムです. incrementは0.1秒経過したらresolveというコールバック関数を実行する関数です. コールバック関数の内容はthenの後に記述します. 実際に, 0.1秒ごとに1増加していくのがわかると思います.

まあこれでも少し読みづらいですが, コールバック地獄から解放されて大分コードが読みやすくなりました. 素晴らしい.

察しのいい読者は, どうせ次はasyncとawaitについての説明をするんだろ, と思うところでしょう. 実際僕もasyncとawaitのお話をするべきなのでしょうが, どうしてかセオリー通りに行きたくないものでGeneratorの話をします(え??).

Generatorのお話

Generatorの話をするにはもちろん理由がありますよ??
async, awaitの前に追加された機能ですし, Redux-Sagaで使われていますし(元々Redux-Sagaについての記事を書きたかった).

とりあえず実際にコードを見てみましょう. さっきよりも大分コードが読みやすくなりましたね. 非同期処理をやっている実感がわかないほどに.

実際にやっていることはPromiseのコードと同じになります. 0.1秒ごとに1を足しています.
yieldと書いた処理が実行されるまで次の処理が実行されなくなっているのがわかると思います. 0.1秒経ったらnumに1足された値がnumに代入されることがわかりますね.

Async, Awaitのお話

なんだかんだでasync, awaitのお話は需要があると思うので.

先程のcoにすごく似ています. async関数はawaitを含むことができ, awaitと書いた処理が実行されるまで次の処理が実行されなくなります.

まとめ

Node.jsのお話を長々としました.
Node.jsのノンブロッキングIOという特殊な性質に興味を持っていただければ幸いです.

今回は, クラスタリングとか, Node.jsがシングルスレッドで動くようになった時代背景について詳しく話せなかった(記事がさらに長くなると考えると恐ろしい…)ので, 今度時間があるときにまた記事を書きたいなーと思っております.

では, よいお年をー!!

Flutter Webはいいぞ

これはKCS AdventCalendar2019 16日目の記事です

15日目 | 17日目→

こんにちは、日吉代表に決まった直後から舐められているFastriver(@fastriver_org)です。5日目の記事もよろしくお願いします。

Flutter Webはいいぞ

表題のとおりです。いいです。とてもいいです。三田祭期間中ずっと感動していました。

まあまずはFlutterについておさらいしていきましょう。

Flutterとは?

fluter

FlutterGoogleが開発を主導しているオープンソースのクロスプラットフォームUIフレームワークです。

2015年に発表され、2018年12月にAndroid・iOS向けの1.0がリリースされました。

特徴

Dart lang

FlutterはDartを使用してアプリケーションを記述します。DartはGoogleが開発した言語で、元々はWebにおけるJavaScriptの代替として開発されていましたが、あまり広まらず(DartVMを載せられなかった)、TypeScriptと同様なAltJSとして落ち着きました。その後Googleの標準がTSになるなど消えそうな感じでしたが、Flutterが開始したことで息を吹き返し、現在は活発に開発が続いている言語です(2.7で拡張関数追加されたのがウレシイ)。TypeScriptよりもJava寄りな記法で書けます(主観)。

ネイティブコード

Xamarinと違ってVMを介さずネイティブコードにコンパイルするため、クロスプラットフォームにしては動作が速いです。サイズも普通になります。

Widget


Flutterは画面を構成するのに”Widget”を使います。ButtonやTextだけでなく、LayoutやPaddingなどもWidgetで、それらをツリーにして画面を作ります。この辺りはこのスライドが一番わかりやすかったので共有しておきましょう。またWidgetの便利たる所以は、元からモダンなデザインが用意されているということです。脳死UIでもそれっぽい感じにアプリができてしまいます(逆に言えば凝ったデザインはやりにくい?)(僕はMaterial Design信者なので問題ない)。

HotReload

アプリ開発者なら分かると思うのですが、「画面のボタンのデザインをちょっと弄りたい」「eventを差し替えたい」とかいったときにはアプリをリビルドするのに数十秒ほど待たねばなりません。UIの微妙な調節などでこんなことをやっていると非常に時間がかかってしまいます(そのためにUIはビルドしなくてもプレビューできることが多い)。しかしFlutterではHotReloadが使えます。コードを変更後リビルドしなくても、HotReloadの数秒(もっと短い?)で挙動を確認することができます。この開発体験は尋常じゃないですよ。

AndroidStudio

勿論Google謹製のサービスなのでJetBrains社の世界最強IDEを使って開発できます。素晴らしいね!(VSCodeで開発もありあり)

Flutter Web とは

Hummingbird

さて、ここまではモバイルのお話でした。しかし時は2018年12月(モバイル版の正式版と同じだね!)にWeb向けのFlutter、”Hummingbird”が発表されました。そして

・2019年5月: “Flutter for Web” テクニカルプレビュー開始(本体と名前空間は別)

・2019年9月: Flutter 1.9にて本体に統合(名前空間も同じに)

・2019年12月: Flutter 1.12にてベータ版に ←New!

はい、遂に先日Betaになりました。

特徴(Alphaの知識で語る)

 

静的ページ

ビルドするとHTMLとJSファイルが吐き出されます。Dartで書いたものをJSに変換してくれます。それだけなので(少なくともフロント側には)サーバーサイドが要りません。静的ページなので、コードを公開してもいいならGitHub Pagesで無料でURLがもらえます。開発中にローカルサーバーを立てる必要もないです。

コードの共通化

UIの部分含めほぼ全てコード共通化ができます。できないのはプラットフォーム固有の機能などくらいです。

サクサク

思った以上にサクサク動きます。アニメーションにもたつきを感じることはありません。また開発スピードも先のHotReloadが使える(割と死にやすいが)のでサックサクです。

超高速開発!!!

 

この記事を参照だ!!

この2つは三田祭期間中に開発しました(GitHubにコードもあるよ)。

動物将棋 https://doubutsu.fastriver.dev/#/

ルーレット https://roulette.fastriver.dev/#/

超便利な単語帳アプリの「クラタン」 も、数日でアプリ版からWebに移植しました。

https://clatan.fastriver.dev/#/

Web版が素早くできたおかげで 💩林檎💩に金(1万円/年)を貢ぐことなく [^1][^2]全ユーザにサービスを届けられるように[^3]なりました。感謝

現状問題点(Alphaの知識)

 

まだ正式版じゃないですが割と安定しています。しかし、未だかゆいところに手が届かない感じです。また僕はアプリの畑の人間なので他のWebとの差異はよくわかりません。

URL…

一応画面遷移時にURLをつけられるのですが、DeepLinkのように直接Linkにアクセスするなどは現状難しいです。なので普通のWebPageでなくSPAを作るのが適切だと考えたほうが良いと思います

パッケージ互換

モバイル版はもう1年近く正式版をやっているのでプラグインが割と豊富です。しかしWeb版には対応していないものも多く(公式含む)、プラグイン頼りのプロジェクトは移行に少し手間がかかりがちです。またWebでしか叩け無いライブラリ(dart:htmlとか)もあるのでややこしいです。

文字

未だに日本語の完全なサポートがされていません(本体もしてない)。デフォルトで漢字を使うと中華フォントになってしまい違和感がすごいので工夫する必要があります。またChromeだと調子いいことが多いのですが、Safariで開くと日本語含む諸々が崩れがちです。プラグインとか色々入れると対策はできます。あとキーボードの読み取り内容がブラウザに依存するらしく、KeyEventを拾おうとしてもあまりうまくいきません(つらい)。

情報の錯綜

まだ存在が発表されてから1年弱で、alpha -> betaと進んでいてしかも本体と統合したりしているので破壊的な変更が今年だけでも多いです。なので古い(半年以上前とか)サイトの内容も信用ならなかったりします。統合前のものを「Flutter for Web」統合後を「Flutter web」と言い分けているような風潮もありますが、ググって解決策が出てきても使えなかったりしてつらいです。最新のIssueとかを頑張って追いかけましょう。もう既にBetaになったので来年は落ち着いてくると思います。古い情報を抹消するためにもコミュニティ活性化していきましょう。

まとめ

いかがでしたか?

 

百聞は一見に如かず、どの畑の人もちょっと試してみてください。環境構築もWebやるならFlutter SDKをインストールするだけ(最最低限)です。

初心者向けの説明で良さげなやつ:

https://medium.com/flutter-jp/first-step-9b7f2c74fb08

RTA:(超高速開発のとこのURLと同じ)

http://nageler.hatenablog.com/entry/2019/11/29/181315

 

興味のある人が多ければ、軽くHands-On会でも開こうと思うんですがどうですか?何かしら反応してくれると嬉しいです(つよつよはお呼びでない)

 

[^1]: AppleのDeveloperには99ドルの年貢が課される。Googleは永年で25ドルだよ?Microsoft Storeは永年たった19ドルだよ?皆でUWP Developerにならないか?
[^2]: 実際のところとしてはAppleのDeveloper登録が未成年(20歳未満)だと自分のアカウントが作れないため躊躇っているということがある。18からでもよくないか?Googleで年齢聞かれたこと無いぞ?
[^3]: 世の中世知辛いので学生向けだとiOS対応しないと誰も使ってくれない。つらい。いい加減滅びないかな。

15日目 | 17日目→

おいしいカレーのつくりかた

*これはKCS AdventCalender2019 15日目の記事です*

こんにちは.アドベントカレンダー遅延常習犯,いくぴー(Twitter: @190ikp)です.
前回に引き続き書く羽目になりました.修行だと思って書いていきます.

はじめに

「おいしいカレーのつくりかた」とは何か?
曰く,「これを制するものはレポートを制す」
曰く,「これを制するものは就活を制す」
曰く,「これを制するものは設計を制す」

というわけで今日は「おいしいカレーのつくりかた」を書いていこうと思います.

必要なもの

  • 材料
  • 調理器具
  • やる気
  • 要件定義

…要件定義?

そう,私たちははじめに,「カレーとは何か?」を今一度考え,その上で今回作るカレーの要件定義をしなくてはなりません.
これがない限り,必要な材料も調理器具も,工程数によるやる気の必要量もわかりませんので,非常に重要です.

それではさっそく,グーグル先生に聞いてみましょう.
なお,我が家代々の家訓に「Googleの検索エンジンを使うべからず」とあるので,検索はDuckDuckGoで行うものとします.

curry

ちなみに「カレーとは?」は国ごとに異なるようで,グローバルな定義らしきものも「多種の香辛料を併用して食材を味付けしたもの」という,なんともふわっとした感じでした.
今回作りたいのは(日本人的に)おいしいカレーなのですが,まだ「どの国のカレー」を作るかを決めていませんでしたね.
各個人の好みによって洋食のカレー,インドカレー(これにもさらに様々な種類がある),欧風カレー等々,意見が分かれそうです.
これは先の長い戦いになりそうだぜ…

…やる気が消失したので今回はここまでとします.

 

〜(完)〜

 

 


ここから本編


 

 

というわけで

今回は,開発の下準備である,要件定義・設計の大切さについてポエムっていきたいと思います.
(本当は関数のカリー化について書いてみたかったけど各方面から飛んでくるであろうマサカリが怖い)

要件定義とは

何かしらのシステムの開発・構築を始めるとき,そこには必ず目的があると思います(こういうものが欲しい,顧客からこういう依頼をされた,etc…).
要件定義とは,この目的をはっきりさせることです.
頭でっかちなふんわりとした目的をより具体的に絞り込み,最終的にそのシステムにどういった機能をもたせるかを決めます.
この作業を怠ると,顧客も含めて開発に携わるすべての人が不幸になります.ゴールが見えないからです.

人生にゴールは定めなくてもいいと思いますが,せめて開発にはゴールを定めましょう.

設計とは

要件定義をしたら,次は設計に移ります.

設計とは,要件定義に従って具体的なシステムの構成を検討・決定することです.
この「要件定義に従って」という部分はとても重要です.
ゴールを無視して暴走し始めると歯止めが効かなくなります.こわいこわい.
もしも要件定義に無かったことが設計段階で出てきたら,もう一度要件定義に立ち返って本当に必要なのか確認してみましょう.必要であれば追加しましょう.
ただし,ひとつのシステムにあれこれ盛りすぎると無駄に精神と体力がすり減ります.
あまりにも機能マシマシになってしまう場合には,複数のシステムに分割できるかを検討しましょう.

このプロセスは,次の段階である開発に移っても同じです.
もし実際に開発してみて「これもあったほうがいいかもしれない」と思ったら,何も考えず突っ走る前に一段階前のプロセス,つまり設計に戻ってよく考えましょう.
その機能を追加したことで設計に不整合が出てしまうと,メンバー全員が毎夜シュンケルする羽目になってしまいます.

必要だと感じたら,何度でも前のプロセスに立ち返りましょう.そのほうが結果的に開発効率は上がります.

おわりに

今回の記事では,複数人のチームでの開発を前提とした感じで,要件定義・設計がとても大事であると書いてきました.
これは,実際に何かしら作ったことがある方だと身に沁みて感じたことがあると思います.
ただ,この話は別にチームでの作業に限った話ではなく,個人で何かしら作るときにも生きてくることだと思います.
個人だと飛ばしがちですが,要件定義と設計のプロセスをきちんと踏むことでより効率的に開発ができるようになるでしょう.
作り始めたはいいものの中々終わらんぞ…ということが多々ある方はぜひ参考にしてみてください.

以上,要件定義が難しい「おいしいカレー」の開発は困難を極める,という話でした.

 

←14日目 | 16日目→

ogiwaraの一年間の自習の振り返り

「オタクは隙あらば自分語り」らしいので、その慣例に従うことにします。

どちらかと言うと、自分自身の為の記録という意味合いが強いので、他の方が見て面白いかどうかはわからないです(私が何やってたか興味ある方が居れば読んでみると面白いかもしれません)。

SFCの方のアドベントカレンダーでも投稿しているので、良ければ読んでみてください。↓
最終課題で物理エンジン作ってイキった話

4月

https://twitter.com/designpatterngf/status/1117356173752033280?s=20

Penmarkアプリをリリースして間も無かったこともあり、あまり自習には時間を割けませんでした。

Atomic Design、システム設計手法の本を読んでいました。

Atomic Design: Web componentの設計手法。物質の原子、分子、有機体…という構成をまね、その構成をWeb componentでも採用したもの。
現場で役立つシステム設計の原則: そもそもオブジェクト指向とは何か、ドメイン駆動とは何か、どんなパターンがあるか、など現場で役に立つ設計手法のノウハウ本です。

5,6月

https://twitter.com/designpatterngf/status/1132616250364813312?s=20

部室の本棚に、前々から読みたかったTaPLがあったので、一念発起して読破しようと決心しました。その準備としてCoPLを二週間で読み終えました。
理数系の本を読んだことが今までなかったので、非常に苦労しながら読んでいたのを覚えています。でも各章の内容は非常に魅力的でした。
また、某君に影響されてWebGLを始めました。

CoPL: Concept of Programming Languagesの略。「プログラミング言語の基礎概念」という本。プログラムの意味論とかについて簡単に触れている。
TaPL: Types and Programming Languagesの略。れっきとした型システムの入門書。入門書とは言いつつもレベル的には一応海外の院レベルぽい?ラムダ計算と操作的意味論を元に部分型付け、多相性など実用的な話題が多いので非常にお勧めです!
型システム: プログラミングにおける型とは何か、どのようにして、「プログラム全体が正確に型付けされていたら、実行時にエラーを吐かないか」を証明するか、など。
WebGL: OpenGLのWebブラウザ版。OpenGLは低レイヤーのグラフィックスレンダリングライブラリ。

7月

https://twitter.com/designpatterngf/status/1149312784833712128?s=20

情報基礎1の最終課題として物理エンジンを作りました。それについてはSFCのアドベントカレンダーの方(上記)で記事を投稿しました。
TaPLを読み続けていましたが、25章で挫折しました。全然訳がわからなくなったので、夏休みになったら一から読み直そうと決心しました。
期末テストの時期でしたが、試験は2個しかありませんでした。SFCなんでね。

8,9月

https://twitter.com/designpatterngf/status/1175765095168671744?s=20

朝から晩まで自習の時間が取れる夏休みは最高ですね。
挫折したTaPLをもう一度一から読み直し、なんとか読み終えました。他の進捗は上に書いてある通りです。
また集合位相の本については、サークルのメンバーと一緒に輪講会を開きました。一週間で一章、というえげつない量でしたがスピードラーニングで効率よく習得できたと考えています。

10月

https://twitter.com/designpatterngf/status/1179721654567456768?s=20

TaPLの輪講会をSFCで開き、教授と院生の方二名と私で一週間で一章ずつ読んでいきました。毎回21時ごろまで付き合ってくださった教授には頭が上がりません…。
また、某君がPRMLの輪講会を始めたので、PRML上/下を買って読み始めました。一週間でテキトーーーに確率・統計の勉強を始めて機械学習の入門書としてPRMLを読み始めました。

11月

https://twitter.com/designpatterngf/status/1200756332699107328?s=20

PRML。ひたすらPRML。輪講会では一週間に一章のペースだったので。

12月

https://twitter.com/designpatterngf/status/1206115108646051842?s=20

TaPLの時のように挫折することもなく、とりあえずPRML上巻を読み終えられました。
後期の勉強を何もしていない状態で期末試験1ヶ月前になったので、一回期末試験の内容を勉強するためにPRML二週目はお預けにしました。期末試験の勉強の合間合間にTaPLとATTaPLを読みました。
ATTaPL: Advanced topics in types and programming languagesの略。 TaPLの続編と言われている。これはあまり知られていないかも?

振り返り

自習時間が沢山確保できた

SFCに転部してから、かなり自習の時間が確保できるようになりました。自習の内容的には総じて充実した一年間だったと思います。ただ、やっぱりTaPLとPRMLといったかなりヘビーな本を読むのに時間を取られましたね。

Twitterでの進捗管理

私は所謂ツイ廃で、Twitterで進捗をよく呟いてました(上記の投稿がまさしくソレですね)。簡単にメモを取れるし、アドバイスしたり褒めてくださる方もおり(非常にありがたいです)、自分自身のモチベ維持には非常に役に立ちました。
しかしながら、これはTwitterではよくあることなのですが、他人の進捗や投稿を見てしまったが故に焦燥感に駆られたり、「自分は今まで何をしていたんだ…」とショックに陥るパターンが少なからずあります。当然こういった状況は避けたいのですが…なかなか難しいものです…。

P.S. )

https://twitter.com/furikake555/status/1206419847699001344?s=20

 

ちょっとした後悔

数学系の自習をまともにはじめたのはTaPLを読み始めてからでした。いわゆる独学というやつは高2のころから行っては居ましたが、数学系の独学は自分には難しいと思い、ずっと敬遠していました。ここはもう少し早めにやるべきだったと思います。

なぁ・・・ネットワークしようや・・・

*これはKCS AdventCalender2019 14日目の記事です*

はじめに

はじめまして. KCSの時空の歪み担当,来年もJ科B2のいくぴーです.
AI・高度プログラミングコンソーシアム(AIC) というところで計算サーバの面倒をみています.

最近,ネットワークを真面目に構築するか〜という空気ができつつあるので,KCS内でネットワークのお勉強会でもやってみようかな,と考えています.
具体的な活動は年明けから行う予定なので,ここでは「何を使って勉強すればよいか」ということを書いていきます.
参考にしてみてください(参考になるとは言ってない)

書籍ですが,まずは『マスタリングTCP/IP 入門編』を読みましょう.めちゃくちゃわかりやすいです.
これを読んで大まかに基礎を学んだらCCNA(Ciscoのネットワーク技術者資格)の本を読んでもいいのですが,ほとんどの方は演習用の実機を用意するのはハードルが高いと思います.
そこで,後述するGNS3を使うことになると思うのですが,これの使い方については正直ググったほうがより新しい情報が手に入れられます.
ただ,2019年現在だと今年出版された『GNS3によるネットワーク演習ガイド』が,そこそこわかりやすく導入が書かれており良さげです.

ツール

GNS3

仮想マシンを使って仮想的なネットワーク構築ができるソフトウェアです.無料で使えます.
使い方はここに割とまとまっています(ありがたい…).
ただ,使用するにはネットワーク機器のOSが別途必要です.

Cisco IOS

Cisco製のネットワーク機器に載っているOSです.
他ベンダーのコマンドもこれに近いので,ネットワークの勉強をする人はこれを使うことが多いです.
ただ,個人が入手するにはルータ等を購入してIOSを吸い出す必要があり(ヤフオクで買え).,少々ハードルが高いです.
そこで,次に挙げるVyOSを使うといいと思います.

VyOS

オープンソースのネットワーク機器向けOSで,Linuxディストリビューションのうちの1つです.
コマンドはIOSと少々異なりますが,学習用としては十分だと思います.
ネット上に情報も充実していますし,日本語のコミュニティもあるので良いのではないでしょうか.

Linuxベースだと他にCumulus Linuxもあります.
僕としてはこちらを推したい気持ちがあります.というのも実際に一部のベンダーはCumulus Linuxが載ったネットワーク機器をリリースしているからです.
GNS3等で仮想ネットワークの構築に使いたい場合はCumulus VXを無料で使うことができます.

さいごに

今まで自分の知らなかった分野を学習する際,ハードルとなるのが

  • 何から勉強すればよいか
  • 何を使って勉強すればよいか

だと思います.用語も何も知らなくてはググることもできませんからね…
今回の記事が,ネットワーク構築の学習をする上で後者の悩みを解決する一助となれば幸いです.

あ,あとKCSでネットワークに興味ある方は,よければjournal-networkチャンネルに参加してください.よろしくお願いします.

 

←13日目 | 15日目→