一般

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

プログラミング初学者はこれを見ろ!

傲慢なタイトルでごめんなさい。

質問が来た

お花見の季節が来たのに外出を自粛させられたりなんか極寒の中雪が降ったりしていた時、質問箱に

Annotation 2020-04-01 215508

というのが届いたわけです。140字で答えるには敵が多すぎるのでここに回答したいと思います。

偉大な先人たちの記事

全くの初心者からの機械学習ロードマップ

音楽班紹介Ⅴ ~DTMと制作環境~

自己紹介

こんにちは、箇条書き好きのFastriverです。春から電気情報工学科2年になりました。新歓で特設ページを作った人です。

どうでもいいので本題に行きましょう。

対象

  • これからプログラミングを学びたい人
  • 1,2個プログラミング言語を習得して次を考えている人

つよつよはお呼びでない

何を最初に学ぶべきか?

プログラミング言語は数多あり、それぞれに特徴があります。まして初学者にはそこから自分にあったものを選ぶのは難しいでしょう。そのため私の(基本的にあてにならないと言われている)経験から選定基準をあげていこうと思います。

1. なにをしたいか

個人的にはこれが一番重要だと思ってます。目的意識があるだけでもプログラミングの継続率は十分高くなります。特になにをしようとでもなく「流行っているから」「プログラミング言語を学びたい」みたいな感じで学習に入る人は多いですが、基本で挫折するか、基本を終えてもその後何していいのか分からずやめてしまう、というケースが散見されます[独自研究?]。意識があるのは素晴らしいですが、せっかく勉強するのだから私としては楽しさを分かってもらいたいです。

Webサイト、人工知能、アプリ、ゲーム、音楽…自分の興味の方向でなにか作品を作るために勉強する、としたほうが楽しいし、やることが明確になるので進む方向を決めやすくなります。プログラミングは「道具」であり「手段」であることを忘れてはいけません。

2. 情報は豊富か、周りに経験者はいるか

メジャーな言語の良いところは情報が豊富なところです。偉大な先人たちがその疑問に対する答えを用意してくれています。ググり方については

習うよりググれ

を参照してください。

本文では色々言ってますが、周りに経験者がいるのといないのでは問題解決速度が桁違いです。(私は周りに誰もいなかったのでTwitterで人を捕まえて質問してました…)

こういった人材、経験者や仲間と出会えるのはKCSに入ることの大きな強みだと思っています。とりあえず入って損はないですよ!

あと、情報は豊富であればあるほどいいというわけではなく、初心者が入門することの多い言語などは質の低い記事による検索汚染がなされていることもあります(最近GASで似たような状況になった)。逆にマイナーな言語でも熱心なユーザーが数人いて記事をたくさん書いてくれていると情報が多く流れているということもあります。まあこの辺は初心者にはどうしようもないので気にしなくてもよいです。

3. 学習コスト

当然プログラミング言語によって習得するまでのコストは大きく違います。比較的容易なPythonから、「完全に理解した」が常に偽となるC++まで、色々言われていますが、重要なのは

  • その言語の基本文法を書けるようになるコスト
  • それを使って成果物を作るコスト

の2つです。これらのバランスで最低限の学習コストが算出されます。基本文法が簡単でもそこから成果物を作るのに多大なコストがかかるのであれば中々作品が仕上がりません。また多少難しい言語でも、それに付随するフレームワークが優秀であれば、もはや言語の理解が及んでいなくても作品制作まで進むことができます。そのため目的が決まっているのであれば、フレームワークから選ぶのも十分アリだと思います。

4. 環境構築

なんとプログラミングというのはパソコンを用意すればすぐにできるわけではなく、プログラミング言語ごとにコーディング環境、実行環境を用意せねばならないのです。C++ならコンパイラ、PHPなら仮想サーバーなどです。

Mac、Linuxを使っている人はそこまで困らないかもしれません。ただWindowsは環境構築で躓く確率が非常に高くなっています(Qiitaとかで初手 brew installしてるやつ!!! 許さんからな!!!!!)。環境は人によって異なるので、ここは経験者と一緒にやるのがよいでしょう。

環境構築を楽にする方法:

  1. Linuxを使う -> 真理(WindowsならWSLというものがあるぞ!)
  2. VisualStudio等の神IDE(統合開発環境)を使う -> 容量がすごいが楽。私はVS温室で育ちました
  3. オンラインでやる -> 簡単なものを動かすならこれが楽。

IDEとか大きいものをパソコンに入れていくと環境汚染が進みがち(いつの間にかPythonが4つくらい入ってたりする)なので最初はオンラインのサイトを使うのがいいと思います(Google Colaboratoryとか)。

考慮しなくていいこと

将来の役に立つかどうか

