長期インターンのリアル/メリット・デメリット

はじめに

こんなツイートを見かけたので、実体験に基づく話でも書いてみようかと思いました。

長期インターンの定義

本稿では、

  • 無期雇用で週に数回働く
  • その会社の採用フローとは特に関係ない

とします。

また、職種はエンジニア職を前提としています。(他の職種でも参考にはなると思います)

あなた誰?

https://russianblue25.github.io/

RussianBlue25 (RussianBlue25) · GitHub

長期インターン歴はそこそこ長いです。

Web系の受託開発をメインとしている会社に二年半弱、セキュリティベンダーに一年弱といった感じです。

こちらは一社目の退職時にインタビューしていただいたものです。↓*1 長期インターンをしようと思っている人へのメッセージもあるので合わせてご覧いただければと思います。

www.claves.co.jp

基本的な話

長期インターンの探し方

特にツテがない場合は、Wantedlyなどの求人サイトからいくのがいいと思います。

一社目は求人サイトから探しました。求人サイトの新着に載っている会社は応募が多数来ていて通過率も低いだろうと踏んで、あまり最初の方に出てこない会社の中で通えそうなところを探しました。

重視した点としては、様々な技術に関われそうかというところと、とにかく通えるかどうかです。*2

Twitterで観測している限りだと、

  • 短期のインターン先で誘われた
  • 知り合いに誘ってもらった

とかも多いようですね。

二社目はちょっと特殊で詳しくは書けないのですが、普段お世話になっている方繋がりといったところです。

採用まで何社応募するべきか

ツテがあるとかでなければ、キャパオーバーしない程度にたくさん受けるのがいいと思います。

新卒採用などと違って長期インターンは枠そのものが少ないので、応募のタイミングなど本人にはどうしようもない理由で落ちることも多いからです。

私は正確には覚えてませんが、10社くらい応募したと思います。明確に採用内定になったのは働いたところ含めて2社だったと記憶しています。一社目の採用フローがかなり早かったので選考結果が出る前に辞退したところが多いです。

ちなみに上で書いた

求人サイトの新着に載っている会社は応募が多数来ていて通過率も低いだろう

は本当でした。ものすごく面談の予定が入っていて長期インターンをやりたい人って多いんだなあと思っていました。

勤務日数・時間

一般的には週2フルタイム程度の時間をトータルで求められることが多いと思います。

私は時期によりますが週3で働いています。授業の兼ね合いでフルタイムではない日もあります。長期休暇はもっと入ったり、逆に忙しい時期は減らしたりと柔軟にスケジュールを組んでいます。もちろん案件次第ですが。

一社目のインターン生だと、

  • 週2フルタイム
  • 週1午後出勤(授業の兼ね合い)、週2フルタイム

とかの人が多かったように記憶しています。

私が出会った人の中には休学して週5日・1日8時間のフルコミットをしてる人もいました。

時給

ここでは一般的な話をします。

採用フローに関わらない、ここで定義している長期インターンは1000-2000円あたりが相場ではないでしょうか。地方だと1000円切るところもありますが、技術職としてはちょっと低いかなと思います。

当然未経験の人と、ある程度実績がある人では異なると思います。

ちなみに2000円以上の額を目指すとなると、知り合いのツテで採用してもらうとか、スカウトされるとか、メガベンチャーの短期のインターンから長期インターンに誘ってもらうなどクローズドなルートになるかと思います。個人の観測の範囲です。

就活に有利になる?

有利にはなるが、長期インターンをやったことそのものが有利になるわけではない

就活のためにやるというスタンスでは多分うまくいかない

と私は思っています。

長期インターンで出会った人は、有名企業の内定をもらったり早々と就活を終えている人が多かったです。

長期インターンで培った経験がおそらく生きているとは思います。ですが、長期インターンに行かなかったとしてもなんらかの経験を得て内定を取っただろうなという人たちが多い印象でした。

強いていうなら、ある程度希望している職種で働いた経験があるので、どういった会社に行きたいかとかどういう技術に触れていたいかといった自己分析がしっかりできるというのはあるかもしれません。

メリット

ここからは実体験に基づくメリット編です。

メンターの元、多種多様な技術に触れられる

