転職フローについて

転職の流れ

今回の私の転職フローは以下のような流れでした。 1. 転職の決意を決める 前回の記事で記載したように前職最後のPJで継続の心が折れたので、転職をきめました。 1. 転職サービス等に登録 新卒時に使っていたpaizaとエージェントサービス目的でdodaさんを併用しました。 それぞれの利点などを書きます。 - paiza そこまで大規模でない企業も結構多い、また、サービスなども結構わかりやすく書いてくれてて企業について調べやすい。 カジュアル面談などでスタートできるのでかっちりした準備まで要らない例が多い。 しかし、デフォルトではエージェントサービスがないので、スケジューリングなどを自分でする必要がある。 なお、面談日の予定入力画面では各エントリー中の企業に提示したスケジュールを出してくれるので、面接対策などが自分でできるような人であれば問題ないかもしれない。 - doda 大規模な企業の求人も多い。エージェントサービスを使うこともできるため、初めての転職だと割とこっちの方がよいかもしれない。

  1. エントリー 自分が入りたいと考える各企業へエントリーする 大体10%前後で内定が取得できるとのご説明をいただきました。 私は割と何でも屋的な扱いになっていたため、選考的に難しい可能性が高いためdodaでは15社程度、paizaでは10社行かない程度、合計で20社ちょっとにエントリーしました。
  2. 面接 面接。 一時期は退職後、毎日面接を続けるという日程感になっていた。
  3. 内定 内定をもらう。 私は最終的に4-5社から内定をもらいました。
  4. オファー面談 最終的に相手へどんな雇用体系になるかなどの最終確認をします。 その後一週間程度の猶予のあとに、内定受諾の期限が切られます。
  5. 退職手続き 前職をやめましょう。 退職後に転職する方もいらっしゃいますが、やはり貯蓄がある程度ないと厳しいので、 在職中の方がよいと思います。
  6. 転職 これで転職が完了になります。

まとめ

面接などで割と体力・精神的にも疲れ果てることが多かったため、 稼働が低い状態で、ある程度心身に余裕のあるタイミングで転職活動を開始されることをお勧めします。

転職しました！

日記

転職をしました。

新卒後ちょうど3年勤続した会社を退職しました。 このエントリでは、とりあえず、辞めるに至った経緯/理由と簡単なまとめを記載します。 実際に行った転職フローについては次記事に記載します。

経緯

一言でいうと我慢の限界に達しました。 理由にも記載するのですが、最後にアサインされていたPJでの体制があまりにもひどく、 上司、先輩社員らへの信頼というかが0からマイナスに落ち込みました。 詳しく書きすぎると身バレする可能性が出てきたり、退職時誓約にかかわるのですが、 社長肝入りで「新規ソリューションを作ろう」というPJの試作開発というかの段階にアサインされました。 体制の中で採用しようとしている技術に関する基礎的知識を持つ人が私一人のみでした。 その状態でメテオフォールな形で仕様変更/採用技術の変更をざっくばらんに投げつけられました。 その中には、到底採用予定のチップでは計算量不足が見え見えなものばかりで、 計算量が足りないのを何度上申しても「あっ。そ。じゃあ、どうにかしてね。」とばかり言われました。(経験3年目でその技術に特化してない若造に何をやれと…………)

という感じで1年ほど続けられて、途中で、週次でしかミーティングをしないのに1~2日のタスクしか投げずに、 私から「これこれについてはそちらで選定されて動いたとか言ってましたが、サンプルのソースなどはありますか。」 と聞くと「そんなのは別にあと回しにしてほしいんだよな。」などとミーティング周期とタスクが全く見合わない状態にされ、 さらに動いた環境が搭載環境に比べると圧倒的にリッチな計算力のノートPC(GeForceのGTX10クラス以上のGPU搭載)でやってるにもかかわらず。 「ノートPCで動いたから問題なく動くっしょ」などとのたまったので ミーティング中に私の堪忍袋の緒が切れました。

