task4233のめも

書きたいことをつらつらと

BlueStacks 4.27.0 を MacOS にインストールする際にクラッシュする問題の解決方法

TL;DR

  • インストール済みの VirtualBox および BlueStacks を App Cleaner で削除する
  • PC を再起動する
  • 公式ページから最新版の BlueStacksInstaller を再度ダウンロードする
  • ダウンロードした BlueStacksInstaller で BlueStacks をインストールする
  • ダイアログが表示された場合は公式のサポートページ を参考に対応する
  • これで BlueStacks を起動できるはず

はじめに

この記事は、BlueStacks を MacOS で起動する際にクラッシュする問題の対処法をまとめた記事です。内容はほぼ Reddit に投稿されたコメントの転載ですが、日本語の記事がなかったため投稿することにしました。その Reddit の投稿や公式のサポートページは、本記事の末尾にあるので必要に応じて参照してください。

解決に至るまで

Android Emulator である BlueStacks を利用したかったのですが、起動時にクラッシュが起きていました。クラッシュレポートを読むと、以下のように Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999 というエラーが多数発生していました。

クラッシュログの一部

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

applicationDidResignActive

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

applicationDidBecomeActive

Setting IMAP State 0

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

PrivilegedHelper: ERR: Executing: /usr/bin/kmutil showloaded --list-only --bundle-identifier org.virtualbox.kext.vboxdrv

PrivilegedHelper: ERR: No variant specified, falling back to release

Virtualization driver is loaded

SetupSignals()

-[ServiceStateMachine start]

-[ServiceStateMachine enterStateStarting]

PrivilegedHelper: ERR:

VBoxBridge: Already initialised

VBoxBridge: VBoxBridgeStartMachineAsync()

VBoxBridge: VBoxBridgeStartMachine_Begin()

VBoxBridge: VBoxBridgeInternalOpenMachine()

VBoxBridge: VBoxBridgeStartMachine_Tick()

VBoxBridge: VBoxBridgeIsPowerOperationPending()

VBoxBridge: VBoxBridgeStartMachine_End()

VBoxBridge: VBoxBridgeCompletePowerOperation()

int VBoxDevicesRegister(PPDMDEVREGCB, uint32_t) -> 0x700007223bd8 393217

Cannot parse contents of file /tmp/BlueStacks-501-Private/guest-network-tcp-9999

AudioConstruct -> 0x7f88041e8220 0 0x7f8805666660

Assertion failed: (pDevIns->pHlpR3->u32Version == PDM_DEVHLPR3_VERSION), function AudioConstruct, file /Volumes/android/bst-v4.270.1-bgp64-mac/app-player/hd/external/appplayer/Host/BlueStacks/bstdevices/bstdevices/AudioDevice.m, line 246.

INFO : BSG_KSCrashReport.c (1557): void bsg_kscrashreport_writeStandardReport(BSG_KSCrash_Context *const, const char *const): Writing crash report to /Users/task4233/Library/Caches/KSCrashReports/BlueStacks/BlueStacks-CrashReport-80D7BC24-7BA7-4CDF-B144-D3D675D9AAEA.json

zsh: abort /Applications/BlueStacks.app/Contents/MacOS/BlueStacks

Saving session...

...copying shared history...

...saving history...truncating history files...

...completed.

Deleting expired sessions...none found.

[Process completed]

ググると、類似のエラーが出たという Reddit の投稿を発見しました。

www.reddit.com

ここに投稿された以下のコメントに従って対処したところ、クラッシュが起きなくなりました。

www.reddit.com

対処方法は冒頭に記した通りです。

もし同じ問題にハマっている方の助けになれば幸いです。

参考リンクたち

NTTコミュニケーションズ ISPネットワークのつくり方 参加記

はじめに

こんにちは。task4233 です。

2022年1月22日(土)にNTTコミュニケーションズにて開催された「ISPネットワークのつくり方」に参加しました。午前中にはISPネットワーク構築に関する座学が、午後にはハンズオンが行われました。

この記事は、特に学びが多かった午後のハンズオンの内容を書き記すために執筆されました。そのため、ハンズオンに繋がるStatic RoutingとDynamic Routingの話を紹介した上で、ハンズオンで利用したJunos OSとCisco IOSと私が挑戦したExtra Stageの内容について書きます。

午前 - 座学

今回の座学は、OSI基本参照モデルネットワーク層に該当し、ネットワーク機器間の通信経路を確立するための処理に関わる話がメインでした。

前提知識

説明に関わる基本単語をここで提示します。

  • AS(Autonomous System)
    • 相互に接続し合うネットワークのこと
    • 世界で一意な番号が付与されている
  • Peer
    • 接続したASの経路を交換して、お互いのネットワーク到達性を確保する関係のこと
  • ISP(Internet Service Provider)
    • インターネット接続サービスを提供するプロバイダ
  • IX(Internet eXchange)
    • 必要な回線数を減らすためにISPやデータセンタ同士の相互接続するポイントのこと
    • IXが無いと、N個のASがある場合フルメッシュでPeerを張るとN(N-1)/2 回線必要
      • IXを用意すれば、各ASがIXにアクセスするだけで良いので N 回線で済む
      • 嬉しいね
  • ルーティング
    • TCP/IPネットワーク上で目的のノードまでの最適な経路を選択すること
  • ルーティングプロトコル
    • ネットワークの経路情報を交換するためのプロトコル
    • Static Routing(静的経路制御)とDynamic Routing(動的経路制御)の2つがある

ルーティングに利用されるロジックと技術

ルーティングにおける最適経路選択におけるロジックとして、下記の3つのロジックがあります。

  1. Longest Prefix Match
  2. Administrative Distance(AD値)
  3. Metric