これは会社によりますが、個人開発では触れることがないだろうなという技術に触れられるのが良い点でした。業務で得た知識が研究や個人開発にも生きて、学びが加速したように思います。

また、社員さんにコードレビューをしていただくことで、可読性の高いコードを書くという経験が積めたかと思います。これは個人開発だとなかなか難しいかと思います。(意識はしてるんですけどね...)

チームで動くということを学べる

これも個人だと難しいことですね。

また、就活ではチームで動いた経験を求められることが多いので、話のネタになるという点はメリットかと思います。

スケジューリング能力が鍛えられる

長期インターンに限らない話ですが、複数のことを同時並行するのでスケジューリング能力は鍛えられます。とはいえ私は失敗続きで、最近になってやっとうまく回せるようになってきた感じですが...*3

個人的にこれはメリットの中で一番大きいかなと思います。

ちなみに色々と両立が大変で長期インターンをやめる人も見てきました。

新卒入社する会社/職種に何を求めるのかが明確になる

これもメリットの中で大きいかと思います。

例えば実際にエンジニアとして働いてみて、やっぱりこれじゃないなと思ったとしたらその「これじゃないな」を明確にして、就活に生かすことができると思います。

新卒入社後のミスマッチがある程度起きにくくなるのではないでしょうか。

好きなことをしてお金がもらえる

コードを書いてお金がもらえるのは最高です。

デメリット

ここからは実体験に基づくデメリット編です。

時間が決まっている授業・ゼミとの両立

ある程度業務時間を確保しないといけないので、何時から何時というように決まっている授業との調整は大変でした。

私の場合は通勤に一時間以上かかっていたのも大きいです。大学近くの職場だったり、リモートの会社を選べば大きな問題にはならないかと思います。

あと、私の場合は時間拘束のない研究室で、ゼミの準備や研究なども全て自分の裁量でやれたのが大きかったです。実験系だったりして時間拘束があると厳しいと思います。学業は大事です。

中期のインターンに行きづらい

ここでの中期インターンとは、期間が一ヶ月程度の採用に関わるインターンシップのことです。

長期インターンをやっているとどうしてもやっている案件に責任を持たないといけないので、気軽にメガベンチャーの良さげなインターンには行きづらくなります。もちろん事前に相談すれば休ませてもらえると思います!

個人的には長期インターンに拘らず、そういったインターンを渡り歩くのもいいのではないかと思います。

おわりに

やっぱり企業で長期インターンが正解なのかな

への答えですが、長期インターンをしたという選択を正解にするというのが大事かと思いますね。正解は自分の中にしかないです。

長期インターンは万人におすすめするものではないです。息をするように気づいたら働いてた人が向いているのではないかと時々思うことがあります。

*1:肉がヤバい。切実に痩せたい。

*2:千葉在住なので、ベンチャーによくある立地の新宿渋谷は通いづらい

*3:多方面にたくさんご迷惑をおかけしました

2020年を振り返って

はじめに

今年一年大変お世話になりました。厚くお礼申し上げます。

今年は年初めは謎の風邪で数ヶ月苦しんだり*1、後半は気力が尽きてしまったりと思うように動けない期間もあって大変でした。現在は心身ともに健康です。

以下、ゆるりと今年やったことをまとめていきたいと思います。

情報発信など

ふとした思いつきで始めたImaizumi Lab Advent Calendarでかなり記事数を稼ぎました。本当に思いつきだったので記事のストックもなく、12月の私の首を絞めることに...

まだ完走できてないので修論の息抜きでちょっとずつ埋めていこうと思います。そろそろネタが...

他にはクローズドな場ですが研究室周りで勉強会をやったりしていました。

おしごと

2017年の冬からお世話になった職場(主にWebアプリ開発)を退職しました。

その後転職(?)して脆弱性診断のアルバイトを4月から始めました。*2

来年からは情報セキュリティ業界のとある会社で来年から働きます。今アルバイトしているところとは別です。脆弱性診断に従事する予定です。*3

昨年から引き続きセキュリティ・キャンプ企画Gr.として主にミニキャンプ周りの活動させていただきました。また、昨年から引き続きセキュリティバグハンティングコンテストの運営メンバーも務めました。

個人開発

github.com

RISC-Vのエミュレータを書きました。(現在は修論作業中にて休止中)

初めてGoで書きました。

