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

iOS以外でも前向きにSwiftを使いたい話

Swift アドベントカレンダー

本記事はこれです。

qiita.com

iOS以外でSwiftの出番がない話

皆さんはiOS以外でSwiftを採用したことはありますか？私はないです。Swiftとかいうマイナーな言語を授業や研修で使うわけがありません。

「言語何にするー？」
「Ruby/Java/Pythonならみんな書けるっしょー？」完

たまにはSwiftって言われてみたい……
全員がiOSエンジニアにも関わらずiOS以外をやる用事があればSwiftになるかも？

たとえば、iOSコミュニティでサーバサイドをやることになったとか……

アクセスポイント毎の接続数をSwiftを使って取得する

具体的には

自前でカンファレンスのネットワーク環境をやろうと思った時には、ログを集めたり監視したりするように作らなければならない。ここでネットワーク管理ソフトウェアZabbixの利用が候補に上がる。

ざっくりとした図:
f:id:S_Shimotori:20181220235419p:plain

例えば、各APの接続数は、APの親玉であるWireless LAN ControllerからZabbixに届けられる。
ZabbixはREST APIで叩くことができるので、あとは煮るなり焼くなりVaporでヒートマップを出すなり自由。もしwebassemblyが完全対応すればWi-Fiヒートマップの描画までSwiftがやっちゃうかもしれない。

SwiftでZabbix REST APIを叩く

Linux（適当なUbuntu）サーバ上で叩くので、Linux対応のライブラリがあると便利。Package.swiftが置いてあるかというよりも、READMEで名言されていたり #if os(Linux) がソースコード上にあったりIBMだったりするほうが信用度高め。

github.com

let request = RestRequest(method: .post, url: "http://Zabbixホスト/zabbix/api_jsonrpc.php")
request.messageBody = try! encoder.encode(略)
request.response { data, response, error in 煮るなり焼くなり }

略の部分に、たとえば

{
    "auth":"ログインした時に返ってきたやつ",
    "method":"item.get",
    "id":1,
    "params":{
        "search": {
            "name":"* Ap If No Of Users * GHz"
        },
        "searchWildcardsEnabled":true,
        "output": ["name", "key_", "lastvalue", "prevvalue"]
    },
    "jsonrpc":"2.0"
}

というふうになる struct Hoge: Encodable を与えておくとZabbixから接続数が取れる。

Zabbix自体をカンファレンス参加者に叩かれるわけにはいかないし、キャッシュの役割をする人がいてほしいので、Vaporを立ててそこからAPIやらhtmlやらを出させるとなおよし。

github.com

routes.swiftに上手に書けばVapor1人で両方出せる。テンプレートを使ってりっちにhtmlをやりたい場合はleafもセットで。

.package(url: "https://github.com/vapor/vapor.git", from: "3.0.0"),
.package(url: "https://github.com/vapor/leaf.git", from: "3.0.1"),

なんでこんなことしなくちゃいけないの？

え、自分の所属するコミュニティのカンファレンスのネットワーク環境やっていきたくないんですか？

まとめ

興味がある人はそのへんのカンファレンスのネットワークチームを乗っ取っていっしょにSwiftまみれにしましょう！iOS関係ならSwiftを使ってもメンテの人手には困……らないかどうかはわからない。責任は取りません。

ちなみに上の図の画像はいらすとやさんです。アクセスポイントにははんぺんを使いました。便利ですね。

TraitとBar周りの英単語の語彙が乏しいのでドキュメント読み直した

アドベントカレンダー

本記事はiOSアドベントカレンダーの12日目です。

qiita.com

アドベンチャーモードの分量と難易度、どっちも調整おかしいんじゃねえのと思いながら週末溶かしてアドベントカレンダーどころではなくなった。

  • 現在地

看板が読める気がするいややっぱわからん

雑談はさておいて、本記事では、ドキュメントが英語で書いてあってよく読み取れないので頑張って読み取ります。
新規性なんてなかった。

本記事のネタを書くに至った経緯について

上手に UINavigationBar に背景画像を表示させたいな！端末のサイズによって適切な背景画像のサイズが異なるから上手に計算したいな！

そういえばsize classなるものがあってregularとcompactの2種類があったな？

Adaptivity and Layout - Visual Design - iOS - Human Interface Guidelines - Apple Developer

