僕とコードとブルーハワイ

omega (@equal_001) の日記

月イチくらいで四人で七輪を囲んで雑な会話をしたい

前はMTGや飲み会でたくさん意見を喋るほうだったけど, 最近は割と黙って聴くことが多くなった.
どっちが良いということはないけど, 話を聞いてもらいたいという欲求が発散できてないから多分本当は話したがりなんだと思う.
どうでも良いことでも真面目な話でも, ちゃんと最後まで話しを聴いて受け止めてくれる人はとてもありがたい. そういう態度を取ってくれる人だと, こっちも話をちゃんと聞くか〜となる. ちゃんと聴いてくれないで何度も話を遮ったりする人は「もうお互い自由に振る舞いましょう」という感じになる. それで成り立てば吉, それが駄目だったらまずお前がちゃんと話を聴く姿勢を持てよとなって, 変な空気になり, 多分そこでコミュニケーションは終了する.
世の中, ちゃんと話を聴いてくれる人というのは少ない.

私は話の腰を折られるのが大嫌いで, 話してる最中に微妙なタイミングでウェイトレスがご飯を運んできて話が中断され, 相手がその話はもういいやみたいな空気になると食欲も失せて即退店したくなる. 人生でそういうことたくさんあってもういいやとなって以来, お店では内容が長くなるような真面目そうな会話は自分からは段々しなくなった. 「あ、こいつちゃんと話聴いてくれないタイプだ」と思った瞬間から, 料理美味しいですねーとかしか喋らなくなる. 一緒にテーブルに座っている人がたまたまちゃんと最後まで話を聴いてくれる属性を持った人の場合は「それで, さっきの続きは〜」みたいな流れになり, 最後まで自分の思ったことを伝えることができるからイラッとしなくて済む. そういう人とご飯に行くと, 自分から話を開始する回数と発話時間が圧倒的に長くなる.
親や付き合いの長い友人だとそういうのを気にせずにお互い言いたいこといって雑に話を聴く感じになるけれど, 社会に出た先で出会った人たちでそういう感じで会話できることはあまり少ない.

昨日の社の飲み会は結構良くて, 普段仕事上の関わりも雑談もすること無いメンバーなのに, お互いが喋りたいタイミングで言いたいこと言うのに皆それを楽しんでいたし私も一切不愉快にならなかった. でも会話は程よくちゃんと聴いてくれて, レスポンスもあるしで最高だった. 昨日のアレは, みんな気が合って重くない感じに気を使いあえる奇跡的な集まりだったんだなぁと朝起きたときにふと思った.
人数の問題もあるかも知れない. 昨日は四人だったから会話場の狭さがちょうどよかった気がする.
空間にも要因があるかも. お店も赤ちょうちん系で親しみやすい空間でもあった. 皆の席も比較的近めで, 七輪を囲むスタイルというのも良かった.

今度からいい感じに打ち解けたいときは4人くらいで七輪を囲むスタイルをやっていこうかな.

2018(前半) -> 2018(後半)

振り返り.

2018(前半)

Kotlinでまともに動作するWebアプリケーションを作ってみる

50/100点
同僚と週イチで開発をしていたけど, お互い緊急対応だったりでリスケが結構あって思ったよりも開発が進まなかった. 週イチはちょっと少なかったかな.
技術選定, アプリケーションの設計からKotlinで簡易login機能の開発など色々できて楽しかった.
現在は趣旨を変える+仕事的なアレでAndroidアプリをKotlinで開発するという方針に変えたので, 一旦こちらの開発はstopしそう. でももったいないから時間を見つけてPRを出し続けたい.

Real World HTTPを業務で使えるレベルまで理解する

20/100点
業務で活用する部分があまりなかった. 後半は色々お世話になると思うので活用していきたい.

いくつかのDesign patternを"使える"ようにする

20/100点
これも評価が難しいけど, そんなに使う場面無かったのとあまり勉強進まなかった.

Djangoのコードを読んでWeb Application Frameworkへの理解を深める

70/100点
仕事上自動的にコードを読まざるを得なかったのでそれなりに知識は増えた. 学んだことをBlogとかにまとめれば良かったかなとちょっと反省.

Frontendのレベルを人並みにまで上げる