このプロジェクトあたりからコミットメッセージを英語で書くようにし始めました。こういう機会でもないと英語を書くことがないので...

他には、個人のポートフォリオをちょっと整備し始めたりしました。まだまだ未完成です(github.ioなので気になる方は見に行ってみてください)

資格

russianblue25.hatenablog.com

趣味で色彩検定2級を取得しました。

russianblue25.hatenablog.com

10月に受けた情報処理安全確保支援士試験に合格しました。*4

これで二年間午前免除になるのは大きいので、次はネスペあたりを狙っていきたいと思っています。あまりネットワークには詳しくないので知識を補完したい。

他にはOSCPにチャレンジしたいとも考えています。

おわりに

今年は新型コロナウイルスの影響もあり、あまり新しいことができない一年になってしまったなと思っています。ずっと同じことばかりやっていても成長しないので、来年はどんどん新しいことにチャレンジしていきたいです。

週数回フルタイムで働きながら学業もやっていくという生活が数年続き、いろいろ迷惑をかけながらやっとうまく両立できるようになったところで卒業となりました。

個人的には忙しい/複数のタスクを同時に抱えている方が性に合っているようです。体力と気力の続く限りこの生活ペースを今後も維持していきたいと思います。

来年はまず修論を出したいです。目標ページ数まで残りXXpあるので正月返上で頑張ります。

そしてWebアプリを作ったりするのがやっぱり好きだということにバイト先を辞めてから気づいたので、来年は個人開発だったり受託開発だったりで活動していければと思っています。

来年もよろしくお願いします。

*1:実はあれは...と今でも思っています

*2:社名公開してないですがわかる人が見たら...

*3:社名出してないけどこれもわかる人が見たら...

*4:この手の資格、資格取得手当を設定してる企業も多いのであまり学生のうちに受けるメリットはないかもしれません。自己満足ですね。ちなみに自分の行く会社がどうかは知りません。

情報処理安全確保支援士試験に合格した

この記事はImaizumi Lab Advent Calendarの14日目です

はじめに

情報処理安全確保支援士試験に合格したので備忘録です。といってもそこまで書くことがないのですが...

参考書など

以下の三つを使っていました。

www.sc-siken.com

www.ap-siken.com

www.amazon.co.jp

隙間時間で過去問道場をやりつつ、まとまった時間にポケットスタディで勉強していました。

期間としては一ヶ月くらいです。午前問題なんかは特に過去問が再利用されるので、短期集中でえいやっとやってしまうのがいいと思います。

感想など

午前1

免除がないので辛かったです。勉強法としては空いた時間にちょっとずつ過去問道場で応用情報の勉強を進めてました。

午前2

過去問道場を二周すれば十分だと思います。

私は前々日に一つのカテゴリの問題を集中的に解く→もう一回やり直して定着させる でやりました。

午後1

対策としてはポケットスタディの午後対策のページを一周読んだ程度です。

問1(スマートフォン決済)と問3(脆弱性診断)を選択しました。

問1は研究室で取り組んだ危機管理コンテストの知識が、問3は脆弱性診断のアルバイトの経験が生きたと思います。その割には79点と思ったほど取れていませんでしたが...

午後2

こちらもポケットスタディの午後対策のページを一周読んだ程度です。

問1がWebサイトの統合の話(ソースコードを読むやつ)、問2がテレワークの話で問2を選択しました。

後から聞いた話だと問1は結構簡単だったようなので問1にしておけばよかったです。*1

おまけ:登録セキスペになるか

会社から全額出るのであればとりあえず登録してみるかもしれませんが、そうでなければ登録しないと思います。お金がかかるので...

*1:二択の連続する箇所があり、そこをミスったら大幅減点だなと思ったので避けました

touchコマンドの本来の使い方

この記事はImaizumi Lab Advent Calendarの24日目です。

はじめに

空のファイルを作るときに「touch hogehoge」とやりますよね。

本当はファイルのタイムスタンプを変更するためのコマンドというのは結構知られていると思いますが、じゃあどういう使い方ができるの? ということでまとめていきたいと思います。

ファイルのタイムスタンプは3種類ある

ここでちょっと遠回りして、ファイルのタイムスタンプについて解説します。