それぞれ簡単に説明します。

  • Longest Prefix Match
  • Administrative Distance(AD値)
    • プロトコルごとで優先度をつけるための値
    • 値が小さい方が優先される
    • ベンダによって異なることがあるが、大枠の優先順位としては変わらない
  • Metric
    • 同一のルーティング, プロトコルでルートが重複した際にどちらを優先するか決める値
    • 値が小さい方が優先される
    • RIPならホップ数、OSPFならインタフェースの帯域幅と言ったようにルーティングプロトコルに応じて異なるMetricを利用する
      • 全てのルーティングプロトコルで同じ指標なわけないよね

以上の経路の情報はRIB(Routing Information Base)として保持されます。このRIBはルーティングテーブルとも呼ばれ、後述するDynamicなルーティングプロトコルであるOSPFやBGPごとに存在し、ルータはそれらの経路をマージして1枚のルーティングテーブルを作成します。

この情報を用いてルータのパケット転送に最適な情報であるFIB(Forwarding Information Base)が生成されます。この結果がルータのCAMに書き込間れることで、ハードウェア的に高速なルート決定を行っています。

CAMとTCAM等については、こちらのスライドの説明が具体的で分かりやすかったです。

www.slideshare.net

Static Routing と Dynamic Routing

先述したとおり、ルーティングプロトコルには、Static Routing(静的経路制御)とDynamic Routing(動的経路制御)の2つがあります。正しくは、ルータが直接接続しているネットワークであるConnected(直接接続経路)もありますが、そのままなので説明は省きます。

  • Static Routing
    • 静的に設定された経路情報を使う
    • メリット
      • 帯域幅が狭い時に適している
        • Dynamic Routingのような経路探索のための通信が発生しないため
      • ルータに負荷がかかりづらい
        • 入れた瞬間にルータ自身のRIBとしての計算は走るが1回のみ
    • デメリット
      • 障害があったときに死んだまま
      • ネットワークが大きくなればなるほど設定が辛い
  • Dynamic Routing
    • ルーティングプロトコルにて他のルータの経路情報を使う
    • メリットとデメリットはStatic Routingのvice versa
    • ルーティングプロトコルとして、IGPならOSPF、EGPならBGPが有名
      • OSPFに関しては、DR*1とBDR*2を用意して、それらのルータにコネクションを集中させることで、ネットワーク全体のコネクション数を削減している
        • BDRはバックアップという位置付けではあるが、実質ダブルマスターの構成のイメージ

この後、ISPネットワークへの攻撃手法と対策、監視と制御、SDNに関する話がありました。午後のハンズオンに大きく関わる訳ではないので詳細は省きますが、基本的な内容でした。

午後 - ハンズオン

ハンズオンでは、提示された要件を満たすネットワークを構築しました。
ネットワークは2つのASから構成され、AS間はEGPとしてBGPを、AS内ではIGPとしてOSPFを用います。

ネットワーク機器の設定でミスが発生すると大きな障害に繋がり、最悪の場合SLAに大きな打撃を与える可能性があります。そのため、データベースのトランザクションのように、変更がCommitされるまで適用されないという特徴を兼ね備えているものが多いそうです。

今回のネットワーク内ではJunos(Juniper Networks)およびCisco IOS(Internet Os Software)が混在していました。いずれも処理の流れに大きな違いはありませんでした。

基本の流れは下記の3手順でした。

  1. 状態の確認
  2. 変更のプール
  3. 変更の適用

ネットワークの構成図は非公開だと思うので、ハンズオンでよく利用したコマンド等を備忘録として貼っておきます。困ったらヘルプが見れるので大体 ? を実行しておけば良いです。

Junos OS

Junos OSはシェルコマンドモード、オペレーションモード、コンフィグレーションモードの3つのモードが存在します。下記ページの説明がわかりやすかったです。

www.infraeye.com

よく利用したコマンドは下記の通りです。大体 ? を実行するかドキュメントを参照すればなんとかなります。

  • オペレーションモードからコンフィグレーションモードに移行したい時
    • configure
  • 現行の状態を表示したい時
    • show ${表示対象のキーワード}
    • 困ったら show ? でなんとかなる
    • e.x.) show configuration, show route
  • 情報を新たに設定したい時
    • set ${表示対象のキーワード} ...
    • 困ったら set ? でなんとかなる
  • 変更を取り消したい時
    • delete ${削除対象のキーワード} ...
    • 困ったら delete ? でなんとかなる
  • commit前の変更差分を見たい時
    • show | compare
  • commitする時
    • commit check で変更内容のバリデーション
    • commit でコミット

Cisco IOS

Cisco IOSは4つのモードがあります。下記ページの説明がわかりやすかったです。

www.infraexpert.com

よく利用したコマンドは下記の通りです。大体 ? を実行するかドキュメントを参照すればなんとかなります。

  • Privileged EXECモードからGlobal Configurationモードに移行したい時
    • configure terminal
  • 現行の状態を表示したい時
    • show ${表示対象のキーワード}
    • 困ったら show ? でなんとかなる
    • e.x.) show running-config
  • 情報を新たに設定したい時
    • 設定したいコンフィグレーションモードに入る
    • コンフィグレーションモードに入ると、(config-*)# の様に表示される
      • interfaceのコンフィグレーションなら (config-if)#
      • routerのコンフィグレーションなら (config-router)#
  • 変更を取り消したい時
    • no句を接頭辞として、情報を新たに設定したい時と同じ処理を実行すれば良い
    • 困ったら no ? でなんとかなる
  • commit前の変更差分を見たい時
    • show commit changes diff
  • commitする時
    • commit でコミット

Extra Stage

追加課題が5つ用意されていた内2つ解きました。その時の問題と解答例をこちらで供養しておきます。

