社会人って「いつ死んでも良い」って言う人多くない?

社会人になってからちょくちょく「俺はいつ死んでも良いと思ってる」と発言する人に出会う。 新卒でベンチャー気質の会社に入ったのもちょっとは関係しているのかな。 新卒で入った会社の上司がまさにそのうちの一人で「俺は人生は暇つぶしだと思っているし、いつ死んでも良いと思っている。今俺が生きている理由は俺の周りの人達を幸せにしたいからだ。」と言っていた。 こういう類の発言ってどうにも嘘っぽく感じてしまって駄目なんだよな。 「俺の周りの人達を幸せにしたい」は別に全然良いと思うんだけど、「俺は人生は暇つぶしだと思っているし、いつ死んでも良いと思っている」は十中八九嘘でしょ。 一休さんなら「分かりました、ではまずここで死んでみせてください」と言えるんだろうけど、そんなの社会人として言えるわけがないしな。 ちなみにその上司はバイクで転倒して鎖骨とか肋骨を折る大怪我をしたんだけど、普通に手術して、普通にリハビリしてた。 やっぱり人間はみんな生きたいんだよな。 そろそろ死を利用してカッコつけるのやめないか?

2025-03-19

TryHackMeが面白い

『TryHackMe』というサイトがある。 わざと脆弱性を残してある仮想環境に対して攻撃を行うことでセキュリティの勉強をすることができるサイトだ。 こういう種類のゲームをCTF(Capture The Flag)と呼ぶらしい。 セキュリティの勉強をするなら自分が攻撃者側を体験するのが一番効率的だというコンセプトなんだろう。 自分はYoTubeで以下の動画を見てTryHackMeの存在を知った。 これが結構面白い。 攻撃の手順は割とテンプレ化できるところがあるので、よく使うサイトやコマンドをいつでも見返せるようにこの記事に残していく。 この記事は定期的に更新していくタイプの記事にする予定。 よく使うサイト pentestmonkey https://pentestmonkey.net/ リバースシェルのコマンド等が言語ごとにまとまっている。 『TryHackMe』では基本的にはシェルで侵入し、そこから攻撃を仕掛けていくことが多い。 ここで使えそうなコマンドを探してシェルに侵入していこう。 GTFOBins https://gtfobins.github.io/ Linuxのコマンドを使って権限昇格を行う方法がまとまっている。 『TryHackMe』ではrootユーザに権限昇格できればほとんど勝ち確である。 このサイトで権限昇格できそうなコマンドを探してrootユーザになることを目指そう。 よく使うコマンド ポートスキャン nmap -sV (IP Address) -sVオプションを付けることで動いているサービスとそのバージョン情報を取得できる。 実際の実行例が以下。 PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 7.2p2 Ubuntu 4ubuntu2.8 (Ubuntu Linux; protocol 2.0) 80/tcp open http Apache httpd 2.4.18 ((Ubuntu)) tcpの22番ポートでsshが、tcpの80番ポートでhttpがそれぞれ動いていることがわかる。 ...

2025-03-17

落ちた会社のフォロー面談を受けた