Size classes are traits that are automatically assigned to content areas based on their size. The system defines two size classes, regular (denotes expansive space) and compact (denotes constrained space), which describe the height and width of a view.

もしや setBackground で UIBarMetrics を指定するときにこの知識が役に立つのでは…？

UIBarMetrics - UIKit | Apple Developer Documentation

Constants to specify metrics to use for appearance.
case default
Specifies default metrics for the device.
case compact
Specifies metrics when using the phone idiom.

なるほど、defaultとcompactの2種類があるんだな！いやdefaultってお前誰だよ。ていうかphone idiomってなんだよ。つーかprompt propertyってなんだよ。英語難しいな！

size classを擁するtraitについて

iOSのインターフェース環境はtrait（特徴）を持ち、このtraitには

  • size class ( UIUserInterfaceSizeClass )
    • 縦と横それぞれ
  • display scale (浮動小数点数)
  • display gamut ( UIDisplayGamut )
    • 色域のこと。iOSは基本的にsRGBを使用する。最近のディスプレイはP3対応。
  • user interface idiom ( UIUserInterfaceIdiom )
    • phone や pad といったインターフェースの種類を指す。ちなみに、idiomには慣用句の他に表現方法という意味もあるらしい。
  • force touch capability ( UIForceTouchCapability )
    • 3D touchが使えるかどうか
  • layout direction ( UITraitEnvironmentLayoutDirection )
    • レイアウト方向がLTRかRTLか
  • user interface style ( UIUserInterfaceStyle )
    • darkスタイルにすべきかlightスタイルにすべきか。tvOSやCarPlay限定。
  • preferredContentSizeCategory ( UIContentSizeCategory )
    • Dynamic Typeでユーザが設定したサイズ？？？

がある。
これらはclass UITraitCollection でまとめて表されており、protocol UITraitEnvironment の

var traitCollection: UITraitCollection { get }

や

func traitCollectionDidChange(_ previousTraitCollection: UITraitCollection?)

から取得することができる。

いろいろなscaleについて

UIScreen から取れるscaleは3種類存在する。

  • var traitCollection: UITraitCollection 経由で取れる displayScale
  • nativeScale
  • scale

このうち役割が違うのが nativeScale で（多分）、ユーザがDisplay Zoomの設定を変えると nativeScale の値も変わる（きっとそう）。

公式ドキュメントのどこかに明記されていたら教えてください。

色空間について

f:id:S_Shimotori:20181211135622p:plain:w150

Color - Visual Design - iOS - Human Interface Guidelines - Apple Developer

このグラフはXY色度図といい、XYZ表色系における色を2次元グラフ上に表したもの。Zの値はXとYが決まれば定義から求められるのでグラフ上には載っていない。

図中の三角形をカラートライアングルという。Display P3やsRGBなどの色空間が定める3原色をつないだもので、各色空間は三角形の中の色のみを再現できる。要するに、sRGBよりDisplay P3の方が再現可能な色が多い（だから必要な時はP3を使ってね！by Apple）ということが図から読み取れる。

本題: UINavigationBarの背景画像を変更する

次のメソッドで背景画像を設定することができる。

func setBackgroundImage(_ backgroundImage: UIImage?, for barMetrics: UIBarMetrics)

問題は

barMetrics
A bar metrics constant.

これ。

そもそもBarには protocol UIBarPositioning というprotocolが用意されていて、 UINavigationBar や UISearchBar は var barPosition: UIBarPosition 経由でBarの位置を取得することができる。

この protocol UIBarPositioning が enum UIBarPosition の他に enum UIBarMetrics を擁する。metrics = 指標。

なまえ 種類 役割
UIBarPositioning protocol Barの位置の取得方法を提供。 var barPosition をつければOK
UIBarPosition enum 上とか下とか
UIBarMetrics enum appearance（= 外観）のために用いる指標

UIBarMetrics は以下4つの要素を持つ。

  • default
    • Specifies default metrics for the device.
  • compact
    • Specifies metrics when using the phone idiom.
  • defaultPrompt
    • Specifies default metrics for the device for bars with the prompt property, such as UINavigationBar and UISearchBar .
  • compactPrompt
    • Specifies metrics for bars with the prompt property when using the phone idiom, such as UINavigationBar and UISearchBar .