UNIX系システムのファイルのタイムスタンプには「atime」「mtime」「ctime」の3種類が存在します。*1

atimeはファイルの最終アクセス日時、mtimeはファイルの最終更新日時、ctimeはinodeが更新された日時です。inodeとは、ファイルのアクセス権や実データの場所などの属性情報のことです。

これらはstatコマンドで確認することができます。(以下、コマンドの実行例は全てUbuntuでのものです。statの出力は省略しています。MacOSだとstat -xで似たような表示になります)

$ stat a
Access: 2020-12-25 01:25:27.354297000 +0000
Modify: 2020-12-25 01:25:27.354297000 +0000
Change: 2020-12-25 01:25:27.354297000 +0000

例えば「echo "aaaa" > a」で中身を編集すると、

$ stat a
Access: 2020-12-25 01:25:27.354297000 +0000
Modify: 2020-12-25 01:25:27.354297000 +0000
Change: 2020-12-25 01:25:27.354297000 +0000
$ echo "aaaa" > a
$ stat a
Access: 2020-12-25 01:25:27.354297000 +0000
Modify: 2020-12-25 01:26:32.174235000 +0000
Change: 2020-12-25 01:26:32.174235000 +0000

のようにmtimeとctimeが更新されます。

「cat a」とすると、atimeのみが更新されます。

$ stat a
Access: 2020-12-25 01:25:27.354297000 +0000
Modify: 2020-12-25 01:26:32.174235000 +0000
Change: 2020-12-25 01:26:32.174235000 +0000
$ cat a
$ stat a
Access: 2020-12-25 01:27:59.621939000 +0000
Modify: 2020-12-25 01:26:32.174235000 +0000
Change: 2020-12-25 01:26:32.174235000 +0000

「vi a」でファイルの中身を更新すると、3つとも全て更新されます。

$ stat a
Access: 2020-12-25 01:27:59.621939000 +0000
Modify: 2020-12-25 01:26:32.174235000 +0000
Change: 2020-12-25 01:26:32.174235000 +0000
$ vi a
$ stat a
Access: 2020-12-25 01:29:46.577553000 +0000
Modify: 2020-12-25 01:29:46.577553000 +0000
Change: 2020-12-25 01:29:46.579553000 +0000

使ってみる

はじめに以下のようなファイルがあるとします。

$ ls -l
-rw-r--r-- 1 root root 6 Dec 25 01:31 a
-rw-r--r-- 1 root root 0 Dec 25 01:31 b
-rw-r--r-- 1 root root 0 Dec 25 01:31 c
$ stat a
Access: 2020-12-25 01:31:52.187919000 +0000
Modify: 2020-12-25 01:31:52.187919000 +0000
Change: 2020-12-25 01:31:52.187919000 +0000

オプションなし

「touch a」とするとaのatime、ctime、mtimeが書き換わります。

$ stat a
Access: 2020-12-25 01:31:52.187919000 +0000
Modify: 2020-12-25 01:31:52.187919000 +0000
Change: 2020-12-25 01:31:52.187919000 +0000
$ touch a
$ stat a
Access: 2020-12-25 04:13:09.531173000 +0000
Modify: 2020-12-25 04:13:09.531173000 +0000
Change: 2020-12-25 04:13:09.531173000 +0000

rオプション

「touch -r a b」とすることで、aのタイムスタンプがbのタイムスタンプになります。

$ touch -r a b
$ ls -l
-rw-r--r-- 1 root root 6 Dec 25 04:13 a
-rw-r--r-- 1 root root 0 Dec 25 04:13 b
-rw-r--r-- 1 root root 0 Dec 25 01:31 c

このオプションの使い道として、配布するソフトウェアの中身のタイムスタンプを揃えるとかがあるようです。

tオプション、dオプション

任意の時刻にタイムスタンプ(atime、mtime)を指定することができます。

$ touch -t 01011111 a
$ stat a
Access: 2020-01-01 11:11:00.000000000 +0000
Modify: 2020-01-01 11:11:00.000000000 +0000
Change: 2020-12-25 04:50:34.724411000 +0000

$ touch -d "2020-1-2 22:22" a
$ stat a
Access: 2020-01-02 22:22:00.000000000 +0000
Modify: 2020-01-02 22:22:00.000000000 +0000
Change: 2020-12-25 04:52:03.686661000 +0000