2次で落ちた会社のフォロー面談を受けた。メモを取っていたので、その内容を振り返ってみる。 いきなり話題がそれるけど、落ちた人に対してフォロー面談をしてくれる企業の目的ってなんなんだろうな? 落ちて落ち込んでいる人を相手にするのってただでさえシンドそうだし、何十人かに一人は感情的に食ってかかる人もいるんじゃないかな? 担当者のメンタルは結構キツそう。 ただ、落ちた身からするとフィードバックがもらえるのはめちゃくちゃありがたい。 「手応えあったのになんで落ちたんだろう?」みたいなことって割とあるし、そういうときに落ちた理由を知ることができたらめちゃくちゃ成長できると思う。今回の面談も学びが多かったので本当に感謝してる。 フィードバック 良いところ 実装の一つ一つは特に問題なし 悪いところ WikiやREADME.mdを書いていない 環境変数に対するコメントがない 保守性の観点で微妙なところがある 前職はフロントエンドもバックエンドもインフラも全部一人でやるみたいな環境だったから、こういうチームで働く上での当たり前の部分が全然身についてないんだよな。 一応Notionとかにドキュメントを書いたりはしてたんだけど、「コードを書いたら即ドキュメント」みたいな感じではなかったんだよな。 仕事が一段落して余裕のあるときに、「いけね、ドキュメント書かなきゃ!」って感じ。 今回はコーディング試験で落ちたんだけど、仕事でもドキュメント書けない人間がコーディング試験でドキュメントを書こうなんて発想になるわけないよな。これは反省だわ。 こっちからの質問1. どうすれば保守性の高いコードを書けますか? 担当者Aさん「弊社ではオニオンアーキテクチャを採用しています。アーキテクチャに関する知識を身につけると良いかもしれないです。あとは依存性の少ないコードを意識するのも大事です。」 担当者Bさん「会社のフェーズによって保守性を大事にするかどうかって全然違います。弊社では保守性を意識するフェーズに入っていますが、そうでない会社もたくさんあります。座学で保守性を学ぶこともできますが、保守性を意識している会社に身を置かないと経験できないこともたくさんあるので、そこら辺を就活の軸にするのも良いかもしれないです。」 自分でも保守性の高いコードは書けていないんだろうなという自覚はあった。 デザインパターンみたいなのも全然知らない。ここらへんは座学すべきかな。 「保守性を意識している会社に身を置かないと経験できないこともたくさんある」って言葉はかなり響いた。今までがむしゃらに座学中心で勉強をしてきたけど、実務で経験しないと成長しない部分ってあるよなあ。 こっちからの質問2. クッキー認証の実装が自信なかったんですけど、どうでしたか? 担当者Aさん「特に問題があるというコメントはないので大丈夫だと思います。」 やったぜ。今回のコーディング試験では仕様上クッキー認証を使う必要があったんだけど、前職ではlocalStorageにJWTを保存する認証しかやってなかったから不安が大きかった。 結構クッキー認証について調べてから実装したんだけど、特にレビューがつかなかったみたいなので嬉しい。 こっちからの質問3. テストを書こうと思ったんですが認証の部分が難しくて書きませんでした。書いたほうが評価は良かったですか? 担当者Aさん「細かく統計を取ったわけではないですが、合格する人の多くはテストを書いている印象です。認証の部分を乗り越えるためにはE2Eのフレームワークを使ったりするなどの工夫が必要かもしれないですね。認証部分は無理でもユニットテストだけ書く方も結構いますね。」 担当者Bさん「さっき申し上げた環境変数のコメントを書いてないとかにも通じるところがあるんですけど、それぞれの会社に宗教があるので分からなかったら担当者に聞いたほうが良いと思います。ある会社ではGOODとされてたことが、ある会社ではBADと評価されるってことはよくあるので、そこは担当者とコミュニケーションを取りながら探っていくのが良いと思います。自分も聞かずに面接で落とされた経験があるので、それ以来ちゃんと聞くようにしています。」 いやー、Bさんの言葉が響いたね。 俺の場合「聞きたいけど勇気が出なくて聞けない!」とかじゃなくて、そもそも聞くという発想にすら至らない。どんだけコミュニケーション力低いんだよ! 「聞いたほうが良いですよ」と言われて、思わず「おっしゃる通りです」と返答してしまった。 まあ、これに関しては前職でなんでもかんでも自分でやりまくっていたというのも大きいかな。壁にぶつかったら自力で乗り越えるっていうのが当たり前になっていたから、他人に聞くとか他人に頼るみたいな発想がコマンドの1ページ目に出てこないんだよな。 一応SIerに就職が決まっているんだけど、SIerは顧客折衝が大事な仕事だからコミュニケーション能力の低さは改善しなきゃだな。 担当者から最後の一言 担当者Aさん「個人的な印象では〇〇さんは勉強熱心でやる気もあって非常に好印象でした。技術に前のめりで向き合う姿勢も良いと思います。再チャレンジする機会があったらぜひ再チャレンジしてみてください。」 お世辞も入っているのかもしれないけど素直に嬉しい。 今回のフィードバックをもとにもっと成長していこうー!!

2025-03-11

技術面接でボコボコにされた備忘録