compactとpromptが何を表しているかというと…

試しに

UINavigationBar.appearance().setBackgroundImage(赤色画像, for: .default)
UINavigationBar.appearance().setBackgroundImage(青色画像, for: .compact)

などでどちらが使われるか試してみると、

size class for w&h bar metrics
iPhone 8縦 compact&regular regular
iPhone 8横 compact&compact compact
iPhone 8 Plus縦 compact&regular regular
iPhone 8 Plus横 regular&compact regular
iPhone XS Max縦 compact&regular regular
iPhone XS Max横 regular&compact regular

となる。つまり

  • size classを雑に参照すれば UIBarMetrics も定まる 違う
  • .compact にphone idiomと書いてあるからiPhoneは全部 .compact になる 違う
  • Plus、Max、XRのような、Landscape時にregular&compactとなっている端末は常に .regular 設定が使われる ←これが正解！

である。

promptはこれのことっぽい。（が、prompt stringとセットで使っても反映されない・・）

f:id:S_Shimotori:20181211154209p:plain:w300

UINavigationBar - UIKit | Apple Developer Documentation

結論

  • 英語難しい
  • "compactPrompt" でGoogle検索してもenum要素の1つであることしかわからないことがわかった。使ってる人あんまいないんちゃう？

  • func setBackgroundImage(_: barMetrics:) はそこまで上手にやってくれないので我々が頑張りましょう。縦時背景画像は .regular で横時背景画像は .compact とか設定するのは間違い。

参考文献

iOSDC Japan 2018でネットワークスタッフと30分セッションとシークレットLTをやりました #iosdc

Swift イベント

Qiita記事書いたらブログ書こうと思っていたら1週間が経過しました。

iosdc.jp

ネットワークスタッフをしました

ここまでの経緯

母校でDroidKaigi2016が開催されるというので当日スタッフに参入
↓
DroidKaigi2017でコアスタッフとしてCONBUさんを見学
↓
DroidKaigi2018でネットワーク専門コアスタッフ
↓
iOSDC2018でネットワークチーム参入（not コア、not CONBU）

適当に仕事を抜け出してセッションを聴きに行きたいのでコアスタッフではないしその予定もない。

成果

今回はサーバサイドをやったがうまくできなかったのでそのへんでリベンジする。うまくできなかったぶん当日は宣伝に注力した。
8の字巻きにはもう慣れたと思う。

LANケーブルを作る仕事はネットワークスタッフにはない*1のだがちょうどいい機会なので初作成した。作ったものはいまこの瞬間、有線接続するのに活躍している。
他のスタッフのみんなは1本作るのに3分くらいでできるだとか家に工具があるだとかが常識らしいが私にはよくわからない。ぐろ〜ばるIPもちょっとよくわかりたくない。

30分セッションをしました

フォントと組版の30分入門 by S_Shimotori | プロポーザル | iOSDC Japan 2018 - fortee.jp

出したら通ってしまったので登壇した。聴衆が何を期待しているのかは無視して自分の好きなことをしゃべった。

t.co

結果タイ語とアラビア語に質問が集中したので別途Qiita記事を書いた。流石にあまり馴染みがないようだ。でもWWDCで名指しで紹介されるような言語なので無視してはいけない。

qiita.com

資料を探すのに新宿区立図書館を使った。なんと西早稲田キャンパスの目の前、道を渡るだけ。なので西早稲田に行った回数はコアスタッフや早大◯◯理工学部の現役生の次くらいに多い自信がある。

あと印刷博物館は300円で楽しめるのでおすすめ

www.printing-museum.org

Qiita記事を書くのに苦労しました

iPhoneのスクショ画面はDisplay P3というカラープロファイルを使っているので、デフォルトカラープロファイルがsRGBであるIllustratorに配置すると色がおかしくなる。Photoshopは正しい色で扱ってくれる。

iPhone iOS 11 screenshots problem on illustrator – Adobe Illustrator Feedback

シークレットLTをしました

東松さんがほとんどしゃべっていたとかいうツッコミはいけない。宣伝のためだ。iOSエンジニアにネットワークチームへ入ってもらうためだ。なので許してください。

f:id:S_Shimotori:20180908171942p:plain

ネットワークやりたい人を募集しています

