形容詞の表現には具体性を持たせようという話
先日こんなツイートをした。
「〇〇にすれば安い」というフレーズに対してこういうコストの考え方が広まることはいいことだと思った。https://t.co/pqhO0A4eUK
— takamii228 (@takamii228) 2020年11月26日
そもそも安いって形容詞なので(ry
— takamii228 (@takamii228) 2020年11月26日
会話や主張の中で、「〇〇は良い」「xxは低い」「△△は高い」等の形容表現をすることがある。
このとき、話者が正しく意図を伝達するためには、形容詞に対するコンテキストの具体性を持たせる必要があると思ってる。
ここでいう具体性とは、例えば話者がそう形容するに至った理由や具体的な尺度や基準だ。
「一人暮らしで家賃10万は安い」
という表現の場合、地方に住んでいる人から見れば高いと考えるかもしれないし、23区内の人から見れば安いと考えるかもしれない。
「一人暮らしで都内で駅から10分以内で家賃10万は安い」
少し具体性が増した。これに間取りも付与したらより伝わりやすくなるだろう。
しかし最後に受け手の主観が残る。健脚な人で駅からの近さよりも部屋の広さを重視する高いと思うかもしれない。
なので誤解なく伝えるためには、話し手は間取りは多少狭くても駅から近いことを重視している、という尺度をあわせて伝える必要がある。
10万円という具体的な数字に加えて、立地条件や相場、さらに話し手の評価基準を伝えて初めてこの主張は正しく受け手に伝わるのだと思う。
少し前にもこんなツイートをしていた。
形容詞は統一尺度か比較対象とセットで初めてお互いの感覚の擦り合わせの土俵に上がる気がする。
— takamii228 (@takamii228) 2020年7月2日
冒頭の「自炊すれば安い」の例ではそれが欠損しており、受け手によって異なる視点から様々な反応が得られたケースだと思った。
物事を決めたり、判断・評価するときに形容詞を使うことは多いが、スペースの都合で具体性や尺度や基準といったコンテキストを省いてハイコンテキストな文章にしてしまうと、あっという間に誤解して受け取られてしまうので注意したほうがいいなと思う。
物事を形容するというときにはその対象をそれぞれの中の評価軸で射影した値を比較・判断しているという前提のもと、その軸がなんなのか、また境界やレンジはなんなのかをすり合わせると表現の解像度が上がるのだと思った。
関連して、最近ここにたどり着くことが多い思考を貼っておく。理数系の人が似たような感覚を持つのか、理数系のバックグラウンドがない人はどう思うのかふと気になった。
多変数の制約の条件下では全て同じ向きに向いてるベクトルはないのて自分の価値観や仕事の成果の評価軸に射影したときのスカラー値が最大になるような選択肢をとるイメージ。
— takamii228 (@takamii228) 2020年7月30日
あらゆる意思決定、結局数理最適化問題だなーと今更ながら思う。
— takamii228 (@takamii228) 2020年1月10日
minimize f(x)
subject to x ∈ X = {x | x ∈ A1 ∧ x ∈ A2 ∧ ...}
的な。目的関数は何かなーとか制約は何かなーとか洗い出して、適当にパラメータいじって探索する。
DevFest Tokyo 2020でFlutterのCI/CDについてLT発表した #DevFestJa #flutter
10/17、18に行われたDevFest Tokyo 2020にてLT発表を行いました。
発表内容はここ1年間主に取り組んでいたFlutterの仕事で試行錯誤したCI/CDパイプラインについてを5分にまとめました。
内容の詳細については以前ブログに書いた内容になってます。
- Flutterを使ったAndroid・iOSアプリ開発のCIパイプラインを構築する(前半) #flutter - つばくろぐ @takamii228
- Flutterを使ったAndoird・iOSアプリ開発のCIパイプラインを構築する(後半) #flutter - つばくろぐ @takamii228
- Flutterを使ったAndroid・iOSアプリ開発のCDパイプラインを構築する #flutter - つばくろぐ @takamii228
- Visual Studio App Centerを使って内部向けに継続的にネイティブアプリを配信する - つばくろぐ @takamii228
発表はリモートで自宅から行いました。Google Meet経由での画面共有を運営の配信システムを経由してYoutubeに配信する形で、初めての経験で緊張しましたが無事発表を終えることができました。
リハーサルと違う画面配置で画面共有をやったらサブディスプレイの縦長の画面共有になっちゃって一瞬焦りましたが無事その場で解決して発表できました。
イベントの動画一式のアーカイブは以下で見ることができます。
Flutterに関しては @wasabeef_jp さんの「Flutter はプロダクション開発に耐えうるのか」という発表が同意する点も多くとても参考になりました。
CI/CDについて話されたらどうしようとビクビクしてましたがご配慮いただいたようです。ありがとうございます。
.@wasabeef_jp さんのセッションでCICDの話ガッツリが出ないか内心ヒヤヒヤしました。この後LTでさらっと話します! #DevFestJa
— takamii228 (@takamii228) 2020年10月17日
LT にあるなぁと思ったので削っときました(*´σー`)エヘヘ
— ᴅᴀɪᴄʜɪ ғᴜʀɪʏᴀ / ᴡᴀsᴀʙᴇᴇғ (@wasabeef_jp) 2020年10月17日
あわわ、ご配慮ありがとうございます!
— takamii228 (@takamii228) 2020年10月17日
このこともあったので、@wasabeef_jp さんとはAsk The Speackerでご挨拶と雑談をしました。
雑談してたら見事に @najeiraさんの「Inside Flutter」の発表を少し聞き逃してしまったのですが、Flutterがどういう仕組みで動いているかについて細かく解説されていたようなのであとでアーカイブを見て復習しようと思います!
他にもすたぜろさんの「これからはじめるAndroid開発」の発表はAndroidの情報が網羅的に含められていてとても参考になりました。
DevFest Tokyoは以前は参加者としての参加してました。今回は初めてのオンライン開催<発表でしたがより一層楽しませていただきました。運営のみなさんありがとうございました!来年も参加したいと思います。
ISUCON10に参加した #isucon
先日行われたISUCON10に元同僚の id:int128 先生と id:translucens 先生と gosoudan2というチームで参加してきました。
事前準備
実はISUCON9に同じメンバーでgosoudanというチームで参加していて、このときは始めてだったので勝手が分からなかったものの無事スコアを残せてよかった、という形で終わってました。
参考順位的には594チーム中246位相当でした。
ISUCON10に向けては、各メンバーの事情やコロナもあって集まって練習したりということはせず、一週間くらい前から前回の振り返りをしつつ今回どういうTryをするかを話し合ってました。振り返りのKPTからは以下のようなものが上がっていました。
- Keep
- CDパイプラインが構築できた
- 初参加でスコアが残せた
- StackDriver Profilerでボトルネック分析のサイクルが回せた
- Problem
- 問題文の理解が不十分でスコアに影響する改善に時間がかけられなかった
- 改善の計画や評価をうまく整理できず、行き当たりばったりになってしまった
前日のミーティングにて以下のTryをすることを決めました。
- 問題文をまず精読してドメインをきちんと把握する
- 最初のスコアを出す、最初の改善を出すまでにやることをリストアップしておく
- 1時間単位で情報の同期をとる
また目標としては去年以上の順位をとること、またアルゴリズム、データベース、ネットワーク通信、インフラ構成の中から少なくとも3種類の性能改善を実現することを上げました。
利用する言語は全員Gopher道場卒業生なのでもちろんGoです。
当日スムーズに動けるように、競技が開始してからやることをTo DoリストにしてGoogle Docsで共有しておきました。また当日も各メンバーが気づいたことわかったことをGoogle Docsに集約する形ですすめることにしました。また競技中のコミュニケーションはZoomを繋ぎっぱなしにしてSlackでテキストコミュニケーションを取ることにしました。
当日の流れ
当日は開始が遅れて12時20からの開始になりましたが、事前に昼食を済ませて待機していました。
時系列でやったことを並べると以下のような試合展開でした。
- 12時 ~ 13時台
- 問題文の精読を各メンバーで実施し20分個人作業、15分共有のサイクルを回す
- sshの設定を全員で共有し全員各サーバにsshできることを確認
- サーバー構成を確認して上がっているプロセスや動いているアプリケーションの状況を確認
- 標準構成でスコアを取りに行った => 13:15分ごろに初回ベンチ実行して499
- ソースコードをGitHubにコピー
- インフラ系の設定ファイルをあとでロールバックできるようにバックアップを作成
- メトリクス計測できるようにStack Driverの設定を実施
- GitHub ActionsでSelf Hosted Runnerを使ったCDパイプラインの構築に着手
- 業務シーケンスのわかったことを共有
- 14時台
- 15時-16時台
- 17時台-18時台
- 19時台
- MySQLを8にしたらスコアが激減、conf設定をいじり始める
- いじってもスコアが改善しないのでMySQL5.6に切り戻す
- select *を変えると初回チェックで弾かれるのではと思い断念
- Topの low_priced にpriorityやstockのORDERをつけたらスコアが伸びるのではとトライ開始
- データ登録のInsertをbulk insertに変更するように修正
- featureの文字列カンマ結合のLIKE検索が重そうなのでTABLE追加に着手
- 20時台
- low_pricedの修正を入れたらレスポンス不正でアウトだったので断念
- bulk insertの修正が入ってスコアが1472に
- featureのTABLE追加はレスポンス不正の不具合が取れず断念
- bulk insertのバージョンでサーバーにデプロイして再起動テストに備えて設定を最終確認
私がアプリの深い仕様理解やスコア改善に効果がありそうな改善のリストアップを、 id:translucens 先生がプロファイル設定やDB周り改善の実施、id:int128先生がデプロイパイプライン含めた開発の下回り整備とGoのアプリ実装という役割分担でうまく3人で協力しながら立ち回れたかなと思います。
スコア推移
サブミットしたスコアの推移は以下の通りでした。最終的な参考順位は1399で92位 / 468チームだったようです。nazotteの改善ができたあたりでは途中は30位内くらいだった気がしますが、そこからスコアが伸びなかったのが悔やまれます。
振り返り
前回は初回参加で右も左も分からなかったですが、前回の反省を踏まえた改善アクションも取れましたし、ある程度の性能改善アクションも取れてスコアも伸ばすことができました。
競技終了後の振り返りでは事前準備がうまくいったこと、tag pushによるGitHub ActionのCDパイプラインができたこと、問題を十分理解できたことなど前回の反省が生かされたKeepが上がりました。一方でAP2台+DB1台の構成に固執してたねってのが上がって、事前に想定してないアクションはなかなか本番ではとれないなと感じました。
個人的にはGoを1年以上まともに書いてなかったので、アプリの改善を自信を持って書けなかったのは悔しかったです。でも業務理解やタイムキーパー、nginxの設定等でチームには貢献できたかなと思います。
来年もISUCONがあるかわからないですが、3回目は機会があれば本戦出場を目指して戦えたらいいなと思います。参加した皆さん、運営の皆さん本当にお疲れさまでした!!!