"Thanks for inventing javascript" を解読してみた
JavaScriptの気持ちになってみた
時々Swiftの話が出てくるのは気分の問題
JavaScript書いたことないので解釈間違えてそう
Thanks for inventing #javascript! ;-) pic.twitter.com/NISVQTALWB
— Claudio De Sio (@cdesio) June 30, 2018
typeof NaN
typeof NaN
→ 'number'
これは別に普通ではなかろうか。そうでもないのか??いやまあ名前に反してるかもしれないが。
個人的にはこっちのほうが微妙↓↓
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つ以上の引数を要するのでそもそもこんなことはできない。
加算演算子
加算演算子の処理方法はちゃんと仕様で決まっている。
以下意訳
lref
を左辺の評価結果とする。lval
をlref
の参照外しの結果とする。rref
を右辺の評価結果とする。rval
をrref
の参照外しの結果とする。lprim
をlval
をプリミティブ化したものとする。rprim
をrval
をプリミティブ化したものとする。lprim
とrprim
のどちらかがStringならそれぞれをStringにして結合結果を返す。そうでなければNumberにして和を返す。
[] + []
/ [] + {}
/ {} + []
[] + []
→ ''
[] + {}
→ '[object Object]'
{} + []
→ 0
配列の足し算は未定義っぽい。むずかしい。
'[object Object]'
については ''
と [object Object]
を足してみたのだろうなあと推測できなくはないが、 0
は厳しい。 0 + NaN
で NaN
になるならまだわかる。
ちなみに、
{} + {}
→ '[object Object][object Object]'
let a = [] let o = {} a + o
→ '[object Object]'
[] + {} === {} + []
→ true
等々となるので、 {} + []
が '[object Object]'
を返してくれさえすれば未定義といえど辻褄が合っているように見える。気がする。
(!+[]+[]+![]).length
(!+[]+[]+![]).length
→ 9
.length
はここでは関係ない。
! + []
→ true
あの…なんで ! + []
が成立するんでしょうか…。 [] + !
は !
が引数(?)を要求するのでさすがにダメ。
! + []
はさておき、! + [] + []
は true + []
→ 'true' + ''
→ 'true'
と考えればそれっぽい。
【追記ここから】
そういえば単項演算子に +
とかいうのいましたね…
expr
を左辺を評価したものとする- Numberに変換したものを返す
なので、 ! + []
→ ! (+ [])
→ !0
→ true
。
ご指摘ありがとうございました。
【ここまで】
expr
を右辺を評価したものとする。oldValue
をexpr
をBooleanに変換したものとする。oldValue
がtrue
ならfalse
、false
ならtrue
。
という処理をするので、 ![]
は ![]
→ !true
→ false
となるっぽい。じゃあなんで ! + []
が true
なのかと聞かれるとやはりわからない。
【追記ここから】
[]
は true
であり 0
であり、 0
は false
。なるほど。
【ここまで】
9+"1"
9+"1"
→ "91"
"1" が文字列なので文字列結合が実行される。
91 - "1"
91 - "1"
→ 90
減算演算子の場合は lprim
と rprim
の型にかかわらずNumberに変換した上で四則演算が実行される。
"a"
などが含まれている場合、 NaN
に変換されるので減算結果も NaN
になる。
等価演算子
仕様上、
==
の判断は
- 両辺が同じ型なら
===
の結果次第。 - 両辺がどちらも
null
かundefined
だったらtrue
。 - NumberとStringの比較の場合はStringの方をNumberに変換したうえで
==
で比較。 - Booleanの場合はそれをNumberに変換した上で
==
で比較。 - 両辺のどちらか一方がObjectだった場合はそちらをプリミティブ化したうえで
==
で比較。 - 以上のどれにも当てはまらない場合は
false
。
===
の処理は
- 両辺の型が違うなら
false
。 - Numberのとき、どちらかが
NaN
ならfalse
。同じ値ならtrue
(-0
と+0
は同じ値とみなす)。どれでもないならfalse
。 - Number以外のときは型の種類ごとに両辺が同じかどうかを判断。
となっている。
true + true + true === 3
true + true + true === 3
→ true
true
はStringではないのでNumberに変換した上で加算する。 true
は 1
扱い。
両辺ともに同じ数となるので結果は true
。
true == 1
/ true === 1
true == 1
→ true
true == 1
→ 1 == 1
→ 1 === 1
と経て最後は true
。
true === 1
→ false
両辺の型が違うので false
。
[] == 0
[] == 0
→ true
空の配列 []
をプリミティブ化した時に 0
になるので 0 === 0
で true
。
ちなみに空文字列で "" == 0
した場合も true
。
けっきょくよくわからなかったこと
【追記】解決した! + []
がなぜOKなのか!
はAdditiveExpressionということでいいんですかね
[] == 0
がtrue
で[""] == 0
がtrue
で["a"] == 0
がfalse
なのはなぜか- 空文字列と同様に空配列はfalseな感じがあるらしいが、それがどこに書いてあるのか仕様が長すぎてわからない
- 【追記】
[]
がtrue
で0
で0
がfalse
でobject
がtrue
というのが原因だろうが、ここまで来るともはや何が何だかわからない。
- 【追記】
- 空文字列と同様に空配列はfalseな感じがあるらしいが、それがどこに書いてあるのか仕様が長すぎてわからない
- Swiftで
[] + [:]
とやると[(key: AnyHashable, value: Any)]型になるのだが、この+
はどこからきたのか
むずかしい!
参考文献
typeof
- typeof 演算子 - JavaScript | MDN
- Types — The Swift Programming Language (Swift 4.2)
- type(of:) - Swift Standard Library | Apple Developer Documentation
浮動小数点数ツール
max
/ min
- ECMAScript® 2018 Language Specification
- Math.max() - JavaScript | MDN
- Math.min() - JavaScript | MDN
- max(_:_:) - Swift Standard Library | Apple Developer Documentation
- min(_:_:) - Swift Standard Library | Apple Developer Documentation
加算演算子
- Arithmetic operators - JavaScript | MDN
- Logical Operators - JavaScript | MDN
- ECMAScript® 2018 Language Specification
- https://www.ecma-international.org/ecma-262/9.0/#sec-additive-operators
- https://www.ecma-international.org/ecma-262/9.0/#sec-subtraction-operator-minus
- https://www.ecma-international.org/ecma-262/9.0/#sec-toprimitive
- https://www.ecma-international.org/ecma-262/9.0/#sec-ordinarytoprimitive
- 【追記】https://www.ecma-international.org/ecma-262/9.0/#sec-unary-plus-operator
等価演算子
- ECMAScript® 2018 Language Specification
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
api
- This dependency is exported to consumers, that is to say found on their compile classpath.
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.api
や configurations.implementation
では回収してくれないので compile
を使わざるを得ない(?)
参考文献
Migrate to Android Plugin for Gradle 3.0.0 | Android Developers
技術書典4でバッグにチラシを詰めまくりました
仕事中の心境
ああ……詰めても詰めてもバッグとチラシが補充される……
まるで賽の河原じゃん……?
えっ
バッグとチラシの在庫無くなった
マジかよ!
詰め終わったやつもみんな持ってかれてる!!!
疲れはしましたが、詰めたものが全部皆さんに行き渡って、しかも戦利品でぱんぱんになっていると嬉しいものですね。
手に入れられなかった方ゴメンナサイ。
ただいま17時をもちまして、#技術書典3 閉会いたしました!
— 技術書典公式アカウント (@techbookfest) October 22, 2017
台風直撃の最中、ユニークの来場者数では2750名、再入場者含む、のべでは3100名のご入場がありました。
ご参加本当にありがとうございました! #技術書典
ただいまを持ちまして、 #技術書典4 閉幕しました!今回の総参加者数は6380人でした。
— 技術書典公式アカウント (@techbookfest) 2018年4月22日
皆さんご来場ありがとうございました。
晴れると来場者数が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便で鹿児島への卒業旅行に向かったので不参加。
自宅→成田空港第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を扱うため
やはりヒートマップを表示させておくとみなさんが興味を持ってくださるのでいいね
なんたってセッション〜休憩の移動でヒートマップのようすが刻々と変わってくからね
どんな機材使ってるの?
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では雨天のため屋根のない場所にお待ちいただくことになってしまった。
午前中は外に出なかったのでわからないが、4Fがあったりそもそもそんなに混まなかったりで去年より快適だったと思う。特に4Fは落ち着いて立ち読みできたと思うし、人混みが苦手な人には特におすすめ。
そんなに混まなかったといっても、お昼頃は身動きできなくて大変だった。そして雨にも関わらずさっと完売をキメる人気サークルの皆様。
戦利品
- 技術季報2
- Effective Meat Tenderness Measurement Effective肉の固さ測定
- Super Mario Makerプログラミング入門
- 公開鍵暗号計算演習書
今回(というかイベントのたびにだけど)疲れていたのでこれだけ。もうちょっと深呼吸していろいろ目を通せばよかった。
真面目本として技術季報と公開鍵暗号、ちょっとネタ本として肉とマリオを買った。(公開鍵暗号は売り切れてたので厳密には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はガベージをコレクションするというよりぶら下がりポインタの対処話になってしまうので、どう頭の中で整理したものかめっちゃ混乱した。
俺コン「今こそテストの気持ちを考える」
あまりに社会人のみなさんが懇親会で「テスト書いてません」とおっしゃるので喧嘩を売りにいった。なのでこれも発表していて怖かった。実際にこれを聞いてくださった方は、わざわざ聞きにきてくださるだけあってさすがにテストは書いているようだった。
テスト書いてない問題はもちろん、そもそもテストとはなんなのかという疑問を出発点にテストを調べ始めた。したがってこの15分の話は調べたことのほんの一部にしか過ぎないし、もちろん調べ終わっていない。JUnit3→4移行話とかXCTest内部実装とか早急に調べたいのだがうわー修論うわーうわーうわー。
Reject Conference「郵便屋さんの演算子」
Swiftのガイドの演算子の文法の箇所を見て、何書いてあんのかわからん!となったのがきっかけ。Qiitaを調べても、演算子定義の方法は書いてあっても使える文字の話の記事はなく。
マジで何が書いてあるのかわからないのでしばらく読まずに放置していたが、技術書典2でUnicodeポスターを買ったのをきっかけに気合いで読んだ。ついでにちょっとだけUnicodeに詳しくなった。ちょっとだけ。
発表してみて
- リジェクト分はOtemachi.swiftとかiOS Test NightとかSwift Tweetでやるしかないかなあと思っていたが、結局iOSDC関連でだいぶ片付いた。ありがとうございました。
- 勉強会駆動勉強により、GCとテストとUnicodeの知識がちょっとついた。
- 自ら発表することにより、懇親会で来てくださった方の側から話しかけてくださったのでコミュ障的には楽だった。
- 多少顔を覚えてもらったかなあ。Swift TweetやOtemachi.swiftで発表するなどしたのもあったと思う。
- 今の実力では、リファレンスに書いてあることや理論をお伝えするのが限界。ベストプラクティスを共有するには経験値が皆無で無理。
- 修論つらい
- 結局俺コンとリジェクトコン2日目をキャンセルごめんなさい
今後に向けて
- 引き続きテストについては調べていく所存。
- GCについてはとりあえず一旦終わり。C/C++/Rustの勉強はまだ足りないからいずれやるかも。アルゴリズムを考える脳みそはないので専門家にお任せしたい
- 演算子は実用的でないのでもういい。Unicodeは…何か読み物を読むくらいなら
- ベストプラクティスというか実際の業務やOSSで役立つ手法というか、そういうのを共有できるようになりたいですね
- しゅ〜〜〜うろ〜〜んしゅうろんしゅうろ〜〜〜ん修論〜〜〜〜〜〜〜〜
- 就活と学位論文は人間の体に毒なので即刻やめるべき
- 脳内に「学位論文」というラベルの貼られたタスクがある、それだけで猛毒
- とりあえず勉強会からは冬眠