10/100点
ほぼほぼフロントエンド触ることがない半年だった.
Vue.jsのチュートリアルをやって同僚のVueのコードをレビューしたくらい.

総評

40/100点
やりたいこと詰め込みすぎた. あとプライベートで色々辛みがあってメンタル的に個人素振りの時間が取れなかったというのがある. Kotlin開発はちょっとずつ前進しているので良い感じ.
全体的にもう少し学習スピードを上げていきたい.

2018(後半)

2018年(後半)でやること・やりたいこと

  • Android開発で学ぶKotlin
    • 社のAndroid開発に小さなPRを投げてmergeできるくらいになったら達成でいいかな
  • Real World HTTPを業務で使えるレベルまで理解する
    • 書かれた内容が8割くらい理解できて人に説明できるくらいならまぁ達成でもいいかな
  • Golang リモートペアプロ
    • 友人とやろうぜという話になったのでやってみる

  • 旅行たくさんする
  • 美味しいご飯いっぱいたべる
  • 自分の時間を大事にする

Android開発でKotlinを学ぶログ1 開発環境の準備とAndroid projectとView, Layout, Click Event

今日から同僚にAndroid開発の基本を伝授してもらえることになったので忘却録を書いていく.
Kotlinの勉強も合わせて行うので, 以後使用言語はKotlinがメインとなる.

開発環境の準備

近年では Android Studio が主流とのことなのでこれをInstallした. Downloadにちょっと時間がかかるくらいで特に躓いた点は無し.

Android Project 概要

MainActivity.kt

  • onCreate()
    • こいつがエントリポイント, 一番最初に呼び出される
    • MainAtivityは画面描画する前に呼び出される
  • setContentView(R.layout.activity_main)
    • ここでres配下のxmlファイルが呼び出される
    • 内部でres配下にあるxmlファイル群に一つずつidをふっていて, setContentView() にID群(R.layout.activity_main)が渡された結果, 初動のUI表示の実行がされる.
    • つまりこれをコメントアウトすると真っ白な画面が表示される.
    • 内部的に一意な数値として扱えるメリットがある

res/layout

  • UIの定義が書かれたxml fileを配置する場所
  • ここにButtonとかTextとかの定義をガンガン書いていく

String Resource (res/values/strings.xml)

  • layout や Activity から呼び出し可能なresourcesを管理するfile
  • 例えば 0 と書いておくと initial_text というIDでTextViewに初期代入してやると起動時に0が表示される
  • 初期表示やローカライズ(多言語対応)するときなどに使うと便利

UI定義でよく使われるものたち

基本的に各ViewにIDを付けてActiviryで呼び出すという形っぽい.

よく使われるLayout

1 Layoutにつき1 XMLというイメージでやることが多いらしい.
ただし, 入れ子にもできるし他のxmlに外出ししてincludeしたりできる.
本格的にfileを分けたりなんだりするとCustomView?という概念がでてくるらしいけど長い話になるのでまた今度と言われた.

  • Linear Layout
    • vertical: 上から下, holizone: 右から左 の繰り返しでコンテンツ表示するlayout
    • layout_widthでよく使われる単位はdp(端末毎に違うpixcelを解消するために生まれた単位. これを使うとどの端末でも大体同じ大きさになる) , fontはsp(スマホ端末で文字大きさ変えても反映される)
  • Relative layout
    • 親に対する子の要素を決めて配置できる. cssのrelativeみたいなやつ
  • Frame layout
    • point 0.0からframeを重ねていくイメージの配置方法
    • 上のメニューバーを固定しつつメインコンテンツをスクロールするみたいなものを作りたいときに便利だったり

よく使われるView

  • Text View
    • 編集できない, ただ表示するだけのView
    • Pythonistaでいうlabelにあたる
  • EditText View
    • 編集可能な方のText View
  • Image View
    • その名の通り画像を表示するView
  • Button
    • その名の通り, ボタンのネイティブUIを呼び出したいときに使うやつ
    • これも実はVIewの仲間らしい

Click Event

  • Buttonだけかと思われがちだが, Viewならどこでもclick eventが取れる
  • 方法は簡単で, Viewにidを付けてActivity側でsetOnClickListener()するとeventが取れる

Activity_main.xml

<Button
        android:id="@+id/count"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="@string/count_label" />