1.任意のリンク切断

  • 任意のリンクを切断することによりルーティングテーブルやTrafficにどのような変化が起きますか?
    • 切断したリンクのTrafficが0になった
    • ルーティングテーブルは確認していないが、リンク切断に応じてそのルートの優先度が低い並びに変更されていると考えられる
  • Dynamic Routing Protocol(OSPFやBGPなど)はどのようなしくみで動的に経路を制御しているでしょうか?
    • Neighborとの到達を確認することで、そのコストを動的に確認することで制御していると考えられる

2.in-boundおよびout-boundのtrafficをねじ曲げる

  • 指定した経路をTrafficが流れるように設定を変えてください
    • 指定した経路のBGPのLP(LOCAL_PREF)属性を高く、MED(MULTI_EXIT_DISC)属性を低くする
      • ちなみに、configを見る限り、LPはINはout-bound用に、MEDはin-bound用に利用されると考えられる
    • 指定した経路以外の経路に逆操作を行う
  • Static Routing/Dynamic Routingそれぞれのメリット/デメリットとして何が考えられるでしょうか?

おわりに

マスタリングTCP/IPの入門編程度しか読んでいなかった中で、実際にコマンドを実行しながらISPネットワークの構築とルーティングプロトコルについて学べるイベントでした。そもそもASを複数利用する現場にJOINすることがなかった(今後もなさそうな)ので、非常に貴重な経験ができたと思います。

来年も実施されるようであればぜひ参加してみてはいかがでしょうか? (これ毎回言ってる気がしますね)

*1:Designated Router: 代表ルータ

*2:Backup Designed Router: バックアップ代表ルータ

2021年の振り返りと2022年の目標を述べてみる

はじめに

こんにちは。task4233です。
この記事は私の2021年の振り返りと2022年の目標をまとめるために書かれました。

2021年は研究を控えめにしてインターンシップに注力した年でした。多少の悔恨はあるものの、悩んだ末に決めた振る舞いだったのでこれはこれで良かったのかなと思います。2022年は一心不乱に研究に取り組みたいと思います。

今年もポエム多めなので、興味のあるところだけ拾い読みしてください。

過去の振り返り記事たち

もくじ

2021年の振り返り

2021年1月1日に掲げた目標は以下の3つでした。

そのうち、1つを達成しました。

「え、1つだけ?」と思った方もいると思うので、それについてざっくり述べようと思います。

私は研究者になりたいのか、開発者になりたいのか

結論から言うと、私は研究者よりも開発者になりたいと思ったので、研究は控えめでインターンシップをたくさん経験するという選択をしました。この選択に至った理由は2つあります。

まず、やったことが誰かの役にたって欲しいという思いが私の中にあると気づいたためです。
これは主観ですが、研究の8割は実世界で使われることがないと思っています。もちろん、ある研究にインスパイアされて開発された製品やソフトウェアは五万とあるでしょう。しかし、それが世の中に出るまでに数年〜数十年かかるはずです。私はこの事実を楽しいと思えなかったため、私は研究を主軸に置いた職が合っていないと思ったのが理由になります。

次に、研究を続ける環境が開発を続ける環境よりも整備されていなかったためです。
これも主観ですが、研究は1人で続けるものではないと思っています。もちろん一流の研究者はそれができるのかもしれませんが、私は一介の学生に過ぎません。その点で、私の所属している研究室は放任主義です*1。教授が次の研究テーマについて口を出してくる訳でもないですし、進捗に対して口うるさく言ってくる訳でもありません。必要であれば教授にアポを取って相談するという形になりますし、輪読と進捗報告は月にそれぞれ1回あるくらいです。

私はこの研究室の体制に不安を感じ、同じ研究を続けられるような筑波大学院のとある研究室を受験しました。曲がりなりにも学部時代に人並みにCSを学んでいたため、問題なく試験は通過できました。しかし、その研究室の輪講に参加させていただいたときに、コメントがほとんど飛び交っていない事実に絶望しました。そこで、結局研究室を変えても意味はないのだな、と悟ったのをよく覚えています。

それならば、今いる研究室の環境をよりよくする方向にシフトした方が良いと思い、最近はその働きかけに取り組んでいます。
私の力ではありませんが、研究室のSlackがProプランになりました。それと、研究室のGitHubがなかったので勝手に作りました。良いですね。

以上が、私が研究者よりも開発者になりたいと思うに至った経緯です。
後述しますが、計10個のインターンシップに参加して、研究の進め方にヒントを得た気がしたので2022年は実践していこうと思います。

SecHack365 研究駆動コースのアシスタントを担当させていただいた件

閑話休題、そんな私に、3月ごろ研究駆動コースのコースマスターである猪俣先生からアシスタントのオファーをいただきました。私は昨年の研究駆動コースの中では落第生寄りという自己評価をしていたので、オファーをいただいた時は非常に驚きました。しかし、オファーをいただいたからには自分ができることを最大限やってやろうと決めました。

その後、私に求められているものについて熟考した結果、研究時のアドバイス以外に

  • 習慣化セッションへの助力
  • アシスタント側の企画出し
  • 開発系のアドバイス・知見の共有
  • 1on1の実施

といったことを僕ならサポートできるだろうと思い、コースワークの他に尽力してきました。

結果として、アシスタント側の企画書は事務局の方に好評でしたし、実施した1on1も良かったと言ってくれたトレーニーもいたので、少しでも力になれたと思いたいです。

研究駆動のトレーニーの方々に「アイツ、研究してないのに何偉そうにコメントしてんだ?」とか思われてたら泣いちゃいますが、アシスタントとして最後までサポートできることはやっていこうと思います。

また、習慣化では本当にお世話になったので、今年も継続しています。毎日の筋トレや1日1コミットを続けています。