aオプション

atimeとctimeを変更することができます。

$ stat a
Access: 2020-01-02 22:22:00.000000000 +0000
Modify: 2020-01-02 22:22:00.000000000 +0000
Change: 2020-12-25 04:52:03.686661000 +0000
$ touch -a a
$ stat a
Access: 2020-12-25 04:55:19.327739000 +0000
Modify: 2020-01-02 22:22:00.000000000 +0000
Change: 2020-12-25 04:55:19.327739000 +0000

mオプション

mtimeとctimeを変更することができます。

$ stat a
Access: 2020-12-25 04:55:19.327739000 +0000
Modify: 2020-01-02 22:22:00.000000000 +0000
Change: 2020-12-25 04:55:19.327739000 +0000
$ touch -m a
$ stat a
Access: 2020-12-25 04:55:19.327739000 +0000
Modify: 2020-12-25 04:56:21.502631000 +0000
Change: 2020-12-25 04:56:21.502631000 +0000

余談:Macでのタイムスタンプの挙動が変

この記事を書くにあたってMacOSで最初試していたのですが、「cat a」したときにaのatimeが更新されるはずが更新されないという事象に遭遇してしまいました。

ディスクの書き込みを軽減させる目的でatimeの更新を無効化することがあるそうですが、調べた感じだと明示的に設定しないと有効にならないようなので、今回の場合は違うようです。

何かわかったらまた記事にしたいと思います。

*1:この他にもあるケースもありますが、本稿では取り扱いません

コマンドの存在を調べるときはwhichよりtypeの方がいい

この記事はImaizumi Lab Advent Calendarの13日目です。

TL;DR

whichで出てくるパスの実行ファイルが実行されているとは限らない

詳しくみる

※私はfishを使っています。typeコマンドの-sオプションはないシェルもあります。

普通のコマンドの場合

$ type -s brew
brew is /usr/local/bin/brew
$ which brew
/usr/local/bin/brew

一致しますね。

ビルトインコマンドの場合

$ type -s source
source is a builtin
$ which source
(何も表示されない)

ビルトインコマンドということを知らずに実行してしまうと「コマンドがない!」と焦ることになりそうです。

typeとwhichで表示が異なる場合

$ type -s cd
cd is a function (defined in /usr/local/Cellar/fish/3.1.2/share/fish/functions/cd.fish)
$ which cd
/usr/bin/cd

typeとwhichで結果が異なっています。実際にはtypeで表示されたパスのコマンドの方が読み込まれています。

typeとwhichの結果が異なる理由

そもそもwhichとは、PATHに設定されているディレクトリを順番に調べて最初に見つかった実行ファイルを表示するコマンドです。(オプションなしの実行時)

実際に実行されるコマンドのパスとは限らないのです。

ビルトインコマンドであるcdやechoなどは、実行ファイルが/binや/usr/bin下にも存在することがあり、そういったケースでwhichを使うと実際に実行されるコマンドのパスと出てくるパスが異なってしまいます。*1

(2020/12/19追記) Macの場合ですが、/binや/usr/bin下にあるビルトインコマンドと同名のコマンドの中身はbuiltin(ビルトインコマンドを優先実行するコマンド)のようです。結局のところビルトインコマンドが実行されているようです。

困りそうなケースとしては、ビルトインコマンドと同名のコマンドを作成して/bin下に置いている時とかでしょうか。

思わぬハマりポイントになりかねないので、なるべくtypeを使った方がいいと思います。

*1:ビルトインコマンドなのでコマンドのパスという言い方が適切なのかどうかは...

CSSで背景を斜めにしたい

この記事はImaizumi Lab Advent Calendarの11日目です。

はじめに

f:id:RussianBlue25:20201218212827p:plain
斜め背景の例

画像のように背景を斜めにしたい時に使えるライブラリの紹介です。なるべく面倒なコードは書かずに楽をしたいですよね。

Angled Edgesというライブラリを使うことで簡単に実現することができます。

github.com

使い方

css(またはscss)をソースに放り込んで、sectionタグやdivタグにクラスを指定します。それだけでOKです。

<section class="angle--both-left-left" id="Projects">
        <h1 class="section__title--projects">Projects</h1>
        <h2>These are my projects.</h2>