就職などを見据えて始める人も多いと思いますが、遠い未来を見すぎると挫折の原因になります。プログラミング言語は多種多様といえど基本は同じなので1つ習得してしまえば他の言語もすぐに習得することができます。現時点でやれそう/やりたい言語を勉強したほうが効果的です。

学ぶために必要なもの

  • パソコン(できるだけスペックの高いやつ)
  • やる気

以上!

どうやって勉強すればいいのか

さて、どのプログラミング言語を勉強するか決めたところで、どうやって学べばよいのでしょうか。

基本は書籍です。入門書はその言語の大事なところを体系的にまとめてくれているので、しっかり読めば応用が効くようになります。でも高い?図書館とかにもたくさん置いてあるので借りるといいぞ! 読みたい本が無い? KCSには技術書が多くあるし読みたい本があれば部費から買うこともできるぞ!

注意点としては、言語というのは日進月歩なので古い本は往々にして役に立たないということです。なるべく最新のを選びましょう。

プログラミング学習サイト

最近(最近でもないか?)、Progateなどオンラインで特定の言語について学習できるサイトが増えてきています。基本文法をわかりやすく、マイペースに学べるのでとてもいいと思います(私は使ったことがないので詳しくは分からないです)。ただ実際に自分で作りたいものを書かないと中々覚えられないと思うので、一通り回ったら他で実践してみましょう。

公式リファレンス

稀に公式が超有能な場合があります。その時はブログなど漁るより圧倒的に質の良い情報が手に入るので、優先的に見ましょう。ただし基本英語です。

【独断】適当な言語紹介

迷える子羊のために、私の独断で言語の紹介をしていきたいと思います。アルファベット順に並べています。情報が変だったら突っ込んでください。でも僕の悪口は言わないでください。

BASIC

読み方: べーしっく

学習コスト: 低

用途: Excel VBAとか?

あまり書いている人は見かけないが、古くからある偉大な言語。Excelの自動化とかに書ける。Visual BasicにはMicrosoftの後ろ盾があるのでライブラリが豊富。

C言語

読み方: しー

学習コスト: 中

用途: OS制作

これも古くからの言語。実行速度が速いぶん人間にとっては少し扱いづらい。殆どはこれの拡張言語であるC++を使うのかな?私はC言語から入門したが、ポインタで挫折した。入門にはあまりおすすめしない。

C++

読み方: しーぷらすぷらす, しーぷらぷら

学習コスト: 高

用途: OS制作, 競技プログラミング, グラフィック, ゲーム, マイコン, ロボットプログラミング等

C言語の進化系。使える機能が増えている。実行速度が速いので競技プログラミングや、ロボットプログラミングに用いられる。ロ技研で主に教えているのはこれだぞ!スマホアプリなんかも作れるが、道のりは険しい。

C#

読み方: しーしゃーぷ

学習コスト: 中

用途: Windowsのソフト, ゲーム(Unity), スマホアプリ(Xamarin), Web等

巨人Microsoftの主力言語。C++に名前が似ているが、中身はJavaに近い。Rxなどモダンな言語に大きく影響力を与えた機能も多い。.NET Frameworkの一員なので、すごく色々なところで使える。Unityでゲームを作るなら避けては通れない。VisualStudio IDEの恩恵を受けられるので環境構築などはとても楽。

Dart

読み方: だーと

学習コスト: 低

用途: Web(Angular), スマホアプリ(Flutter)等

ここはメジャーな言語を紹介する場では?と言われるほどマイナーな言語だが、周りのフレームワークが有能なので紹介。JavaScriptに近い言語だが、より書きやすくなっている。Googleの推進するFlutterを書くために必要な言語。書きやすくて作品もすぐに作れておすすめ!(宣伝)

HTML/CSS

読み方: えいちてぃーえむえる/しーえすえす

学習コスト: 低

用途: Webサイトのデザイン

Webサイトを作るときに必須の言語。小中高で学んだことのある人は多いと思う。ただ実際のHTML5/CSS3は書き方がほとんど違うのでご注意。厳密にはマークアップ言語と言い、プログラミング言語でないとされる。私は書けません…

HTML(Hyper Text Markup Language)はタグで画面を構築していくやつ

CSS(Cascading Style Sheets)は色とかの見た目を整えるやつです

Java

読み方: じゃば, じゃゔぁ

学習コスト: 中

用途: PCソフト, サーバー, Androidアプリ, ゲーム等

30億のデバイスで走るJava。様々なデバイスで動く。それなりの古参言語だが新しいバージョンでは機能も豊富でモダンな言語にも負けない。Androidアプリ開発にもAndroid Javaが用いられるが、別物と考えたほうがいい(古いし書き方が独特)。学習コストも高くなく他の言語との類似性も高いので、結構おすすめ。

JavaScript