f:id:task4233:20220101020700p:plain
365 Days of Codeを達成した図

個人的にとても嬉しいです。

インターンシップにて得られたもの

一方で、私が今年最も力を入れていたインターンシップでは多くのことを得られました。その中で、特に価値があったと感じているものは、タスクの進める時の質問の仕方タスクの進め方図々しさです

タスクを進める時の質問の仕方

ドキュメントから得られないドメイン知識*2に関する情報は、積極的に早めに聞くべきだと思います。逆に、普遍的に得られる情報は、自分で調査する癖をつけると調査する力がつくので、可能な限り自分で調査するべきだと思います。

前提として、質問とは相手の時間を奪う行為だと思っています。とはいえ、質問回数をゼロにすることは、自分のタスクを停滞させる要因になり得るので悪手に他ならないとも思っています。
そこで、可能な限り意味のある質問をしたいです。

では、意味のある質問とは何でしょうか。
私は、質問者がいくら調べても答えが得られない情報を得るための質問だと思います。

そのような質問がドメイン知識に関する情報を問う質問です。そのため、インターン生は、ドメイン知識に関する情報は質問した方がタスクを速く進められるはずです。

逆に、インターン生のメンターは、事前にドメイン知識をドキュメントにまとめておいたり、ドメイン知識の理解に役立つドキュメントの在処を提示すると良いと思います。
ここで、最初にオリエンテーションを設けて口頭で説明する方もいましたが、インターン生は聞くだけでは結構聞き落とすことが多いので、文字にして残すのがオススメです。
更に、こういう時は質問してね、こういう時は自分で考えてね、といったことを共通認識にしておくと良いかもしれません。たかが数分のSyncでその後の進捗が大きく変わるはずです。

タスクの進め方

手に余る大きいPRを1つ作るのではなく、細分化されたPRを小さく複数作ってレビューしてもらった方が結果的に速く終わると感じました。

大体のインターンシップでは、1つのJIRAチケットを切られて、そのタスクに取り組むことが多かったです。
このタスクが十分に細分化されていたならば問題ないですが、実装方針が一度に描けないのであれば細分化した方が良いと思いました。

ここで、タスクを細分化するデメリットとして、しない時と比べてレビュアーの時間を多く奪ってしまうことを、私は危惧していました。
これをとあるエンジニアさんに相談したところ、

  • 第一に、君のタスクは"君だけ"のタスクじゃない
  • レビュアーも開発メンバーの一員
  • 君がそこで小さく切り出すことでレビュアーはレビューごとに解像度が上がる
  • レビューはレビュアーを君のタスクに巻き込む手段にすぎない

という話をされたのがきっかけで、小さなタスクで切り出すようにしました。その結果、タスクを進める速度は結構速くなった気がします*3

この小さく作って小さくレビューしてもらうサイクルは研究でもできることだと思いました。タスクの細分化は大事とよく言いますが、細分化した後の進め方として迷ったときにレビューを挟むと言うサイクルを入れていない場合が多い気がしました。そのため、2022年の研究ではこれに気をつけて進めていこうと思います。

図々しさ

そして、図々しさも得られたと思います。 図々しさっていいことなのか?と思うかもしれませんが、開発現場では図々しさが美徳な気がしました。

これは私が一方的に尊敬している方の話なのですが、彼はとてもアクティブで前のめりに発言して、考えるよりも手が先に出るタイプの人です*4。彼の近くで1年間研究を続けてきて、基本的に図々しい方が欲しい情報は得られる気がしました。私もそれに倣って意外と図々しく過ごしてきた方だと思いますが、結果としてより多くのものを得られた気がします。

学部卒で社会人になっている友人に「陽キャはあんま仕事できなくても声が大きいだけで評価高いんだから理不尽な世界だよな」と言われたことがありますが、それができることが凄いことなんだなと思うなどしました。

その他

また、言うまでもありませんが、技術面とコミュニケーション面でも大きく成長できました。下手なエンジニアよりも成長してる気がしますね*5

技術面で成長できた要素は以下の通りです。

  • 実践を通したクリーンアーキテクチャの理解
  • Goの内部仕様の理解
  • 負荷試験を実施する際の指標・ツールの理解
  • A/Bテストを実施する際の指標・ツールの理解
  • 既存コードの文法に併せてシュッとコードを書く力
  • アプリケーションを設計する力
  • ドキュメントを読んでコードに反映する力
  • 設計書を書く力
  • ユニットテストを意識した設計・コードを書く力
  • MVPを意識して設計・実装を行う力
  • k8sの基本的なコンセプトに関する理解
  • AWSGCPのリソースを活用して開発に取り入れる力
  • OAuth2/OIDCの実例から学ぶ認証/認可の流れの理解
  • TerraformのCustom Providerを実装する力

コミュニケーション面で成長できた要素は以下の通りです。

  • 自分の施策を他人に構造的に伝える力
  • 同期的コミュニケーションと非同期的コミュニケーションの得手不得手

おそらくまだまだあると思いますが、今パッと思い浮かんだのはこんな感じです。

今思うと、インターンシップに行き過ぎた気もしますが、将来を考えるといい選択だったなと思います。インターンシップの話を聞きたい人がいたら*6気軽に話を振ってくれれば対応します。

失敗した朝活

冒頭でも書いた通り、朝活は見事に失敗しました。要因は大きく分けて2つあると思っています。

1つ目の要因は、朝早く起きるモチベーションが続かないことです。 実は、3月ごろまで、はてなブックマークでまとめられている記事について話す会をClubhouseでやっていたのですが、結局モチベが続かずにやめました。

やるなら何か朝やることを作ると良いのだと思いますが、特に毎日やりたいことは夜にやっているので 🤔 という顔になっています。そこで、2022年は夜寝る前にやっている読書を朝やってみることにします。