(ちなみに、転職活動中の「自身の欠点は？」と聞かれた際にこのエピソードを話したら、「体制にあまりにも問題があるのでは」と言ってくださり、とても精神的に楽になりました。どの会社さんの面接担当の方だったか思い出せないのですが、本当にありがとうございました。(もしかしたら現職の上の方かもしれません。))

理由

転職に至るまでの理由を一度全部羅列します。 1. 年収が少なかった 1. 尊敬できる先輩がいなかった 1. 会社の体制に疑問を持った 1. 会社の設備にあまりにも嫌な点が多かった 1. 労基法に順守していなかった

これからそれぞれ少し詳しく記載します。

年収が少なかった

私が基本的に残業をせずにいたため、日本式給与決定フローから外れてしまっていたのも理由の一つの可能性があるが、 ボーナスが約1カ月分を年二回のため、約14カ月分であり、 退職時は22万円 * 14カ月の約308万円が退職直前の金額だった。(正確には月棒には基本給のほかに固定手当てが付与されていたので、もう少し年収が低い)

尊敬できる先輩がいない

入社後、導入されたknowledgeというOSSのサービスについて、先輩方はほぼ記載をしなかった。これだけなら、「業務が忙しいだけなのでは」と考えられるかもしれないが、それ以外に、後述の体制にもかかわるが、新規採用技術系等に関して基礎学習などをしていないとしか考えられない存在しかいなかった。

会社の体制に疑問を持った

社長肝入りのPJで、導入したい技術に明るくないメンバのみで仕様および、採用技術を決める。といったような技術屋として疑問しか浮かばない決定フローしかなかった。また、私がその技術に若干知識を持っているとのことでアサインされたが、ハードウェアのスペック不足などを何度報告してもエスカレーションされず、数か月後に急に上のメンバの思い付きのみでハードウェアの変更が行われるなど作業者に対してあまりにもメテオフォールが過ぎた。 また、この感染症に対して、接触を下げるためにリモートワークが導入されたが、部長クラスがあまりにも対面を好むためか、 基本的には週に2日もリモートワークすることを許されなかった。 あと、PPAPが現役。(←これ結構でかい理由かも)

会社の設備にあまりにも嫌な点が多かった

客先に公開するための試験サーバなどが業務フロアに置かれており、そのサーバの騒音があまりにもひどかった(ラックマウントなサーバが10台超くらい置かれてた)。会社が雨漏りしていた。また、雨漏りについて数年レベルで対策が行われていない。

労基法に順守していなかった

結構世の中には多いようだが、残業代が1分単位で計測されない。 30分を過ぎないと残業時間が切り捨てられるという運用をしていた。 また、上司の中には本人が自覚していないようなセクハラ/パワハラを行うような存在が居た。

簡単なまとめ

正直、ITエンジニア職などで1年目の月給から、その会社のボーナスなどの計算で年間の理論年収を算出して、 320-330を超えないような会社は速攻でやめていいと思いました。 転職前後で会社規模が転置ほどの違いになってますが、理論年収で80万上がりました。 個人的に280-300前後の年収で3年間過ごしたのですが、首都圏だと趣味や書籍・衣類などを買うと 普通に月の収支で赤字になる時もあるレベルになると思うのでもっと最低限度の文化的な生活を営めるようになりましょう。

PPAPのような論理的にセキュリティレベルが上がってない(むしろ下がる)ようなルールを採用していたり、 自身や、大学時代の同期などの常識からあまりにも乖離してるような会社環境であれば、 無理せずに辞める方がよいと思います。 実際、私が入社した次の年以降で部署に合計で5名ほど新入社員が入ったのですが、 うち2名が精神的な疾患になったそうです。 私も最後のPJや、2年目での大炎上で病院に行ったら「鬱」 などと診断されてもおかしくはなかったかもしれないという自覚があります。 割と新人が何人もこんな状態になるような会社も世の中にはあるので、 無理せずに、親などに泣きつけるうちは泣きついて離職をしたり、頑張って転職活動を行ってダメージを最小化しましょう。 「3年は継続しろ」理論にも正しい点はあると思いますが、皆様ご自身の心身が最も重要です。