読み方: じゃばすくりぷと

学習コスト: 低

用途: Webサイト, サーバー, GAS等

Javaと名前は似ているが、中身はメロンとメロンソーダくらい違う。Webをやろうとすると逃げられない。基本文法は簡単なので軽く学習するのはおすすめ。ただしそれ以上踏み込むのは非常に危険。これは中間言語である。

※中間言語 … 人間の書くプログラミング言語から機械語に翻訳するときに一度経由する言語。人間には読みづらい。

というのもJavaScriptを書きたくない先人たちは、そのために新しい言語を作ってそれをJavaScriptに翻訳するという荒業に出た。DartやTypeScript、CoffeeScriptなどがそうである。実用にはこれらを使うことをおすすめする。

Kotlin

読み方: ことりん♪

学習コスト: 中

用途: Androidアプリ, サーバー等

Android Javaを書きたくない人のための言語。世界最高峰[要出典]のIDEことIntellij IDEAの全面サポートがあり嬉しい。モダンな言語ともあり色々なテクニックが使える。これからアプリをやりたい人には非常におすすめ。Javaをやったことがある人はすぐ使えるようになると思う。私はインターン先で使ってます。

PHP

読み方: ぴーえいちぴー

学習コスト: 低

用途: Web

よくわからないと思うが「PHP: Hypertext Preprocessor」の略。サーバーサイドで動く言語で、HTMLを動的に生成することで動きのあるWebサイトを作れる。環境構築が多少面倒。去年(2019)のWeb班ではこれを中心に講習をやりました。

Python

読み方: ぱいそん, ぴーとん

学習コスト: 低

用途: 機械学習, Web, 競技プログラミング等

機械学習といえばPython。学習コストが低くanacondaやGoogle Colaboratoryなど優秀な環境も多くライブラリも豊富なので大人気。基本は速くないがライブラリがC++でチューニングされているため全体として実行速度は優秀。機械学習だけでなくWebやソフトウェアにも使えるので便利。ただ中・大規模開発には向かない(読みにくくなるので)。AI班では必然として学びます。

Ruby

読み方: るびー

学習コスト: 低

用途: Web(Ruby on Rails)とか?

日本産の言語。初心者には結構人気らしい(あまり良く知らない)。Railsは学習コスト高めなので注意[要出典]。書き方が結構独特で読めないっす…

Swift

読み方: すうぃふと

学習コスト: 中

用途: iOSアプリ, Macアプリ

林檎さんの言語。iOSアプリ開発するならこれでやったほうがいい。書きやすいと評判です(使ったこと無い)。ただし流石Apple、Windowsだと全然使えないです…

TypeScript

読み方: たいぷすくりぷと

学習コスト: 低

用途: JavaScriptの顔出すところ

MicrosoftによるAltJS。AltJSとはJavaScriptに翻訳できるためJavaScriptを書かなくて済む言語である。情報も豊富なのでJavaScriptに嫌気が指したらとりあえず試してみると良い。

 

目にしそうな言語は一通りあげてみましたが、プログラミング言語は無数にあります。頑張ってお気に入りの言語を見つけてみてください。

さいごに

  • プログラミング言語はたしかに「手段」だが、目的にしたほうがたぶん楽しいので是非プログラミングを目的にプログラミングをしてほしい
  • プログラマは基本みんなやさしいのでリアルでもTwitterでも質問はガンガンやってOK(ググって分かることはググろうね!)
  • KCS入ろう

2020年新歓特設サイトを公開しました!

新歓ページを作りました

新歓オリエンテーションが中止になるという災禍に見舞われた中、KCSで新歓用の情報発信サイトを制作、公開しました。

https://kcs1959.github.io/2020new/

ソースコードはKCSのGitHubで公開しています。

仕様

Flutter Web

未だBetaですがこれで作りました。詳細はこちらを見てください

PWA対応

ホーム画面に追加することでネイティブアプリのように動作できます。キャッシュ活用で速度もあがります

注意事項

  • とても重いです。なるべくスペックの高いデバイスで閲覧ください。
  • 推奨環境はGoogle Chrome/Chromium 動作環境は加えてSafari, Firefoxです。IE/Edgeなどでは閲覧できないのでご注意ください。
  • PCのファンがうなりだしたりスマホが熱くなったりする可能性がありますが、気にしないでください。正常です。
  • 画面サイズの変更には弱いのであんまりやらないでください
  • 稀によく文字が消えますが心の中で補ってください
  • 画像が消えることがありますが仕様です

最後に

新歓ページが少しでも良いと思ったら@fastriver_orgを褒めてあげてください。とても喜びます。

良くないと思う箇所があったらこっそり教えて下さい。修正します。

気に入らなくても悪口をあまり言わないでください、悲しくなるので

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日目→