2つ目の要因は、就寝時間が遅いということです。 当然ながら就寝時間が遅いと早起きできる訳ないですね。そこで、9月ごろからみんちゃれと言うアプリで、1時までに就寝するグループに入って今まで継続しています。意外と時間をオーバーしてしまうことがありますが、これをやっているお陰で徹夜することはないと思います(今日はのぞきます)。

minchalle.com

実はとある2daysのハッカソンで徹夜してしまい、2日目で寝落ちした経歴があるのでそこから徹夜はしないようにしています(今日はのぞきます(2回目))

2022年の目標

  • 学外発表を1回はする
  • 毎朝5分は読書する
  • 7月に軽めの振り返り記事を書く

2022年の目標を立てようと思ったのですが、将来のために必要なことを2021年のうちにほとんどやってしまったので、今年の上半期は研究8割、就活2割くらいで頑張ろうと思います。下半期は何をしようか決めていないので、上半期が終わったら軽めの振り返り記事を書こうと思います。

おわりに

以上が、2021年の振り返りと2021年の目標でした。

2021年は目標と異なる年になってしまいましたが、結果として今しかできないことを享受できたので本当に良い年だったと思います。

長くなってしまいましたが、ここまでお読みいただきありがとうございました。今年も1年よろしくお願いします。

*1:それが普通なのかもしれませんが

*2:その業界・チームのみの専門知識。例えば、サーバの構成など。

*3:一方で、PRを複数出すときは修正内容を被らないようにしてほしいと言われました。これは私の改善点です......

*4:前のめりに発言しすぎてて、一瞬ギョッとさせられることもありますが

*5:ダウトです

*6:いるのか?

気が沈んだ時や不安な時にやっていること

この記事は目黒ワンニャンパーク Advent Calendar 2021 の 6日目の記事として執筆されました。7日目の記事はeuxn23さんのこれが本当の目黒ワンニャンパークだです。

はじめに

こんばんは。task4233と申します。Goが好きで、最近は誕生日にCTFを開催してた大学院1年生です。

本記事ではタイトルにもある通り、気が沈んだ時や不安な時に意識的にやっていることをポエムにしたものです。このポエムで書かれていることは100%正しい訳ではないので、参考程度に留めていただければ幸いです。

TL;DR

  • 課題の分離をすると良いかもしれない
  • わだかまりを何かに書き出すと良いかもしれない
  • 瞑想をすると良いかもしれない

もくじ

この記事を執筆するに至ったきっかけ

最近、将来について考える機会が増えたり、人と関わる機会が増えたりしたためか、気が沈んだり猛烈な不安に襲われたりすることが増えてきました。

今までは、こういう時には不安の根源が何なのか考えて、その根源を改善するために何ができるのかを考え、それでもどうしようのない場合は友人に相談することで解消してきました。実際に、本アドカレの発足者である、なかひこさんにもお話を聞いていただいたこともあります。その節はお世話になりました。

しかし、仮にその結果自分で納得したとしても*1、その全てが精算される訳ではなく、多少のわだかまりが残ります。部屋を頑張って掃除しても、隅の方にホコリが溜まっていくようなものです。

このわだかまりは通常時間と共に消えていくのですが、最近はこの回数が増えてきたので、どうしようかと悩んでいました。

そこで、色々と調べてみました。

その課題はあなたが介入できる課題なのか

まず最初に手に取ったのは、嫌われる勇気という本でした。この本は、悩みを持つ青年が哲人と会話をしながらアドラー心理学に踏み込んでいく本です。このアドラー心理学は賛否両論ありますが、人間関係に苦しんでいた高校生くらいの時に読んでみて救われたので、私は良い本だと思っています。

話が逸れましたが、この本では「課題の分離」という概念が提示されています。この「課題の分離」とは、その課題があなたの課題なのか他人の課題なのかを切り分けて考え、お互いに相手の課題に踏み込まない概念のことと私は理解しています。「課題の分離」をすることで、あなたが介入できる事柄と介入できない事柄に分けて考えることができ、困難な状況の解消に繋がることが多いです。

この分離には下記の2つの質問に照らし合わせて考えることができます。

  • その課題の責任を最終的に負うのは誰か
  • その課題の結論を最終的にだすのは誰か

要するに、その課題の主体は誰なのかという話と似ていますね。主体があなたならばそれはあなたの課題でしょうし、他人なら他人の課題のはずです。

例えば、「Twitterのタイムライン上に鬱陶しい人のツイートが表示されていたので、あなたが気分を害した」という場合を考えます。この場合、

  • あなたが介入できる事柄
    • タイムラインに表示されるツイートの設定
    • 鬱陶しい人のブロック・ミュート
  • あなたが介入できない事柄
    • 鬱陶しい人のツイートそのもの
    • 鬱陶しい人の性格・考え

のように分離できます。そのため、この場合は、あなたが介入できる事柄である、ツイート表示設定の変更をすることで問題を解消できます。逆に、鬱陶しい人に対して、取り消しをお願いしたり、思考を正すように言ったりするのは、相手の課題に踏み込む行為なのでしない方が良いと思います。

本の中では人間関係に絞って考えていますが、この考えを一般化して捉えると、その課題はあなたが介入できる課題なのか、それとも介入できない課題なのかになると思います。気が沈んだ時や不安な時にこれを実践すると、意外と簡単に課題が解消されることもあります。

そのため、課題がある時には課題の分離をして、

  • あなたが介入できることは改善タスクに積む
  • 他人の課題には介入せず関わらないようにする

とストレスフリーで良いと思います。

それでも、頭では理解できていても、モヤモヤすることもあるでしょう。そのモヤモヤはどのように解消できるのでしょうか。

モヤモヤ君へのおてがみを書く