MainActivity.kt

val count_button: Button = this.findViewById(R.id.count)
count_button.setOnClickListener { view: View? ->
    Log.d("MainActivity", "this is log")  // count buttonが押される度にconsole logに"this is log"と表示される
}

Kotlin学びポイント

Buttonを押すと+=するCounterの実装をしたのだけれど, 私は愚直に実装してしまった.

val count_button: Button = this.findViewById(R.id.count)
val text: TextView = this.findViewById(R.id.result)
var count = 0
count_button.setOnClickListener { view: View? ->
    count += 1
    text.text = count.toString()
}

同僚はおしゃれなコードを書いていた.

val text = this.findViewById<TextView>(R.id.count_text)
var count: Int by Delegates.observable(0) { _, _, new ->
    text.text = new.toString()
}
this.findViewById<Button>(R.id.count_up_button).setOnClickListener {
    count = count + 1 
}

Observable property をうまく使った例.

Delegates.observable() は、2つの引数を取ります。初期値と修正のためのハンドラです。ハンドラは(割り当てが行われた 後 に)プロパティに割り当てるたびに呼び出されます。それには3つのパラメータがあり、割り当てられているプロパティ、古い値、そして新しい値です

_, _, new は prop, old, new の順番で値が入れられていて, 今回は count+= された結果, つまり最新のcount数が入ったnewだけ必要なので, propとoldはアンダースコアで捨てている.

そういえば by Delegatesを使うと+=記法をしたときにerrorになるらしく, 仕方なく count = count + 1 と書いているらしい.

今日はここまで.

OSC 2018 Hokkaido に今年も参加してきた+札幌旅行ログ

OSC Hokkaido

www.ospn.jp
おそらく北海道で一番大きいITイベント. 毎年500名以上が来場する. 今年はもっと多かったようだ.

私は学生の頃から参加していて, ちゃんと計算したら2012年から7回連続で参加してた.
去年は参加するだけだったけど今年はLTをしてきた. 来年はそろそろセミナー講師をやりたい.

Day1

夕方に札幌駅に到着. 友人たちとお茶をした.
札幌の友人たちがほぼ同じ時期に子供を出産していて, 4人とも女の子という奇跡を成し遂げた話を聴いたり, 赤ちゃんたちを膝に乗っけてふにふにしたりした.
その後OSC前夜祭に途中参加して石鍋亭で恒例のニラタワーをしてきた.

Day2

OSC本番という感じ. Day1は行けなかったので色々見て回った.

遊びに行ったブース

  • LOCAL 学生部
    • 大変よい技術書だったので, 興味ある人は私に「読ませろ!」とメッセージください.


  • OpenStreetMap Taiwan
    • OpenStreetMap の紹介とデモをしてくれた
    • どんどんデータが溜まっているようで、タイ国は3年前くらいは何も無かったのに今ではバンコク周辺なら結構なデータが入っていた
    • APIを叩く制限みたいなのは特に無いらしく, それなりの回数なら普通に耐えられるらしい
  • 株式会社レピダム

聴いたセミナー・聴きたかったセミナー

  • サイボウズOSS活動ポリシーを作った話
    • 著作権帰属のルールはシンプルで、上長から明確に指示を貰って作成したものと会社の機密情報的なものじゃない限りはokみたいな感じだった(うろ覚え)
    • あんまりルールつくるとみんなOSS化してくれないのでそれなりの議論を重ねて削りに削ったらしい

LT大会

「もしかするとこれが本編では?」と錯覚するくらいOSC HokkaidoのLTは毎年ハードルが上がっている気がする.

Ejectユーザ会とLOCALが10周年を迎えたり, 20年前のWeb系最新情報を淡々と解説している人が居たりと今回も個性豊かな発表だった.

私もLTした.
docs.google.com
近年にしてはわりと早めに発話したけど5分オーバーしてしまった.
北海道だと周囲の人たちに壁を感じること無く素で話せるので, 人前で喋って純粋に楽しかったのは久し振りだった.

最後は富良野で教育をメインにIT活動をしているtomio氏がトリだった.
彼はFuraITという地域に根付いたITイベントを定期開催しているので, 富良野近辺に遊びに行く予定のある人はFuraITに参加して欲しい. 学生たちと一緒に,電子工作やプログラミングを純粋に楽しめるイベントです (勝手に宣伝).
furait.connpass.com

