Twitterでふぁぼったものをひたすら試します

"Thanks for inventing javascript" を解読してみた

JavaScriptの気持ちになってみた
時々Swiftの話が出てくるのは気分の問題
JavaScript書いたことないので解釈間違えてそう

typeof NaN

typeof NaN

'number'

これは別に普通ではなかろうか。そうでもないのか??いやまあ名前に反してるかもしれないが。

NaN - Wikipedia

個人的にはこっちのほうが微妙↓↓

typeof typeof NaN

'string'

いいのか文字列で。いいのか。はい。
Swiftはmetatype typeで返す。

type(of: type(of: Float.nan))

Float.Type

9999999999999999

9999999999999999

10000000000000000

JavaScriptのNumberは実は64bit float。

符号部 指数部 仮数
0 10000110100 0001110000110111100100110111111000001000000000000000

これを10進数に戻すと 10000000000000000 になってしまう。

0.5 + 0.1 == 0.6 / 0.1 + 0.2 == 0.3

0.5 + 0.1 == 0.6

true

符号部 指数部 仮数
0.5 0 01111111110 0000000000000000000000000000000000000000000000000000
0.1 0 01111111011 1001100110011001100110011001100110011001100110011010
0.5+0.1 0 01111111110 0011001100110011001100110011001100110011001100110011
0.6 0 01111111110 0011001100110011001100110011001100110011001100110011
0.1 + 0.2 == 0.3

false

符号部 指数部 仮数
0.1 0 01111111011 1001100110011001100110011001100110011001100110011010
0.2 0 01111111100 1001100110011001100110011001100110011001100110011010
0.1+0.2 0 01111111101 0011001100110011001100110011001100110011001100110100
0.3 0 01111111101 0011001100110011001100110011001100110011001100110011

浮動小数点数の宿命。

Math.max() / Math.min()

Math.max()

-Infinity

Math.min()

Infinity

仕様です。

各静的メソッドの構文は次のようになっている。

Math.max([value1[,value2[, ...]]])
Math.min([value1[,value2[, ...]]])

Swiftの max(_:_:)min(_:_:) は1つ以上の引数を要するのでそもそもこんなことはできない。

加算演算子

加算演算子の処理方法はちゃんと仕様で決まっている。

以下意訳

  1. lref を左辺の評価結果とする。
  2. lvallref の参照外しの結果とする。
  3. rref を右辺の評価結果とする。
  4. rvalrref の参照外しの結果とする。
  5. lprimlval をプリミティブ化したものとする。
  6. rprimrval をプリミティブ化したものとする。
  7. lprimrprim のどちらかがStringならそれぞれをStringにして結合結果を返す。そうでなければNumberにして和を返す。

[] + [] / [] + {} / {} + []

[] + []

''

[] + {}

'[object Object]'

{} + []

0

配列の足し算は未定義っぽい。むずかしい。

'[object Object]' については ''[object Object] を足してみたのだろうなあと推測できなくはないが、 0 は厳しい。 0 + NaNNaN になるならまだわかる。

ちなみに、

{} + {}

'[object Object][object Object]'

let a = []
let o = {}
a + o

'[object Object]'

[] + {} === {} + []

true

等々となるので、 {} + []'[object Object]' を返してくれさえすれば未定義といえど辻褄が合っているように見える。気がする。

(!+[]+[]+![]).length

(!+[]+[]+![]).length

9

.length はここでは関係ない。

! + []

true

あの…なんで ! + [] が成立するんでしょうか…。 [] + !! が引数(?)を要求するのでさすがにダメ。