そもそもモヤモヤとは、課題があるが課題が何なのかが分かっていない状況にあると考えられます。Five Orders of Ignoranceの2OIや3OIに該当しますね。

下記の画像は質問に関する5OIですが、分かりやすかったので貼っておきました。

f:id:task4233:20211214031551p:plain
5OI

qiita.com

したがって、不明瞭な課題を明瞭にするための手段が必要です。ここで使えるのが、モヤモヤを何かに書き出す行為、通称、モヤモヤ君へのおてがみです。

このおてがみは、簡単にいうと、あなたのモヤモヤに向き合うヒントを見つけるために、手紙で語りかけるように書き出す行為です。下記の記事がまとまっているので、興味のある方は1度目を通してみてください。

style.nikkei.com

この施策がうまく刺されば、1OIに持っていけるので、その後課題の分離に基づいて次のアクションをとれば良いです。

私はこのモヤモヤ君へのおてがみをGitHubのIssueで管理しています。こちらがIssue Templateになります。

https://raw.githubusercontent.com/task4233/life/8df894dafccf86108207517c07ad646019655d10/.github/ISSUE_TEMPLATE/self-therapy.md?token=AHCLCSBLG2MIP4PJHYIO6FLBYDA2C

そして、恥ずかしながら、このテンプレートを使って書き出したIssueの例がこちらです。

f:id:task4233:20211214032051p:plain
前に書いたやつ

黒歴史ですね、もしかしたらこのブログもモヤモヤ君に届くかもしれません。それはまた別の話です。

瞑想も1つの手段ではある

今までで書いてきたのは、ポケモンでいう「はねやすめ」のような大幅回復系の手段だと思いますが、毎ターン少しずつ回復してくれる「たべのこし」のようなものがあるとより良いですよね。

その手段として使えるのが寝る前の瞑想です。この瞑想は坐禅を組んでやるようなカッチリした瞑想ではなく、マインドフルネス瞑想と呼ばれるものです。

私はYouTubeの音声に従っているだけなのでよくわかりませんが、簡単にいうと心を落ち着かせて1日を振り返る行為のことです。その音声でとても良いなと思っているフレーズが、今日という1日が良かった人も、そうでなかった人も、あなたがその時にできた最善の選択をとってきたことを理解しましょう といったフレーズです。

結果的に良くない結果、行為になってしまったとしても、人はその時に良いと思って行動しているはずです。自分から悪いと思って行動する人はそもそもその行動をしないと思いますし。だからこそ、やってしまったその行為への罪悪感を反芻するのではなく、その時のベストだったんだからしゃあない、くらいの気持ちでいると気が楽です。

おわりに

読み返してみると、結構なポエムになってしまいましたが、誰かのためになれば幸いです(なるのか)?

7日目の記事はeuxn23さんのこれが本当の目黒ワンニャンパークだです。興味があればご覧になってみてはいかがでしょうか?

*1:こういう時は納得した気になっているだけで、根本の問題は解消されていない気がします

CODE BLUE 2021 @TOKYO 学生スタッフ 参加記録

こんばんは。task4233(@task4233)です。

2021年10月19日-20日の2日間、東京ポートシティ 竹芝ポートホールで開催されたCODE BLUE 2021 @TOKYOに学生スタッフとして参加してきました。

今回は2回目の参加であり、前回の参加記にも書いた通りスピーカーアテンドを希望してスピーカーアテンドに従事させていただきました。

兎にも角にも, CODE BLUEは非常に楽しめたカンファレンスでした。来年度も縁があって参加できるようならば, スピーカーアテンドに挑戦するつもりです。

ref: CODE BLUE 2019 @TOKYO 学生スタッフ 参加記録 - task4233のめも

学生スタッフの概要に関しては上記の2年前の記録に書かれているため、今回は下記の3点を共有するために本記事を投稿します。

  • スピーカーアテンドの概要
  • スピーカーアテンドとしてお手伝いした感想
  • 改善されると良いなと思ったこと

もくじ

スピーカーアテンドとは

スピーカーアテンドの責務は、スピーカーが気持ちよく講演できるように全力を尽くすことです。基本的な業務は下記の2点です。

  • いらっしゃったスピーカーを待合室にご案内すること
  • スピーカーを登壇前に発表場所までご案内すること

ただし、これ以外にも言語化されていない業務は複数あり、いかにスピーカーに気持ちよく講演してもらうかを意識して、臨機応変に自分の頭で考えて対応する必要があります。

スピーカーアテンドとしてお手伝いした感想

非常にやりがいのある仕事でとても楽しかったです*1

最低限しなければならないことは定義されていますが、他の作業はベストエフォートです。私は同じ作業を淡々とこなすよりも色々と考えて作業する方がワクワクしますし、体を動かす方が好きなので、今回の業務に明示的に含まれていなかった業務フローを勝手に追加したり、一部フローを変えたりして従事させていただきました。

その結果、担当させていただいたスピーカーに感謝を伝えられることが何度もあり、スピーカーの方々に気持ちよく講演していただくことができたと考えています。

改善されると良いなと思ったこと

COVID-19の影響です。アイツらのせいで色々と不自由があり、非常に残念でした。

そんな状況下でもオンサイトで開催していただいた運営メンバー、ご協力いただいたスポンサーの方々、登壇していただいたスピーカーの方々に深く感謝いたします。

学生スタッフがより楽しくなるムーブ

来年参加する学生に向けて、老婆心ながら2つだけ書いておきます。

  • 名刺の作成
    • 名前、所属、SNSアカウント、連絡先等は書いておくと良いと思います
    • 渡すときに簡易的な自己紹介ができると良いと思います
  • 気になった業務の相談
    • 業務をやる上で、「こうだったら良いのに...」と思ったことはスタッフに相談した方が良いです
    • 大体改善されるので、改善案も併せて提示すると良いと思います