iOSDCネットワークチームでは新しいことを始めたい人を募集しています。8の字巻きやアクセスポイント配置やサーバサイドならiOSエンジニアでもできると思います。
カンファレンスのWi-Fiは繋がらないものだと思い込んでいる人たちのその思い込みをやっつけるためにがんばりたい。この記事を読んだ人はネットワークスタッフへの応募を必ず検討してください。約束ですよ。

*1:既製品をまとめ買いするため

iOSDC Japan 2018でネットワークスタッフと『フォントと組版の30分入門』をやります #iosdc

Swift イベント

iOSDC Japan 2018でやること

  • ネットワークチームのおしごと
  • 『フォントと組版の30分入門』

ネットワークスタッフのおしごと

クイズ！1000人規模のカンファレンスでネットワーク環境を提供するには何をすればいいでしょうか。

ネットワークスタッフは、私の認識が正しければ次のようなチーム分けになっている。

  • wifi: WLCとAPと配線のお世話
  • ネットワーク: IXのお世話
  • サーバ: データセンター内に各種サーバを用意

くわしくは当日暇そうなネットワークスタッフを捕まえて聞いてほしい。
私が経験済みなのは配線（DroidKaigi 2018）とDHCP/TFTP/DNSサーバ（今回）である。しかしDHCPサーバが完動している形跡がないので危うい。

以下はお役立ち情報。

『フォントと組版の30分入門』

2018/08/31 16:00〜 Track Cです。

フォントと組版の30分入門 by S_Shimotori | プロポーザル | iOSDC Japan 2018 - fortee.jp

iOSエンジニアに聞いて欲しいトーク、っていうんならこういう分野もありなのかな？？と思って出したら通ってしまった。説明書きに『間違えるとこわーい人にツッコミを入れられてしまうかも！』とあるが、ツッコミを入れられてしまう可能性が高いのは登壇する私自身である。書籍や企業HPや大学HPならば大丈夫だろうと思ってどうにか調べている。

組版の話となれば流石にこれは避けられないと思って作った。本格的な縦組みは私の能力では不可能なので、セッションで深掘りするつもりはない。許してほしい。こんなん無理。

そのかわり……にはならないかもしれないが、こういうのをやってみた。

話に聞いていただけのものを実際に見たりやったりというのは楽しいね。
というわけで、本セッションは以下に当てはまる方に聞いて欲しい。

✅フォントや組版を気にしたことがない人
✅まず実物を見たほうが取り掛かりやすい人
✅歴史が好きな人
✅アプリ多言語化対応の予定がある人
✅同人誌を読む側の人

以下の方にはお楽しみいただけないかもしれません。

❌フォント警察
絶対フォント感の解説はできませんゴメンナサイ。。ていうか代わりにやって欲しい。
❌校閲のプロ
これは入門編ですこわいですやめてくださいこわいよ〜〜〜
❌業務で縦書きをしている人、予定がある人
ていうか代わりに(ry

登壇練習会 at Ebisu

さきほどTimersさんのオフィスで登壇練習会をしてきた。みなさんありがとうございます。ネタバレはできないので、ぜひみなさん自身の目で確かめて欲しい。どれも面白い話で本番が楽しみ。

むしろ自分の発表がみんなに負けないくらい面白いかどうか不安になってきた。正確には、フォントも組版も面白いのは間違い無いんだけど、自分がそれをちゃんと伝えられるかどうか不安になってきた。最後の追い込み頑張ります。

"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. lval を lref の参照外しの結果とする。
  3. rref を右辺の評価結果とする。
  4. rval を rref の参照外しの結果とする。
  5. lprim を lval をプリミティブ化したものとする。
  6. rprim を rval をプリミティブ化したものとする。
  7. 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'と考えればそれっぽい。

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

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

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

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

論理否定演算子は

  1. expr を右辺を評価したものとする。
  2. oldValue を expr をBooleanに変換したものとする。
  3. 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 になる。

等価演算子

仕様上、

== の判断は

  1. 両辺が同じ型なら === の結果次第。
  2. 両辺がどちらも null か undefined だったら 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に変換した上で加算する。 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 というのが原因だろうが、ここまで来るともはや何が何だかわからない。
  • 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.api や configurations.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円

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

まとめ

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