大懇親会

過去最高の参加者数だったらしい. 私も過去最高に色んな人と会話した気がする.
毎年, 企業グッズや本が景品として出されるじゃんけん大会をやっていて, 折角なのでと「いちばんやさしいPythonの教本」を1冊献本した.

一度は東京でも会える友人の手に渡ったが, 大人力が発揮され本は室工大の学生さんのところに落ち着いた. 彼も イラスト図解でよくわかる ITインフラの基礎知識 という本を献本していたので, お互い本を購入してサインをし合おうぜ!という話になった.
とてもありがたいことに「この本を読んで勉強中です!」という方々がいて, 3回くらいサインを書いた. 緊張と普段文字を書くことがないことでうまく手に力が入らなかった.
びっくりしたのが 「本を持ってきてないのでスマホケースに書いてください」だった. 本当にいいの?!と5回くらい聴いて, 変な汗を書きながら名前とメッセージを書いた.
これからもいちやさPythonが色んな人の学びの手助けになると嬉しいな.

関係者懇親会2次会

珍しく年齢の近しい人達と会話していた気がする. 今年は本当に学生が多くて嬉しい.
来年のOSCをもっと楽しくしたい北海道の学生さんを募集中とのことなので, みんなやっていくと良いと思う.


12時前には無事に宿へ戻りました.

感想

今年は学生さんが多かった印象. 毎年参加していると同窓会みたいな感じになっていつも同じ人と喋りがちだけど, 今回は新しい人達とたくさんお話できたのが一番の報酬だった.

飲食

OSC二日目は毎年友人と近くの回転寿司屋にいっていて, 今年も寿司を無事ゲットできた. 毎年食う量が減っている気がする.
ちなみにこの店のポイントカードの有効期限は1年なので, 年に1度しか来ない私がこれを利用しようとすると, 来る度に発行と失効を繰り返すことになる.

昔からある札幌のおにぎり専門店. ありんこのおにぎりはめちゃくちゃ美味しくて, 札幌に住んでいた頃は結構行ってた.
札幌に行ったら是非立ち寄って欲しい.

新千歳空港は東京ではあまりみない珍しいお酒が置いてある大きい冷蔵庫です.


以上.

PyconThailandでDeodjangoについて発表してきた + タイのアレコレ

6/16 ~ 6/17, PyconThailand に参加してきた.
th.pycon.org

そろそろ海外カンファレンスで登壇する経験をしたかったのと, 現在所属している会社のサービスがタイにも進出しているので色々丁度良かったという理由で応募した.
発表言語が タイ語 or 英語 だったので自動的に英語で喋ることになった. タイ語は難しい.

PyconThailand

PyconThailand自体は今回が第一回目とのこと.
スタッフは現地のエンジニアと海外で働いているPycon常連メンバーで構成されていた. Co-OrganisedのTHAI PROGRAMMER はタイのプログラマコミュニティらしい. あまり活発ではなさそうだけど, メンバーはこれから盛り上げて行きたいぞと言っていた.
思ったより海外の参加者が多かった, 1/4くらいは海外勢だったのでは.

タイのプログラマ・IT企業事情

プログラマの数はまだまだ少なく, コンピュータ・サイエンスの学位を持った人は外に流れることが多いらしい.
タイが本社の有名な企業とかはあまりないらしい. WongnaiとKaideeは名前は聴いたことあるけど, 確かに他に何かあったっけとなる. ローカライズされたアプリとかは結構あるらしい, 詳しいアプリ名とかは聞き逃した.
でもスタートアップは増えつつあって, 去年にはタイ国主催でスタートアップのイベントをやったりしていた.
こちらのブログにイベントの様子が詳しくまとまってたのでリンクを貼らせていただく.

Day 1

会場ビル
f:id:equal_001:20180705004819j:plain

7:30からPyLadies Breakfast があったけど起床に失敗したので行けなかった. スタートが早い.
Keynoteはpandas開発者のWes McKinney氏. 午前中は現地にいる同僚と会う約束があったので聴いてないけど, 後で動画が上がるとのことなのでそれ待ち.