最後に転職して入職後1週程度経過しましたが、理由のほとんどは解消されているので、 皆さんもどんどんフランクに転職しましょう。

nfcpyの使い方について思ったこと

python

タグ取得時の動作について

日本国内ではtype-3タグ(いわゆるところのFelicaなど)以外のタグの入手などが難しいためか Qiitaなどに掲載されているnfcpyのサンプルコードでは、基本的にtype-3タグしか考慮していないようなコードが散見される。

nfcpyについて

nfcpyではモジュール内で状態を持っているようで、タグ取得後、それぞれのタイプに応じて別のクラスからのインスタンスが生成される。 これらの確認はpythonの組み込み関数のdir()を用いることですべて取得することができる(最近この関数を知ったが、割といろんなとこで使えるのでちゃんと覚えたいと思った次第)

先述の問題について

type-3タグしか考慮していないコードだと、不意にPixel系のスマホなどをリーダーにかざすと、読み込み対象を絞っていないときではエラー落ちしてしまう。 そのため、すべてのタグの種別にはtypeというインスタンス変数のようなものを持っているため、 このtypeをキーとした辞書型で処理を変えるなり、if文で分岐するようなコードを書いておくとモノを作る時などに問題をちゃんと考慮できる状態になるかと考えられる。

#!/usr/bin/env python
# -*- coding: utf-8 -*-
import nfc

def connected(tag):
  # IDm, PMM等を出力
  print(tag)

  if tag.type == "type3tag":
    # 内容を16進数で出力する
    print(('  ' + '\n  '.join(tag.dump())))

  else:
    print("error: tag isn't Type3Tag")

# タッチ時のハンドラを設定して待機する
clf = nfc.ContactlessFrontend('usb')
clf.connect(rdwr={'on-connect': connected})

といったような感じ。("type3tag"については業務などで触れた時のあやふやな記憶に基づいてるため、実際にコードにする際にはご自身でご確認の上実装してください)

PCがぶっ壊れた件

自作PC

最初に

先日PCがぶっ壊れました。()

症状

PC稼働させっぱなしで数日動かしてた状態で近くの自販機に飲み物を買いに行って戻ってきたら モニターが真っ暗になっていた。

試した方法

  • メモリ差し直し
  • グラボ差し直し
  • 一昼夜放置して完全放電

上記のことを試したがBIOS表示までいけなかった。 マザボにエラー情報が見れる8セグLEDがあったのでそれを監視していたところ、 CPUの初期化シーケンスなるところで初期に戻っていたようなので、 相談していた友人とともにCPUが逝ったorマザボが逝ったと判断してPCケースとストレージと電源を除いて買い替えました。

新規システムの構築

自作PC初心者だったりしましたが、無事に組めました。が、逝ったと判断したシステムと同様BIOS画面が出ない。 なので、以前のシステムから持ち越していたものを一つ一つ外して検証を開始しました。(そのため、電源も結果として購入することとなりました。)

PCケースから外してマザボを裸の状態にして、起動を試したところ正常に起動しました。

そのため、PCケースからの接続ピンを一つずつ検証しました。

結果として、RESET端子が短絡しているのか、そこを外して試したところ問題なく起動しました。

おまけ

旧系統のパーツを試したところ無事に起動しました…………＞＜

リッピングの効果について

オーディオ python

リッピングとは

オーディオ界隈ではCDの取り込みでのやり方で音に違いが出るとまことしやかに言われています。

その理由としては、通常の取り込みでは、特定ビットがドライブの不調などで読み取れなかった場合にそのデータを前後のデータから類推して補うといった処理が行われます。

この時に、補間されたデータは元のデータとはなんら関係のないものとなるため、よくないとされてます。