! + [] はさておき、 ! + [] + []true + []'true' + '''true'と考えればそれっぽい。

【追記ここから】
そういえば単項演算子+ とかいうのいましたね…

  1. expr を左辺を評価したものとする
  2. Numberに変換したものを返す

なので、 ! + []! (+ [])!0true

ご指摘ありがとうございました。
【ここまで】

論理否定演算子

  1. expr を右辺を評価したものとする。
  2. oldValueexpr をBooleanに変換したものとする。
  3. oldValuetrue なら falsefalse なら true

という処理をするので、 ![]![]!truefalse となるっぽい。じゃあなんで ! + []true なのかと聞かれるとやはりわからない。

【追記ここから】
[]true であり 0 であり、 0false 。なるほど。
【ここまで】

9+"1"

9+"1"

"91"

"1" が文字列なので文字列結合が実行される。

91 - "1"

91 - "1"

90

減算演算子の場合は lprimrprim の型にかかわらずNumberに変換した上で四則演算が実行される。

"a" などが含まれている場合、 NaN に変換されるので減算結果も NaN になる。

等価演算子

仕様上、

== の判断は

  1. 両辺が同じ型なら === の結果次第。
  2. 両辺がどちらも nullundefined だったら true
  3. NumberとStringの比較の場合はStringの方をNumberに変換したうえで == で比較。
  4. Booleanの場合はそれをNumberに変換した上で == で比較。
  5. 両辺のどちらか一方がObjectだった場合はそちらをプリミティブ化したうえで == で比較。
  6. 以上のどれにも当てはまらない場合は false

=== の処理は

  1. 両辺の型が違うなら false
  2. Numberのとき、どちらかが NaN なら false 。同じ値なら true-0+0 は同じ値とみなす)。どれでもないなら false
  3. Number以外のときは型の種類ごとに両辺が同じかどうかを判断。

となっている。

true + true + true === 3

true + true + true === 3

true

true はStringではないのでNumberに変換した上で加算する。 true1 扱い。
両辺ともに同じ数となるので結果は true

true == 1 / true === 1

true == 1

true

true == 11 == 11 === 1 と経て最後は true

true === 1

false

両辺の型が違うので false

[] == 0

[] == 0

true

空の配列 [] をプリミティブ化した時に 0 になるので 0 === 0true
ちなみに空文字列で "" == 0 した場合も true

けっきょくよくわからなかったこと

  • ! + [] がなぜOKなのか 【追記】解決した
    • ! はAdditiveExpressionということでいいんですかね
  • [] == 0true[""] == 0true["a"] == 0false なのはなぜか
    • 空文字列と同様に空配列はfalseな感じがあるらしいが、それがどこに書いてあるのか仕様が長すぎてわからない
      • 【追記】 []true00falseobjecttrue というのが原因だろうが、ここまで来るともはや何が何だかわからない。
  • Swiftで [] + [:] とやると[(key: AnyHashable, value: Any)]型になるのだが、この + はどこからきたのか

むずかしい!

参考文献

typeof

浮動小数点数ツール

max / min

加算演算子

等価演算子

Gradleメモ

またこんどGradle使う機会があったら勉強する

複数モジュール

設定例

/
┣ settings.gradle
┣ build.gradle
┣ モジュール1/
┃   ┗ build.gradle
┗ モジュール2/
    ┗ build.gradle

【settings.gradle】

rootProject.name = 'プロジェクト名'
include 'モジュール1'
include 'モジュール2'

【build.gradle】

同じ依存先同じバージョンを使いまわしたいときに

ext {
    hoge_version = 'x.y.z'

    commonDependencies = [
            hoge: "come.example:example:$hoge_version",
    ]
}

【サブモジュール/build.gradle】

dependencies {
    Map<String, String> dependencies = rootProject.ext.commonDependencies

    implementation dependencies.hoge
}

Main関数

apply plugin: 'application'
mainClassName = 'com.example.Main'

でMain関数呼べる

sourceSets

sourceSets {
    main.java.srcDirs += 'src/main/kotlin'
    test.java.srcDirs += 'src/test/kotlin'
}

Kotlinなのに src/hoge/java に置いてはつまらないとき用

dependencies

  • compile
    • 古い
    • 注: compile、provided、apk は 現在も利用可能です。 ただし、これらは Android プラグインの次期メジャー リリースでは削除されます。
  • api
  • implementation
    • This dependency is used internally, and not exposed to consumers on their own compile classpath.

jar

jar {
    from {
        configurations.compile.collect {
            if (it.name.contains('kotlin-stdlib')) {
                []
            } else {
                it.isDirectory() ? it : zipTree(it)
            }
        }
    }
}

いらないものがあれば適当に空配列を返しておく
configurations.apiconfigurations.implementation では回収してくれないので compile を使わざるを得ない(?)

参考文献

Migrate to Android Plugin for Gradle 3.0.0  |  Android Developers

技術書典4でバッグにチラシを詰めまくりました

仕事中の心境

ああ……詰めても詰めてもバッグとチラシが補充される……
まるで賽の河原じゃん……?

えっ

バッグとチラシの在庫無くなった
マジかよ!
詰め終わったやつもみんな持ってかれてる!!!

疲れはしましたが、詰めたものが全部皆さんに行き渡って、しかも戦利品でぱんぱんになっていると嬉しいものですね。
手に入れられなかった方ゴメンナサイ。

晴れると来場者数が2倍になるマジック。

戦利品

7,300円のおかいものをしました。

【お04】日経電子の本

0円

めっちゃお世話になった方々なので速攻もらってきた。
なんで新聞社さんがtry! SwiftにいらしてたりRebuild.fm公開収録してたりするんだ??というところから(個人的には)始まり、その後技術的な話題でちょくちょくバズって楽しい。

1面最下段の内輪ネタが面白かった。ご本人に読み上げていただkいやなんでもない

【う20】ニッチ技術への招待

1,000円

KuniwakさんのGitリカバリマニュアル狙い。
Kuniwakさんのお名前はGitのイベント(git challengeに参加して3位だった - S_Shimotori’s diary)の時に覚えたと思う。あれで結構Gitへの苦手意識が無くなった。

とはいってもコマンド覚えるだけじゃGitはマスターできそうにない。現状では「このコマンド打つと多分こうなるからうまくいく」という程度の理解。Gitの仕組みがどういう考え方なのかまで勉強しなくちゃなあ。

【え08】文鳥と読む労働法

200円

使われる側が法律わかってないとダメなんだなあってブラック事例を見て思ったので買った。この手の知識の出番がないことを祈る。

【え05】 Effective肉の多汁性測定

600円

前回に引き続き新刊を購入。Anovaをやるときの参考にする。
お肉は美味しいお肉を上手に焼かないと美味しくない。

【く08】 ZIP、完全に理解した

1,000円

そういえば全然知らない分野なので購入。知らない分野だけど、圧縮ファイルをメールで送るときはパスワードかけた上で別ファイルでパスワードを送り届けなくちゃいけないらしいってのは知ってる。

【く45】 大きめなAndroidアプリでの設計を考えてみる

1,000円

Androidマジでわからんので買った。GitHub - DroidKaigi/conference-app-2018: The Official Conference App for DroidKaigi 2018 Tokyoあたりが今1番無難なやり方なんだろうけど、知識がないとさっぱりわからない。

【き27】 Fast Code for Ruby

500円

Rubyのきもちになるために買った。もしRubyを書くことがあればRubyらしい書き方で書きたいし。
動的型付け言語つらい

【い14】 エウレ・テクノロギア

800円

もともとiOSタイポグラフィを狙って買ったのだが、他の章も面白そう。
かつてパンフレット制作をしていた後遺症で文字の位置どりが気になってしょうがない。

【あ03】 できるよ!中堅企業IT読本

100円 * 2冊

読み物として買った。技術情報目的というよりは情シスの気持ちになるつもり。

【け13】 「純肉」純粋培養肉

500円

将来食糧難で培養肉食べないといけないかもしれないから…… (?)
単に味の面で興味があって1冊買ってみた。というか、技術的なイメージが全然湧かなかったから買った。

【け05】 コンピュータによる旧字旧かな文書作成入門 2018増補版

0円(※ダウンロード版)

これも後遺症で組版や入力が気になって仕方ないので買った。古い文献を引用することはないと思うので、実践することはないかもだけど。

【い15】 日本語入力を作るのに必要だった本

1,000円

macOSとなればSwiftの数少ない出番だからね、知っておきたいよね。

【い15】 工場実習日記

500円

これも技術的な話が目的ではなく、工場実習の人の気持ちになって買った。
章立てからしてもうやばい。

まとめ

  • 晴れると人がめっちゃくる
  • さらにさらに知名度上がった
  • 疲れたねむい

try! Swift Tokyo 2018に参加してきた #tryswiftconf

全体的な感想

1銭も金にならなそうな話ばかりで満足度が高かった。そういう話が聞きたくて参加したんだ。

我々にはiOSDCがあるので、年に2度もお金になる話を聞いてしまうと厳しいものがある。この辺りのバランスはiOSとSwiftに特有の話かもしれない。iOS以外でSwiftをやっている方や海外からの方もいらっしゃる以上、全部のセッションを純Swift語の話にするわけにはいかないだろうけど、来年もこういう枠をいくつか用意してほしい。

どこかのDroidKaigiで見たようなバリスタさんがいらっしゃった。美味しかった。

スカラシップ制度を利用しました

当然スーパーSwift早割を速攻買ったがそれでも高いのでお願いした。来月就職を控えて後輩達ほど就職先に困っていない上、参加にホテル宿泊の手間と費用を必要としない私が制度利用をするのもどうかと思ったのだが、それでも元が高いんだもんしょうがない許して。

スポンサーはPicAppさん。
ちなみにPicAppさんはDroidKaigiでネットワークスポンサーだったので、今春はPicAppさんに支えられた春と言っても過言ではない。
DroidKaigi 2018にスタッフ参加してネットワーク環境の提供をした #droidkaigi - S_Shimotori’s diary

ありがとうございます!ありがとうございます!
後日ランチの場で色々お話させていただいた。企業様のお金でごはんをたべる用事はもうないので、学生の身分を理由に助けていただくのはこのPicAppさんが最後になりそう。今までカンファレンスチケットくれたりごはんくれたりしたみなさまありがとうございました。次は私が後輩たちのチケット代やごはん代を稼ぐ番ですが社畜にはなりたくないです。働きたくないでござる5000兆円ほしいでござる。

Qiita記事が未だ書き終わりません

私は常日頃から「Swiftを書きたいからバイトでiOSをやってきた。UIKitを触りたいとは一言も言ってないし余計に学習コストがかさむから触りたくない」と言ってきた。

それが祟ってか(?)、try! Swift参加前、後輩に
「なんでSwiftがいいんだ」
と聞かれ、
「そりゃーおめぇ、Protocol指向と列挙型があるから」
と答えたら
「似たようなの他の言語にもあるだろ」
と突っ込まれて泣いた。実際、パラダイムやデータ型が似ている言語としてScalaとKotlinとTypeScriptがあるのでSwift固有のメリットではない。でもTypeScriptだけはなんか使いづらそうだし敵じゃないな。

現在、復習を兼ねてtry! Swiftの発表の中からいくつか引用しつつSwiftの列挙型の強さの理由をまとめたQiita記事を書いている。できればどこかで発表したく思う。しかし書き終わらない。tarunonさんの発表]にあった存在型に関連して全称型を引用しようとして、型システム入門をやっつけなければならなくなった。orakaroさん発表の変位については、すでにその手の資料がたくさんあるので全称型ほどではない。
ともかく、他の言語と全く変わりませ〜ん(笑)ってことはないようなので安心して書いてる。がんばる。

「Swift の値型を極める powered by SWIFT QUEST」のアシスタントをしました

Open Source Swift Workshopにしようかどうか迷っているうちに申し込み自体を忘れた。

のだが、koherさんがSwift の値型を極める powered by SWIFT QUESTのアシスタントを募集していたのでしゅっと応募。
セーフ!セーフです!

いきなりのアシスタント参戦だったのでぐだぐだになってしまって申し訳なかった。

try! Swift Tokyo After talksに参加しませんでした

3月6日のGK627便で鹿児島への卒業旅行に向かったので不参加。

www3.nhk.or.jp

自宅→成田空港第2ターミナルポケモンストア→第3ターミナル搭乗ゲート前→東京駅→軽井沢北口1泊→草津1泊→自宅
をやった。ちょうど草津は雪だったので「火山灰が降ってきた!」ってはしゃいだ。悲しかった。

DroidKaigi 2018にスタッフ参加してネットワーク環境の提供をした #droidkaigi

もう3回目だよ

DroidKaigi 2016のスタッフをやったはなし - S_Shimotori’s diary
DroidKaigi直前のCONBUさんにお邪魔してきた - S_Shimotori’s diary
3週連続で西新宿に行ってきた #tryswiftconf #droidkaigi #落し物 - S_Shimotori’s diary

なぜ参加したの

  • 2016が大学を借りての開催で、会場案内くらいならできそうだったから
  • その後は惰性 スタッフを辞める理由はなかったから
  • 私以外のスタッフがAndroid開発のプロ、つよい
    • わたしはSwiftを書きたいので仕方なくiOSやってる(バイト辞めたのでそれすらわからなくなった)
  • iOSDCやtry! Swiftのコアスタッフをやろうものなら聞きたいセッションを全部聞くのは難しいだろうから、ここは専門分野を外してAndroidのスタッフをやるのがいいと思ったから
  • 大学学園祭とはまた違った環境と規模で興味深いから
  • ネットワークの勉強のため

学園祭実行委員会ではネットワーク担当という名でWeb屋(PHPer)をやっていたので名前詐欺だったが、今回は本当にネットワーク環境の用意をやったのでマジネットワーク担当。

ネットワークスポンサーはPicAppさん、
技術協力はCONBUさんとブロードバンドタワーさんとさくらインターネットさんでした!!!!!!

CONBUさんといっしょにネットワーク設営

CONBU - COnference Network BUilders :: ホーム

ネットワークチームに首を突っ込むのは、ホットステージにお邪魔したDroidKaigi 2017当日飛び入り参加したiOSDC Japan2017に続いて3回目。
今回はSWやAPやケーブルの配置を決めた!それ以上の仕事は修論が爆発してできなかったので次の機会に。

いただいた質問

ヒートマップってどうやって出してるの?

アクセスポイント→Wireless LAN Controller→Zabbix→(キャッシュ)→JavaScript描画

要するにヒートマップは
🙅 人の位置
🙆 アクセスポイントごとの端末接続数
を表したもの

下図の○がアクセスポイントの位置
WLCとZabbixはさくらのクラウド上で運用。CONBUさんが鯖(物理)を持ち込んでやっていた頃、鯖が壊れてどうしようもなくなった事件があったらしい。リバースプロキシがいるのはヒートマップ等のAPIを扱うため

f:id:S_Shimotori:20180211123952p:plain

f:id:S_Shimotori:20180211130424p:plain

やはりヒートマップを表示させておくとみなさんが興味を持ってくださるのでいいね
なんたってセッション〜休憩の移動でヒートマップのようすが刻々と変わってくからね

どんな機材使ってるの?

Ciscoググるとやり方が出てくるからよい
物理鯖ではなくクラウドなので誰でも使える親切設計
pfsenseには誰でも持ってるmacbookを使おうとしたがダメだった

アクセスポイントの置き場所はどうやって決めたの?

部屋の定員(200人とか)を50端末/台で割った数
……から1を引いた数を各部屋に散らした(機材の数が厳しかったため)

あとは会場や人の動線との相談
転ばないようにLANケーブルを這わせ、電源のあるところにPoEスイッチを置き、参加者の方やビデオ撮影に邪魔にならない位置にAPを置く

APあたりの接続数は50端末で見ておけばいいかな?という話だったのだが、上手に配置できなかったりAPの向きがイマイチ(届く範囲は正面180度とのコト)だったりして、結局1台に150端末繋がっていることもあった

ちなみに:
狭いスペースにたくさんの人と端末が集まっているということは、つよいAPに狭い範囲をカバーさせなければならないということである
場所を移動したら接続先のAPを変えて欲しいので……

  • APを置く台として譜面台を採用し、あまり遠くまで飛ばないよう高さを低くする
  • 通信速度が一定値を下回ったら接続を切る設定をしておく

1日目遅かったんだけど??

  • AP1台に最大150台繋がってて厳しかった
    • 物理的な位置の問題
    • 設定の問題??
  • pfsenseを動かしていた機材のスペックがipsecの暗号化処理には厳しかった

ので、2日目は

  • 一部のAPの物理的な位置をずらした
  • 一部のAPの高さを高くした
  • pfsenseの機材をいいやつにした

などなどで対応した

会場側pfsense〜クラウド側pfsenseの間は、厚い札束でなぐったり工事したりする領域なので、速くするにも限界はある

まとめ

まだ修行が足りぬ〜〜

CONBUさんはメンバーを募集していらっしゃるしDroidKaigi側のネットワーク人材も足りてないので誰か一緒にやろう

技術書典3でもお手伝いをした

前作: 技術書典2に初参加した - S_Shimotori’s diary

わたし「技術書典3やるんだ、また混雑するんだろうな」
わたし「🐑さん、当日の人手は十分に集められたのかなあ」
わたし「なんちゃって」

🐑「22日暇ですか」

わたし「出、出〜!」

わたし「ていうか22日雨じゃん!!!!!!!どうかしてやがるぜ!!!」

10月は雨季だからイベント降水確率は体感で50%くらい。10月に何度歴史を繰り返してもどうせ雨だから諦めろ。でもそこで台風クジをひくのはすごい。

イベント当日のスタッフの必需品

  • ショルダーバッグ OR ウェストポーチ …マニュアルやパンフレットやPCを入れるなら前者
  • モバイルバッテリー AND ケーブル …ツイッターとソシャゲをし続けるよりは消費しないので、普段より電池の持ちがいい
  • ハサミ AND カッター …必要な時に限って手元にない
  • 軍手 …すぐ怪我する
  • タオル …雨だもの
  • 予備の靴下 …濡れると不快
  • 蛍光ペン …地図入りの案内のビラに道順を書き込んで渡す
  • 飲み物 …人権
  • ウイダーinゼリーみたいなパウチ …疲労のあまり固形物が食べられない場合がある
  • 足用カイロ …会場設備によっては寒い
  • 野菜ジュース …栄養バランス補正
  • 立ち仕事に耐久性のある足 …エンジニアが失ったもの
  • 強い腰 …すでに破壊されている人は諦めるしかない
  • 強い腕 …腕が短く体格のない人間にはあっても無意味

技術書典は1日開催で会場も小さいので、蛍光ペンウイダーinゼリーと野菜ジュースはいらないし、モバイルバッテリーの出番もなかった。カイロも靴下も外のシフトがほとんどなかったから出番なし。

入場待ち問題

前回の技術書典2では雨天のため屋根のない場所にお待ちいただくことになってしまった。

blog.techbookfest.org

blog.techbookfest.org

午前中は外に出なかったのでわからないが、4Fがあったりそもそもそんなに混まなかったりで去年より快適だったと思う。特に4Fは落ち着いて立ち読みできたと思うし、人混みが苦手な人には特におすすめ。

そんなに混まなかったといっても、お昼頃は身動きできなくて大変だった。そして雨にも関わらずさっと完売をキメる人気サークルの皆様。

戦利品

今回(というかイベントのたびにだけど)疲れていたのでこれだけ。もうちょっと深呼吸していろいろ目を通せばよかった。

真面目本として技術季報と公開鍵暗号、ちょっとネタ本として肉とマリオを買った。(公開鍵暗号は売り切れてたので厳密には0円でQRコードを取得)

もちろん肉もマリオもガチでネタに走っているので、中は文字やグラフや図解でびっしり。読んでてわくわく。

Anova、ブラックフライデーとか型落ちとかで安く買える場合があるという情報を教えてもらった。

まとめ

結構大学の知り合い来ててビビる。

#iOSDC でも #orecon_ios でも #iOSDCRC でも発表してしまった感想とか

なぜiOSDCで発表したのか
???「チケットタダで欲しかったし…学生のうちにカンファレンス級で発表したかったし……」

なぜ俺コンで発表したのか
???「@tarappoさんが是非って言ってくれて嬉しかったから…」

なぜReject Conferenceでも発表したのか
???「みんなの応募の勢いが悪かったからいいかなって」

なぜそんなに発表したのか
???「勉強会駆動勉強というのがあってですね、勉強会で発表するために必死に資料を読むんですよ」

自重しろ
???「この3種の発表資料を生み出すのにまた修論進捗を犠牲にしたのでもうだめです(人生が)」

iOSDC JAPAN 2017「ARC vs. GC? ARC in GC?」

GCについて何も知らないなあと思ったので発表した。正直この3回の中では一番炎上危険度が高く、発表していて怖かった。
Rustのリファレンスを読んだところまではいいけど、Cycloneの環境構築のページを読んだところで正直やる気が削がれた。興味がある人は是非Cyclone先輩に挑戦してみてほしい。

それから、特にC/C++/Cyclone/Rustはガベージをコレクションするというよりぶら下がりポインタの対処話になってしまうので、どう頭の中で整理したものかめっちゃ混乱した。

speakerdeck.com

俺コン「今こそテストの気持ちを考える」

あまりに社会人のみなさんが懇親会で「テスト書いてません」とおっしゃるので喧嘩を売りにいった。なのでこれも発表していて怖かった。実際にこれを聞いてくださった方は、わざわざ聞きにきてくださるだけあってさすがにテストは書いているようだった。

speakerdeck.com

テスト書いてない問題はもちろん、そもそもテストとはなんなのかという疑問を出発点にテストを調べ始めた。したがってこの15分の話は調べたことのほんの一部にしか過ぎないし、もちろん調べ終わっていない。JUnit3→4移行話とかXCTest内部実装とか早急に調べたいのだがうわー修論うわーうわーうわー。

github.com

Reject Conference「郵便屋さんの演算子

Swiftのガイドの演算子の文法の箇所を見て、何書いてあんのかわからん!となったのがきっかけ。Qiitaを調べても、演算子定義の方法は書いてあっても使える文字の話の記事はなく。
マジで何が書いてあるのかわからないのでしばらく読まずに放置していたが、技術書典2でUnicodeポスターを買ったのをきっかけに気合いで読んだ。ついでにちょっとだけUnicodeに詳しくなった。ちょっとだけ。

speakerdeck.com

qiita.com

発表してみて

  • リジェクト分はOtemachi.swiftとかiOS Test NightとかSwift Tweetでやるしかないかなあと思っていたが、結局iOSDC関連でだいぶ片付いた。ありがとうございました。
  • 勉強会駆動勉強により、GCとテストとUnicodeの知識がちょっとついた。
  • 自ら発表することにより、懇親会で来てくださった方の側から話しかけてくださったのでコミュ障的には楽だった。
  • 多少顔を覚えてもらったかなあ。Swift TweetやOtemachi.swiftで発表するなどしたのもあったと思う。
  • 今の実力では、リファレンスに書いてあることや理論をお伝えするのが限界。ベストプラクティスを共有するには経験値が皆無で無理。
  • 修論つらい
    • 結局俺コンとリジェクトコン2日目をキャンセルごめんなさい

今後に向けて

  • 引き続きテストについては調べていく所存。
    • XCTestの内部実装のうち、XCTAssertシリーズは近いうちに共有したい。
    • JUnit3→4問題については、Javaアノテーションの仕様も勉強しないといけないので面倒臭いなあ頑張りまーす
  • GCについてはとりあえず一旦終わり。C/C++/Rustの勉強はまだ足りないからいずれやるかも。アルゴリズムを考える脳みそはないので専門家にお任せしたい
  • 演算子は実用的でないのでもういい。Unicodeは…何か読み物を読むくらいなら
  • ベストプラクティスというか実際の業務やOSSで役立つ手法というか、そういうのを共有できるようになりたいですね
  • しゅ〜〜〜うろ〜〜んしゅうろんしゅうろ〜〜〜ん修論〜〜〜〜〜〜〜〜
    • 就活と学位論文は人間の体に毒なので即刻やめるべき
    • 脳内に「学位論文」というラベルの貼られたタスクがある、それだけで猛毒
    • とりあえず勉強会からは冬眠