個人的に一番楽しかったのは、「Hy: Running a webapp with LISP on Python」というLTだった.


狂気からイカのキャラクターがクトゥルフの一種に見えてくる.

Official Party
地元のクラブでの開催で, 尋常ではない量のピザと1drink無料ビールが提供された.
f:id:equal_001:20180705004843j:plain

せっかくの場なので自社アプリについて聴いたり勧めたり, タイのプログラマ事情について聴いたりしていた (→ タイのプログラマ・IT企業事情).
そのあとは何故かリタイアしたおじいちゃんエンジニアと孫の写真を見たりタイの観光地について教えてもらっていた. お互いPythonistaを知っていたので色々実行したりしてちょっと遊んだ.

パーティ開始1時間くらいしたところでDJが爆音でミュージックをかけはじめて会話が困難になったのでホテルへ戻った.

Day 2

この日は自分の発表があった.
CFP
Powerful geographic web framework GeoDjango

スライド
docs.google.com


発表時間が最後ということもあったが, 技術的な内容を英語で話すという経験がほぼ無かった為かなり緊張した.
緊張しすぎて発表者noteに書いてあった喋ることリストをすっ飛ばしまくり, 結果かなり発表時間を余してしまった.

昨日からお腹の調子がおかしくて, 発表を聴いてはトイレに行くみたいなことをしていた. トイレに行く度に受付前を通らなければならず, スタッフと目があう度に気まずかった.
原因不明だけど, タイの氷はそこらへんの水を使っている可能性あるので危険だよと教えてもらった. カンファレンスのfree drink ticketで飲んだThai teaの仕業だと思っている.

あと緊張と腹痛で体調が最悪になってあまり発表聴けなかった.

実際にやってみて

  • 人間, 緊張しすぎると頭が真っ白になり, 何を言っているのかわからなくなることがある
  • あまり綺麗でない発音の英語を聞き取れなくて質疑応答がお葬式になった. 金を払って聴く英語は綺麗, 現実は厳しい
  • ランチ時間にスクリーン繋ぐ練習とかしておいたほうが良かった. 緊張も相まってかなりもたついた

完全に失敗したと思っているけど, 自分の英語で発表するときのレベル感がわかってよかった.

今後

  • 緊張せずに話せるようにメンタルコントロールできるようになりたい. 精神の安定を得るにはたくさん練習して英語での発表経験を積むしかなさそう.
  • 次はPyConAPACで登壇したい

その他

  • スタッフ曰く参加者は200名くらいだったらしい
  • 日本から来ていた知人が4人くらいいてあまり寂しくはなかった. 今回で海外勢の知人が何名かできたので, 他のPyconでまた会えたらいいな
  • 英語がんばらないといけないのかと思っていたのだが, スタッフに日本語が喋れる人がたくさんいたのでそんなに英語喋らなかった

飲食


私の友達の友達のお店. みんなタイに行ったら是非寄って欲しい.




他にも色々写真撮ったけど載せるのが面倒なので割愛.

気が向いたらタイでの生活について何か記事を書くかも.

健康

健康的に痩せた.

2ヶ月くらい大江戸線のあの大変長い階段を昇り降りをし続けていたら, 特別なことはしていないし寧ろ飲酒量とか増えてるのに体重が3kg減って謎に腹が引き締まってウエストが5cm細くなった. 長時間座っていても疲れなくなったし, 集中力がアップした. あと前よりもポジティブになった気がする. 筋肉量が増えた上で体重が落ちていて, いい感じに健康的に痩せている.
前に女医から「脹脛は第二の心臓で, 意識的に動かすことで血液の循環が良くなる」と言われ, 先生のとても綺麗な御御足を見せられて以来, 私も階段を登るようにしている.

大江戸線がどのくらい深いかというと, ある駅ではホームから改札を出るまでにカップラーメンができたり, 大江戸線深すぎ.com というサイトが作られるくらい.
私がよく使用する駅は深度21mくらいで他の駅よりは浅いらしいんだけれども, それでも階段を使って登るとホームから地上まで4分はかかる.

大江戸線だけでこんなに効果が出るか?と思ったけど, 自宅(4階)も階段を使っていて, それ以外の場所でもできるかぎり階段を使用している. 集団行動中にみんながエスカレータを使っていても協調性を無視できる範囲内で階段を使用する(元から協調性は無い方ではあるが). 階段の昇り降りだけでここまで効果が出るとは思っていなかった.