おわりに

今回もおかげさまで非常に楽しめました。

前回の参加記に書いた通り、今回私はスピーカーアテンドとして参加させていただきました。そのため、次回はNOCメンバーとしてCODE BLUEに従事したいと考えています*2

そして、学生スタッフはセキュリティに興味のある他の学生との交流の場でもあるため、普段触れることのない技術のセキュリティに関心を持つきっかけにもなり得ます。今回だと、例えばゲームAIに用いられるGOAPシステム、ETC等に用いられるDSRCというプロトコルAndroid用APKファイルの構造などです。 少なくともCODE BLUEに来ている他の学生は、自分よりも強い分野を1つは持っていますし、他の学生と雑談するのも楽しみの1つなのかもしれません。

また、今回配信された動画は全てアーカイブとして学生に共有されるとのことで、後ほど閲覧できるのが非常に楽しみです。

セキュリティに興味がある学生は、他の場所では経験できないことを経験し知見を広めるチャンスです。そのため、来年度も募集がかかった場合は、ぜひ学生スタッフに応募してみてはいかがでしょうか?

*1:初日遅刻してしまったのは内緒です

*2:NOCメンバーの方々、なにとぞ......

ヤフーのインターンシップで広告配信システムの機能追加フローを一通り経験してきた

はじめに

こんにちは。 8/30(月)~9/10(金)で、Yahoo! JAPAN(以下ヤフー)のインターンシップに参加してきました。

about.yahoo.co.jp

そこで、ディスプレイ広告に用いられるコンテンツキーワードターゲティングに用いられるロジックの機能追加フローを一通り経験してきました。

コンテンツキーワードターゲティングとは

一言で言うと、広告をより適したページに提供する仕組みです。

コンテンツキーワードターゲティングは、広告が表示される掲載面を指定するターゲティングの一つです。広告を配信したい(または配信除外したい)ウェブページやアプリのコンテンツをキーワードで指定して、掲載面を調整します。

ads-promo.yahoo.co.jp

この技術はGoogle Adsでも利用されており、Keyword contextual targetingと題して運用されています。

support.google.com

経験したこと

今回は、中身のとあるコンポーネントに利用されるロジックについて、一通りのフローを経験してきました。

一連のフローとは、

  • 設計
  • 実装
  • リリース
  • A/Bテスト
  • 結果に対する考察
  • 改善案の提示

のことです。

設計と実装はどこのインターンシップでも経験できると思いますが、リリースとA/Bテスト、結果考察まで経験できたのが特に貴重でした。

また、A/Bテスト中やレビュー待機中に他のコンポーネントの実装や修正も経験でき、圧倒的進捗をうみだすことができました。

学べたこと

ブレのない開発のために、

  • 実装の目的を意識すること
  • テストのスコープを意識すること

が重要であることを経験を通して学びました。

今回は2週間のインターンシップでしたが、A/Bテストの実施とその考察までできたのは、手戻りがほぼなかったからだと考えています。

実際に、設計のための議論や実装のレビュー時に、「これの目的って〜だから、その設計は目的とズレてない?」や「そのテストって何のためにやるの?」といった指摘をいただけたことが何度もありました。

これらは言語化されていませんでしたが、私の所属した部署の方々は既に理解されていたようで、流石レベルが高いと思いました。

インターンシップを通して

基本的に手が止まっていた時間がなく、余った時間で常に何かをしていたので、2週間という期間ながら本当に満足度の高いインターンシップでした。

そして、学べたこと、経験できたことも幅広かったです。

  • 業務に利用した技術
  • 新たに経験できたこと
    • 実装のリリース
    • A/Bテスト

また、定期的に1on1やランチ会を実施してくださったおかげで、最初の1週間でかなりメンバーと仲良くなれました。その時に使った資料も、反響が大きかったので良かったなと思っています。

speakerdeck.com

おわりに

全体としての感想は、一言で言うと「レベルの高い環境だった」です。広告配信系が生み出す利益が多いのからかもしれませんが、KPIを強く意識していたと思いました。そのために、どのような施策をすれば良いのか、エンジニアが考えて実行していたので、レベルの高い環境だと感じました。

ヤフーは配属ガチャがあるので、今回の環境が別でも満たせるかは分かりませんが、少なくとも今回の環境は非常に良い環境だったと考えています。

最後になりますが、今回のインターンシップについて尽力してくださったメンターの方々、関わってくださった方々、ありがとうございました!

VOYAGE GROUPのTreasureに参加して圧倒的成長をしてきた

はじめに

こんにちは。task4233です。

8/9(月)〜8/27(金)の3週間、株式会社VOYAGE GROUP(以下VGと略します)のTreasureに参加してきました。

このエントリでは、前半に行われた講義の概要と後半のチーム開発についてサックリ書きます。
最後にも書きますが、Treasureは他のインターンシップでは得られない経験が多く、本当に素晴らしいインターンシップでした!

もくじ

Treasureとは

Treasureとは、VGのエンジニア向け3週間インターンシップのプログラムです。
今年度は、前半に現場のエンジニアから講義を受け、後半にチーム開発を行いました。

このインターンシップのコンセプトは、「学生のスキル成長」です。
そのため、インターン開始前から人事や講師、サポーター陣からサポートを受けることができました。
また、インターン中も1on1が実施されるなど、非常に手厚いサポートがありました。

詳しくは下記の記事をご覧ください。

focus.voyagegroup.com

このように、「学生のスキル成長」がコンセプトであるインターンシップがTreasureです。

5つの講義

この章では、それぞれの講義の概要と感じたことをそれぞれ書きます。