</section>

これが先程の画像のコードです。

nigelotoole.github.io

こちらのサイトで使用例を詳しく見ることができますので、参考にしてみてください。

現代のTelnetは暗号化できる

この記事はImaizumi Lab Advent Calendarの6日目です。

はじめに

youtu.be

Telnetは暗号化しないからセキュリティ的に危険」と教わった人は多いでしょう。

ところが、特定の条件下だとTelnetでも暗号化する場合があります。

先日行われたjusのUNIX歴史講座で「今のtelnetは暗号化する」という話題が出て、Twitterの方で知らなかったと言ってる方がちらほらいらっしゃったので意外と知られていないのかと思い記事を書くことにしました。

(その話題は動画だと35:00ごろ)

関連するRFC

  • RFC2946-2950, 2952-2953「Telnet Encryption」
  • RFC5929「Channel Bindings for TLS

という関連したRFCが存在します。ざっと眺めたところ、暗号化の方式ごとに議論されているようです。

実装を調べる

man

BSD General Commands Manual、Ubuntu manpagesを見る限りだと、encryptオプションなるものが存在するようです。ただし、

telnet が暗号化なしでコンパイルされた場合、 encrypt コマンドはサポートされない。

とのことです。

現在のバージョンの telnet は、暗号化をサポートしていない点に注意すること。

という記述がmanページにあるケースとないケースがあったため、なければ対応しているのかも?

どちらにしてもデフォルトで暗号化されるというわけではなさそうです。

ソースを読む(BSD)

BSDでは少なくとも10年ほど前から暗号化がサポートされているようです。FreeBSDtelnet.cの実装を見ると、encrypt.hというヘッダファイルを読み込んでいます。

以下特に関連しそうなソースです。

https://svnweb.freebsd.org/base/head/contrib/telnet/telnetd/telnetd.c?view=markup#l53

https://svnweb.freebsd.org/base/head/contrib/telnet/libtelnet/encrypt.h?view=markup

https://svnweb.freebsd.org/base/head/contrib/telnet/libtelnet/encrypt.c?view=markup

https://svnweb.freebsd.org/base/head/contrib/telnet/libtelnet/enc_des.c?view=markup

(BSDに関しては参考文献一つめの@bakamingさんの記事及び研究室の先生にご教示いただきました)

どうやらBSDの実装では共通鍵暗号方式(DES)を採用しているようです。

パッケージ

https://pkgs.org/search/?q=telnet

パッケージ検索で調べてみると、Ubuntutelnet-sslという実装があるようです。その名の通り、SSLをサポートしたTelnetのようです。

Dockerで試してみる

Ubuntutelnet-sslをDockerで試してみます。telnet-serverの方でtcpdumpを用いてパケットをキャプチャしてみます。

こちらのリポジトリに入っているので、すぐに試すことができます。*1

github.com

ちなみにUbuntu20.04からSSLのセキュリティレベルが上がった関係で、20.04ではうまく動かないようです。私は18.04で試しています。

詳しくはリポジトリのREADME.mdをご覧ください。

Wiresharkでキャプチャを開いてみる

暗号化した場合としなかった場合、それぞれのキャプチャファイルをWiresharkで開き、「分析>追跡>TCPストリーム」で見てみましょう。

普通のTelnetの方はログインユーザ、パスワードが全て書かれています。一方、暗号化されたTelnetの方はよく分からない文字列になっています。

f:id:RussianBlue25:20201217125520p:plain
暗号化されていないTelnet

f:id:RussianBlue25:20201217123130p:plain
暗号化されたTelnet

おわりに

暗号化するTelnetは確かにRFCに記載があり、実装もあることがわかりました。また、暗号化されていることをWiresharkを使って確認することができました。

ただし「現代のTelnetは暗号化できる」だとちょっと語弊がありますね。厳密には「現代のTelnetは暗号化できる(こともある)」ってところでしょうか。

参考文献

telnetは通信を暗号化できる…らしい - Qiita

docker間通信をtcpdumpしてpcapをいじる - やる

Dockerでたてたコンテナにtelnet-serverを入れて、telnetでコンテナ間通信ができるようにしてみた - 君は心理学者なのか?

*1:生のTelnetと暗号化Telnetは共存できないようなので、分けています