やっちのわいわい日記

電通大に編入した元高専生の日記。日記を書きつつ編入のこととか勉強のこととか書こうと思っています。編入とかで質問があるかたは@amhflcl0514にDMくださいお

プリッカソン#8に参加のかしこま

プリッカソン#8に参加してきました

prickathon.connpass.com

今回から前回のプリッカソン(#7)で塩キャベツ先生(@siokya)が描いてくださいったバナーに変更されました

らぁらちゃんかわいい

プリッカソンとは

要するにエンジニア女児による技術イベントですが、プリッカソン自体はコンテンツが好きなら誰でもウェルカム!雑談も含めてなんでもやってみよう!みたいなスタンスで優しい会となっています

みんな友達みんなアイドルの精神ですね

実際に会場にきて違うタスクをしながらプリティーシリーズについての会話をしてる方もいてフリーダムでした

日曜開催ということもあり、開始と同時に最新話を視聴しながら実況とかしてて楽しかったです

今回も主催の @takanakahiko さんはじめ運営の方ありがとうのゆめかわ!

当日

やる気元気寝起きの状態で自己紹介 → 交流・コンテンツ鑑賞しながらもくもく開発 → 成果発表 → 懇親会

という感じの流れでした

技術領域・年齢・性別もバラバラな集まりでしたが、プリティーシリーズ好きという共通のある人たちの集まりだったので、とても居心地がよかったです

発表もARで色々やってる方・イラスト描いていた方・スマホ向けのアプリケーション・WEBアプリケーション・slack用のアプリケーションなど多種多様でめちゃくちゃおもしろかったです!

やったこと

自分は前回に引き続きキャプ画像DBの開発を行いました

普段から手をつけておりすでに公開・運用済みだったので改良をしていました

実際主目的はキャプ画像DBの宣伝(?)だった気がしないでもない気がしました (あんまりうまく説明できなかったのが後悔)

pri-image-db.site

前回の記事は↓になります

nishikino3.hatenablog.com

前回から今回までの間で

  • マスタデータ(作品やキャラ)の登録や編集
  • 画像の投稿とデータとの紐付け
  • キャラと作品での検索
  • セリフでの検索
  • ソート
  • UX改善
  • 公開
  • Twitter連携

をやっており

今回のプリッカソンでは

  • 他の方が開発している PrismDB との接続を試みるということで話数の情報を引っこ抜いて画像に情報付与
  • 話数の情報で検索
  • slackで画像投稿を通知
  • 紹介ページの作成

をしました

アプリケーションの運用・開発なので細かいところで結構時間とられがちで大変です...

つかったもの

Ruby on Rails

基本的にすべての機能はRailsで実装しました

細かいところを見ていくと

  • DBはポスグレ
  • Twtter投稿にはRedisを使って定期的に非同期処理
  • フロントはSemantic UIというCSSフレームワーク

heroku

  • デプロイが楽ちん

S3

  • ファイル保存が楽ちん

今後

とにかく今は画像のアップロード作業がだるい!!!

ので画像のアップロードだけでも楽になるような仕組みを作りたいです

ひとまず次にやろうとしているのは

  • アップロードのAPI
  • 画像を一気にアップロードするスクリプトを組む

あたりかなという感じです フロントエンドの勉強がてらいい感じのUIにしていくのもやりたいです

個人的な究極のゴールは

  • 過去作品のおもしろそうなキャプ画をすべて情報込みで登録する!
  • 最新話放送されたら自動でキャプ画像が登録される
  • イケてるUI

お願い

キャプ画像持て余してる方いたらアップロードしていただけると嬉しいです!!!

http://pri-image-db.site/images/new

現状画像が300枚もないのでtwitterでよく同じ画像をみかけます笑

あとよかったらbotのtwiterをよろしくおねがいします!

twitter.com

最後に

会場を提供してくださいったGaiaxさん・素晴らしい会を運営していただいた なかひこくんさん、ありがとうございました!!

Gaiax一番すきな株式会社です!

Elixir勉強日記4 〜パターンマッチング・制御構造編〜

引き続きElixir勉強日記を書いていきます

ほんとは毎日できるといいんですけどうまくいかないです

毎日動画投稿しているYoutuberさんはすごいな 〜とか思う今日このごろです

f:id:nishikino3:20190611145254j:plain

elixirschool.com

今回はパターンマッチングと制御構造のところをまとめてやっていきをしていきます

そろそろ勉強を進めながらなにかしら作ってみたい気持ちになってきてますね

パターンマッチング

パターンマッチングはElixirの強力な部品で、単純な値やデータ構造、果ては関数でさえもマッチすることができます。 このレッスンではパターンマッチングの使い方から見ていきます。

強そう(小並)

マッチ演算子

Elixirでは、=演算子は実際には代数学での等号に値するマッチ演算子です。このマッチ演算子を通して値を代入し、その後マッチさせることができます。マッチングに成功すると方程式の結果を返します。失敗する場合はエラーを投げます。

iex> x = 1
1

一般的にプログラミング言語=って等号よりは代入(:=)を表すことが多いですがElixirにおいては代数学における等号に値するとあるので認識が違うみたいですね

上の例だと普通に代入しているように見えます

iex> 1 = x
1
iex> 2 = x
** (MatchError) no match of right hand side value: 1

あーーね

左辺に数字があるのは経験上気持ちわるいのですが、等号と同じという役割であるとなんとなく納得ができる感じがします

マッチ演算子はコレクションでも利用できます

# リスト
iex> list = [1, 2, 3]
iex> [1, 2, 3] = list
[1, 2, 3]
iex> [] = list
** (MatchError) no match of right hand side value: [1, 2, 3]

iex> [1 | tail] = list
[1, 2, 3]
iex> tail
[2, 3]
iex> [2|_] = list
** (MatchError) no match of right hand side value: [1, 2, 3]

# タプル
iex> {:ok, value} = {:ok, "Successful!"}
{:ok, "Successful!"}
iex> value
"Successful!"
iex> {:ok, value} = {:error}
** (MatchError) no match of right hand side value: {:error}

コレクションにおいても同様に使えるところをみるとコレクションを集合って考えたら代数学的に等号っていう表現がなんとなくわかるような気がします

ピン演算子

マッチ演算子は左辺に変数が含まれている時に代入操作を行います。 この変数を再び束縛するという挙動は望ましくない場合があります。 そうした状況のために、ピン演算子(^)があります。

ピン演算子で変数を固定すると、新しく再束縛するのではなく既存の値とマッチします。

変数定義・代入したときに使うのがマッチ演算子=で、マッチするか確認するのに使うのがピン演算子なんですかね

iex> x = 1
1
iex> ^x = 2
** (MatchError) no match of right hand side value: 2
iex> {x, ^x} = {2, 1}
{2, 1}
iex> x
2

上の例はピン演算子を使うともともと1が代入されているxと2はマッチしないんですがwwwって怒られてる感じですかね

上の例は分かるピン演算子で違う値に代入しようとしてMatchErrorを出しているからな

だが下の例はどういうことだアァァァァ!!??

落ち着いて考えるならマッチ演算子でタプルの左のxに2が代入されて、ピン演算子で1を代入しようとしたけど値を変える代入なので代入をやめたっていう認識をしました

Elixir 1.2ではマップのキーや関数の節でのピン演算子がサポートされました。

iex> key = "hello"
"hello"
iex> %{^key => value} = %{"hello" => "world"}
%{"hello" => "world"}
iex> value
"world"
iex> %{^key => value} = %{:hello => "world"}
** (MatchError) no match of right hand side value: %{hello: "world"}

この例がマップのキーを文字列からタプルに変えようとしているのに気づくまで1分かかりました

iex> greeting = "Hello"
"Hello"
iex> greet = fn
...>   (^greeting, name) -> "Hi #{name}"
...>   (greeting, name) -> "#{greeting}, #{name}"
...> end
#Function<12.54118792/2 in :erl_eval.expr/5>
iex> greet.("Hello", "Sean")
"Hi Sean"
iex> greet.("Mornin'", "Sean")
"Mornin', Sean"
iex> greeting
"Hello"

ファッ

関数内のgreetingと引数をピン演算子で確認して第一引数が"Hello"だったら"Hi"を表示してそれ以外の場合はそのまま表示してるって感じか

てかしれっと関数のマッチングしてそう

実際に動かすコードでこういう書き方ってするのか私気になります

制御構造

ifとunless

ひょっとすると以前にif/2と出くわしているかもしれませんし、Rubyを使っていればunless/2をご存知でしょう。Elixirではこの2つはほとんど同じように作用しますが、言語の構成要素としてではなく、マクロとして定義されています。この実装はKernel moduleで知ることができます。

Elixirでは偽とみなされる値はnilと真理値のfalseだけだということに、留意すべきです。

falsenilのみが偽となるのは基本的にはRubyと同様の制御がされるっぽいですね

言語の構成要素としてではなくマクロとして定義されているっていうあたりは、モジュールを呼び出す必要がないってことでいいんですかね

case

複数のパターンに対してマッチする必要があるなら、case/2を使うことができます

こちらもRubyと似たような使い方ができそうです

iex> case {:ok, "Hello World"} do
...>   {:ok, result} -> result
...>   {:error} -> "Uh oh!"
...>   _ -> "Catch all"
...> end
"Hello World"

あくまでも関数型言語なので分岐した先は関数っていう感覚で書くっていうのに慣れて生きていきたいです

_変数はcase/2命令文の中に含まれる重要な要素です。これが無いと、マッチするものが見あたらない場合にエラーが発生します

Rubyでいうところのdefaultってことなんすかね

iex> case :even do
...>   :odd -> "Odd"
...> end
** (CaseClauseError) no case clause matching: :even

iex> case :even do
...>   :odd -> "Odd"
...>   _ -> "Not Odd"
...> end
"Not Odd"

どうでもいいけどcase/2の引数に定数を渡すの気持ち悪いですね

_を”他の全て”にマッチするelseと考えましょう。

case/2はパターンマッチングに依存しているため、パターンマッチングと同じルールや制限が全て適用されます。既存の変数に対してマッチさせようという場合にはピン^演算子を使わなくてはいけません

iex> pie = 3.14
3.14
iex> case "cherry pie" do
...>   ^pie -> "Not so tasty"
...>   pie -> "I bet #{pie} is tasty"
...> end
"I bet cherry pie is tasty"

この辺り覚えてないと詰みかねないですね

case/2のもう1つの素晴らしい特徴として、ガード節に対応していることがあげられます

iex> case {1, 2, 3} do
...>   {1, x, 3} when x > 0 ->
...>     "Will match"
...>   _ ->
...>     "Won't match"
...> end
"Will match"

ガード節 分岐ができて いい感じ(575)

cond

値ではなく、条件をマッチさせる必要がある時には、cond/1を使うことができます。これは他の言語でいうところのelse ifやelsifのようなものです

引数のないcase/2みたいな認識でいいんすかね

iex> cond do
...>   2 + 2 == 5 ->
...>     "This will not be true"
...>   2 * 2 == 3 ->
...>     "Nor this"
...>   1 + 1 == 2 ->
...>     "But this will"
...> end
"But this will"

caseのように、condはマッチしない場合にエラーを発生させます。これに対処するには、trueになる条件を定義すればよいです

それはそう

with

特殊形式のwith/1はネストされたcase/2文を使うような時やきれいにパイプできない状況に便利です。with/1式はキーワード, ジェネレータ, そして式から成り立っています。

ジェネレータについてはリスト内包表記のレッスンでより詳しく述べますが、今は<-の右側と左側を比べるのにパターンマッチングが使われることを知っておくだけでよいです。

with/1の簡単な例から始め、その後さらなる例を見てみましょう

なんかややこしそうなやつですね

iex> user = %{first: "Sean", last: "Callan"}
%{first: "Sean", last: "Callan"}
iex> with {:ok, first} <- Map.fetch(user, :first),
...>      {:ok, last} <- Map.fetch(user, :last),
...>      do: last <> ", " <> first
"Callan, Sean"

これってuserのマップにfirstlastのkeyがあるか確認して表示してるってことなんすかね

式がマッチに失敗した場合はマッチしない値が返されます

iex> user = %{first: "doomspork"}
%{first: "doomspork"}
iex> with {:ok, first} <- Map.fetch(user, :first),
...>      {:ok, last} <- Map.fetch(user, :last),
...>      do: last <> ", " <> first
:error

ここではMap.fetch/2の戻り値が:errorなのでそいつが返ってきてるということですね

それでは、with/1を使わない長めの例と、それをどのようにリファクタリングできるかを見てみましょう

まずはcase/2で書いた場合ですね

case Repo.insert(changeset) do
  {:ok, user} ->
    case Guardian.encode_and_sign(user, :token, claims) do
      {:ok, jwt, full_claims} ->
        important_stuff(jwt, full_claims)

      error ->
        error
    end

  error ->
    error
end

それをwith/1に置き換えてこうじゃ!

with {:ok, user} <- Repo.insert(changeset),
     {:ok, jwt, full_claims} <- Guardian.encode_and_sign(user, :token, claims),
     do: important_stuff(jwt, full_claims)

優勝!!!wwww

Elixir 1.3からはwith/1でelseを使えます

import Integer

m = %{a: 1, c: 3}

a =
  with {:ok, number} <- Map.fetch(m, :a),
    true <- is_even(number) do
      IO.puts "#{number} divided by 2 is #{div(number, 2)}"
      :even
  else
    :error ->
      IO.puts("We don't have this item in map")
      :error

    _ ->
      IO.puts("It is odd")
      :odd
  end

これはcaseのようなパターンマッチングを提供することで、エラーを扱いやすくします。渡されるのはマッチングに失敗した最初の表現式の値です。

これってwith {:ok, number} <- Map.fetch(m, :a):errorだったらエラーを表示して:errorを返してるってことか!!!

天才!www

第4回まとめ

パターンマッチング

  • =(マッチ演算子)は代入というより等号を意味している.変数の再代入は可能
  • すでに定義されている変数に関しては^(ピン演算子)で値の確認ができる(等号
  • コレクションの要素毎の代入も可能

制御構造

  • if/2unless/2カーネルモジュールが与えている機能でおおよそRubyと同じ動作をする
  • case/2もおおよそRubyと同様に動作するがマッチングしない場合はdefaultではなく_
  • case/2のマッチングにはパターンマッチングと同じ制限が適用されるため既存の変数に対してはピン演算子を使う必要がある
  • cond/1else ifと似たような動作をする
  • case/2がネストしていたりする場合にはwith/1を使うといい感じにリファクタできる場合がある(errorのハンドラーとか)

Elixir特有の要素を掘り出していくとこれ使えるのかどうか疑問に思うことがある機能がある気がしますが、今回やったあたりをスマートに使いこなせるようになりたいですね

Elixir勉強日記3 〜コレクション・Enum編〜

Elixir勉強日記第3回です

f:id:nishikino3:20190611145254j:plain

今回もElixir Schoolを引き続きやっていきます

elixirschool.com

今回は基本的なデータ構造をまとめてきいます

メソッドの説明について

初めにメソッドの説明する際の記法に関して説明します

Elixir(とその土台のErlang)において、関数や演算子の名前は2つの部分、与えられた名前とその アリティ から成ります。アリティはElixir(とErlang)のコードについて説明するときの中核となるものです。アリティは関数や演算子が取る引数の数です。名前とアリティはスラッシュで繋げられます。後ほどより詳しく扱いますが、この知識は今のところこの表記法を理解する助けになるでしょう。

要するに(メソッド名)/(数字)という風に記述されていたらそのメソッド(メソッド名)の引数の個数(数字)ということになります

この(メソッド名)には演算子が入ることもあります(正確には演算子もメソッド)

Elixirではメソッドの引数の個数が異なると違うメソッドとして認識されるので気をつけましょう

リスト

リストは値の単純なコレクションで、複数の型を含むことができます。また、一意ではない値を含むことができます:

iex> [3.14, :pie, "Apple"]
[3.14, :pie, "Apple"]

同一の型である必要がないのはrubyと類似してますね

Elixirはリストコレクションを連結リストとして実装しています。すなわちリストの長さを得るのは線形時間(O(n))の処理となります。このことから、リスト先頭への追加はほとんどの場合にリスト末尾への追加より高速です:

ほうほうつまりリスト => 線形リストなので末尾への処理より先頭の処理の方が早いということですね

iex> list = [3.14, :pie, "Apple"]
[3.14, :pie, "Apple"]
# リスト先頭への追加(高速)
iex> ["π" | list]
["π", 3.14, :pie, "Apple"]
# リスト末尾への追加(低速)
iex> list ++ ["Cherry"]
[3.14, :pie, "Apple", "Cherry"]

リストの連結

リストの連結には++/2演算子を用います

iex> [1, 2] ++ [3, 4, 1]
[1, 2, 3, 4, 1]

文字列連結の演算子<>だったり、+では無かったりするので使い分けの注意が必要ですね

リストの減算

減算に対応するために--/2演算子が用意されています。存在しない値を引いてしまっても安全です

iex> ["foo", :bar, 42] -- [42, "bar"]
["foo", :bar]

べんり

重複した値に注意してください。右辺の要素のそれぞれに対し、左辺の要素のうち初めて登場した同じ値が順次削除されます

iex> [1,2,2,3,2,3] -- [1,2,3,2]
[2, 3]

はぇ

参考: リストの減算の値のマッチには strict comparison が使われています。

なるほど

頭部 / 尾部

iex> hd [3.14, :pie, "Apple"]
3.14
iex> tl [3.14, :pie, "Apple"]
[:pie, "Apple"]

# リストを頭部と尾部に分けるのにパターンマッチングやcons演算子(|)を使うこともできます
iex> [head | tail] = [3.14, :pie, "Apple"]
[3.14, :pie, "Apple"]
iex> head
3.14
iex> tail
[:pie, "Apple"]

タプル

タプルはリストに似ていますが、各要素はメモリ上に隣接して格納されます。このため、タプルの長さを得るのは高速ですが、修正を行うのは高コストとなります。というのも、新しいタプルは全ての要素がメモリにコピーされるからです。タプルは波括弧を用いて定義されます

タプルは関数から補助的な情報を返す仕組みとしてよく利用されます。この便利さは、パターンマッチングについて扱う時により明らかになるでしょう

iex> {3.14, :pie, "Apple"}
{3.14, :pie, "Apple"}
iex> File.read("path/to/existing/file")
{:ok, "... contents ..."}
iex> File.read("path/to/unknown/file")
{:error, :enoent}

書き換えが遅いってことは定数とかに使う感じなのでしょうかね

キーワードリスト

Elixirでは、キーワードリストは最初の要素がアトムのタプルからなる特別なリストで、リストと同様の性能になります

iex> [foo: "bar", hello: "world"]
[foo: "bar", hello: "world"]
iex> [{:foo, "bar"}, {:hello, "world"}]
[foo: "bar", hello: "world"]

キーワードリストの重要性は次の3つの特徴によって強調づけられています:

  • キーはアトムです。
  • キーは順序付けされています。
  • キーの一意性は保証されません。

連想配列のkeyをタプルに限定してリストと同じように記述するとリストと同様な性能が得られるということなんでしょうかね

こうした理由から、キーワードリストは関数にオプションを渡すために非常に良く用いられます。

なるほど

マップ

Elixirではマップは”花形の”キーバリューストアで、キーワードリストとは違ってどんな型のキーも使え、順序付けされません。マップは%{}構文で定義することができます:

花形で草

iex> map = %{:foo => "bar", "hello" => :world}
%{:foo => "bar", "hello" => :world}
iex> map[:foo]
"bar"
iex> map["hello"]
:world

# 変数をマップのキーにすることができます
iex> key = "hello"
"hello"
iex> %{key => "world"}
%{"hello" => "world"}

# アトムのキーだけを含んだマップには特別な構文があります
iex> %{foo: "bar", hello: "world"}
%{foo: "bar", hello: "world"}

iex> %{foo: "bar", hello: "world"} == %{:foo => "bar", :hello => "world"}
true

# アトムのキーにアクセスするための特別な構文もあります
iex> map = %{foo: "bar", hello: "world"}
%{foo: "bar", hello: "world"}
iex> map.hello
"world"

# マップのもう一つの興味深い特性は、マップの更新のための固有の構文があることです
iex> map = %{foo: "bar", hello: "world"}
%{foo: "bar", hello: "world"}
iex> %{map | foo: "baz"}
%{foo: "baz", hello: "world"}

マップの便利構文使いたかったらなるべくアトムをキーにしとけって気がした

%忘れそう

小まとめ

  • リスト
    • 単純なデータの羅列で複数の型に対応
    • [1, 2, "hoge"]
  • タプル
    • リストに類似するが、メモリ上に隣接して格納される.タプルを得るのは早いが修正を行うとすべてコピーしなおされため遅い
    • {1, 2, "hoge"}
  • キーワードリスト
    • アトムのタプルからなる特別なリストでリスト同様の性能
    • [foo: "bar", hello: "world"]
    • [{:foo, "bar"}, {:hello, "world"}]
  • マップ
    • どんな型でもキーにできるキーバリューストア
    • %{}

Enum

コレクションを列挙していくために用いる一連のアルゴリズム

コレクションを制すぞい

Enumモジュールはおよそ70個以上の関数を含んでいます。タプルを除外した全てのコレクションは全て列挙可能です。Enumモジュールはおよそ70個以上の関数を含んでいます。前回のレッスンで学習した、タプルを除外した全てのコレクションは全て列挙可能です。

めんどうなので雑に列挙します

all?

all?を使うとき、そしてEnumの多くのケースで、コレクションの要素に適用する関数を渡します。all?の場合には、コレクション全体でこの関数はtrueと評価されなければならず、これを満たさない場合はfalseが返ります。

全部条件に合うえばtrue

any?

any?は少なくとも1つの要素がtrueと評価された場合にtrueを返します:

一つでも条件に合えばtrue

chunk_every

コレクションを小さなグループに分割する必要があるなら、恐らくchunk_every/2こそが探し求めている関数でしょう

&2で指定した長さのコレクションに分割

chunk_by

コレクションを要素数ではない何か他のものでグループにする必要がある場合には、chunk_by/2関数を使うことができます。この関数は列挙可能な値と関数を引数に取り、その関数の返り値が変わると新しいグループが始まります

iex> Enum.chunk_by(["one", "two", "three", "four", "five"], fn(x) -> String.length(x) end)
[["one", "two"], ["three"], ["four", "five"]]
iex> Enum.chunk_by(["one", "two", "three", "four", "five", "six"], fn(x) -> String.length(x) end)
[["one", "two"], ["three"], ["four", "five"], ["six"]]

指定した方法でグルーピングできる

map_every

時にコレクションをグループに別けるだけでは充分ではない場合があります。nth毎のアイテムに対して何かの処理をしたい時にはmap_every/3が有用です。これは最初の要素にかならず触れます。

# 毎回3個を飛び越えながら関数を呼び出す
iex> Enum.map_every([1, 2, 3, 4, 5, 6, 7, 8], 3, fn x -> x + 1000 end)
[1001, 2, 3, 1004, 5, 6, 1007, 8]

一部の要素に対して処理したいときに使いそう

each

新しい値を生成することなく、コレクションを反復する必要があるかもしれません。こうした場合にはeach/2を使います

iex> Enum.each(["one", "two", "three"], fn(s) -> IO.puts(s) end)
one
two
three
:ok

map

関数を各要素に適用して新しいコレクションを生み出すには、map関数に目を向けましょう

iex> Enum.map([0, 1, 2, 3], fn(x) -> x - 1 end)
[-1, 0, 1, 2]

人生で一番使いそう

min

コレクションの中で最小の(min/1)値を探します

min/2も同様ですが、コレクションが空である場合、最小値を生成するための関数を渡します

max

minとおなじ

filter

filter/2を使用するとコレクションで与えられた関数で評価して true になる要素のみを返すことができます。

絞り込むときに絶対につかう

reduce

reduce/3を用いることで、コレクションをまとめ、そこから単一の値を抽出することができます。この処理を実行するにはオプションとしてアキュムレータ(積算器。この例では10)を関数に渡しますが、アキュムレータが与えられない場合にはコレクションの最初の値が用いられます:

iex> Enum.reduce([1, 2, 3], 10, fn(x, acc) -> x + acc end)
16

iex> Enum.reduce([1, 2, 3], fn(x, acc) -> x + acc end)
6

iex> Enum.reduce(["a","b","c"], "1", fn(x,acc)-> x <> acc end)
"cba1"

コレクションを一つにまとめるのね完全に理解した

rubyだとinjectが近そう

sort

コレクションをソートするのは1つではなく、2つあるソート関数を使えば簡単です。

sort/1Erlangのterm orderingを使ってソート順序を決めるというものです

これはシンプルに昇順になります

sort/2には順序決めに使う関数を渡すことができます

# ソート関数あり
iex> Enum.sort([%{:val => 4}, %{:val => 1}], fn(x, y) -> x[:val] > y[:val] end)
[%{val: 4}, %{val: 1}]

# なし
iex> Enum.sort([%{:count => 4}, %{:count => 1}])
[%{count: 1}, %{count: 4}]

これは必要

uniq_by

uniq_by/2を使ってコレクションから重複した要素を取り除くことができます

iex> Enum.uniq_by([1, 2, 3, 2, 1, 1, 1, 1, 1], fn x -> x end)
[1, 2, 3]

uniq/1もあったぷり

紹介されてる以外に使いそうなのはこんなところでしょうか

  • uniq/1
  • reverse/1
  • empty?/1
  • join/2
  • find/2
  • reject/2
  • with_index/1

ほかのメソッドたちは↓を見れば良さそう

hexdocs.pm

第3回まとめ

  • コレクション、リスト・キーワードリスト・タプル・マップについてまとめた
  • それぞれのコレクション長所や利点なんか生かして実装したい
  • Enumモジュールのメソッドを紹介した
  • いい感じに使えるようになりたい

キングオブプリズム プリズムワールド周りの事実確認と考察

※キンプリとプリティーリズムのネタバレが多く含まれてます

スッスッスッ10話までを視聴した方は分かると思うのですが、それまではキャラ回ではそれぞれがどのような理由でプリズムショーに向かい合っているか、という内容が主題でした

しかし4章では一転して、プリティーシリーズの世界全体の仕組みに関するストーリーが主軸となりました(一応それまでちらほら伏線は張られていた)

考察したいのですが色々と事実確認をしていかないと訳わからんになったので、プリズムワールド(プリティーリズムの世界)についてまとめて見ようと思います

プリズムの使者について

RLまでの情報

プリズムの使者についてレインボーライブの時点で分かっていることは

  • プリズムワールドから来たプリズムの煌めきを世界に広めるために世界に派遣される
  • 派遣される使者は中身が同一であるが異なる姿で世界にいることができる
  • 同じ世界に同時にプリズムの使者は1人しか存在できない(正確には複数人いると力が弱まる)
  • 各世界を移動すると記憶が失われる
  • 命は永遠である
  • 別の世界で伝説のジャンプを伝えアクトを導いた(あいら、みあヘインらしき絵とともに)
  • プリズムの使者は表舞台に立つと世界中がプリズムの煌めきで溢れてしまい滅亡へと向かってしまう
  • プリティーリズムレインボーライブにはりんねジュネの中身が同じ2人のプリズムの使者が同時に存在した
  • プリティーリズムレインボーライブの世界にはりんねが現れる5年前にジュネが現れる
  • ジュネは世界を離れるはずであったが、プリズムの女神によって残ることを許された。その代償にショーができなくなる・記憶を失う等のペナルティーを背負った

以上の情報はプリティーリズムレインボーライブの1,14,43,44,50話あたりを視聴すると分かります

キンプリ10話でわかったこと

キンプリ10話で分かったことについてまとめていきます

主にG.o.d.の会話と文字列を基にしています

  • プリズムの使者は初めはソナタプログラムが使用されていた
    • ver1.01からver2.26まであった
    • このソナタプログラムプリティーリズムの世界に関して多くの功績を残してきた
  • プリズムの煌めきが弱まったため、新たな試みとしてF型(Rinne ver1.01)M型(Shine ver1.01)のプリズムの使者を作り派遣
    • M型ヒビキワタルとして表舞台に出てキングになってしまう
    • F型は暴走したM型を止めるために封印する
  • M型封印後F型ver2.01~2.06...と自己消滅を繰り返す
  • その後不要な情報を削除し、最低限の情報のみを持ったRINNE ver3.01を派遣
    • その後RINNEプログラムは少なくともver4.11まで派遣される
  • F型の見た目だけを変え、メモリを引き継いだ新しいプログラムRuis ver1.01を派遣する
    • これがキンプリの世界に現れる如月ルヰである可能性が高い

ここでひとつレインボーライブでの内容の相違点があります

プリズムの使者は別の世界に移動すると記憶が失われる

しかし少なくともプリズムワールドの使者を派遣しているG.o.d.たちのメモリが云々の会話を聞く限り、任意に記憶が操作できることが可能であることが分かります

ソナタプログラムの成果

注意:このあたりから考察が混ざりだします

先程話したソナタプログラムの成果についてまとめていきます

これはG.o.d.たちがソナタプログラムについて話している際の映像の文字列をまとめます

  • Eve Hatsune Area:0001
    • Primogenitor of the Prismshow. Contributed to the propagation of The Sparkle of the Prism.
    • ハツネイヴ... 教祖みたいな感じなんですかね
  • Mikoto Kadowaki Area:0066
    • Created new concept values through Coordination.
    • カドワキミコト... プリパラの監督に似てる気がするなぁ...
  • Kanae Yamada Area:0100
    • The invention of the Prism Space and Prism Stone. Laid the foundations to spreading The Sparkle of the Prism.
    • きっとメガネかけててCV伊藤かな恵なんだろうなって気がする
  • Cosmo Hojo Area:0256
    • Global success as fashion designer. Conceived and spread advanced Coordination.
    • コズミックの人、RL・プリパラでちらほら出てた
  • Kei Takigawa Area:0400
    • Conceived Aurora Rising. Became the top standard for Stars around the world. Contributed throughout.Lifetime to the upbringing of Stars.
    • 唐突に窓開けて叫びだしてた人
  • Aira Harune Area:0476
    • Won Prism Queen. Succeeded in Aurora Rising Dream. Provided dreams to Stars around the world.
    • ぎゃふんの人の名前
  • Mia Ageha Area:0477
    • Completed Grateful Synphonia. Spread the Prism Act worldwide.
    • いっちぶぁぁんの人の名前
  • Maria Himuro Area:4989
    • Deceased after winning the Prism Queen. Moved countless people around the world.
    • 氷室聖の母親の名前、Area4989はキンプリの世界という言及はされている(12話)

この名前は使者なのか?

あくまでもこれらの名前成果として紹介されているだけであり、プリズムの使者自身を表している可能性もあり、プリズムの使者を派遣して得られた成果としてその世界の人間を表している可能性もあると考えられます

個人的には後者であってほしい気がしています

Areaに関して

ここではArea XXXXという項目がありこれは各世界を表している可能性があります

しかしこの考えは矛盾が一つあります

Area0400 0476 0477プリティーリズムオーロラドリーム及びディアマイフューチャーと同じ世界での出来事であるためArea自体が異なる世界だとするのは安直すぎます

なので以下のこと考えられます

  • そもそもAreaは世界を表していない
  • ソナタプログラムの功績と過去作の関連がそもそもない
    • RL14話だとADとDMFは別の世界のような表現をしていた
  • Areaの数値が近いと同じような世界が生成されている(シュタインズゲート世界線のイメージ)
  • 上位2桁が世界を表していてそれ以外の数字は別のものを表している
  • 派遣された使者によってナンバリングが変わる

シャインの封印に関して

  • Shinne ver1.01ヒビキワタルを宿主として派遣、その後Rinne ver1.01によって封印される
  • キンプリの世界で一条シンに宿り、シンがプリズムショーと如月ルヰ(Ruis ver1.01)に干渉していく内にShineが目覚める
  • 「封印されていた間も様々なプリズムスターを見てきた」というセリフからヒビキワタル一条シンの間にも様々な世界で封印されたまま宿主がいた可能性が高い
  • 目覚めかけたシャインはG.o.d.の使命でキンプラでルヰに再封印される。これによりシンはジャンプができなくなる。キングカップのシンのショーの途中でルヰが封印を解除し、シンはジャンプを成功させる
    • このときルヰから羽が消滅し、その後G.o.d.とのやり取りが無くなること、シンに対する「君と同じになれたね」というセリフからプリズムの使者を破棄したと考えられる
    • 後にショーができなくなるということから、プリズムの使者ながらも世界に残ることができたジュネと同じ状況と考えらる(ワンチャン記憶が無くなっている可能性も考えた)
  • スッスッス10話のprism oneで如月ルヰのショーはキングカップのときのような完璧なショーというよりはシンへの想いをそのまま表現したものになっており、ショーを再びできるようになったのは一条シンへの恋心による心の煌めきであると考えられる

レインボーライブのリンネとジュネ

レインボーライブのリンネはレインボーライブの世界でプリズムワールドに何らかの問題が発生し記憶を失って現れました (おそらく記憶を消して派遣されたため)

この時点で既に世界にプリズムの使者はジュネという形で存在していました

しかしジュネはプリズムクイーンになるなどして表舞台に立っていたため(プリズムの使者のタブー)、世界の煌めきを奪っていました

そのためどちらが世界に残るかを懸けてデュオショーをして決闘(最終的に言い争い)をします

結果どちらが勝ったか明確にされていませんでした。ショー直後の感じだと恋愛知ってるマウントでジュネが勝ったように見えたのですが、ペアチャムはリンネの方に現れたのでどちらが勝利なのかよく分かりません。

最終的にジュネは世界から消えかけますが、プリズムの女神にプリズムの使者を破棄することで特別に世界に残ることを許されます。

そしてプリズムの使者の使命を全うするためリンネは次の世界に行ってしまうのでした(ガチ泣きした)

このジュネがプリズムの使者を破棄されることでスッスッスッ10話の冒頭で出てきたプリズムの使者のエラーリストに含まれているのだと思われます

プリズムの使者のエラーリスト

Rinne Program Error List

Case20080714 Rinne 1.96
"Meguru Kisaki" Forbbiden Love

Case 20111114 Rinne2.54
"Ameri Hosho" Love addiction

Case20140329 Rinne 3.17
"June Amou" Triangle of behind Love

Program Disposed

この20140329は現実世界でのレインボーライブ最終回の放送日時と一致しています(他は謎)(一応調べたら20111114は現実世界のオーロラドリームの要の初登場回の3,4日前)

また、どのエラーリストを眺めると、プリズムの使者と恋愛がなんらかのトラブルになっているのかと思われます

ちなみに先程のアップデートの情報から見ると、こんな感じになります

  • Rinne 1.96はシャイン封印付近のリンネ
  • Rinne 2.54は自己消滅を繰り返す時期のリンネ
  • Rinne 3.17はRLの時期の数年前に派遣されたリンネ(ジュネ)

ヒビキワタルと山田リョウ

10話を視聴していると色々疑問を抱える人物、寮長の山田リョウと山田リョウの憧れのスタァヒビキワタルについてまとめます

前述した通りヒビキワタルはシャインに宿されていて、タブーである表舞台に立っており、キングカップ付近まで活躍しています

その後G.o.d.の命令で同時に派遣されたF型プログラムであるリンネによって封印されます

そしてヒビキワタル山田リョウ曰く「近所にいたプリズムスタァ」と言うセリフから実在していたことは明らかであるに関わらず、キンプリの世界ではヒビキワタルの情報は一切存在しておらず、他の誰の記憶にも残っていません

プリティーリズムでは山田・田中という人物が多く転生(?)していることから山田リョウも同様に転生している可能性もあるのでは...などと考えたりもしています

そう考えると、ヒビキワタル山田リョウがいた世界とキンプリの世界は異なる世界で山田リョウは記憶をもったまま転生してる可能性もあります(ソナタプログラムの功績の中にあるKanae Yamadaの可能性???)

最後に

読みにくくまとまっていない文章でしたがここまで読んでくださありがとうございました

正直考察はあんまり得意じゃないのですがプリティーシリーズが好きなので事実確認をメインに進めました

まだまだルヰやシャインが何回も口にしている1000年の時や、過去作とRL・キンプリで言及されているAD・DMFは同じ世界なのか...などまだまだ分からないことが多いのです

今回の考察や確認もこうだからこうっぽいって考えで進めることが多かったので、実際に正しいとは限らないということでご了承ください

今後またなにか新しい発見や気付きがあるといいです

Elixir勉強日記2 〜基本演算編〜

Elixir勉強日記(一日ずつやるとは言っていない)第2回です

f:id:nishikino3:20190611145254j:plain

今日は演算とかのあたりから進めていこうと思います

elixirschool.com

コードを見ながらざっくり進めていきいます

インストール

MacでもLinux(Ubuntu)でもさくっとインストールして動かせました

各所で議論される型ですね

言語によって重要視したりしてなかったりするのでElixirどんな感じなのか気になりますね

整数

# 動かしてみた感じ最大値は決まっていないようです
# あと長い桁数は_で区切ることもできます。この辺はrubyと似てますね
iex> 255
255
iex> 999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999
999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999

# 2進数、8進数、16進数は組み込みで対応しています
iex> 0b0110
6
iex> 0o644
420
iex> 0x1F
31

浮動小数

# Elixirでは、浮動小数点数は少なくとも1桁の数字とその後に続く小数を必要とし、 64ビットの倍精度で、指数eに対応しています
iex> 3.14
3.14
iex> .14 # この書き方はだめらしい
** (SyntaxError) iex:2: syntax error before: '.'
iex> 1.0e-10
1.0e-10
iex>  0.000000000000000000000000000001 + 1.0 
1.0

真理値

# Elixirは真理値としてtrueとfalseを提供しています。また、falseとnil以外は真とみなされます

iex> true
true
iex> false
false

アトム

# アトムは自身の名前がそのまま値になる定数です。Rubyをご存知なら、シンボルと同義になります
iex> :foo
:foo
iex> :foo == :bar
false

# 真理値のtrueとfalseはそれぞれ、アトムの:trueと:falseでもあります。
iex> true |> is_atom
true
# ちなみに!! |> を使うと左項の値を右項の引数として扱います!これすこ!シェルのパイプみたいな感じですね
iex> :true |> is_boolean
true
iex> :true === true
true

# Elixirのモジュールの名前もまたアトムです。MyApp.MyModuleは、そのようなモジュールが宣言されていなくても有効なアトムです。
iex> is_atom(MyApp.MyModule)
true

# アトムとモジュールの名前が被るのが若干懸念される気がしますね...

# アトムは、Erlangのビルトインのものも含めたライブラリのモジュールを参照するのにも使われます。
iex> :crypto.strong_rand_bytes 3
<<23, 104, 108>>

# アトムでErlangのモジュール参照できるのすごいですがわりと名前被りそうで怖い

文字列

# 文字列はElixirではUTF-8エンコードされていて、二重引用符で囲みます
iex> "Hello"
"Hello"
iex> "dziękuję"
"dziękuję"

# 文字列は改行やエスケープシーケンスに対応しています
iex> "foo
...> bar"
"foo\nbar"
iex> "foo\nbar"
"foo\nbar"

基本的な演算

算術

# 基本的にいつも通り
iex> 2 + 2
4
iex> 2 - 1
1
iex> 2 * 5
10
iex> 10 / 5 # /は常に浮動小数点を返すので注意
2.0

# 結果が整数の割り算
iex> div(10, 5)
2
# %ではないので気をつける
iex> rem(10, 3)
1

論理

# ||と&&と!は基本的にどんな型にも対応してる
iex> -20 || true
-20
iex> false || 42
42
iex> 42 && true
true
iex> 42 && nil
nil
iex> !42
false
iex> !false
true

# このあたりはrubyと同じですね
# nil判定とかに便利そう

# 最初の引数が真偽値である必要がある演算子`and``or``not`
iex> true and 42
42
iex> false or true
true
iex> not false
true
iex> 42 and true
** (ArgumentError) argument error: 42
iex> not 42
** (ArgumentError) argument error
# はぇ〜〜〜

比較

# 基本はrubyと一緒な感じ
iex> 1 > 2
false
iex> 1 != 2
true
iex> 2 == 2
true
iex> 2 <= 3
true
iex> 2 == 2.0
true
iex> 2 === 2.0 # 整数と小数を厳密に比較
false

# 型を比較できてソートにおいて有用
# これは他の言語ではあまり見られない気がします
# number < atom < reference < function < port < pid < tuple < map < list < bitstring

iex> :hello > 999
true
iex> {:hello, :world} > [1, 2, 3]
false
# これってリストを型でまとめるようにソートできるってことですかね?

文字列への式展開

# Rubyを使っているなら、Elixirでの式展開は見覚えがあるでしょう
iex> name = "Sean"
iex> "Hello #{name}"
"Hello Sean"

# 見覚えありますねぇ

文字列の連結

# 文字列連結は<>演算子を利用します
iex> name = "Sean"
iex> "Hello " <> name
"Hello Sean"

# +じゃないのね

第2回まとめ

  • 基本的な演算や数値の扱いはrubyと似ている(値自体がインスタンスではないけど)(そもそもElixirはクラスない?)
  • / は常に小数を返す
  • 剰余算は%じゃなくてrem/2
  • アトムはrubyのシンボルとほぼ同義
  • モジュール名はアトムとして扱われている
  • 論理演算は真偽値じゃなくても扱える
  • ただしand``or``not演算子は真偽値のみ
  • 比較は小数まで厳密に比較する===演算子があったり、異なる型だと型での比較ができる
  • 文字列の式展開もrubyと同じ、文字列連結の演算子<>

基本的な演算とかはrubyと同じで馴染みそうだな〜って感じです

Erlangのモジュール使うことあるしErlangも多少は眺めたほうがいいのかな

こっちも進めてみたい感じあるので気が向いたら切り替えるかもしれません

hexdocs.pm

Elixir勉強日記 1

はじめに

Elixirを勉強していきます

ロゴの感じだと紫のイメージなんですね

f:id:nishikino3:20190611145254j:plain

以前Haskellをちょっとやって挫折したので今回は頑張りたいです

きっかけは各所バックエンドの技術でアツいらしく、どの辺が実際にアツくてどんな感じで書くのか勉強していきたいです

あとrubyの影響を大きく受けているらしいですが、関数型でrubyの影響ってどういうこっちゃ??????っていう気持ちもあって気になったのもあります

基本的にはElixirの公式ガイドに沿っていくので単純に勉強したいだけならそっち読んだ方が早いかもしれません

ブログにしてるのはなにかしらアウトプットしておきたかったからです

あと日本語のテキスト少ないからですね

Qiitaと悩んだのですが日記っぽくしたかったのでブログにしました

Elixirを書いている人のことをアルケミストって呼ぶらしくめちゃくちゃ格好いいな〜〜〜ってなってます

1回目は言語の特徴を書いていこうかなと思います

ではアルケミスト目指してはじめていきます〜〜

そもそもElixirって?

そもそもElixirってFFにエリクサーっていうHPとMPが全回復するアイテムがあったけど実際なんだろうどうゆう意味なんだろうと思って調べてみたところ、

錬金薬 万能薬

(weblioより)

みたいな意味らしいです

要するになんかすごい薬って意味なんでしょうね。

そんな錬金薬をコネコネするたちなのでElixirプログラマアルケミストalchemist:錬金術)ってことなんですかね。 かっこいい

ちなみにGoogle検索でElixirって検索すると化粧品が出てくるあたりまだまだメジャーな言語じゃない感じなんですね

Elixirの特徴

ではElixirの基本的な特徴を調べていきます!

Elixirの公式ページ(?)です

elixir-lang.jp

冒頭より抜粋

Elixirは拡張性と保守性の高いアプリケーションを構築するためにデザインされた、動的で関数型のプログラミング言語です。

Elixirは、低レイテンシで分散型のフォールトトレラントシステムや、Webや組み込みシステムの領域で成功を収めている、Erlang VMを利用します。

要するにElixirErlang VMを利用した動的な関数型言語でWebや組み込みで機能的にも書き方的にもいい感じに書けるプログラミング言語ってことなんでしょうかね。

関数型言語と言ったらLispHaskellschemeとかを触ってきましたがどれもしっくり来なくて挫折した気がします。 どの言語もこの先たくさん書いて何かを作るっていうイメージが湧かなかったのでElixirがしっくりくるといいな〜〜〜って思ってます。(Haskellあたりは圏論の勉強を少しやったのでもう少し頑張ってみたさはある)

拡張性

全てのElixirのコードは、隔離された軽量の実行スレッド(プロセスと呼ばれる)の中で動作し、メッセージを通して情報をやり取りします。

はやそう(小並感)

その軽量性により、同一のマシン内で数千のプロセスが 同時に 起動することも珍しくありません。プロセスの隔離により、各プロセスが個別にガベージコレクションされることを許容し、システムの広範に及ぶポーズを減らし、全てのマシンリソースを可能な限り効率的に使うことが出来ます。(垂直拡張)

プロセスは、同一のネットワーク内に存在する、他のマシン上で動作しているプロセスとも通信することが出来ます。これは分散型システムの基盤となり、複数のノードにまたがったシステムの構築を可能にします。(水平拡張)

え〜〜要するに

  • 垂直拡張:複数プロセスを動かす際のリソース割り当てとかの効率がすごい(小並)
  • 水平拡張:他のマシン上のプロセスとの通信ができるから並列でいろいろできる

っていう認識でいいんでしょうかね

フォールトトレランス

本番環境で動作するソフトウェアに対する避けられない真実は いつかは壊れる ということです。ネットワークやファイルシステムサードパーティのリソースを考慮するとその確度はさらに高まります。

障害に対処するために、Elixirはスーパーバイザを提供します。スーパーバイザは何かが失敗した時にシステムの構成要素をどのようにリスタートするかや、動作が保証された既知の初期状態に戻す方法を表します。

例外がちゃんとキャッチして次の動作ができるってことですかね(rubyでいうところのraiseみたいな?)

children = [
  TCP.Pool,
  {TCP.Acceptor, port: 4040}
]

Supervisor.start_link(children, strategy: :one_for_one)

関数型言語

関数型プログラミングは、保守性が高く、高速に動作し、また少ない記述量でコードを書く、というコーディングスタイルを促進します。例えば、パターンマッチングはデータを容易に分解し、その内容にアクセスすることができます。

知らなかったですねぇ...

ガードとパターンマッチングをの組み合わせは、あるコードを実行するための特定の条件を、エレガントに match, assert することを可能にします。

def drive(%User{age: age}) when age >= 16 do
  # Code that drives a car
end

drive(User.get("John Doe"))
#=> Fails if the user is under 16

ガードパターンマッチングを使うと条件分岐がエレガントに書けるらしいです

予期される様々な制約の下で、ソフトウェアが動作することを確実にするために、Elixirはこれらの特徴に強く依存します。そしてもし動作しなかったとしても心配無用です。その場合はスーパーバイザがサポートします。

スーパーバイザがいい感じにやってくれるんですね〜

拡張性とDSL(言語的な)

Elixirは拡張可能なようにデザインされています。開発者は生産性を高めるために、特定のドメイン用に言語を自然に拡張することができます。

例として、 ExUnitと呼ばれるElixirのテストフレームワーク を使った簡単なテストケースを書いてみましょう。

async: true オプションは、可能な限り多くのCPUコアを使うことで、各 test を並列に実行することを可能にします。assert はコードを内観でき、テスト失敗時に素晴らしいレポートを提供してくれます。これらの機能はElixirのマクロを利用して実現されており、あたかもそれが言語の一部であるかのように、新しい構文を追加することが可能です。

defmodule MathTest do
  use ExUnit.Case, async: true

  test "can add two numbers" do
    assert 1 + 1 == 2
  end
end

つまりテストコードを例に、コードの拡張が書きやすくて並列処理できるってこと?????

ツール

Mix

そろそろ行こうぜ三連MIX!!タイガーファイヤーサイバー(ry

Elixirは開発を容易にするための素晴らしいツールを提供します。 ビルドツールであるMix は、プロジェクトの作成、タスクの管理、テストの実行などを容易にする手段を提供します。

rubyで言うところのgemとbundlerとrakeを併せたところらしいです

IEx

IEx (Elixirの対話型シェル) のようなツールは、言語とプラットフォームの多くの側面を利用して、オートコンプリート、デバッグツール、コードの再読込、よく整形されたドキュメントを提供することができます。

この辺もrubypythonでよく使う対話型のやつですね〜〜

デバッグとか動作確認とかでよく使うのでありがたいです!!

Erlang との互換性

Erlang VM 上で動作するElixirは、HerokuやWhatsApp、Klarnaといった会社が分散型でフォールトトレラントなアプリケーションを構築するために使っている、Erlangエコシステムへの完全なアクセスを開発者に提供します。Elixirプログラマーは実行時の追加コスト無しにすべてのErlang関数を実行することができます。

まってErlangってなに

What is Erlang?

www.erlang.org

Erlang is a programming language used to build massively scalable soft real-time systems with requirements on high availability. Some of its uses are in telecoms, banking, e-commerce, computer telephony and instant messaging. Erlang's runtime system has built-in support for concurrency, distribution and fault tolerance.

---- 以下google翻訳 ----

Erlangは、高可用性が要求される、大規模にスケーラブルなソフトリアルタイムシステムを構築するために使用されるプログラミング言語です。 その用途のいくつかは、電気通信、銀行取引、電子商取引、コンピュータテレフォニー、およびインスタントメッセージングにあります。 Erlangのランタイムシステムは、並行性、分散、およびフォールトトレランスをサポートしています。

おう....??

要するにプログラミング言語なんやな

つまりrubyCで書かれてるのと同じ感覚なんですかね...?

そのノリでErlangの機能もElixirで使えるんすね〜すごい

第1回まとめ

  • Elixirという言語の概要まとめたよ
  • 並列で複数プロセスを動かすのに最適な言語だよ。つまり大規模なアクセスが想定されアプリケーションとの相性がよさそう
  • 関数型言語だけどrubyの影響を受けてるよ
  • ライブラリの管理や対話型などツール周りもrubyに近いよ

ということで次回から実際のコードを勉強していきたいと思います

しゅうかの就活

私の就活備忘録です しゅうかの就活です(私はしゅうかではありません)

高専時代からずっと就活から逃げてきましたがさすがにD進する気にはならず就職することになりました2324歳学生女児です

私の就活は11月~1月くらいの期間でした

初期

私の就活で絶対に折らない軸としてスーツを絶対に着ないというのがありました

これは建前上では、スーツを着てるかどうかで人を判断して会社に入れるかどうかを決められるのは腑に落ちないと思ったからで

本音は着るのがだるいという理由です。ただのクズです

そんな理由で思考停止で始まった就活ですが、最初はその天罰が下って苦しめられます

逆求人イベ

縁があり某就活サポート支援社の人と知り合った関係で企業の方と1対多で話せる面談イベントに参加しました

そこで知り合った企業さんや夏に参加していた面談イベントで話した企業さんあたりを受けようと考えていました。その方が手っ取り早そうだったので

就活の軸

さてその面談イベントで私は就活(で受ける企業)の軸がブレッブレのブレだったことを思い知らされます。

web業界は大小企業合わせたらよりどりみどりです

その中からどう企業を選ぶか、、、ご縁(笑)だけで受けてたらさすがに苦笑いされそうですね、私が面接官だったら苦笑いします

そのときの私はエンジニアとして成長しやすい働きやすい環境とかとってつけたような曖昧な内容で企業選びの軸を定めていました

そしてそのうち気がつくのですが、たいていのうまくいっているweb企業でその絞り込みをかけると95%くらい当てはまります

つまり企業選びの軸としての情報量がほぼ皆無ということです

企業訪問とかをする中で

そんな舐め腐った就活をする私ですが、経験やスキルに興味を持っていただいた企業さんは幾つかあって何社か実際に会社を訪ねて、エンジニアの方とお話しする機会を作っていただきました

面談では面接と違ってラフな空気で、会社の事業内容だけでなく、実際の業務内容や働き方、環境について多くの時間をとって頂いて話すことができました

そんな中で手探り状態ですが、企業選びの軸が曖昧ですが新たに定めることができました

直会社訪問してなかったら就活の軸とか全く定まらなかったな〜〜って今思います

ざっくり自分が見つけたのは、ものづくりに携わるにあたって大きなモチベーションになるものがその会社にあるかどうかという感じでした

ES

ESは5つまでにして区切ろうって決めてました

5つの理由は研究室の先生に「大学院生なら5つくらいじゃね」って言われて、だらだら就活しないようにするためです

会社訪問と面接の日程とかがごちゃごちゃになってカオスだった記憶があります

5社とかでこの有様なので、数十社とか受けてる人の自己管理力が怖すぎます

google calendarをうまく使いました

面接

特別なことはしてません。あえて気取らず自分らしくして受かったらその会社と相性がいいくらいの感覚で面接しました

結果としてこれは良かった気がします

面接の中でお互いのことを色々知ることができた気がします

ちなみに後から面接のときの態度が悪かったですと注意されたりしました

結果として

ES出した企業では第一志望とかの優劣はなかったのですが、色々な企業の方と面接して話したりする中で純粋にこの人達と働きたいと思った企業さんから内定が出たので私の就活は幕をとじることになります

一般的な就活から見たら消化不良、というかまだやることはありそうに思えるかもしれませんが、この時点でこの会社に入っておかないと後悔しそうと思えたことや、この事業に関わってみたいと思えたことや、単純に就活が疲れたになりました

この業界は転職しやすいのでそこも含めてもうゴールしてもいいかなって感じで終わりになりました

  • 受けた企業数:5
  • 会社訪問して面談した企業数:7
  • 1on1面談で話した企業数:20くらい

よかったこと

  • 逆求人イベとかで一気に企業と知り合えた
  • その流れで色々会社訪問できてどう就活を進めるか定められた
  • 企業主催の勉強会に参加して企業の技術やエンジニアの方を知ることができた
  • 面接でわりと素直な自分で話せた
  • インターンや技術イベントで会社の技術に触ることができた
  • クソザコナメクジ自己管理力なりに日程管理できた

失敗(?)

  • 間違えて文系のインターンに応募してしまい、課題の小論文をポエムにして送る → 落ちる(通ったらギャグになったから通ってほしかった)
  • 都内勤務希望なのに地方の企業のインターンに行って、志望について聞かれて??????ってなる(インターン自体はめちゃくちゃ楽しかったし、自分の糧になりました)
  • 面接前日に徹夜 → 面接遅刻 → 意識朦朧とする中で意味不明な言動を繰り返す → 落ちる
  • 「うちの会社で何がしたい?」→ ワイ「えっっっっ???(準備不足)」
  • 面接会場到着 → 「あっUberEATSですか?」→ ワイ「????????」
  • ゲーム会社の面接で面接官と好きなゲームのジャンルがそもそも違くて話が噛み合わない
  • 面接にジャージやパジャマでいってしまう
  • 「女児アニメとアイドルアニメが好きなんですね...」
  • 「プリパラが好きなんですか...ガチ目のオタクですね...」
  • Twitterのアカウント見たけどめっちゃオタクだね」