私も最近Exact Audio Copy(EAC)というツールを使ってCDを取り直していたので、友人から「ほんとに違うならRMSE取ってみろよ～～」と言われたのでやってみました。

 

対象とするデータ

今回は手元にあった「ゾンビランドサガ　フランシュシュ　The　Best」をもちいて実施しました。

 

コード

今回は機械学習でも用いられるRMSEを出すため、pythonを用いてコードを作成しました。

import sys
import glob
import wave
from sklearn.metrics import mean_squared_error
import numpy as np
import datetime

def get_file_list(directory):
    files = glob.glob(directory+"/*.wav")
    return files

def file2data(file_name):
    wav = wave.open(file_name)
    data = wav.readframes(wav.getnframes())
    data_array = np.frombuffer(data,dtype="int16") // 32768.0
    duration = wav.getnframes()//wav.getframerate()
    wav.close()
    return data_array,duration

args = sys.argv
if len(args)!=3:
    print("Usage")

before = get_file_list(args[1])
after = get_file_list(args[2])

for i in range(len(before)):
    print(before[i])
    true_data,time = file2data(before[i])
    pred_data,time = file2data(after[i])
    print(datetime.timedelta(seconds=time))
    print(mean_squared_error(true_data,pred_data,squared=False))
    print()

 15行目の除算を入れないとMSEの導出でなぜか負数がでてくるため、こちらのサイトを参考に除算を入れました。

結果

結果としてそれなりに誤差が出てくるのがわかりました。

最初に負数が出てきてもとりあえず無理やり絶対値にしてから平方根を取るなどした場合の考察としては、波形が大きく変化しそうな曲が誤差が大きかったため、波形が大きく変わる際にリッピングのツール次第では勝手に補正を入れてしまうことがあるのではという推察になりました。

 

また、波形が大きく変わるというのをしっかりと残すようになるため、きれいにリッピングした場合は「かっちりした音になる」といったような意見が多くみられるような効果が出るのもなんとなく理解できました。

 

もし、pythonでwavファイルを扱う場合はこういうやり方のほうが良いなどの知見をお持ちの方はコメントください。それをもとにやり直します。

RHEL系のポートフォワーディングについて

サーバ系 NW

あと数年でサポートが終わってしまいますが、CentOSでのポートフォワーディングを設定することがあったので、軽くまとめます。(きっと今後Rocky Linuxなんかで使い道が出ると考えて残します。)
他のテクノロジー系のブログでもINPUT側の記述はしてるけれど、OUTPUT側の記述をしていないことが多かったので、これらについて忘れないように備忘録とします。
環境
・CentOS7以降のRHEL系OSサーバ

firewalldとは
従来のCentOS6以前での、
ポートフォワーディングはiptablesでの設定となっており、コマンドでの実行結果は再起動後などには揮発してしまう。ファイルに設定書き込みこみすることで、揮発しない設定にすることも可能でした。ただし、iptablesでの設定では、ネットワークのリロードを行う必要があったため、ネットワークの瞬断が発生してしまっていました。
それに対して、CentOS7以降で導入されたfirewalld(firewall-cmd)では、ネットワークの瞬断を伴わないほか、その時にコマンドで設定すると、再起動時に揮発するか/揮発しないようにするかを選べたり、その時に揮発する設定でも設定をそのまま不揮発な状態にすることが可能です。

コマンド例
INPUT側でのコマンド

firewall-cmd --zone=external --add-forward-port="port=[ポート番号]:proto=tcp:toport=[ポート番号]:toaddr=[IPaddr]"

OUTPUT側でのコマンド

firewall-cmd --direct --add-rule ipv4 filter [任意文字列] 1 -m tcp -p tcp -dport [ポート番号] -d [IPアドレス] -j ACCEPT

ランタイムの設定を不揮発にする。

firewall-cmd --runtime-to-permanent 


以上のコマンドの感じでできるはずです。