どこまで体重が落ちるのかわからないけど, 今も週一単位でみると少しずつ数値が減少していて嬉しい.
知人の優秀なエステティシャンに「バランスよく痩せればもっと魅力的になるのにどうして努力しないの?若さでカバーできるのは今のうちなのよ?老化を舐めてるの?うちに来たって一時的にしか細くならないのよ?」と煽られ続けて早5年経過しているので, このまま健康的なダイエットを続けていこうと思う. 遺伝で下半身の肉が落ちづらいのでどうにかして綺麗なスタイルに持っていきたい. モテたい.

いま思ったけどこれ, 他の運動を取り入れたらもっと筋肉量が増えて肉の落ちるスピードが加速するのでは.
とりあえず社のヨガ部に入って頑張らない程度にジム行くことにした.

ミスコミュニケーション

なんか最近, 人生で一番ミスコミュニケーションが発生していてやばいなととても思う. ハッキリ物事を言われないとわからなくて「何故あの人はこういう態度をとっているんだ?」となり, 曖昧な状態で真意が宙ぶらりんとなった結果, あの人は意図的にそういう曖昧な状態を選択しているのだな, と結論付けてしまう事が多い. だってずっと接していてそういう言動が続いている中, 何故そういう態度を取るのか問うてみても曖昧な返事しか返ってこないのであればそう思うしか無かったのだった. 果たしてこれは私だけが悪いのだろうか. 2度も明示的なリクエストを送ったのにその度に明示的なレスポンスを返さなかったら受け手側はそう解釈する他ないと思う. 根気よく何度もリクエストを投げれば下手に問題を発生させずにすっきりと解決したのだろうか. 曖昧な部分が1つだけならまだ認識の齟齬は小さかったのかも知れないが, 今回は二つも三つもあって, 私からすると一貫して曖昧さが目立ったため, 私は相手側が曖昧な状態を保持したいのだと結論づけた. この考え方は駄目だったのだろうか. もっと優れた観察眼があればミスコミュニケーションは生まれなかったのかな, 私の能力が低いせいなのかな. こんなことは今まで滅多に発生しなくて, 何故今こんなに積み重なってしまっているのか本当にわからない. わからなくてどうすれば良いのか色々考えて, システム開発と同じで, 結局は曖昧なデータを返されたらフロント側でデータを加工していい感じに解釈するしか無いんだろうなと雑に想像した. でも仕様がわからないので結局ちゃんとしたテストは書けなくて, 自分の第六感みたいなもので「これはassert_trueだな」と一つ一つ想像でやっていくしか無いなと思う. じゃあサーバ側のロジックを見てみるか, となるけれど相手側のサーバ(脳内)には入ることはできないし, 何が正しいデータなのかも確認できない. お手上げなので, やはり解釈可能なデータが返ってくるまで根気よくリクエストを送り続けるしか無いのだろうなと思う. こういうのが積み重なると, 部下と上司の平行線の対立が続いて離職に繋がるんだろうなぁと思った. 私は割と 良い/悪い/好き/嫌い の意志を日常的にハッキリ伝える方だしそういう人たちが周りに多かったので, 曖昧さに慣れていないというのもありそう. 曖昧な状態がとても居心地が悪くて落ち着かないし, そういった態度を本人が無意識にやっているのか意識的にやっているのかの区別をうまく付けられない. 以前はこんなことで悩むことが無かったので, なんだかどんどん人間性が失われている気がする. 色々人生相談したときに「omega氏, ようやく人間性が生まれたね」みたいな話を知人とした矢先にこれで, やはりダメなのかもしれない. 正直どうしたら治るのかちょっとわからないんだけれども, 今回色々考えてみてわかったのは, 自分は割と他者の行動への意味解釈に対して人よりも視野が狭く, 短期間のうちに限定的な情報で解釈の結論を付けがちという点で, 深く内省した. やりたくて勘違いしているわけでは決して無いし, 正直同じ過ちを二度と繰り返したくはないので, ロジカルシンキングのアプローチからどうしようもないミスコミュニケーションを無くしていきたい. あと人間性を養いたい.