2021年度のTreasureでは5つの講義が実施されました。
その講義は、バックエンド講義、フロントエンド講義、インフラ講義、DB講義、アイデア講義の5つでした。

バックエンド講義では、peiさんによるGoのハンズオンが実施されました。
個人的には、Goの書き方よりもAPI設計の心得が学びになりました。

また、peiさんからは、昼休みの雑談でデータモデリングに関する話が聞けたのがとても良かったです。
ビジネスのデータの扱い方とデータ解析者のデータの扱い方が異なるという話からディメンション・モデリングの素養まで教えていただき、知見しかなかったです。ありがとうございました。

フロントエンド講義では、ちゅうこさんによるTypeScript+Reactのハンズオンが実施されました。
私はTreasureに参加するまでPureJSとVue.jsを少し書いた程度のひよっこだったので、バックエンド講義よりも学びが多かったです。
特に、バックエンドの都合をフロントエンドのロジックに紛れさせないために、境界面できっちりエラーハンドリングをする話が一番の学びでした。

インフラ講義では、SyotaさんTonoさんによる、AWS CodePipelineを用いたCI/CDの構築のハンズオンが実施されました。
私は普段GCPをよく使うので、GCPの各サービスにAWSのどのサービスが該当するのかを使いながら学ぶことができました。

DB講義では、t_wadaさんによる、データモデリングの概観説明とハンズオンが実施されました。
この講義では、2021年におけるRDBMSの位置付けに関する話が前半にあり、この内容が元々なかった視点だったので、特に学びになりました。

イデア講義では、きっしーさんとガイアさんによる、価値あるプロダクト(MVP)の見つけ方の説明とグループワークが実施されました。
この講義では、UNS(User/Needs/Solution)に分けて段階的にアイデアを考える手法をグループワークを通して体験することができました。

実際に、ここで出たアイデアが後半のチーム開発で開発されたので、良い議論ができたと思っています。

以上の5つの講義は、その全てにハンズオンが取り入れられており、手を動かしながら学べたのが実に良かったです。

実は、この講義内容や数はVGのクルー同士で議論して毎年改変が加えられるそうです。力の入れ方が凄いですね。

チーム開発

この章では、チーム開発の概要と感じたことを書きます。

チーム開発は、アイデア選定含め、後半の約1週間で行われました。
この開発期間では時間外開発(18時半以降の開発)が禁止されていたため、開発できる期間が限られていました。
そのため、各チームはアイデアの核になる要素を思索し、それを満たす最小構成の実装を行う必要があり、技術力以外のスキルが研鑽された1週間でした。

私達のチーム「ホリネズミ」は、最初の3日をUNS固め、1日を環境整備、最後の3日を開発に使いました。
前半UNS固めの段階で1度UserとNeedsを定義したにも関わらず、チームメンバ間で認識の齟齬があったために、その定義を放棄して1から考え直すこともありました。

正直、認識の違いはスルーすることも出来たはずですが、チームメンバがお互いに意見をぶつけ合うことでより良いアイデアを発想できたと思っています。
この絞り出されたアイデアを実現するためのコアな機能のみを実装することで、1週間という短い期間ながらも最後まで全力で走り続けた結果、なんとか動くものが開発できたのは良かったです。

この特徴的なエピソードとして、Socket.IOを用いたリアルタイムチャットの実装が時間的に間に合わなそうだということが最終日に分かったため、REST APIの実装に差し替えてポーリングする方針に変えたというエピソードがあります。最終的に動かないゴミになることはなかったので、このインターンシップにおいては良い選択だったと思っています。

そして、結果的に「ホリネズミ」はグランプリを受賞できなかったものの、CI/CD賞をいただくことができました。
賞の発表を聞いた時は、全力を出し切った後だったのでぼんやりしていて、あまりリアクションが取れなかったのをよく覚えています。

とはいえ、時間外の開発を許してくれればもう少し開発できたので残念という気持ちもあります。
しかし、後述するAjitingでチーム開発のことを忘れて技術トークをできたので、悪い面ばかりではなかったと思っています。

Ajitingでのお話

VGでは、業務時間後に有志が集まる習慣があります。これは参加自由でインターン中は毎日開かれていました。
Ajitingは好きなことを話す場なので、ISUCONのチーム練習を配信したり、競プロの問題を画面共有して解いたりする人もいました。
中には、原神や筋トレ、ボルダリングを布教する人もいました。面白い人がたくさんいるなと強く思いました。

Ajitingで深夜にJavaScriptの謎挙動でワイワイするTreasure生の図
Ajitingにて深夜にJavaScriptの謎挙動で遊ぶTreasure生の図

コロナ禍で人と定期的に話す機会が減っていた私にとって本当に楽しい時間でしたし、毎日別の話題で学びがあるのはとても刺激的でした。

おわりに

ここまでで、Treasureの講義の概要とチーム開発、Ajitingについて書きました。

全体としての感想は、一言で言うと「本当に楽しかった」です。夏に圧倒的成長をしたいという全ての学生にオススメしたいインターンシップでした。

技術的な学びは言わずもがな、議論を進めるときの効率的な進め方やアイデアの発想方法、開発するときのコミュニケーションの取り方を体系的に学べたのが本当に大きな収穫でした。
その点で、当初の目的であった「スキル成長」は満たせていましたし、Ajitingとチーム開発によって横の繋がりができたので本当に有意義な時間になりました。

また、VGという会社が*1どういう会社なのかを知ることができたのも良かったです。
クルーの全員が考えて行動し、言われた仕事をやるだけ人間が1人もいないと感じられるほど、面白い方々ばかりでした。

最後になりますが、チームホリネズミのメンバー、Treasureに関わってくださったVGの皆さん、そして私と関わってくださった皆さん、本当にありがとうございました!

*1:今はCARTA HOLDINGSですが