技術面接でクイズを出されてボコボコにされた。もちろん落ちた。 ボコボコにされたあと、「次に同じ機会があれば答えられるようにしないと!」と思って急いでクイズの内容をメモした。そのメモを見ながら面接の内容を振り返ってみる。 1. GETとPOSTの違いを説明してください。 自分: GETはリソースの取得に使い、POSTはリソースの作成に使います。 面接官: 内部的にはどう違いますか? 自分: え…!?メソッド名が違うとかそういうことですか? 面接官: あ、分からないなら分からないでいいですよ。 自分: すみません…。分かりません…。 ググった感じ、「内部的にはどう違いますか?」という質問に関しては、「GETはクエリパラメータにデータが含まれるのに対して、POSTはリクエストボディにデータが含まれる」的なことを答えれば良かったと推測される。 でも、それって内部的な違いって言うかな?内部的な違いと言われると、エンジニアが直接触れることのない部分での違いを問われているように感じる。 クエリパラメータとリクエストボディって割と意識的に操作していない? 「データの渡し方の違いはどうですか?」と深堀りされていたら普通に答えられていたので、ぶっちゃけ面接官の深掘りの仕方も良くなかった気がする。 まあ、このあとにも答えられなかった質問がいくつかあるので、これに答えたところで結果は変わらないと思うけどな! 2. N + 1問題とはなんですか? 自分: あのー、なんかORMとかを使っているときにテーブルを結合したりするとSELECT文が大量に発行される的なやつだと思うんですが…。すみません、詳しいことは分かっていません。 やらかし。完全に忘れていて答えられなかった。 N + 1問題はテーブル結合とは関係なく発生するので的外れ。 なんで自分がN + 1問題を忘れてしまっていたのかを振り返ってみたけど、おそらく自分の脳内ではN + 1問題が なんかSELECT文が大量に発行されるやつ(超ざっくりとした概要) railsならとりあえずbulletを入れとけば大丈夫(解決策) の2つに極端に抽象化されてしまっていた。 実務では概要と解決策の2つさえ抑えておけば具体的な内容を理解していなくてもなんとかなることが多いけど、でもこれって本質を理解してないってことでもあるよな。 超反省です。 3. DBで片方のテーブルにしかない情報を取得するときに使うのはINNER JOINですか?OUTER JOINですか? 自分: OUTER JOINです。 これは自信を持って回答できたやつ。 前職で大量に生のSQLを書いていたので、SQLのクイズに関しては大体のことに答えられる自信がある。 その分ORMの知識がおざなりになってしまったんですが…。 4. Fizz Buzzを書いてください。 これも自信を持って回答できたやつ。Pythonで書いた。AtCoderのおかげです。 5. セッションとクッキーの違いはなんですか? 自分: セッションはサーバ側にデータを保存するのに対して、クッキーはクライアント側にデータを保存します。クッキーはサーバへのリクエスト時に自動で送信されるようになっているので、サーバ側のセッションと突き合わせることで認証などを行うことができます。 前半は良いんだけど、後半はセッションとクッキーの違いじゃなくて認証の話してるよな。 回答した直後に「あれなんか途中からズレたな?」って気づいた。 結局セッションとクッキーの違いを明確に理解してないから、なるべく自分の知っている知識に持っていこうとして回答がおかしくなってしまうんだろうな。 これも反省だな。 6. SQLインジェクションとはなんですか? 7. XSSとはなんですか? この2つは正しく回答できたと思うけど、なんかグダグダ説明しすぎた。もっと短文でパッと答えるべきだった。 8. CSRFとはなんですか? 自分: 罠サイトの中に攻撃対象のサイトをめっちゃ小さいiframeで埋め込んでクッキーとかを盗むやつです。 ...

2025-03-05

冷静に考えれば気づけるはずのことに気づけないことがある

昔から麻雀AIに興味があって、ちまちまと麻雀AIを開発してきた。 大学生の時には強化学習に挑戦したくて麻雀AI同士を戦わせるための環境を作っていた。 ゲーム系の環境を作るときは実際にそのゲームをプレイできるUIがあったほうがバグに気づきやすい。 そこでReactを使ってUIを作った。それがこれである。 大学生のときに作って未完成のままなので、かなりのバグがある。 最近、また麻雀AIを作る気力が湧いてきたので、このときのコードをリファクタしようと思ったのだが、そこでふと気づいた。 「なんでReactでUI作ってんの?」と…。 ゲームアプリでフロントエンドとバックエンドを分ける方式にすると必要な情報を漏れなくやり取りする必要がある。 一般的なWebアプリではやり取りするデータの形式がある程度決まっているのに対し、麻雀ゲームでやり取りするデータの形式はてんでバラバラだ。 ツモとかポンとかリーチとかプレイヤーの選択した行動によってデータの性質が全く異なるし、必然的に型定義も面倒になってくる。 しかも麻雀とかいうゲームのルールが複雑すぎるせいで絶対に考慮漏れが発生するのでそのたびに手戻りも発生する。 もちろん型定義もやり直しだ。 誰だよ!麻雀のルールをここまで複雑にしたやつは! 大学生の時に未完成のまま放りだしたのも型定義するのめんどくせーって感じだった気がする。 冷静に考えればUIもゲームの実装の一部としてPythonで書いて、単体のソフトウェアとして完結したほうが絶対楽に決まっている。 ゲーム部分とUI部分でデータのやり取りをする必要がなくなるし、いちいちReactのサーバを起動したりエディタを2つ起動したりする必要もなくなる。 将来的にブラウザ上でAIと対戦できるようなプラットフォームを作りたい場合でも、まずはプロトタイプを作ってバグをある程度取り除いてからの方が良い。 冷静に考えたら当然の帰結だけど、実はこの事実に気付いたのは昨日だ。なんか寝て起きたら気付いた。 自分の方針を疑っていない状態で自分の非効率さに気付くのってマジでむずい。 世間の人はどうやって疑うモードにスイッチを入れているんだろうか? 良いものを効率良く作るなら常に万物に対して疑問を呈さないといけないんだろうけど、それってめちゃくちゃ脳が疲れそうだな。

2025-03-02